← No Hallucinations

Governance · November 2, 2026

The AI Evidence Package: What Makes Governance Defensible Under Audit

By David Monahan · Data Defenders, LLC · the lifecycle, the artifacts, and the gaps that get found

A governance program that cannot produce evidence is, from the outside, indistinguishable from one that does not exist. The committee met. The risk scores were assigned. The deployment gate held and a system got turned away. None of that counts for anything if it cannot be shown to someone who asks — on their timeline, in their format, covering the period they care about. The previous post covered how to score AI risk defensibly. This one covers what happens when someone asks you to prove it.

Evidence has a lifecycle, and most programs stop at stage one

Organizations generate far more evidence than they think. Risk scores get assigned. Approvals get signed. Reviews happen and get discussed. The failure is almost never at the point of creation — it is at everything that comes after. The record lands in an inbox instead of a system of record. Nobody tags it to the control it proves. It ages out of a chat retention window at ninety days. And when the request finally arrives, three people spend two weeks reconstructing what everyone remembers happening.

Click the chart to open it full size.

This is the operational content of the Managed (AIMS) stage from the Governed post. A Governed program has the inventory, the owner, the policy, and the gates. A Managed program can prove all four were working on any given Tuesday eight months ago. The distance between those two sentences is the collection system.

What makes evidence audit-ready: four properties

1. Attributable. Every artifact names a person, a date, and a version. ISO/IEC 42001 makes this explicit in clause 7.5.2: documented information carries suitable identifiers — title, date, author, version, reference number — and is reviewed and approved before use. An undated spreadsheet with no named author is not evidence. It is an assertion, and an auditor will treat it as one.

2. Contemporaneous. The record was created when the activity happened, not in the three weeks before the audit. This is the property that ends engagements badly. Missing evidence is a gap — findable, fixable, and usually survivable. Reconstructed evidence is a credibility problem, and it colors every other artifact in the package, including the ones that were fine.

3. Complete. The artifact covers the full period and the full population, not the convenient slice. A SOC 2 Type II auditor samples across the whole observation window. If collection only started in month nine of a twelve-month period, the sample finds the hole on the first pull, and the scope of the finding is the entire period rather than the three months you missed.

4. Retrievable. The artifact can be produced on demand, within the window the asker gives you. ISO/IEC 42001 clause 7.5.3 requires documented information to be available where and when it is needed, protected against loss of integrity, version-controlled, and held to a defined retention period. The EU AI Act puts a hard floor under the logging piece for high-risk systems: Article 12 requires those systems to generate logs automatically, and Article 19 requires providers to retain the logs they control for a period appropriate to the intended purpose, and in any case at least six months, unless other Union or national law sets a different period.

What actually goes in the package

Seven artifact categories carry most of the weight across most frameworks. The specific controls they satisfy differ by standard; the artifacts themselves do not change much:

• Inventory and tiering records. The AI inventory with a risk tier on every entry, plus the dated history showing when systems were added and when tiers changed.
• Risk scoring records. The rubric itself, the score assigned to each system, and the reasoning behind each dimension — the output of the method in the previous post.
• Approval and gate records. Who authorized each deployment, against which tier, on what date, and every exception granted with the name of whoever granted it.
• Model and vendor assessments. Due diligence on third-party models, contractual terms covering model change notification, and the reassessment record after each material vendor update.
• Monitoring, drift, and bias reports. The cadence, the reports themselves across the full period, and the remediation record for anything the reports found.
• Incident and change records. AI-specific incidents, root cause, resolution, notification timeline, and the change log for prompts, models, and configuration.
• Policy and training records. Every version of the AI usage policy with its approval history, plus completion records showing who was trained and when.

One artifact usually satisfies several frameworks at once. A dated deployment approval tied to a documented risk tier does work under NIST AI RMF, ISO/IEC 42001, and SOC 2 simultaneously. This is why the index matters more than the volume: organizations that collect against questionnaires end up with the same evidence stored four times under four schemes, and still cannot answer a question phrased a fifth way.

Same evidence, four packages

The artifacts do not change based on who is asking. What each audience wants to receive changes completely, and sending the wrong shape to the right audience is a self-inflicted finding.

Regulatory enforcement is adversarial and event-specific. The question is narrow — show the risk assessment that existed before this system went live on this date — and the answer needs chain of custody, verifiable timestamps, and the policy version that was in force at the time rather than the current one. Volume is not the goal here; precision and provenance are.

Certification auditors under ISO/IEC 42001 or SOC 2 want evidence pre-mapped to the clause or criterion it satisfies, sampled across the observation period, with an index they can work through. An unindexed document dump reads as disorganization, and disorganization reads as immaturity. Clause 9.2 of ISO/IEC 42001 expects the internal audit program to be running on its own before the external auditor arrives, so the evidence of your own audits is itself part of the package.

The board or audit committee wants the summary first and the detail underneath it, trend over point-in-time, and a clear read on exceptions and who authorized them. Fifteen minutes on the agenda does not survive a two-hundred-page appendix.

Cyber insurance underwriters want checklist-style proof that named controls exist and are enforced. Does the inventory exist, does it have a named owner, is the usage policy signed, is monitoring running and how often. They are not scoring the sophistication of your rubric; they are confirming the control is real before they price the risk.

Building the collection system: five steps

1. Index against your control set, not against questionnaires. Pick one control framework as the spine — NIST AI RMF or ISO/IEC 42001 for most organizations — and tag every artifact to the control it proves. Crosswalks to other schemes are then a mapping exercise rather than a second collection effort.

2. Name an owner for each artifact category. Not a team, a person. The seven categories above need seven names against them, and those names belong in the same place as the inventory owners from the Governed stage. Unowned categories are the ones found empty.

3. Set the cadence and automate what you can. Monitoring reports monthly, access reviews quarterly, policy review annually, inventory reconciliation continuous. Anything that depends on someone remembering to save a file will eventually depend on someone who forgot.

4. Index at creation, not at audit time. Tagging an artifact to its control takes seconds when the artifact is created and hours when it is excavated eleven months later. This single discipline is most of the difference between a two-week audit response and a two-day one.

5. Run a production drill. Once a year, pick a quarter at random and produce the package for it against a deadline, as if the request were real. The drill finds the retention gap, the departed owner, and the artifact nobody can locate — at a moment when all three are still cheap to fix.

The gaps that get found

Evidence that exists but cannot be located. The most common finding by a wide margin, and the most frustrating, because the program did the work. Unretrievable evidence scores identically to absent evidence.

Reconstructed evidence. The approval that was verbal, documented later. Auditors are good at spotting this — metadata, consistent formatting across records that should have been created months apart, sign-offs that all appeared the same week. The finding that follows is about integrity, not about the control.

Policy without proof of enforcement. The usage policy says high-tier systems require legal review before deployment. The package has the policy and no legal reviews. A documented control with no evidence of operation is worse than an undocumented one, because the organization has written down the standard it is failing.

Inventory that does not match reality. The evidence package describes eleven AI systems. The expense reports show subscriptions to nineteen. Shadow AI is a governance problem on its own, and it is also the fastest way to turn a clean package into a credibility question.

The takeaway

Evidence is not a byproduct of governance. It is the deliverable. The program that can produce a complete, attributable, contemporaneous package within a deadline is defensible; the program that did identical work and cannot produce it is not, and the distinction is invisible from the inside right up until someone asks. Index against one control set, name an owner for each of the seven artifact categories, set a cadence, tag at creation, and drill it once a year. The package is then something you produce, rather than something you survive.

Next in the series: the top of the lifecycle — what Certifiable and Optimized actually require, and how to tell whether your organization should be aiming there at all.

Sources: ISO/IEC 42001:2023, clause 7.5.2 (creating and updating documented information — identifiers, format, review and approval), clause 7.5.3 (control of documented information — availability, integrity, version control, defined retention), and clause 9.2 (internal audit); EU AI Act (Regulation 2024/1689), Article 12 (record-keeping and automatic log generation for high-risk AI systems), Article 19 (retention of automatically generated logs for a period appropriate to the intended purpose, of at least six months unless otherwise provided by Union or national law); NIST AI RMF 1.0 (AI 100-1), GOVERN and MANAGE functions; AICPA SOC 2 Type II observation-period sampling.

← Back to No Hallucinations

Talk to Us Directly

Free 25-minute consultation. Bring your questions.