(The following scenario is a composite illustration drawn from common patterns at regulated institutions; it does not describe a specific bank or event.) In the summer of 2025, a $4 billion regional bank's model risk team began reviewing the inputs to its consumer credit scoring model following a routine validation cycle. What they found stopped the review: the model had been retrained on a dataset that included zip-code-level purchase behavior data sourced from a data broker. The broker's data had been combined with the bank's own account history and enriched with credit bureau attributes. No one at the bank had mapped the full provenance of the training data. No one had assessed whether the zip-code purchase data was a proxy for race or ethnicity. No one had obtained customers' consent for the use of their transaction data in model training beyond the terms in the original account agreement. The model was performing well on every accuracy metric. But it sat on a data foundation that was legally indefensible, empirically unauditable, and potentially discriminatory. The validation stopped. The deployment was paused. The remediation took fourteen months. The lesson from that fourteen-month pause is this: the quality of an AI model is bounded by the quality of the data it was built on. And the defensibility of a model under OCC Bulletin 2026-13, under the Equal Credit Opportunity Act (ECOA, the federal statute governing fair lending in credit decisions), and under the Gramm-Leach-Bliley Act (GLBA, the federal law governing financial institutions' obligations to protect customer financial information) is bounded by the data governance and privacy controls that governed the data before it reached the model.

Data Governance as the Foundation for Defensible AI

Data governance is the framework of policies, processes, roles, and standards that govern how an institution collects, stores, uses, shares, and retires data. For AI models, data governance is not an upstream IT concern that the model development team inherits as a background condition. It is a prerequisite for model defensibility, and under OCC Bulletin 2026-13 (the April 2026 interagency model-risk update issued jointly by the OCC (Office of the Comptroller of the Currency), the Federal Reserve, and the FDIC (Federal Deposit Insurance Corporation), which superseded OCC Bulletin 2011-12 and pulled AI under model risk, fair-lending, third-party, and board governance), it is an obligation the institution must demonstrate it has met before a model can be validated.

The validation requirement under OCC 2026-13 includes a data quality assessment: a documented evaluation of the data sources used in model development, the period of data used for training and testing, any data cleaning or preprocessing steps applied, and an assessment of whether the training data is representative of the model's intended deployment population. This is not a technical formality. It is a governance record that answers the examiner's question: "How do you know the data this model was trained on was appropriate for this use case and consistent with the bank's legal obligations?"

An institution that cannot answer that question has a data governance gap at the base of its model risk program. The gap may not be visible in the model's performance metrics. A model trained on legally problematic data may perform well on accuracy measures while producing disparate impact on protected classes, using input variables that function as proxies for protected characteristics, or relying on data that was collected or used in ways that violate the bank's regulatory obligations. The fourteen-month remediation in the scenario above was not caused by a bad model. It was caused by a data governance failure that the model's accuracy metrics did not reveal.

Data governance for AI in a regulated bank has three operational foundations. The first is data lineage: the institution must be able to trace every feature used in a model from its ultimate source through every transformation to its use as a model input. Without lineage, the institution cannot assess whether a feature carries proxy risk, cannot evaluate whether the data was collected appropriately, and cannot respond to an examiner's request to explain what the model's inputs actually represent. The second is data quality management: the institution must have standards for the accuracy, completeness, and representativeness of training data, with a documented process for identifying and remediating data quality issues before model development proceeds. The third is data classification: the institution must know what type of data each element is (whether it is PII (personally identifiable information), non-public personal information (NPPI), transaction data, public data, or derived data), so that the appropriate use restrictions, consent requirements, and retention obligations can be applied.

GLBA and the Privacy Obligations for AI Training Data

The Gramm-Leach-Bliley Act (GLBA) governs financial institutions' collection, use, and disclosure of customer financial information. The GLBA's privacy provisions are implemented by Regulation P, which requires financial institutions to provide customers with notice of their information-sharing practices and, in some cases, to provide customers the ability to opt out of certain information sharing. The GLBA's safeguards provisions, implemented by the FTC Safeguards Rule (updated in 2021 and effective in 2023), require financial institutions to implement a written information security program with specific administrative, technical, and physical safeguards designed to protect the security, confidentiality, and integrity of customer financial data.

For AI model training, the GLBA creates three specific obligations that the data governance framework must address.

First, the use limitation obligation. GLBA and Regulation P restrict financial institutions' use of customer financial information to purposes consistent with the customer relationship and the institution's privacy notice. Using customer transaction data, account history, or financial attributes to train an AI model is a use of non-public personal information (NPPI) that must be consistent with the bank's privacy notice and the customer's reasonable expectations of the customer relationship. A bank that trains a credit scoring model on customers' deposit transaction patterns, for example, is using NPPI for a purpose that may not be within the original account agreement's scope, depending on how the privacy notice was drafted. The data governance framework must include a review of proposed AI training data sources against the bank's current privacy notice and the applicable GLBA use restrictions before training data is assembled.

Second, the safeguards obligation. GLBA requires the institution to implement administrative, technical, and physical safeguards designed to protect the security, confidentiality, and integrity of customer financial information. For AI training data, this means the data used in model development must be handled under the same security and access controls as other sensitive customer data. A common governance gap occurs when model development teams maintain training datasets in development environments with weaker access controls than the production environment. The safeguards obligation applies regardless of the data's environment: a training dataset containing customer account information is subject to GLBA's safeguards requirements whether it is in a production database or a data scientist's development workspace.

Third, the disclosure and transfer restrictions. GLBA restricts the disclosure of customer financial information to non-affiliated third parties. When a bank uses a vendor AI platform that processes training data, there is a potential GLBA disclosure issue: is the bank's customer financial data being transferred to the vendor's servers, processed by the vendor's systems, and potentially accessible to vendor personnel? The data governance framework must assess every AI vendor that processes training data or receives model inputs containing customer financial information for GLBA compliance, and the vendor contract must include appropriate data use restrictions and safeguards commitments.

Proxy Variables and the Fair-Lending Data Governance Obligation

Fair-lending law, including ECOA (Equal Credit Opportunity Act) and Regulation B (12 CFR Part 1002, issued by the CFPB, which implements ECOA and prohibits discrimination in credit transactions based on protected characteristics including race, color, religion, national origin, sex, marital status, and age), prohibits discrimination in credit decisions. Under the disparate impact doctrine, a credit model can violate the fair-lending laws even if no protected characteristic is used as an input, if the model produces disparate impact on a protected class and there is no less-discriminatory alternative that achieves comparable business objectives with less disparity.

The data governance implication of disparate impact is the proxy variable problem. A proxy variable is a feature that is facially neutral (not a protected characteristic) but that is highly correlated with a protected characteristic in the institution's applicant population. Zip code is a well-known proxy for race and ethnicity in lending. Certain purchase behavior categories (grocery store type, restaurant type, retail spending patterns) correlate with demographic characteristics at the census-tract level. Credit utilization patterns differ significantly by income cohort in ways that interact with race. A model that uses any of these features can produce disparate impact on protected classes even though the features themselves are not protected characteristics and may have genuine predictive power.

The data governance framework must address proxy variable risk before model development, not as a post-hoc check after the model has been trained and evaluated. The pre-development review must include: a proxy correlation analysis for every proposed feature, assessing the feature's correlation with race and ethnicity proxies (using BISG (Bayesian Improved Surname and Geocoding, the proxy estimation method combining surname and census data to estimate race and ethnicity) estimates for consumer lending or HMDA (Home Mortgage Disclosure Act) data for mortgage lending); a documentation of the feature's legitimate business purpose and predictive rationale; an assessment of whether the feature's predictive value can be replicated by a less-proxy-correlated alternative; and a governance decision about whether the feature's inclusion is appropriate given its proxy correlation and the institution's fair-lending risk appetite.

The proxy variable review is not a veto over every feature with any correlation to a demographic variable. Virtually every credit variable has some correlation with demographic characteristics because creditworthiness correlates with economic circumstances that are not uniformly distributed across demographic groups. The governance obligation is proportionality: the institution must be able to document that a feature with material proxy correlation was evaluated against alternatives and that its inclusion represents the least-discriminatory way to achieve the model's legitimate business objective. The absence of documentation of this evaluation is itself a fair-lending governance gap, regardless of whether the model's outcomes show disparate impact.

Data Lineage, Documentation, and the Audit Trail

Data lineage is the documented record of a data element's origin, transformation, and use. For an AI credit model, the lineage of each training feature must document: the original data source (the institution's own records, a credit bureau, a data broker, a government database); the conditions under which the data was collected or obtained (what consent or disclosure was provided to the consumer, what contractual terms govern the institution's use of the data from a credit bureau or broker); the transformations applied to the raw data before it became a model feature (aggregation, normalization, imputation of missing values, combination with other data sources); and the governance approvals obtained for each stage of the transformation pipeline.

This documentation requirement is the reason the bank in the opening scenario faced a fourteen-month remediation rather than a short-cycle correction. The zip-code purchase behavior data from the data broker had been combined with bureau data in a multi-step transformation pipeline. The original data broker agreement had not been reviewed for AI use consistency. The combined feature had not been assessed for proxy correlation. The consent records for the transaction data used in the combination could not be matched to the customers in the training set. Rebuilding the lineage documentation, assessing each step for legal compliance, and rebuilding the feature set from a defensible data foundation required the full fourteen months.

The practical implication is that data lineage documentation must be built as data is collected, transformed, and used, not reconstructed after the fact when a validation or examination requires it. A data governance program that requires lineage documentation to be retroactively assembled from system logs, data transfer records, and vendor agreements is a program that creates examination-time risk rather than eliminating it. The standard for adequate lineage documentation under OCC 2026-13 is that an examiner who has never seen the model can reconstruct the data's history from the lineage record alone, understand the governance decisions made at each stage, and assess whether those decisions were consistent with the institution's legal obligations.

The audit trail for data governance decisions includes the lineage documentation and also the governance records: the approvals obtained for each data source, the proxy analysis conducted for each feature, the GLBA use limitation review for NPPI features, the BISG or HMDA correlation analysis, and the model risk committee's approval of the feature set before training proceeds. Each of these records must be maintained in the model risk file for the AI model they support, not in a separate data governance system that is only consulted during data governance reviews. The integration of data governance records into the model risk file is one of the structural requirements of OCC 2026-13's unified governance framework.

Third-Party Data and the Enhanced Governance Obligation

Third-party data, meaning data purchased from or provided by vendors, data brokers, credit bureaus, or other external sources, creates enhanced governance obligations for AI model development because the institution's control over the data's provenance, collection practices, and use restrictions is limited by the third party's practices and the institution's contractual rights.

Credit bureau data (the tradeline, payment history, and inquiry data provided by Equifax, Experian, and TransUnion under the Fair Credit Reporting Act (FCRA)) has well-established governance controls: the FCRA (which governs the use of consumer report information, including the permissible purposes for obtaining and using credit reports) restricts the permissible purposes for which credit report data can be obtained and used. Using FCRA-regulated credit bureau data for AI model training is a permissible purpose under the FCRA only if the model's intended use is within the permissible purpose scope. A credit scoring model trained on credit bureau data for mortgage underwriting is within the permissible purpose; a customer churn prediction model trained on the same data may not be, and the data governance framework must assess each use of credit bureau data against the FCRA's permissible purpose requirements.

Data broker data, meaning the purchase behavior, location, social, and lifestyle data that commercial data brokers compile and sell, creates substantially greater governance complexity. Unlike credit bureau data, data broker data is not governed by a comprehensive federal framework. The institution must assess each data broker's data collection practices, the consents (or lack thereof) under which the data was collected, the terms under which the institution may use the data, and the proxy risk the data introduces. In 2026, several state privacy laws (including comprehensive consumer privacy acts in states with significant banking populations) require affirmative consent for certain uses of personal data, and the institution must assess whether the data broker's data can be used for model training in those jurisdictions consistent with applicable state privacy requirements.

For both credit bureau and data broker data, the institution must ensure that vendor contracts include: a representation that the data was collected in compliance with applicable privacy laws; a use restriction specifying the purposes for which the institution may use the data; an indemnification provision addressing the institution's exposure if the data was collected improperly; and a data governance provision requiring the vendor to notify the institution of any change in the legal or regulatory status of the data collection practices. The absence of these contract terms creates a data governance gap that will surface in any model risk or fair-lending examination that reviews the model's training data.

Data Retention, Deletion, and the AI Governance Lifecycle

Data governance for AI does not end when the model goes into production. The data lifecycle obligations continue for the training data, the model itself, and the records of model-influenced decisions throughout the model's operational life and after its retirement.

For training data, the institution must define a retention policy that balances two competing obligations: the need to retain training data for model validation, re-validation, and examination support (which argues for longer retention); and the GLBA and state privacy law obligations to limit retention of NPPI to the period necessary for the stated business purpose (which argues for timely deletion). The resolution is a defined retention period with clear justification: training data is retained for the period needed to support model governance obligations (at minimum, the period from training through the next independent re-validation, plus any required examination-support window), and then deleted or de-identified under a documented process. The retention policy must be approved as part of the model's governance approval, not managed as a separate IT data management decision.

For customer data used in model inputs, the institution must honor deletion requests consistent with applicable privacy law. In 2026, state privacy laws in several jurisdictions give consumers the right to request deletion of their personal data, and financial institutions must assess whether those deletion rights apply to data used as model inputs or training data. The practical challenge is that model training is an opaque process: it is not always possible to confirm that a specific customer's data has been removed from a trained model's parameters. The institution's privacy program must address how it handles deletion requests for data that may have been used in AI training, including what representations it can make to customers about the effect of deletion on prior model training.

When an AI model is retired, the institution's data governance obligations do not retire with it. The model's risk file, including the training data documentation, lineage records, validation reports, fair-lending testing results, and monitoring history, must be retained for the period required by the institution's records retention policy, which must be at minimum consistent with the regulatory examination and enforcement look-back periods applicable to the decisions the model influenced. A credit model that influenced mortgage decisions must have its governance documentation retained for the applicable mortgage records retention period, not just the model's operational life.

Key Takeaways

• Data governance is the foundation an AI model sits on: the defensibility of a model under OCC 2026-13, ECOA, and GLBA is bounded by the data governance and privacy controls that governed the training data before it reached the model. A model trained on legally indefensible data is legally indefensible regardless of its performance metrics.
• GLBA (Gramm-Leach-Bliley Act) creates three specific obligations for AI training data: a use limitation obligation (NPPI may only be used for purposes consistent with the privacy notice and customer relationship), a safeguards obligation (training data is subject to security controls regardless of environment), and a disclosure restriction obligation (vendor AI platforms that process training data containing customer NPPI must meet GLBA requirements in their vendor contracts).
• The proxy variable problem means that data governance must include a pre-development proxy correlation analysis for every proposed model feature, assessing the feature's correlation with demographic proxies (using BISG for consumer lending or HMDA data for mortgage lending), documenting the feature's legitimate business purpose, and evaluating whether a less-proxy-correlated alternative achieves comparable predictive value. The absence of this evaluation is itself a fair-lending governance gap.
• Data lineage documentation must be built as data is collected, transformed, and used, not reconstructed after the fact. The standard under OCC 2026-13 is that an examiner can reconstruct the data's history from the lineage record alone and assess whether governance decisions at each stage were consistent with the institution's legal obligations.
• Third-party data including credit bureau data (governed by FCRA permissible purpose requirements) and data broker data (governed by state and federal privacy requirements with substantial complexity) requires enhanced governance: proxy correlation assessment, use restriction review, GLBA compliance assessment for vendor data transfer, and specific contract terms including data collection compliance representations, use restrictions, indemnification, and change notification obligations.
• Data governance for AI continues through the model's operational life and after retirement: training data retention periods must balance model governance needs and GLBA and state privacy law retention limits; consumer deletion requests for data used in model training require a defined institutional response; and model retirement does not end the governance documentation retention obligation.
• All data governance records (lineage documentation, proxy analysis, GLBA use limitation review, BISG or HMDA correlation analysis, model risk committee approvals of the feature set) must be integrated into the model risk file rather than maintained in a separate data governance system, consistent with OCC 2026-13's unified governance framework.
• The fourteen-month remediation scenario illustrates the cost of data governance failures discovered at validation: the cost is not just time and money but the delay of the model's intended benefit to the institution and its customers. Building the data governance framework before AI development begins is not a compliance overhead; it is the foundation that makes model development fast and defensible.