The Question

Regulatory examination of AI systems is moving from aspiration to execution. The EU AI Act's high-risk AI system audit requirements are operationalizing. Financial regulators are incorporating AI data governance into model risk examination procedures. Data protection authorities are conducting AI-specific investigations. Healthcare regulators are asking AI questions in HIPAA audits. The question for enterprise AI teams is no longer whether they will face regulatory examination of their AI data practices, but whether they will be ready for it when it arrives.

The enterprises that survive regulatory AI examination without material findings are not those that have the most sophisticated AI systems. They are the ones that have built the documentation and governance infrastructure that examiners are trained to look for — and built it before the examination notice arrives, not in response to it. The documentation produced under examination pressure is always less complete, less credible, and more expensive to produce than the documentation built as a matter of ordinary governance practice.

Most enterprise AI teams have not been through a regulatory AI examination and don't have a precise picture of what examiners will ask, in what sequence, with what documentary evidence expected. That is the gap this brief addresses.

AI data audit readiness is not a compliance project — it is the governance infrastructure that should exist before any AI system is deployed on personal data, and enterprises that build it proactively are the ones that survive regulatory examination without material findings.


Why This Matters Now

In 2025, the UK Information Commissioner's Office conducted a sweep examination of AI systems used by financial services firms for credit decisioning. The examination was structured as a questionnaire followed by selected deep-dive investigations of firms whose questionnaire responses indicated gaps. The questionnaire covered: lawful basis for training data processing, data minimization documentation, data subject rights capabilities for AI training data, bias testing methodology and results, and audit trails for model updates.

Forty-three percent of firms in the sweep could not produce complete answers to the training data inventory questions. Twenty-eight percent had no documented bias testing results for their credit decisioning models. Seventeen percent could not demonstrate a technical mechanism for responding to data subject erasure requests that implicated training data. The ICO issued improvement notices to eleven firms and opened formal investigations into three.

In parallel, the U.S. Office of the Comptroller of the Currency issued supervisory guidance in 2025 incorporating AI model risk into the existing Model Risk Management (SR 11-7) examination framework. The guidance specified that AI models are subject to the same validation, documentation, and governance requirements as traditional statistical models — with additional requirements for training data documentation, bias testing, and ongoing monitoring. Examinations conducted under the updated framework in late 2025 found widespread gaps in training data documentation across mid-size and regional banks.

The EU AI Act's conformity assessment requirements for high-risk AI systems in Annex III categories — AI used in employment, credit, education, essential services, law enforcement — began applying to in-scope enterprises in 2025. The first wave of notified body assessments has begun producing findings that are now publicly available through the EU AI Act database. The findings consistently identify training data documentation as the most common gap.

The examination environment is not theoretical or future. It is active.


What the CURVE™ Data Shows

The 2026 Stackcurve Data Security for AI CURVE™ Report evaluated the vendor landscape for AI data governance and audit readiness, assessing tools against the documented examination criteria of active regulatory programs.

Training data catalog and lineage: Alation, Atlan, and Collibra led the evaluation for AI-specific training data catalog capabilities — the ability to document data sources, lineage, access history, and update history for ML training datasets specifically, not just general data assets. The evaluation assessed whether each platform's documentation output is structured to answer regulatory examination questions directly. Collibra distinguished itself for its regulatory reporting templates aligned to EU AI Act Article 11 technical documentation requirements.

Bias testing and documentation: IBM OpenScale (Watson Studio), Fiddler AI, and Arthur AI led the evaluation for bias testing tooling that produces examination-ready documentation — bias metrics, testing methodology, test dataset composition, and remediation actions in a format that satisfies SR 11-7 and EU AI Act requirements. The CURVE™ Report assessed not just bias detection capability but documentation output quality, because examiners assess the documentation, not the underlying tool.

Model governance and audit trail: ModelOp and Verta.ai led for model governance platforms that maintain audit trails across the model lifecycle — training data versions, model versions, deployment decisions, monitoring results, and policy approvals — with the tamper-evident logging that satisfies examination standards.

The full vendor rankings are in the 2026 Stackcurve Data Security for AI CURVE™ Report — free to download.


The Gap Most Buyers Miss

The training data inventory gap: most enterprises cannot produce it

The first question in any regulatory AI examination is: what data was used to train this system? The expected answer is a complete inventory — data sources, data categories, data volumes, date ranges, access controls during training, and data lineage for each source back to its origin.

Most enterprises cannot produce this inventory. Training data was assembled by data scientists, from multiple internal and external sources, in a process that was optimized for speed and model performance, not documentation. The data sources are partially documented in model cards (where model cards exist), partially in code comments in training pipeline scripts, and partially in informal team knowledge that has not been captured formally. Reconstructing a complete training data inventory from these sources after the fact is a multi-week effort — and the resulting inventory's completeness cannot be assured.

The governance practice that prevents this gap: a training data catalog, populated before training begins, documenting each data source before it is ingested. This is not primarily a technology problem. The technology (Collibra, Alation, Atlan) exists. The process discipline — requiring engineers to document data sources in the catalog as a prerequisite for training pipeline access — is what most organizations have not built.

The third-party training data due diligence gap

For AI systems trained on data licensed from third-party providers — commercial data vendors, web-scraped datasets, API-sourced data — regulators will ask: what due diligence was conducted on the data provider? Specifically: does the data provider have the rights to license the data for AI training use? What representations did the provider make about the data's provenance, accuracy, and lawful collection? Does the data use agreement specify permitted uses and limitations?

This is an area where the legal and procurement functions of most enterprises have not developed consistent practice for AI training data specifically. Software licensing and data licensing are handled differently in most procurement processes — and data licensing for AI training use is a newer category that procurement teams are still learning. The examination finding in this area is consistently: data use agreements that are insufficient for the claimed license, or no documentation of due diligence on third-party data providers' rights.

The bias testing gap: documentation matters as much as results

Bias testing for AI systems is now required by examination standards — SR 11-7, EU AI Act, and the emerging EEOC AI guidance for employment-related AI systems. What most enterprises have missed is that the examination is not just about whether bias testing was done. It is about whether it was documented in a format that demonstrates the testing was adequate for the system's risk level.

The documentation that satisfies examination includes: the bias metric selected and the justification for selecting it; the composition of the test dataset (is it representative of the population the system will be applied to?); the threshold established for acceptable bias and the justification for that threshold; the testing results; and, if the results showed bias above the threshold, the remediation actions taken and the results of post-remediation testing.

Most organizations have done some bias testing. Most have not documented it at the level that satisfies examination. The gap is documentation depth, not testing effort.


Questions Your Buying Team Should Be Asking

1. Can you produce a complete training data inventory for each of your production AI systems within 48 hours of an examination notice?

This is the audit readiness test. Ask the AI engineering team to produce the training data inventory for your most critical AI system on a 48-hour timeline — not as an actual regulatory response, but as a readiness exercise. The gaps revealed by the exercise are the gaps that will produce examination findings. The 48-hour timeline approximates the response time available when an examination notice arrives with a documentation request.

2. For each third-party data source in your training datasets, does legal have a file containing the data use agreement, the due diligence documentation, and the rights analysis?

Ask legal to pull the file for two or three third-party training data sources at random. If the file doesn't exist for those sources, assume it doesn't exist for any of them. Building the third-party training data due diligence file is a project that should be completed for all current production AI systems before the next examination cycle, not after.

3. For your highest-risk AI systems — those affecting employment, credit, or access to services — does your bias testing documentation meet the specificity requirements of the applicable examination standard?

This requires knowing which examination standard applies: SR 11-7 for bank model risk, EU AI Act Article 9 for in-scope high-risk systems, EEOC guidance for employment-related systems. Ask compliance and legal to produce the applicable standard's bias testing documentation requirements, then ask the AI engineering team to assess whether current documentation meets those requirements. The gap analysis between the standard's requirements and the current documentation is the audit readiness gap.

4. For EU AI Act in-scope systems, has Article 11 technical documentation been completed, and has it been reviewed by external counsel familiar with the implementing regulations?

EU AI Act Article 11 requires technical documentation covering the system's general description, design specifications, training data description, training methodology, and performance metrics. This documentation must be maintained and available to market surveillance authorities on request. Ask whether the documentation exists, when it was last updated, and whether it has been reviewed by counsel with EU AI Act implementation experience. Many organizations have produced documentation that is incomplete against the Article 11 implementing regulation specifications.

5. Does your AI model governance process require documented approval — with a defined approver and documented rationale — for each new AI system deployment and each material model update?

The governance audit trail — who approved what, when, on what basis — is a core examination deliverable for model risk and EU AI Act reviews. Ask for the governance documentation for your last three AI system deployments. If the documentation is informal (email chains, meeting notes) rather than structured (a governance decision record with a designated approver, risk assessment, and documented rationale), it will not satisfy examination standards. Building the governance process that produces examination-ready documentation is a process design task, not a technology purchase.


The Stackcurve Take

The enterprises that will survive regulatory AI examination without material findings in 2026 and 2027 are those that have built, before the examination notice arrives: a complete training data catalog; third-party data due diligence documentation; bias testing documentation at examination-standard depth; EU AI Act Article 11 technical documentation for in-scope systems; and a model governance process that produces tamper-evident audit trails for deployment and update decisions.

This is not an aspirational governance standard. It is the minimum documentation set that active examination programs are requiring. The cost of building it proactively — the engineering time to maintain a training data catalog, the legal time to document data due diligence, the compliance time to structure bias testing documentation — is a fraction of the cost of producing it under examination pressure, with the added dimension of examination findings, potential enforcement actions, and remediation orders.

The organizations currently being examined are demonstrating, through their examination findings, that most of the market has not built this governance infrastructure. The organizations that build it now create a sustained competitive advantage: the ability to deploy AI systems in regulated contexts that competitors cannot operate in without material regulatory risk.

The 2026 Stackcurve Data Security for AI CURVE™ Report covers the AI data governance and audit readiness vendor landscape, with examination-standard documentation templates and vendor capability assessments for each audit readiness domain. Download it free →


← Back to Research Library

Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.