AI Governance Evidence Pack: What to Produce If a Regulator Asks Tomorrow

Picture the letter arriving on a Tuesday. Not a customer's security questionnaire, but something with a case number attached: a state attorney general's office, the FTC, or an EU market surveillance authority wants to see how your company governs the AI system it shipped last year. The response window is measured in weeks, not months. And the real question inside the formal one is simple: can you show your work, or only describe it?

Most companies building or deploying AI have something written down about governance. Far fewer can produce it complete, current, and in a form an investigator will accept on first read. That gap, between having a policy and having evidence, is where I think most AI governance programs actually live or die. A policy is written to satisfy a board member or a due-diligence questionnaire. An evidence pack is written to survive someone asking a second question.

This is what belongs in that pack, and where each requirement actually comes from. Not because a consultant says so, but because a specific clause, article, or statute does.

"Regulator" Is a Wider Category Than the EU AI Act

When people hear "AI regulator" they picture Brussels. That's too narrow. In the United States, the FTC has pursued AI-related enforcement under Section 5 of the FTC Act (15 U.S.C. § 45). Section 5 prohibits unfair or deceptive acts or practices, and it does not require a single word about AI to apply to one. State attorneys general use their own unfair-and-deceptive-practices statutes the same way.

Sector regulators layer on top of that: the FDA for AI-enabled medical devices, the CFPB for AI used in lending decisions, the EEOC for AI used in hiring. None of these agencies need a dedicated AI law to open an inquiry. They need a claim that turned out not to match what the system actually does, or a decision that turned out to disadvantage people in a way the deployer can't explain.

Then there's the EU AI Act, formally Regulation (EU) 2024/1689, the first horizontal AI law with its own documentation and record-keeping obligations built directly into the text. It entered into force on 1 August 2024, and its obligations phase in on a fixed schedule: the prohibited-practices provisions in Chapter II have applied since 2 February 2025. The high-risk system requirements in Chapter III were originally set to apply from 2 August 2026, but the EU's Digital Omnibus on AI, in force since 27 July 2026, pushed that timeline back: Annex III high-risk obligations now apply from 2 December 2027, and Annex I product-embedded high-risk obligations from 2 August 2028. If your AI system touches EU users or the EU market at all, those revised dates are the ones to track, not the original schedule.

And a growing number of "regulators" aren't regulators at all. They're enterprise customers running vendor risk assessments, cyber insurers underwriting AI liability, and certification bodies conducting ISO/IEC 42001:2023 audits. They ask the same questions a government investigator would ask. They just show up with a contract instead of a subpoena.

A Policy Binder Is Not an Evidence Pack

A policy says what the organization intends to do. An evidence pack proves it happened, for a specific system, on a specific date, signed by a specific person. Auditors and investigators both work the same way: they don't accept the policy as proof of the practice. They ask for the record the policy says should exist, then check whether it does.

ISO/IEC 42001:2023 makes this explicit in its own structure. Clause 7.5 requires documented information to be controlled, and that documented information has to demonstrate that the processes described elsewhere in the standard are actually followed, not just written down. An auditor reading your AI policy under clause 5.2 will immediately ask to see the risk assessment records under clause 6.1.2 that the policy claims happen. If the policy exists but the records don't, that's a nonconformity, not a paperwork gap.

What the Pack Actually Contains

The AI System Inventory

This is almost always the first document requested, and the one companies are least likely to have current. An inventory lists every AI system in production or development, who owns it, what it does, what data feeds it, and what decisions or outputs it produces. Without this, nothing else in the pack has an anchor. A risk assessment for "our AI system" means nothing when there are eleven of them and no record of which one the assessment actually covers.

Risk Assessments Tied to a Named System

ISO/IEC 42001:2023 clause 6.1.2 requires an AI risk assessment process, and clause 8.2 requires it to run during operation, not just at design time. The EU AI Act's Article 9 imposes a comparable continuous risk management system for high-risk AI providers, run as an iterative process across the system's lifecycle rather than a one-time exercise before launch. A regulator does not want a generic AI risk framework. They want the assessment for the system named in their inquiry, dated, and showing who reviewed it.

Technical Documentation

For any system that falls under the EU AI Act's high-risk category, Article 11 requires technical documentation with contents specified in Annex IV: the system's intended purpose, design choices, the data used to train and test it, performance metrics, and known limitations. Under the Digital Omnibus's revised schedule, that obligation now phases in from 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I product-embedded ones — but the document still has to exist before the system goes on the market, not get assembled after an inquiry arrives. Reconstructing Annex IV documentation from memory and old Slack threads six weeks into a regulatory review is one of the more painful ways to spend a quarter.

Logs and Records

Article 19 of the EU AI Act requires providers of high-risk AI systems to keep the logs automatically generated by those systems for a period appropriate to the system's purpose, of at least six months, unless another applicable law, most often data protection law, requires longer. That obligation now phases in from 2 December 2027 for Annex III high-risk systems under the Digital Omnibus's revised schedule, but the six-month floor is worth building into internal retention policy today, for systems inside and outside the EU Act's scope, because "we didn't keep the logs" is close to the worst possible answer to give an investigator asking what a system did on a specific date.

Impact Assessments

ISO/IEC 42001:2023 clause 6.1.4, carried through in operation under clause 8.4, requires an AI system impact assessment: a documented look at how the system affects the people subject to it, not just the organization deploying it. This is the document that answers the question investigators increasingly lead with, some version of "who could this hurt, and did you think about that before you shipped it."

Data Provenance and Training Data Records

Annex IV of the EU AI Act specifically requires documentation of the datasets used to train, validate, and test a high-risk system, including where the data came from and how it was collected. ISO/IEC 42001:2023's Annex A control set includes a dedicated category covering data used in AI systems: its provenance, quality, and suitability for the intended purpose. If you can't trace a training dataset back to a source and a collection date, you can't answer the question a regulator asks right after "what does this system do," which is "what did you train it on."

Internal Audit and Management Review Records

Clause 9.2 requires internal audits of the AI management system at planned intervals, and clause 9.3 requires management review of how the system is performing. These records matter because they show the governance program is being checked by someone other than the person who built it. An auditor's first question after seeing a management review agenda is usually whether the decisions from the last one were actually closed out.

Human Oversight and Training Records

Article 14 of the EU AI Act requires high-risk AI systems to be designed to allow effective human oversight — an obligation that now phases in from 2 December 2027 for Annex III systems under the Digital Omnibus's revised timeline — and that requirement only means something if you can show who was trained on what, and when. Training rosters, sign-off records, and documented escalation procedures belong in the pack, not just the training materials themselves.

Incident and Complaint Records

Article 73 of the EU AI Act requires providers to report serious incidents involving high-risk AI systems to the relevant market surveillance authority. Outside the EU Act entirely, keeping a running log of AI-related complaints, near-misses, and corrective actions is the closest thing to an insurance policy against the question every investigator eventually asks: has this happened before, and what did you do about it.

Vendor and Third-Party Model Documentation

If the AI system embeds a foundation model or component from another provider, the evidence pack has to include what that vendor gave you: model cards, usage restrictions, and any documentation the vendor provides toward your own obligations under Article 11 or clause 6.1.2. Regulators increasingly expect deployers to have done diligence on the models they didn't build themselves, not simply pointed at the vendor's compliance page.

How the Frameworks Compare

None of these frameworks substitutes for another. A company holding ISO/IEC 42001:2023 certification still has to build EU AI Act Annex IV documentation separately, because certification proves the management system works; it doesn't produce the specific technical file Article 11 requires. I've seen companies treat certification as the finish line and get caught flat when a different document was actually the one being asked for.

Building the Pack Before the Call Comes

The pack is much cheaper to build in advance than to reconstruct under a deadline. In practice that means a handful of habits, kept up consistently, rather than one large project done once:

• Keep the AI system inventory as a living document with a named owner, updated when a system changes, not reviewed once a year.
• Run risk and impact assessments at defined trigger points, before launch, after a material change, and at a set interval, and keep every version, not just the latest.
• Write management review minutes that name the decision, the owner, and the date it's due, then check them off.
• Retain logs on a written schedule instead of by default settings nobody ever checked.
• Ask every AI vendor for their model documentation when you sign the contract, not when a regulator asks you for it.

None of this requires a large compliance department. It requires the discipline to write things down at the moment they happen, because that's the only moment they're cheap to capture.

What Happens When You Can't Produce It

Under the EU AI Act's penalty structure in Article 99, non-compliance with obligations like Article 11 technical documentation can draw fines of up to €15 million or 3% of total worldwide annual turnover, whichever is higher; violations of the prohibited-practices provisions in Article 5 can reach €35 million or 7%. Those numbers get attention, but in my experience the more common cost is time. As a rough illustration: an investigation that could close in a matter of weeks with a complete pack stretches to months when the evidence has to be reconstructed, and reconstruction under deadline pressure produces worse documentation than the same work done calmly beforehand.

For ISO/IEC 42001:2023, the cost is a nonconformity that blocks certification, or a lost contract when a vendor risk questionnaire comes back with gaps a competitor didn't have. Either way, the pattern holds. The absence of a record doesn't just fail to help you. It gets read as evidence the practice never happened at all.

If you're building an AI management system from the ground up, an ISO 42001 gap assessment is the fastest way to find out which of these documents already exist, which are half-finished, and which don't exist yet, before a regulator or an auditor asks first. For organizations further along, working with an ISO 42001 consultant to structure the evidence pack around your actual system inventory, rather than a generic template, is what turns a compliance exercise into something you can hand over on short notice with confidence.

FAQ

What is an AI governance evidence pack?

A curated, indexed set of the records that prove an AI governance program operates as documented, tied to specific systems rather than described in general terms. It typically includes a system inventory, risk and impact assessments, technical documentation, logs, and internal audit and management review records.

Does ISO 42001 certification satisfy EU AI Act requirements?

Not on its own. ISO/IEC 42001:2023 certification demonstrates a functioning AI management system, but the EU AI Act's Article 11 technical documentation and Article 19 log-retention obligations are separate, specific requirements that certification doesn't automatically produce. The two should be built together, not sequenced.

How long do I need to keep AI system logs?

Article 19 of Regulation (EU) 2024/1689 requires providers of high-risk AI systems to retain automatically generated logs for at least six months, unless another applicable law requires longer. That six-month floor is a reasonable baseline even for systems outside the EU Act's scope.

What document does an investigator usually ask for first?

The AI system inventory. Before a risk assessment or a log means anything, an investigator wants to know what systems exist, who owns each one, and what data it touches. Everything else in the pack gets read against that inventory.

Can a small company build this without a dedicated compliance team?

Yes, if the habit starts now rather than after an inquiry arrives. The pack doesn't need to be exhaustive on day one. It needs a current inventory, a risk assessment method applied consistently across systems, and a written record every time a governance decision gets made.

Last updated: 2026-09-22