Six surfaces, 24 named controls, five ways a governance program lies, and the scoreboard that keeps them honest. A shipped AI system must hold up under this standing regime a year later. This page is no checklist for getting one feature past review.
A security review is questionnaire prep. It gets one feature past InfoSec, Privacy, Risk, and Procurement once, before it ships. Governance must keep holding a year later. The register still lists what is running. A reviewer can still disagree at the checkpoint. The logs can still reconstruct a specific decision. See the security review for the one-time gate. This page describes the regime underneath it.
All six surfaces below apply to a system that is not classified as high-risk. A register, a named owner, and a system cardA system card is a short document stating an AI system's purpose, limits, and owner. cost little. They answer a question that someone will eventually ask, whatever the classification. Scale the rest to what the classification calls for.
As of 12 August 2026. Regulation (EU) 2026/1744 (the "Digital Omnibus on AI") deferred the EU AI Act's high-risk obligations. Stand-alone systems now have until 2 December 2027. Systems embedded in other products have until 2 August 2028. The Article 5 prohibited-practices regime, the transparency duties, and the general-purpose-AI obligations were not part of that deferral. None of the six surfaces below depends on a compliance deadline. Build a register and a system card on the schedule your own risk sets. Add a checkpoint that a reviewer can contest. Do not wait for a regulator to start checking. Regulation (EU) 2026/1744, EUR-Lex →
Each surface fails a different way. No surface can stand in for another.
Covers: Every system that touches a model, who is accountable for it, and how much decision weight it carries.
Breaks when: A team ships a new integration through an approved platform. The register keeper never learns that the integration now calls a model.
Watch: Register coverage
Covers: Which actions a system may take unattended, and whether the person at the checkpoint can disagree with it.
Breaks when: The checkpoint exists on a diagram. The reviewer sees the proposed action but not the evidence behind it. The interface only supports a yes.
Watch: Oversight override rate
Covers: What was running, what it saw, and what it did. The record must be complete enough to answer for one past decision.
Breaks when: A log captures the prompt and the output. It does not capture the model, index, or tool version that produced them. Nobody can run the decision again.
Watch: Share of decisions with a retrievable trace
Covers: What a system is for, what it must not be used for, and whether the people it affects know that AI is involved.
Breaks when: A system card sits in a wiki that nobody outside engineering has read. Procurement improvises an answer to a question the card already settled.
Watch: Share of live systems with a current system card
Covers: What a model or library provider commits to on training use, retention, and sub-processors, and whether that commitment still holds.
Breaks when: A team reads a vendor's terms once, at procurement. Nobody checks them again, even after the vendor adds a sub-processor without notice.
Watch: p95 vendor attestation age
Covers: What happens after launch: who watches the system, what counts as an incident, and what triggers a new review.
Breaks when: A dashboard tracks the right numbers. The last person who looked at it left the company two quarters ago.
Watch: Declaration-to-report latency
Filter by how often a control runs. Then copy the visible list as a Markdown checklist.
Showing all 24 controls
Every governance question starts with two answers: what AI is running, and who is accountable for it. This sounds easy until a team ships a model call in an unflagged feature. The platform already had approval for something else. This surface is the register that must catch that case. It classifies each system by the cost of a wrong decision. Model brand and model size do not matter here.
A human checkpoint that always approves is a delay with a signature on it. It is not oversight. This surface designs the checkpoint so that disagreement is a real, informed option. It sets which actions never run unattended. It sets what the reviewer sees before they decide. It also sets what happens when someone contests an outcome later.
A log that nobody can reconstruct fails when someone disputes a decision months later. This surface turns "we log things" into "we can answer for this decision." Version the prompt, model, index, and tools as one release. Log every decision's inputs and outputs against that version. Keep the logs past the dispute window. Prove on demand that you can reproduce a decision.
A system card that only engineering can find discloses nothing to procurement or a new hire. This surface is the system card that every model-touching system needs. It states purpose, limits, data, evals, and owner. Procurement can hand it to a counterparty without you in the room. This surface also covers a harder task: telling users when they talk to AI and would otherwise assume a person.
A vendor commitment that you read once at signing is worth only what you remember of it. This surface covers every provider that a system depends on. That includes the open-weight models and libraries that most inventories leave out. It names the terms that matter: training use, retention, sub-processors, and residency. It replaces the one-time procurement check with a re-attestation clock. It also answers, per system, which data may cross which boundary.
The first five surfaces lose their value after launch if nobody watches the system. A dashboard that nobody opens does not count. This surface sets post-deployment monitoring with a named owner. It defines what an AI incident is and who may declare one. It requires a rollback path that the team rehearses across model, prompt, index, and tool config. It also sets a rule for when the system, its data, or its rules change enough to re-run the whole review.
No controls match that combination. Clear a filter to see more.
Each of these looks like a passing program until someone asks to see the evidence.
Looks like: A written governance policy exists, and everyone can describe it accurately. Nobody can hand over the evidence pack that it requires.
Costs you: An auditor or a diligence team asks to see the artifact and does not accept a description of the policy. The gap between the two becomes the finding.
Fix: Treat the artifact as the deliverable. If you cannot produce the evidence pack within a business day, the policy is not implemented yet.
See the control: Keep an evidence pack procurement can read without you in the room →Looks like: A human checkpoint is in place. The approval rate sits near 100% month after month.
Costs you: A near-universal approval rate is a finding about the checkpoint. It does not show that the system is right. It usually means the reviewer cannot see enough to disagree, or has no time to.
Fix: Redesign the checkpoint to show the evidence behind a proposal. Track the reject rate as a health metric. Do not treat it as a nuisance number.
See the control: Design the checkpoint so the reviewer can disagree →Looks like: Every decision is logged in detail, with a prompt and an output. The log does not say which model, index, or tool configuration produced it.
Costs you: A log that cannot be tied to a release cannot be reconstructed. When someone disputes a decision, the answer is "probably" instead of a demonstration.
Fix: Version prompt, model, index, and tools as one release. Key every log entry to that version. A timestamp alone is not enough.
See the control: Version prompt, model, index and tools as one release →Looks like: A spreadsheet lists every AI system. Whoever remembers updates it. No gate is tied to it.
Costs you: New systems ship without an entry. Decommissioned systems stay listed as live. The register becomes a historical document, usually within one quarter.
Fix: Tie registration to a real gate: a build or procurement step that cannot complete without an entry. Do not rely on someone remembering.
See the control: Keep one register of every system that touches a model →Looks like: A team reviews a vendor's terms carefully once, at signing. The sign-off is then treated as permanent.
Costs you: A vendor can add sub-processors or change retention terms long after signing. Nothing in the process notices.
Fix: Put every vendor on a re-attestation clock sized to the systems it supports. A one-time procurement checkbox is not enough.
See the control: Re-attest vendors on a clock, not once at procurement →You can measure each of these today. No number is trustworthy alone. Pair each one with the number next to it.
We invented no compliance stats. This section lists what this site already documents and what a real diligence pass found.
The regulation text our governance page's compliance claims are checked against. Retrieved 2026-08-24.
The official guidance on the entry-into-force article our governance page cites. Retrieved 2026-08-24.
The risk-management functions our governance and adoption controls map onto. Retrieved 2026-08-24.
This page describes what a governance program must produce to survive an audit or a regulator's question. These are the controls we build for clients so the answer exists before someone asks. This page is not a legal opinion on what applies to your organization. It is not legal advice. Your counsel makes the compliance call for your situation.
A Ship Audit checks this program against your specific systems. It tells you which surface is covered and which surface only looks covered on paper.
What teams ask us before they stand up an AI governance program.
The register, an accountable owner, and a system card cost little. They answer a question that someone will eventually ask, whatever the classification. Scale the rest to what the classification tier calls for. This includes the oversight checkpoint and the re-attestation clock. Do not skip the whole page because one label does not apply.
Link to this answer: We're not building a high-risk system. Do we need any of this?No. The security review is questionnaire prep. It gets one feature past InfoSec, Privacy, Risk, and Procurement once, before it ships. Governance is the standing regime that must still hold a year later. It covers the register, oversight, records, disclosure, vendor re-attestation, and incident reporting.
Link to this answer: Isn't this the same thing as the security review?Nobody, by default. That is the first problem the inventory surface fixes. In practice, one named individual owns it. This person often sits in engineering leadership or risk. A dedicated AI ethics hire is rare at this size. The owner is accountable for the register and the re-review trigger. Whoever owns each system does the checkpoint and disclosure work for it.
Link to this answer: Who owns AI governance in a 200-person company?The high-risk compliance deadlines moved later. The prohibited-practices rules, the transparency duties, and the general-purpose-AI obligations did not move. See the linked insight for the dates and what stayed in place.
Link to this answer: What changed with the EU AI Act in 2026?Certification is a business decision. It depends on what a specific customer or deal requires. It is not a universal requirement. ISO/IEC 42001 asks for a system inventory, a defined oversight process, and documented risk treatment. These controls largely overlap the six surfaces on this page. If you build to this page, you get most of the way there. That holds whether or not you pursue the certificate.
Link to this answer: Do we need ISO 42001 certification?Hand over four items. The register entry for the system in question. Its current system card. The last completed re-review. A sample decision log with its version resolved end to end. If any one of the four takes more than a day to produce, close that gap first.
Link to this answer: What do we hand an auditor on day one?Source: https://customlabs.io/governance/