Six surfaces, 24 named controls, five ways a governance program lies, and the scoreboard that keeps them honest. This is the standing regime a shipped AI system has to hold up under a year later, not a checklist for getting one feature past review.
A security review is questionnaire prep to get one feature past InfoSec, Privacy, Risk, and Procurement once, before it ships. Governance is what has to keep holding a year later: the register that still lists what's actually running, the checkpoint a reviewer can still meaningfully disagree through, the logs that can still reconstruct a specific decision. See the security review for the one-time gate; this page is the regime underneath it.
None of the six surfaces below are optional because a system isn't 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 and answer a question someone will eventually ask regardless of classification. The rest scales to what the classification actually 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 to 2 December 2027 for stand-alone systems and 2 August 2028 for systems embedded in other products. 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 depend on a compliance deadline: a register, a checkpoint a reviewer can actually contest, and a system card are worth building on the schedule your own risk already sets, independent of when a regulator starts checking. Regulation (EU) 2026/1744, EUR-Lex →
Each surface fails a different way. None of them substitute for each other.
Covers: Every system that touches a model, who is accountable for it, and how much decision weight it actually carries.
Breaks when: A team ships a new integration through an already-approved platform, and the fact that it now touches a model never reaches whoever keeps the register.
Watch: Register coverage
Covers: Which actions a system may take unattended, and whether the person at the checkpoint can meaningfully disagree with it.
Breaks when: The checkpoint exists on a diagram, but the reviewer sees only the proposed action, not the evidence behind it, so agreeing is the only answer the interface actually supports.
Watch: Oversight override rate
Covers: What was running, what it saw, and what it did, tied together well enough to answer for a specific past decision.
Breaks when: A log captures the prompt and the output, but not which model, index, or tool version produced them, so the exact decision can never be run 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 affected by it know AI is involved at all.
Breaks when: A system card exists in a wiki nobody outside engineering has read, so 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 actually commits to on training use, retention, and sub-processors, and whether that commitment still holds.
Breaks when: A vendor's terms were read once at the procurement stage, and nobody has re-checked them since, including after that vendor quietly added a sub-processor.
Watch: p95 vendor attestation age
Covers: What happens after launch: who watches it, what counts as an incident, and what re-triggers a review.
Breaks when: A dashboard tracks the right numbers, and the last person who looked at it left the company two quarters ago.
Watch: Declaration-to-report latency
Filter by how often it's exercised (continuous, periodic, triggered), then copy the visible list as a Markdown checklist.
Showing all 24 controls
Every governance question that follows assumes you can answer a prior one first: what AI is actually running, and who is accountable for it. That sounds trivial until a team ships a model call inside a feature nobody flagged as "AI," through a platform that was already approved for something else. This surface is the register that has to catch that case, classified by what a wrong decision would actually cost, not by which model or how large it is.
A human checkpoint that only ever approves isn't oversight, it's a delay with a signature on it. This surface is about designing the checkpoint so disagreement is a real, informed option: which actions never run unattended in the first place, what the reviewer actually gets to see before they decide, and what happens to someone who wants to contest an outcome after the fact.
A log that can't be reconstructed doesn't hold up once someone disputes a decision months later. This surface is what turns "we log things" into "we can answer for this specific decision": prompt, model, index, and tools versioned as one release, every decision's inputs and outputs logged against that version, retained past the window someone could dispute it, and provably reproducible on demand.
A system card only engineering can find doesn't disclose anything to the people who actually need it: procurement, legal, a new hire. This surface is the system card every model-touching system needs: purpose, limits, data, evals, and owner, written so procurement can hand it to a counterparty without you in the room, plus the separate, harder discipline of telling a user when they're talking to AI and would otherwise have assumed a person.
A vendor commitment you read once at signing and never checked again is worth exactly what you remember of it. This surface covers every provider a system depends on, including the open-weight models and libraries most inventories quietly exclude: which terms actually matter (training use, retention, sub-processors, residency), a re-attestation clock instead of a one-time procurement check, and a live answer to which data may cross which boundary, per system.
None of the five surfaces above are worth much once a system is live if nobody is actually watching it, or if watching it means a dashboard nobody opens. This surface is post-deployment monitoring with a named owner, a working definition of what counts as an AI incident and who gets to declare one, a rollback path rehearsed across model, prompt, index, and tool config, and a rule for when a system, its data, or the rules it operates under change enough to re-run the whole review.
No controls match that combination. Clear a filter to see more.
Every one of these looks like a passing program right up until someone asks to see the evidence.
Looks like: A written governance policy exists, and everyone can describe it accurately, but nobody can hand over the document, log, or evidence pack it supposedly requires.
Costs you: The first time an auditor, a regulator, or a diligence team asks to see the artifact instead of hearing the policy, the gap between the two becomes the finding.
Fix: Treat the artifact as the deliverable, not the policy. If the evidence pack can't be produced within a business day, the policy isn't actually 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, and the approval rate sits near 100% month after month.
Costs you: A near-universal approval rate is a finding about the checkpoint, not evidence the system is reliably right. It usually means the reviewer can't see enough to disagree, or doesn't have time to.
Fix: Redesign the checkpoint to surface the evidence behind a proposal, and track the reject rate as a health metric, not a nuisance number.
See the control: Design the checkpoint so the reviewer can actually disagree →Looks like: Every decision is logged, in detail, with a prompt and an output, but not which exact model, index, or tool configuration produced it.
Costs you: A log that can't be tied to a specific release can't be reconstructed. When someone disputes a decision, the answer becomes "probably" instead of a demonstration.
Fix: Version prompt, model, index, and tools as one release, and key every log entry to that version, not to a timestamp alone.
See the control: Version prompt, model, index and tools as one release →Looks like: A spreadsheet lists every AI system, updated by whoever remembers to, with no gate tied to it.
Costs you: New systems ship without an entry, decommissioned ones stay listed as live, and the register becomes a historical document rather than a current one, usually within a single quarter.
Fix: Tie registration to a real gate, a build or procurement step that can't complete without an entry, instead of relying on someone remembering.
See the control: Keep one register of every system that touches a model →Looks like: A vendor's terms were reviewed carefully once, at signing, and the resulting sign-off is treated as permanent.
Costs you: A vendor can add sub-processors, change retention terms, or shift training-data policy long after signing, and nothing in the process would ever notice.
Fix: Put every vendor on a re-attestation clock sized to the systems it supports, not a one-time procurement checkbox.
See the control: Re-attest vendors on a clock, not once at procurement →Every one of these is measurable today. None of them is trustworthy read alone. Pair it with the number next to it.
No invented compliance stats. Just what's already documented on this site, and what a real diligence pass actually 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 has to produce to survive an audit, a diligence pass, or a regulator's question. It's the controls we build for clients so the answer exists before someone asks, not a legal opinion on what applies to your organization. It is not legal advice; your counsel makes the actual compliance call for your situation.
A Ship Audit checks this program against your specific systems and tells you which surface is actually covered, versus which one just 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 and answer a question someone will eventually ask regardless of classification. Scale the rest, the oversight checkpoint, the re-attestation clock, to what the classification tier above actually calls for, rather than skipping the whole page because one label doesn't 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 to get one feature past InfoSec, Privacy, Risk, and Procurement once, before it ships. Governance is the standing regime that still has to hold a year later, long after that one review passed: register, oversight, records, disclosure, vendor re-attestation, incident reporting.
Link to this answer: Isn't this the same thing as the security review?Nobody, by default, which is exactly the inventory surface's first problem to fix. In practice it's a named individual, often in engineering leadership or risk rather than a dedicated AI ethics hire that doesn't exist yet, accountable for the register and the re-review trigger, with the actual checkpoint and disclosure work distributed to whoever owns each system.
Link to this answer: Who actually 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. See the linked insight for the specific dates and what stayed in place.
Link to this answer: What actually changed with the EU AI Act in 2026?Certification is a business decision about what a specific customer or deal requires, not a universal requirement. The underlying controls ISO/IEC 42001 asks for (a system inventory, a defined oversight process, documented risk treatment) largely overlap the six surfaces on this page, so building to this page gets most of the way there whether or not you ever pursue the certificate.
Link to this answer: Do we need ISO 42001 certification?The register entry for the system in question, its current system card, the last completed re-review, and a sample decision log with its version resolved end to end. If any one of those four takes more than a day to produce, that's the gap to close first.
Link to this answer: What do we actually hand an auditor on day one?Source: https://customlabs.io/governance/