This dimension governs the detection, remediation, and ongoing monitoring of proxy variable leakage — the phenomenon by which features that appear facially neutral in insurance, credit, and lending models encode, approximate, or statistically reconstruct protected attributes such as race, national origin, sex, religion, disability status, or familial status. Proxy leakage is the primary mechanism by which algorithmic systems evade anti-discrimination law while perpetuating structurally discriminatory outcomes, making it the central technical vulnerability in consumer-finance AI deployment. Failure manifests as a model that passes surface-level protected-class exclusion checks while producing premium differentials, credit denials, or loan pricing that systematically disadvantage protected groups at rates indistinguishable from intentional discrimination, resulting in regulatory enforcement, private litigation, reputational collapse, and direct financial harm to consumers.
A regional auto insurer deploys a telematics-augmented pricing model using 47 input features. Protected attributes — race, national origin, religion — are explicitly excluded from the feature set and the exclusion is documented. The model incorporates three postal geography features: five-digit ZIP code encoded as a continuous numeric variable, a derived "claims density index" constructed from historical loss ratios by ZIP, and a "credit utilisation tier" variable sourced from a bureau feed. Post-deployment disparate impact testing conducted eighteen months after launch reveals that Black policyholders in majority-Black ZIP codes pay a mean premium surcharge of USD 847 annually compared to otherwise-equivalent white policyholders in majority-white ZIP codes. Causal attribution analysis establishes that 71% of this differential is driven by the claims density index, which has a Pearson correlation of 0.83 with tract-level racial composition from census data. The ZIP code numeric encoding and credit utilisation tier account for a further 19% of the differential through intersecting correlations with income and residential segregation patterns. The insurer had no proxy detection protocol in place; the model validation team had reviewed only direct protected-attribute inclusion. State insurance regulators open a market conduct examination, issue a corrective action order requiring prospective repricing for approximately 340,000 affected policyholders, and refer the matter to the state attorney general for potential Consumer Protection Act action. Estimated remediation cost including refunds, model redevelopment, and regulatory response: USD 23 million.
A fintech lender offering working-capital loans to small businesses trains a gradient-boosted model on 130 features including transaction categorisation clusters derived from open-banking feeds. One cluster — labelled "ethnic grocery and specialty food retail" in the underlying merchant category taxonomy — is retained as a feature because it shows a raw correlation of 0.14 with 90-day default in the training set. Independently, this cluster has a point-biserial correlation of 0.61 with borrower self-identified Hispanic or Latino ethnicity, documented in a separate CRA dataset used during training data assembly but not reviewed during feature selection. The model is deployed and originates approximately 12,000 loans over nine months. An HMDA-equivalent analysis conducted by a consumer advocacy organisation finds that Hispanic-owned businesses are denied at 2.3× the rate of non-Hispanic white-owned businesses with equivalent debt-service coverage ratios and revenue histories. The feature's discriminatory loading is identified through Shapley-value decomposition. The lender's failure to conduct proxy screening during feature selection is cited by the Consumer Financial Protection Bureau in a supervisory finding. The lender is required to remediate 1,847 individual loan decisions, offer reconsideration at original pricing, and implement a proxy-variable governance programme under a supervisory agreement. Civil money penalty: USD 4.2 million.
A life insurer operating across seven EU member states implements an AI-assisted underwriting assistant that ingests customer portal interaction data. A feature engineer introduces a binary "non-English primary language preference" flag derived from portal language selection, reasoning that it is a neutral operational variable with no protected-class association. In fact, within the insurer's customer base, this flag correlates at 0.54 with female sex (driven by a disproportionate share of non-English female policyholders from specific diaspora communities) and at 0.67 with Muslim religious affiliation (inferred from downstream surname and address analysis in an external enrichment dataset). The underwriting model assigns higher manual review queuing rates — effectively creating a soft denial pathway — to applicants flagged as non-English primary. Across three policy years, 6,300 applicants in this group experience underwriting delays of 14 days or more versus a mean of 2.1 days for the comparison population, with a conversion-to-issuance rate 22 percentage points lower. Under the EU AI Act Article 10 data governance requirements and the national transpositions of the Equal Treatment Directive, the insurer faces simultaneous regulatory inquiries in Germany and the Netherlands. The AI system is classified as high-risk under Annex III and placed under enhanced scrutiny. The insurer commissions an independent algorithmic audit at a cost of EUR 1.8 million and is required to withdraw the language-preference feature, retrain the model, and notify all affected applicants of their right to human review.
This dimension applies to any AI agent, automated decision system, machine learning model, or rules-based scoring system that generates, contributes to, or informs an underwriting decision, credit origination decision, credit pricing decision, claims triage or payment decision, insurance premium calculation, risk tier assignment, or adverse action in the Insurance, Credit and Lending landscape. It applies regardless of whether the system operates as a primary decision engine or as a feature-generation, data-enrichment, or recommendation sub-component feeding a downstream decisioning system. It applies at all stages of the model lifecycle: feature selection, model training, validation, deployment, monitoring, and scheduled redevelopment. Cross-border agents operating across multiple jurisdictions must satisfy the requirements of the most restrictive applicable jurisdiction unless explicitly noted otherwise.
4.1.1 The deploying organisation MUST maintain a documented Proxy Identification Protocol (PIP) that defines the methodology for detecting statistical associations between candidate features and protected attributes prior to model deployment.
4.1.2 The PIP MUST specify, at minimum: the statistical measures used for proxy detection (including correlation coefficients, mutual information scores, and conditional dependence metrics); the protected attributes to be tested against (covering at minimum race, colour, national origin, sex, religion, familial status, disability status, age, and marital status, or equivalent protected classes under applicable jurisdiction); the threshold values above which a feature is deemed a proxy candidate requiring remediation review; and the governance authority responsible for adjudicating proxy candidates.
4.1.3 The PIP MUST be reviewed and re-approved by the model risk governance authority at intervals not exceeding twelve months or upon any material change to the applicable regulatory framework, whichever is sooner.
4.1.4 The PIP SHOULD incorporate intersectional proxy testing that evaluates feature associations with combinations of protected attributes, not only individual attributes in isolation.
4.1.5 The organisation MAY supplement statistical proxy detection with domain-expert structured review panels that assess features for plausible causal pathways to protected-attribute approximation.
4.2.1 Every feature proposed for inclusion in a covered system MUST undergo proxy screening under the PIP before the feature is included in any model trained on production or production-representative data.
4.2.2 Proxy screening MUST be conducted against a reference dataset that is representative of the intended deployment population in terms of geographic, demographic, and temporal coverage. The reference dataset characteristics MUST be documented.
4.2.3 For any feature for which a proxy association score meets or exceeds the threshold defined in the PIP, a written Proxy Candidate Assessment (PCA) MUST be produced prior to deployment. The PCA MUST document: the specific protected attributes with which the feature is associated; the magnitude and type of association; the proposed disposition (exclude, transform, retain with monitoring, or retain with documented business necessity justification); and the name and title of the approving authority.
4.2.4 Features retained after a PCA on business necessity grounds MUST have their retention re-evaluated at every scheduled model review cycle and whenever the model's disparate impact profile materially changes.
4.2.5 The organisation SHOULD maintain a feature registry that records the proxy screening history, PCA status, and current deployment status of every feature ever evaluated for a covered system.
4.3.1 The organisation MUST apply proxy screening to derived, engineered, and aggregated features — including interaction terms, polynomial features, cluster membership labels, embedding representations, and dimensionality-reduced projections — not only to raw input variables.
4.3.2 Where a model ingests third-party data feeds, enrichment datasets, or bureau scores, the organisation MUST conduct proxy screening on the received features and MUST NOT rely solely on the data vendor's representations regarding protected-attribute associations.
4.3.3 For embedding-based or high-dimensional representation features, the organisation MUST use reconstruction-based proxy tests — such as training a classifier to predict protected-attribute membership from the representation — as part of the proxy screening methodology.
4.3.4 The organisation MUST document the provenance of every external feature, including the data vendor, the feature construction methodology as understood by the organisation, and the results of proxy screening applied to that feature.
4.3.5 The organisation SHOULD re-screen external features whenever the data vendor issues material updates to their feature construction methodology or underlying data sources.
4.4.1 Beyond feature-level screening, the organisation MUST conduct model-level proxy leakage testing to assess whether the trained model as a whole — including interactions learned during training — reconstructs or amplifies proxy associations that were not detectable at the individual-feature level.
4.4.2 Model-level proxy leakage testing MUST include: disparate impact ratio analysis disaggregated by protected class across all material decision outcomes; Shapley or equivalent attribution analysis identifying the contribution of each feature to protected-group outcome differentials; and at least one reconstruction test that trains a secondary classifier to predict protected-attribute group membership from model output scores.
4.4.3 Model-level proxy leakage testing MUST be completed and results documented before any covered system is approved for production deployment.
4.4.4 Where model-level testing reveals leakage not detectable at the feature level, the organisation MUST investigate the source of the leakage, update the PIP to incorporate detection methods capable of identifying such leakage, and either remediate the model or document a risk-accepted disposition with executive approval.
4.4.5 The organisation SHOULD conduct model-level proxy leakage testing on an ongoing basis at intervals not exceeding six months during production operation, and upon any material change to the model, its training data, or the population it serves.
4.5.1 Where a proxy feature or model-level leakage is identified and remediation is required, the organisation MUST implement one or more of the following remediation approaches and document the choice: feature exclusion; feature transformation to reduce proxy association while preserving legitimate predictive signal; regularisation or constraint-based training modifications; post-processing output calibration; or model redevelopment.
4.5.2 After remediation, the organisation MUST re-run both feature-level proxy screening and model-level proxy leakage testing and MUST confirm that proxy associations have been reduced to below applicable thresholds before the remediated model is deployed.
4.5.3 Where retrospective analysis identifies that a deployed model has been operating with proxy leakage, the organisation MUST conduct a look-back impact assessment covering at minimum the full period of deployment to identify consumers who may have received adverse or less favourable decisions attributable to the proxy association.
4.5.4 Look-back impact assessments MUST be completed within ninety days of identification of the proxy leakage event unless a longer period is approved in writing by the governing regulatory authority.
4.5.5 The organisation SHOULD establish a consumer remediation programme for cases where look-back analysis identifies material adverse impact, including mechanisms for decision reconsideration and, where appropriate, financial remediation.
4.6.1 The organisation MUST maintain a continuous monitoring programme that tracks the disparate impact profile of every covered system in production at intervals not exceeding ninety days.
4.6.2 The monitoring programme MUST define quantitative alert thresholds that trigger escalation to the model risk governance authority, including at minimum: a disparate impact ratio falling below 0.80 on the four-fifths rule or equivalent jurisdiction-specific threshold; a statistically significant shift in any protected group's outcome distribution relative to the baseline established at deployment; and a material increase in the proxy association score of any retained feature computed on production data.
4.6.3 Alert events MUST be documented, assigned to a named owner, and resolved or escalated within thirty calendar days of the alert trigger date.
4.6.4 The organisation MUST retain monitoring results, alert records, and resolution documentation for a minimum of five years or such longer period as required by applicable regulation.
4.6.5 The organisation SHOULD implement automated data pipeline monitoring that detects upstream changes to input features — including changes introduced by third-party data vendors — and triggers re-screening when such changes are detected.
4.7.1 The organisation MUST designate a named individual or committee with documented accountability for the proxy variable governance programme, including authority to approve or reject feature deployments and model deployments on proxy grounds.
4.7.2 The designated governance authority MUST include or have direct access to expertise in statistical fairness methods, the applicable regulatory framework, and the business domain of the covered system.
4.7.3 The organisation MUST maintain a Proxy Variable Governance Log (PVGL) that records every proxy candidate identified, every PCA produced, every disposition decision made, every monitoring alert triggered, and every remediation action taken, with timestamps and named approvers.
4.7.4 The PVGL MUST be available to internal audit, model risk management, compliance, and — upon lawful request — external regulators without delay.
4.7.5 The organisation SHOULD conduct an independent review of the proxy variable governance programme at intervals not exceeding twenty-four months, conducted by parties organisationally independent of the teams responsible for model development.
4.8.1 For agents operating across multiple jurisdictions, the organisation MUST identify all applicable anti-discrimination and algorithmic fairness obligations in each jurisdiction and document how the proxy governance programme satisfies each.
4.8.2 Where jurisdictions define protected classes differently, the organisation MUST apply proxy screening against the union of all protected classes applicable across all deployment jurisdictions.
4.8.3 The organisation MUST NOT deploy a feature configuration that complies with the proxy governance requirements of a less restrictive jurisdiction but fails the requirements of a more restrictive jurisdiction in which the system also operates, unless the system architecture physically segregates the feature configurations by jurisdiction and the segregation is auditable.
4.8.4 The organisation SHOULD monitor the evolution of proxy governance regulations across all deployment jurisdictions and proactively update the PIP to reflect regulatory developments before they become binding obligations.
4.9.1 The organisation MUST be able to produce, upon request by a regulator or in response to a consumer adverse action inquiry, a plain-language explanation of why a feature is included in a covered system that does not reference any proxy-associated variable as a direct justification for an adverse outcome.
4.9.2 Where an adverse action notice is required by applicable regulation, the organisation MUST ensure that the reasons stated in the adverse action notice are not derived from features that have been identified as proxy candidates and retained only on business necessity grounds, without disclosing the proxy association in the notice.
4.9.3 The organisation SHOULD publish an annual summary of its proxy variable governance activities, including the number of features screened, the number of proxy candidates identified, the number of features excluded or transformed, and the results of disparate impact monitoring, at the level of granularity permitted by applicable confidentiality obligations.
Proxy variable leakage is not a peripheral technical artefact — it is the primary mechanism by which facially neutral algorithmic systems perpetuate the discriminatory patterns embedded in historical data. In insurance and lending markets, decades of redlining, discriminatory underwriting practices, differential access to credit, and residential segregation have produced training datasets in which geography, financial behaviour, consumer purchasing patterns, and even communication preferences are deeply correlated with race, national origin, and other protected characteristics. A model trained to optimise predictive accuracy on such data will, absent deliberate intervention, learn to exploit these correlations. The model does not need to include a field labelled "race" to behave in a racially discriminatory manner; it needs only to include ZIP code, credit utilisation history, merchant category spend, or any of hundreds of other features that partially reconstruct protected-class membership from observable economic behaviour.
The standard industry response of excluding protected attributes from model inputs — so-called "fairness through unawareness" — is structurally inadequate in high-dimensional feature environments. Theoretical work in algorithmic fairness, confirmed by empirical studies of deployed financial models, demonstrates that the information content of protected attributes can be reconstructed to substantial accuracy from as few as three to five routinely available financial features. This means that a model can operate as a de facto discriminatory classifier even when every individual feature passes a naive proxy check, because the model learns to combine features whose individual associations with protected attributes are sub-threshold but whose joint information content is highly discriminatory. Section 4.4's requirement for model-level proxy leakage testing addresses precisely this failure mode.
Purely behavioural controls — policies, training, attestations — are insufficient in this domain because the proxy leakage mechanism is structural: it emerges from the mathematical properties of the model and its training data, not from the intentions of the humans who built it. The preventive control classification of this dimension reflects the consensus that remediation after deployment is significantly more costly — to consumers, to the organisation, and to public trust in AI-assisted finance — than detection and prevention prior to deployment. The governance requirements in Sections 4.1 through 4.4 are designed to create structural barriers that must be traversed before a proxy-contaminated model can reach production. The monitoring requirements in Section 4.6 acknowledge that proxy associations can emerge or intensify over time as populations, data distributions, and upstream feature sources evolve.
This dimension is classified Enhanced rather than Foundational because effective proxy governance requires capabilities — statistical fairness testing, attribution analysis, reconstruction classifiers, disparate impact monitoring infrastructure — that go materially beyond baseline model development hygiene. Organisations deploying AI in consumer finance at scale are expected to have these capabilities institutionalised; the Enhanced tier reflects the technical and organisational investment required and the severity of the harm that the control prevents.
Pattern 1 — Pre-Commit Feature Screening Gate. Implement proxy screening as a mandatory gate in the model development pipeline that must be cleared before any feature is permitted to enter the model training environment. This is analogous to security scanning in software continuous integration: the check is automated, the results are logged, and a failed check requires human adjudication before proceeding. Statistical screening should run correlation, mutual information, and conditional independence tests in parallel, with results aggregated into a per-feature proxy risk score. Features scoring above a configurable threshold are automatically flagged and routed to a human review queue.
Pattern 2 — Layered Proxy Detection Approach. No single statistical measure is sufficient for all types of proxy leakage. A robust programme combines: (a) pairwise correlation measures (Pearson, Spearman, Cramér's V depending on feature type) for simple linear associations; (b) mutual information estimation for non-linear associations; (c) conditional independence testing that assesses whether a feature provides information about a protected attribute after controlling for legitimate risk factors; and (d) reconstruction classifiers — logistic regression or gradient-boosted classifiers trained to predict protected-attribute membership from feature values — for detecting leakage that is distributed across feature combinations.
Pattern 3 — Fairness-Constrained Training. For high-risk models where feature exclusion would materially impair predictive performance, consider incorporating fairness constraints directly into the training objective. Techniques such as adversarial debiasing, reweighting of training instances, and in-processing constraint optimisation can reduce proxy leakage while retaining legitimate predictive signal. Any such technique must be validated for effectiveness through the same model-level proxy leakage tests specified in Section 4.4.
Pattern 4 — Periodic Reconstitution Testing. On a rolling basis, train reconstruction classifiers on production model output scores against externally sourced protected-attribute proxies (e.g., Bayesian Improved Surname Geocoding (BISG) race estimates, geographic racial composition data). A reconstruction classifier that achieves area under the ROC curve substantially above 0.50 is evidence that the model output encodes protected-class information. This test should be run at each monitoring cycle.
Pattern 5 — Vendor Feature Due Diligence Protocol. For every third-party data feed, require the vendor to provide: a feature data dictionary with construction methodology; results of their own proxy screening (if available); and a contractual representation regarding material changes. Conduct independent proxy screening on every vendor-supplied feature regardless of vendor representations. Establish contractual rights to receive notification of upstream changes to feature construction.
Pattern 6 — Subgroup Interaction Mapping. Maintain a subgroup interaction map that documents, for each feature in the model, its known or suspected associations with protected attributes and the economic mechanism by which those associations arise. This map serves as institutional memory that survives personnel turnover and informs future feature evaluation.
Anti-Pattern 1 — Protected-Attribute Exclusion as Sole Control. Excluding race, sex, national origin, and other protected attributes from the feature set and treating this as a complete anti-discrimination control. As discussed in Section 5, this approach is structurally insufficient in high-dimensional environments and will not withstand regulatory scrutiny.
Anti-Pattern 2 — Proxy Screening Only at Initial Deployment. Conducting proxy screening at model launch but not re-screening when training data is refreshed, when new features are added, when the model is retrained on new cohorts, or when upstream data sources change. Proxy associations are not static; they evolve with changes in the underlying population and data infrastructure.
Anti-Pattern 3 — Threshold Shopping. Setting proxy association thresholds at levels calibrated to exclude as few features as possible rather than levels calibrated to the risk of harm to protected groups. Threshold selection must be documented and justified on principled grounds, and must be reviewed by governance authorities independent of the model development team.
Anti-Pattern 4 — Delegating Proxy Governance to Data Vendors. Accepting vendor attestations that a data product is "bias-free" or "fair" without independent screening. Vendors have commercial incentives that are not aligned with regulatory compliance obligations of the deploying organisation, and vendor-conducted testing may use different methodologies, different reference populations, or different protected-attribute definitions than required by the deploying organisation's obligations.
Anti-Pattern 5 — Treating Disparate Impact as Proof of Absence of Proxy Leakage. Concluding that because overall disparate impact metrics are within regulatory safe-harbour thresholds, proxy leakage is not present. Disparate impact ratios can appear compliant at the aggregate level while masking severe sub-group disparities at the intersection of protected attributes. Section 4.1.4's SHOULD for intersectional testing addresses this risk.
Anti-Pattern 6 — Undocumented Business Necessity Retention. Retaining a feature with a known proxy association on informal business necessity grounds without producing a written PCA with executive approval, quantitative justification, and a plan for ongoing re-evaluation. Business necessity is a recognised legal defence in discrimination law, but only when it is documented, proportionate, and the subject of genuine inquiry into whether less discriminatory alternatives exist.
| Maturity Level | Characteristics |
|---|---|
| Level 1 — Absent | No proxy screening programme. Protected-attribute exclusion treated as complete control. No disparate impact monitoring. |
| Level 2 — Reactive | Proxy screening conducted in response to regulatory findings or litigation. No systematic pre-deployment process. |
| Level 3 — Defined | PIP documented. Pre-deployment screening conducted on raw features. Basic disparate impact monitoring in place. |
| Level 4 — Managed | Layered screening including derived features and model-level testing. Feature registry maintained. Monitoring with quantitative thresholds and alert management. |
| Level 5 — Optimised | Automated screening gate in development pipeline. Continuous monitoring with real-time alert capability. Independent review conducted. Third-party vendor due diligence protocol active. Intersectional testing standard. |
Organisations subject to this dimension at Enhanced tier are expected to operate at Level 4 or above within twenty-four months of initial deployment of a covered system.
| Artefact | Description | Retention Period |
|---|---|---|
| Proxy Identification Protocol (PIP) | Current approved version and all prior versions with change history | 7 years from supersession |
| Feature Registry | Complete record of every feature evaluated, screening results, and current deployment status | Duration of system operation plus 7 years |
| Proxy Candidate Assessments (PCAs) | Written assessments for every feature meeting or exceeding proxy threshold, including disposition decisions and approver identities | 7 years from creation |
| Model-Level Proxy Leakage Test Results | Full results of pre-deployment and periodic model-level proxy testing, including test methodology, datasets used, and findings | 7 years from creation |
| Proxy Variable Governance Log (PVGL) | Chronological record of all governance actions, approvals, alerts, and escalations | 7 years from creation |
| Disparate Impact Monitoring Reports | Periodic monitoring results including statistical outputs, alert triggers, and resolution records | 7 years from creation |
| Look-Back Impact Assessments | Methodology, scope, findings, and consumer remediation actions | 10 years from creation |
| Third-Party Data Due Diligence Records | Vendor communications, independent screening results, contractual representations | Duration of vendor relationship plus 7 years |
| Independent Review Reports | Reports from organisationally independent review activities | 7 years from creation |
| Cross-Border Jurisdiction Mapping | Documentation of applicable obligations by jurisdiction and mapping to programme controls | Duration of deployment plus 7 years |
All artefacts must be: (a) dated and version-controlled; (b) attributable to named authors and approvers; (c) stored in a system that preserves integrity and supports audit trail requirements; (d) accessible to internal audit and model risk management without requiring model development team involvement; and (e) available for production to external regulators within five business days of a lawful request unless a shorter period is specified by the requesting authority.
For EU AI Act high-risk system classification, technical documentation required under Article 11 must incorporate or reference the PIP, feature registry, and model-level proxy leakage test results. For ECOA and FCRA regulated entities in the United States, adverse action documentation must be traceable to the PVGL to confirm that adverse action reasons are free from proxy-contaminated feature attribution. For PRA/FCA regulated entities in the United Kingdom, SR Model Risk Management expectations require that model validation reports reference proxy governance findings.
Maps to: 4.1.1, 4.1.2, 4.1.3
Objective: Verify that the organisation maintains a complete, current, and approved PIP that meets minimum content requirements.
Method: Obtain the current PIP. Assess against a checklist covering: statistical measures specified; protected attributes enumerated; threshold values defined; governance authority identified; last approval date; approval authority name and role. Verify that the last approval date is within twelve months or that no material regulatory change has occurred since the prior approval.
Scoring:
| Score | Criteria |
|---|---|
| 3 — Fully Conformant | PIP exists, covers all required elements, approved within twelve months, by named governance authority |
| 2 — Largely Conformant | PIP exists and covers most required elements; minor gaps in one area (e.g., intersectional testing not addressed) or approval slightly overdue |
| 1 — Partially Conformant | PIP exists but missing material elements (e.g., no threshold values defined, or protected-attribute list omits material classes) |
| 0 — Non-Conformant | No PIP exists, or PIP so incomplete as to provide no meaningful governance framework |
Maps to: 4.2.1, 4.2.2, 4.2.3, 4.3.1, 4.3.2, 4.3.3
Objective: Verify that every feature in a sampled covered system underwent proxy screening before deployment, including derived and third-party features.
Method: Select a covered system currently in production. Obtain the complete feature list from the feature registry. For a random sample of 20 features (or all features if fewer than 20), verify: (a) screening results are present in the feature registry; (b) screening was conducted against a documented reference dataset; (c) for features meeting threshold, a PCA is present with required content; (d) derived and engineered features are included in the screening record, not only raw inputs; (e) third-party features have independent screening records separate from vendor representations.
Scoring:
| Score | Criteria |
|---|---|
| 3 — Fully Conformant | 100% of sampled features have complete screening records; derived and third-party features included; PCAs present and complete for all threshold-meeting features |
| 2 — Largely Conformant | ≥90% of sampled features have complete records; minor documentation gaps; no evidence of systematic omission of derived or third-party features |
| 1 — Partially Conformant | 70–89% coverage, or systematic omission of one category (e.g., all third-party features lack independent screening) |
| 0 — Non-Conformant | <70% coverage, or no screening conducted on derived features, or proxy screening programme does not exist in practice |
Maps to: 4.4.1, 4.4.2, 4.4.3, 4.4.4
Objective: Verify that model-level proxy leakage testing was conducted prior to deployment and meets minimum methodological requirements.
Method: Obtain the model-level proxy leakage test results for the sampled covered system. Assess: (a) whether the test was completed before production deployment (check dates against deployment records); (b) whether the test includes disparate impact ratio analysis across all required protected classes; (c) whether Shapley or equivalent attribution analysis is present; (d) whether at least one reconstruction classifier test is documented; (e) where leakage was identified above feature-level, whether the source investigation and disposition are documented.
Scoring:
| Score | Criteria |
|---|---|
| 3 — Fully Conformant | All four methodological components present; testing completed pre-deployment; findings and dispositions documented |
| 2 — Largely Conformant | Three of four components present; or minor timing gap (testing completed within 30 days post-deployment); dispositions documented |
| 1 — Partially Conformant | Only disparate impact ratio analysis conducted; no reconstruction classifier test; or testing conducted post-deployment without documented justification |
| 0 — Non-Conformant | No model-level proxy leakage testing conducted; or testing conducted only at feature level |
Maps to: 4.6.1, 4.6.2, 4.6.3, 4.6.4
Objective: Verify that the continuous monitoring programme is operational, producing results at required intervals, and that alert events are managed within required timeframes.
Method: For the sampled covered system, obtain monitoring reports for the preceding twelve months. Assess: (a) whether reports are produced at intervals not exceeding ninety days; (b) whether each report includes disparate impact ratio analysis and proxy association scores for retained proxy-candidate features; (c) whether alert thresholds are defined and documented; (d) for any alert events in the period, verify that each has a named owner, a resolution record, and that the resolution date is within thirty calendar days of the trigger date; (e) verify that monitoring records are retained and accessible.
Scoring:
| Score | Criteria |
|---|---|
| 3 — Fully Conformant | Reports produced at ≤90-day intervals; all required metrics present; all alert events resolved within 30 days; complete retention |
| 2 — Largely
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Supports compliance |
| NIST AI RMF | GOVERN 1.1, MAP 3.2, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
Article 9 requires providers of high-risk AI systems to establish and maintain a risk management system that identifies, analyses, estimates, and evaluates risks. Proxy Variable Leakage Governance implements a specific risk mitigation measure within this framework. The regulation requires that risks be mitigated "as far as technically feasible" using appropriate risk management measures. For deployments classified as high-risk under Annex III, compliance with AG-625 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
Section 404 requires management to assess the effectiveness of internal controls over financial reporting. For AI agents operating in financial contexts, AG-625 (Proxy Variable Leakage Governance) implements a governance control that auditors can evaluate as part of the internal control framework. The control must be documented, tested on a defined schedule, and test results retained.
GOVERN 1.1 addresses legal and regulatory requirements; MAP 3.2 addresses risk context mapping; MANAGE 2.2 addresses risk mitigation through enforceable controls. AG-625 supports compliance by establishing structural governance boundaries that implement the framework's approach to AI risk management.
Clause 6.1 requires organisations to determine actions to address risks and opportunities within the AI management system. Clause 8.2 requires AI risk assessment. Proxy Variable Leakage Governance implements a risk treatment control within the AI management system, directly satisfying the requirement for structured risk mitigation.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Business-unit level — affects the deploying team and downstream consumers of agent outputs |
| Escalation Path | Senior management notification within 24 hours; regulatory disclosure assessment within 72 hours |
Consequence chain: Failure of proxy variable leakage governance creates significant operational risk within the agent deployment. The absence of this control allows agent behaviour to deviate from governance intent in ways that may not be immediately visible but accumulate material exposure over time. The impact extends beyond the immediate deployment to affect downstream consumers of agent outputs, stakeholder trust, and regulatory standing. Detection of the failure may be delayed, increasing the remediation scope and cost. Regulatory consequences may include supervisory findings, required corrective actions, and increased scrutiny of the organisation's AI governance programme.