Audit Ready: The Evidence an AI Governance Programme Has to Produce

There is a moment in most first AI audits where the conversation stops being about policy. The auditor has read the framework, accepted that a governance committee exists, and then asks for something specific: show me the record that this system was reviewed before it went live, who signed it, and what they saw when they signed.

The answer is often a policy that says such reviews happen. That is not the same thing, and everyone in the room knows it within about four seconds.

This guide is about the difference. Documentation is what you wrote. Evidence is what proves the thing happened, when you say it happened, performed by someone identifiable, and it still exists when somebody asks. Those are four separate properties and a governance programme can satisfy the first without touching the other three. It covers what regimes actually ask for, the retention periods that quietly turn this into an architecture problem, where each artefact should come from, and the five gaps that show up in nearly every first audit.

Documentation is not evidence

Both are written artefacts, which is why they get conflated. They answer different questions and fail in different ways.

Documentation describes a design or an intent. The policy, the procedure, the model card, the framework mapping. It answers "what is supposed to happen". It can be written at any time, including the week before the audit, and nothing about the artefact reveals when it was written.

Evidence records an occurrence. The approval with a name and a timestamp, the test run with its output, the log entry, the ticket with its state transitions. It answers "what did happen". Four properties distinguish it, and a programme can fail any one of them while passing the rest.

The practical test for any artefact is a single question: could you produce this for a system that was retired eighteen months ago, without asking the person who built it? If the answer depends on someone remembering, it is not evidence yet.

What is actually asked for

Three audiences ask, and they ask for different things. Confusing them produces either far too much work or a nasty surprise.

A regulator or notified body, for a high risk system. This is the most concrete published list anybody has, and it is worth reading even if the EU AI Act does not currently bind you, because it is the closest thing to a specification for what a complete AI file looks like. Article 11 requires technical documentation drawn up "before that system is placed on the market or put into service", kept up to date, and written "in such a way as to demonstrate that the high-risk AI system complies with the requirements set out in this Section". Annex IV sets the minimum contents in nine numbered items.

1. General description of the system
   Intended purpose, versions, how it interacts with other hardware and software, the forms in which it is placed on the market, the hardware it runs on, the user interface and the instructions for use.
2. Detailed description of elements and development
   Development methods, design specifications, architecture and computing resources, training data, the human oversight assessment, pre-determined changes, validation and testing, and cybersecurity measures. This is the heaviest item by a distance.
3. Monitoring, functioning and control
   Capabilities and limitations, accuracy levels, foreseeable unintended outcomes, the oversight measures in place, and the specification of input data.
4. Performance metrics, and whether they are the right ones
   Not just the numbers. A description of whether the chosen metrics are appropriate for this system, which is a judgement somebody has to have made and recorded.
5. The risk management system
   A detailed description of the Article 9 risk management system as it applies to this system.
6. Relevant changes over the lifecycle
   The change history. This is the item that quietly requires a working change record from day one, because it cannot be reconstructed later.
7. Standards applied
   The harmonised standards used, or, where none were, a description of the solutions adopted to meet the requirements.
8. The EU declaration of conformity
   A copy of the declaration referred to in Article 47.
9. The post market evaluation system
   How performance is evaluated after the system is on the market, including the monitoring plan required by Article 72.

Article 11 also allows SMEs, including start ups, and small mid cap enterprises to supply these elements in a simplified form, which the Commission is required to create and which notified bodies must accept. Treat that as a route the Act provides rather than a form you can download today.

A certification auditor, for a management system. This audience assesses whether the system of management works, which means sampling. They will take a handful of AI systems and follow each one end to end, looking for the gap between the procedure and the artefacts. The requirements for the bodies that perform these audits were published as ISO/IEC 42006 in July 2025, adding to the general certification standard rather than replacing it. Our guide to ISO/IEC 42001 covers the management system itself.

A board, a customer or an internal auditor. Usually the first audience in practice and the one most often served with a dashboard. A dashboard is a view, not a record. If the underlying artefacts cannot be reproduced on a past date, the dashboard is a claim.

The retention clock nobody planned for

This is the part that turns evidence from a filing exercise into an architecture decision, and it is routinely missed because the numbers sit in articles nobody reads after the obligations table.

Article 18 requires providers to keep five things at the disposal of national competent authorities "for a period ending 10 years after the high-risk AI system has been placed on the market or put into service": the technical documentation, the quality management system documentation, documentation of changes approved by notified bodies, decisions and other documents issued by notified bodies, and the EU declaration of conformity.

Ten years is a long time in this field. It is longer than most SaaS contracts run, longer than most model versions survive, longer than many vendors last, and longer than most of the people who built the system will be in their current role. An evidence strategy that depends on a third party platform remaining purchased, or on a repository remaining accessible, has a dependency it has not written down.

The log duty is shorter and lands on both sides of the relationship. Article 19 requires providers to keep automatically generated logs "to the extent such logs are under their control", "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months". Article 26 puts the same duty, in the same words, on deployers for the logs they control.

Note also that six months is a floor set against the intended purpose, not a ceiling, and that it is expressly without prejudice to other law. Data protection law can require a shorter period for the same records, which is a genuine tension to resolve deliberately rather than by whichever system's default wins.

Evidence as a by-product of the process

The programmes that pass audits comfortably are not the ones that documented the most. They are the ones where the artefact appears automatically because the work was done through a system that records it. The design question is therefore not "what do we need to write" but "which system of record produces this, and does the work route through it".

Four rules do most of the work.

Put the decision in a system that stamps it. An approval made in a ticketing system, a pull request or a workflow tool is dated and attributed by the tool. The same approval made in a meeting and minuted later is a recollection. This is the single highest return change available, and it usually costs nothing beyond deciding where approvals live.

Version the thing you were assessed against, not just the assessment. An assessment that says a system passed is incomplete without the version of the policy, the model and the thresholds it passed against. Six months later all three will have moved, and the record will claim something that cannot be reproduced.

Make the register the source, not a copy. Where the inventory is maintained by hand from other systems, it drifts, and an auditor who finds drift will stop trusting the register as a sampling frame. Our guide to building an AI inventory covers the register itself.

Decide what a negative record looks like. Evidence that a control ran and found nothing is as important as evidence that it caught something, and it is the part teams forget to generate. A review that only produces an artefact when there is a finding cannot be distinguished, later, from a review that did not happen.

An evidence map you can fill in

The exercise that tends to break the deadlock is a single table, filled in per system rather than per policy. Four columns, one row per obligation.

Filling this in for three systems is a better use of a fortnight than writing another procedure, because the empty cells are the finding. Most organisations discover that two or three rows have no system of record at all, and that is a shorter and more actionable list than a framework gap analysis produces.

The oversight row deserves particular attention. Article 26 requires deployers to assign oversight to natural persons with "the necessary competence, training and authority", plus the necessary support. Each of those four words implies a different artefact: a named assignment, a training record, a delegation of authority, and whatever demonstrates that support was actually available.

Five gaps that show up in every first audit

The approval exists but not the basis. Someone approved the system. What they were shown when they approved it was a deck that has since been edited, or a verbal summary. The approval is attributable and timed and proves almost nothing.

The test results are not reproducible. Metrics appear in a report with no record of the dataset version, the model version or the thresholds in force. The numbers may be perfectly accurate and they cannot be tied to a state of the world.

Human oversight is designed but not recorded. The design says a person reviews edge cases. Nothing in the system records that they did, what they saw, or what they changed. This is the most common gap in deployer organisations and the hardest to fix retroactively.

Logs exist but not for long enough, or not under your control. Platform defaults are frequently thirty days. The floor is six months and the right period is tied to intended purpose. Where the system is a vendor's, the logs may not be yours at all.

Nobody can reconstruct a past state. Current state is easy. The question an auditor asks is what the state was in March, what policy version was in force, and what the register said then. Systems built for current state cannot answer it, and the answer is a point in time snapshot discipline rather than a better dashboard.

The trade-offs nobody puts on the slide

Evidence collection is surveillance adjacent. Attributing every review to a named person creates a performance record of that person. In several jurisdictions that engages works councils and employment law, and it is better raised with them while the design is still open.

More evidence is not better. Collecting everything produces a corpus nobody can search, a retention liability, and a discovery exposure in litigation. The map above is a scoping tool precisely because the right answer is a small number of artefacts you can actually produce.

Ten years is a vendor dependency. Any artefact held only in a purchased platform carries the question of what happens at the end of the contract. Export formats and exit terms are an evidence requirement, not a procurement nicety.

Retrofitting has a floor. For systems already in production, some evidence simply cannot be recreated. The honest response is to record the gap, state when complete evidence begins, and fix it going forward. An auditor can work with a dated gap. A reconstructed record that implies completeness is much worse than an acknowledged one.

Frequently asked questions

Where this leaves you

The structural problem is that governance programmes are measured on frameworks adopted and policies written, and audited on artefacts produced. Those two measures diverge quietly, and the divergence is invisible until somebody asks for a specific record about a specific system on a specific date.

The work to close it is not more writing. It is deciding where each decision gets made so that making it produces a dated, attributed record, versioning what was assessed alongside the assessment, and settling who holds the logs before the contract is signed rather than after the request arrives. None of that is glamorous and all of it is cheaper than the alternative, which is a fortnight of reconstruction that produces something weaker than an honest gap.