AI governance should produce evidence, not only policy

AI governance is the ability to show work for a named system

AI governance is the operating practice that assigns decisions, controls, and accountability to an AI system. AI compliance is meeting the legal, contractual, or internal obligations that apply to that system. Governance is working only when it produces evidence an auditor can inspect for a named system on a named date.

A policy says what the organisation intends to do. It does not show whether a particular model, workflow, or deployment did it last Tuesday.

That distinction matters because the relevant legal standard is often demonstrability. GDPR says a controller must be responsible for compliance and able to demonstrate it. ¹ A governance programme that cannot retrieve system-specific records is therefore weak even if its policy library is complete.

For a buyer, the practical test is simple: ask for the artifact, identify the system it covers, and identify the date it represents. If the answer is a general policy, a slide deck, or a certificate with no visible link to the system under review, you have evidence that a process exists, not evidence that the system complied.

A constraint map turns obligations into inspectable artifacts

A constraint map is a working record that connects a requirement to the system, the control that addresses it, the artifact generated by that control, and the owner who can retrieve it. Its purpose is to stop a governance programme from treating every AI deployment as one undifferentiated compliance problem.

The map starts with the named system. “Customer support assistant” is usually too broad. The useful identifier names the specific deployment, such as the return-eligibility assistant running on the EU storefront, together with its purpose, owner, release or configuration, and date in service. The next question is what constraint applies to that system.

A constraint can be a statutory duty, a contractual requirement, an internal approval condition, or a decision the organisation has made about acceptable risk. The map then requires a corresponding artifact. An artifact is a record created by operating the system or controlling it, such as an approval record, technical documentation, evaluation result, access review, change record, incident record, or retained log.

For high-risk AI systems, the EU AI Act makes this concrete. Technical documentation must be drawn up so that it demonstrates that the system complies with the relevant requirements. ² That wording asks for a demonstrable condition of a system. It does not ask whether the provider has written a policy describing good intentions.

The table is deliberately plain. A constraint map should be easy to inspect and hard to decorate. If a row has no artifact, it identifies an intention. If it has an artifact with no system identifier or date, it identifies a document that cannot establish what it covered.

The AI Act requires high-risk systems to technically allow automatic event logging over their operating lifetime. ² Logging added after an incident cannot establish that the required record existed during the period being examined. The evidence requirement changes a build decision.

Evidence differs from a policy because it has scope

A policy can establish that leadership adopted a rule. It cannot, by itself, establish that a particular system stayed within it. The difference is scope.

Consider a policy requiring review of consequential AI outputs. That policy can be useful. Take a credit-decisioning model that scores loan applications: the evidence question is whether a named underwriter was actually assigned to review its declined applications, whether that review step ran or was quietly skipped when volume spiked, what happened when the model was last retrained, and what record of that review still exists to be inspected.

The same distinction applies to technical documentation. A reusable template can make documentation faster to prepare, but it becomes evidence only when it is completed for the system in question and maintained as that system changes. A generic risk statement cannot show that an identified use case, data flow, release, or operating condition was assessed.

This is also why deployment planning should start before implementation. The choice of whether to use AI, and what kind of system to use, determines what must later be shown. When should a business not use AI? helps frame that decision before an organisation creates a system it cannot responsibly operate or evidence.

Evidence also needs retention. For high-risk systems, the AI Act requires providers to keep specified documents available to national competent authorities for ten years after the system is placed on the market or put into service. ² A programme that creates a release record and then loses it has performed a momentary control, not preserved an inspectable one.

Compliance documents can exist without client-specific testing

The alternative to evidence-led governance is document-led governance: write policies, collect attestations, buy a report, and treat the resulting files as proof. It is attractive because documents are visible and centrally manageable.

The weakness appears when the document is detached from the system it is supposed to describe. A report might state that access controls were assessed across “the customer data platform” without saying whether that phrase reaches the marketing analytics warehouse the AI model actually draws its features from. A signed report may establish that an engagement occurred. It does not establish that every relevant control operated for every system, every day, or every transaction.

An assurance engagement is designed to increase the confidence of intended users in information. It does not certify that the underlying claim is unconditionally true. ³ Even reasonable assurance does not use complete testing, and assurance is never absolute. ³

That is not a defect in assurance. It is a reason to ask what was in scope, what was sampled, and which system records were available for inspection. A governance programme should make those questions easier to answer, rather than expecting an external report to replace the records.

Recent peer-review guidance from the AICPA described engagements with identical reports, risk assessments, sample sizes, and testing procedures across different clients. ⁴ The concern is precise: paperwork can survive while the judgment and client-specific testing that give it meaning do not.

For an AI buyer, the correction is to inspect the connection between a report and the named system. Ask which controls were tested, what period was covered, what evidence was sampled, and whether the system under review was included. A report can be valuable evidence. It should not become a substitute for evidence generated by operation.

Apply the map before release, then keep it alive

Start with the systems that make decisions, recommendations, classifications, or generated outputs where an error changes a customer, employee, patient, financial, or operational outcome. The aim is not to create a single company-wide spreadsheet. It is to create a retrieval path for each system whose operation creates meaningful obligations.

Use this sequence:

1. Name the system and its bounded use. Record the accountable owner, intended users, decision affected, and release or configuration being assessed.

2. Identify the constraints that actually apply. Include legal duties, contractual commitments, internal approval requirements, and operational conditions such as required human review.

3. Define the artifact before the control is implemented. State what the artifact must show, who creates it, where it is retained, and how it links to the named system.

4. Test retrieval on a date that was not chosen for a demonstration. Ask the engineer responsible for the fraud-scoring model to produce its approval record without advance notice, on an ordinary Tuesday, not the day before a board review. Record where retrieval fails, takes too long, or depends on personal knowledge.

5. Update the map when the system changes. A material change in use, data, model behaviour, access, or review process can invalidate the earlier evidence path.

The fourth step exposes the difference between an evidence programme and a documentation exercise. A collection of files becomes useful only when someone can locate the relevant one without reconstructing the history from memory.

This work should be sized as part of the delivery plan. Review and rework are operating costs, not administrative residue after deployment. What does enterprise AI cost after review and rework? is relevant because a system that needs continuous checking also needs an explicit plan for the records that checking creates.

More evidence does not solve every governance failure

A constraint map does not prove that an AI system is accurate, fair, secure, useful, or lawful. It proves that specified evidence exists and can be inspected. The quality of the underlying control still needs judgment.

It also does not turn an auditor’s conclusion into certainty. Auditors set scope and use testing methods appropriate to the engagement. The map improves the quality and availability of what they can inspect, but it cannot expand an engagement beyond its stated scope.

There is a cost to producing and retaining evidence. Bruegel estimates AI Act compliance costs for developers at €14,623 to €29,277, roughly 9 percent to 17 percent of total development costs. ⁵ Its analysis also warns that requirements that do not scale by developer size can favour firms able to absorb those costs. ⁵

That limit argues for proportionate artifacts, not for abandoning evidence. The right record is the smallest one that establishes the relevant fact for the named system and date. A policy remains useful because it states the rule. Governance begins when the organisation can show that the rule operated.