# The AI Governance Layer: prove how the system behaves, and who's accountable.

Source: https://customlabs.io/governance/
Updated: 2026-09-20

Governance

# The AI Governance Layer: prove how the system behaves, and who's accountable.

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.

Updated September 20, 2026 · First published August 12, 2026

·

30 min read

·

Key takeaways

- → Rubber-stamp oversight is a named trap: an approval step nobody could actually block.
- → A hand-maintained register usually goes stale within a quarter.
- → Logs without versions can't prove which model version produced a given answer.
- → Oversight override rate tracks how often a human actually stops the system.
- → Time to reconstruct a named past answer is one of six scoreboard metrics.
- → A vendor can add a sub-processor long after signing, and nothing would notice.

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](https://customlabs.io/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 card](https://customlabs.io/glossary/system-card/) 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 →](https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng)

The six surfaces

## What a governance program actually has to cover.

Each surface fails a different way. None of them substitute for each other.

Six governance surfaces cover a system from its first registration to its last incident report.

01

### Inventory and classification

**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

02

### Human oversight

**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

03

### Records and traceability

**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

04

### Documentation and disclosure

**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

05

### Third-party and data assurance

**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

06

### Monitoring, incidents and change control

**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

The control bank

## 24 controls, six surfaces.

Filter by how often it's exercised (continuous, periodic, triggered), then copy the visible list as a Markdown checklist.

Continuous Periodic Triggered

Showing all 24 controls

Copy as Markdown

### 01 Inventory and classification

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.

#### Keep one register of every system that touches a model

Continuous

**What it covers**
A single, current list of every system in the organization that calls a model, however small the feature.

**How to build it**
One register, one owner, and a build or procurement gate that requires an entry before a model-touching feature ships.

**Produces**
A register that answers "what AI do we run" in one lookup instead of a round of Slack messages.

**Tradeoff**
A register nobody is required to update decays within a quarter (see the trap below). It needs a gate, not a request.

**Prove it**
Register coverage: share of systems actually running that have a current entry.

#### Name an accountable owner per system, not per team

Continuous

**What it covers**
One named person accountable for each system in the register, distinct from whichever team happens to maintain the code.

**How to build it**
A required "owner" field on the register entry, held by a named individual with the authority to pause the system, not a distribution list.

**Produces**
A single name to call when a system does something nobody expected, instead of a team that reassigns the question internally.

**Tradeoff**
Ownership has to survive reorgs and departures. An owner field that silently points at someone who left is worse than an honest blank.

**Prove it**
Share of register entries with a current, reachable owner.

#### Classify by decision impact, not model size

Triggered

**What it covers**
A tier per system based on what a wrong decision costs, independent of which model or how large it is.

**How to build it**
A short rubric, scored at registration and not inferred from the tech stack: does this decide something about a person, can it act without review, is the domain regulated.

**Produces**
A tier that tells you which of the other five surfaces to spend the most effort on for this specific system.

**Tradeoff**
A rubric that's too coarse puts everything in the same tier, which is the same as not classifying at all.

**Prove it**
Every register entry carries a tier, assigned before launch, not backfilled after a question.

[Glossary: High-risk AI system](https://customlabs.io/glossary/high-risk-ai-system/)

#### Define what counts as a substantial change

Periodic

**What it covers**
A written, specific definition of the change that forces a system back through classification and review.

**How to build it**
Name the triggers explicitly: a new data source, a materially different model, a new class of action the system can take. Review the list itself on a schedule so it doesn't quietly go stale.

**Produces**
A re-review that happens because a rule fired, not because someone happened to remember.

**Tradeoff**
Too broad a definition re-triggers review on routine changes and the team starts working around it; too narrow and real changes slip through untouched.

**Prove it**
Every re-review in the last period traces to a named trigger, not an ad hoc decision to check.

### 02 Human oversight

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.

#### Decide which actions never run unattended

Continuous

**What it covers**
An explicit, written list of the actions a given system may never take without a human confirming first.

**How to build it**
Name the irreversible or high-stakes actions at design time, things like a refund, a termination, a diagnosis, and route each through a checkpoint before it executes.

**Produces**
A hard boundary the system can't reason its way around, instead of a guideline it can talk itself past.

**Tradeoff**
Every action on this list adds latency and a person's attention. Put too much on it and the checkpoint becomes the thing everyone routes around.

**Prove it**
Zero unattended executions of a listed action, checked against the actual call logs, not the design doc.

[Pattern: Human checkpoint before irreversible](https://customlabs.io/patterns/human-checkpoint-before-irreversible/)

#### Design the checkpoint so the reviewer can actually disagree

Continuous

**What it covers**
What the person at the checkpoint actually sees before they approve or reject: the inputs and retrieved evidence behind a proposal, rather than the proposal alone.

**How to build it**
Surface the evidence the system used to reach its proposal alongside the proposal itself, and make rejection at least as easy as approval in the interface.

**Produces**
A checkpoint with a real reject rate, because rejecting is actually informed and actually easy.

**Tradeoff**
Showing full evidence takes more of the reviewer's time per decision. A checkpoint reviewers can't get through in the time they have gets rubber-stamped anyway.

**Prove it**
Reject rate above zero, and a reviewer who can explain a specific rejection from the evidence shown, not from outside knowledge.

#### Give the affected person a route to contest an outcome

Continuous

**What it covers**
A real path for someone affected by a system's decision to challenge it and reach a human, distinct from the system itself.

**How to build it**
A named contact or process, separate from the system itself, with a committed response time.

**Produces**
A dispute path that exists before the first complaint, not one improvised in response to it.

**Tradeoff**
A contest route that routes back into the same automated system it's meant to check isn't actually a route.

**Prove it**
Median time from a contest being raised to a human response, tracked, not assumed.

[Glossary: Human oversight](https://customlabs.io/glossary/human-oversight/)

#### Keep the people at the checkpoint competent

Periodic

**What it covers**
Whether the reviewer at a checkpoint actually understands what the system does and doesn't do well enough to catch a bad proposal.

**How to build it**
Onboarding and a refresher on the system's known failure modes for anyone who sits at a checkpoint, repeated as the system changes.

**Produces**
A reviewer who can name the specific way this system tends to be wrong, rather than a job title that happens to carry checkpoint access.

**Tradeoff**
Training takes time away from the review queue itself, and it goes stale as the system changes underneath the reviewer.

**Prove it**
Every checkpoint reviewer has completed training current to the system's last substantial change.

### 03 Records and traceability

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.

#### Version prompt, model, index and tools as one release

Continuous

**What it covers**
One version identifier that pins the exact prompt, model, index snapshot, and tool set live at a given time.

**How to build it**
Bundle the four into a single release artifact with one version tag, the same discipline a normal software release already applies to code.

**Produces**
A version number a log entry can point to, so "what was running" is a lookup, not a guess.

**Tradeoff**
Versioning all four together is more release overhead than shipping a prompt tweak on its own. The alternative is a log nobody can actually resolve.

**Prove it**
Every logged decision resolves to one version identifier, checked by trying to resolve one at random.

#### Log inputs, retrieved context, tool calls and output per decision

Continuous

**What it covers**
A single, complete log entry per decision: what went in, what was retrieved, what tools ran, and what came out.

**How to build it**
One structured log record per decision, keyed to the release version above, capturing all four elements instead of only the final output.

**Produces**
A decision that can be read back in full, not reconstructed from whichever pieces happened to get logged.

**Tradeoff**
Logging full inputs and retrieved context at this granularity is real storage and, for personal data, a real privacy-scoping decision, not a free add.

**Prove it**
A decision picked at random resolves to a complete log entry that someone actually checks, rather than one merely documented as policy.

#### Set retention that outlives the dispute window

Periodic

**What it covers**
A retention period for decision records long enough to cover however long someone has to actually dispute one.

**How to build it**
Set retention against the real dispute or audit window for the system's domain, not a generic default carried over from an unrelated policy.

**Produces**
A record that still exists when the dispute actually arrives, instead of one deleted on schedule a month before.

**Tradeoff**
Longer retention is more storage and a larger exposure if that storage is ever breached. Retention should match the actual window, not default to "forever."

**Prove it**
Retention period documented and checked against the system's real dispute or audit window, not left as a database default.

#### Prove reproduction: reconstruct one specific past answer on demand

Triggered

**What it covers**
Whether the exact system that produced a specific past answer can actually be reconstructed and re-run, rather than only described.

**How to build it**
Pick a real past decision, pull its version and log entry, and re-run it end to end against the same inputs, as a drill rather than a one-time proof.

**Produces**
A demonstrated answer to "can you show me how this decision was made," instead of an assertion that you could if asked.

**Tradeoff**
Running the drill takes real time from whoever owns the system, and it only proves what it actually tested.

**Prove it**
Time to reconstruct a named past answer, measured against a real drill, not estimated.

### 04 Documentation and disclosure

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 system card per system

Continuous

**What it covers**
One document per system stating its purpose, limits, data sources, eval results, and owner.

**How to build it**
A short, structured template filled in at launch and updated at every substantial change, stored somewhere outside the codebase.

**Produces**
A single document that answers most of what procurement, legal, or a new team member will ask, before they ask it.

**Tradeoff**
A system card that isn't updated at the same trigger as the re-review above just becomes another stale document.

**Prove it**
Every register entry links to a system card dated at or after the system's last substantial change.

[Glossary: System card](https://customlabs.io/glossary/system-card/)

#### State what it must not be used for

Continuous

**What it covers**
An explicit, written boundary on what the system must not be used for, distinct from a description of what it does.

**How to build it**
A stated out-of-scope list on the system card itself, informed by the classification tier above.

**Produces**
A written answer to "can we use this for X" that exists before someone asks it in production.

**Tradeoff**
A boundary stated once and never revisited drifts out of date as the system, and what people try to use it for, both change.

**Prove it**
The out-of-scope statement is current as of the last substantial-change review, not the original launch date.

#### Disclose AI involvement where a user would assume a human

Continuous

**What it covers**
Whether a user interacting with the system knows they're talking to, or being evaluated by, AI, in any case where they'd otherwise assume a person.

**How to build it**
A stated, visible disclosure at the point of interaction, not buried in a terms-of-service page nobody reads.

**Produces**
A user who isn't finding out after the fact that a decision or a conversation wasn't with a person.

**Tradeoff**
Over-disclosing on every trivial automation trains users to ignore the notice by the time it matters. Reserve it for cases where the assumption would genuinely be wrong.

**Prove it**
A fresh user, shown the interaction cold, correctly identifies whether AI was involved.

#### Keep an evidence pack procurement can read without you in the room

Triggered

**What it covers**
A standing package of system card, eval results, and data-flow summary that answers a procurement or diligence question without a live meeting.

**How to build it**
Assemble the pack from documents that already exist elsewhere on this list, kept current, not written fresh under deadline for each ask.

**Produces**
A same-day answer to a procurement questionnaire instead of a scramble that stalls the deal.

**Tradeoff**
An evidence pack that's only assembled when asked is the trap below wearing a different name. It has to be maintained, not produced on request.

**Prove it**
The pack for a given system can be handed over within one business day of being asked, checked as a drill.

[AI Security Review](https://customlabs.io/security-review/)

### 05 Third-party and data assurance

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.

#### Pin the provider terms that matter

Triggered

**What it covers**
The specific contract terms that actually govern risk: training-data use, retention, sub-processors, and data residency.

**How to build it**
Extract those four terms from every provider's agreement into the register entry itself, instead of leaving them inside a contract nobody re-opens.

**Produces**
A one-line answer to "does this vendor train on our data" instead of a search through a PDF.

**Tradeoff**
Contracts change. A pinned term that isn't re-checked against the current agreement is stale the moment the vendor updates its terms.

**Prove it**
Every third-party dependency has its four key terms recorded and dated.

#### Re-attest vendors on a clock, not once at procurement

Periodic

**What it covers**
A recurring check that a vendor's terms and posture still match what was true when you signed.

**How to build it**
A fixed re-attestation interval per vendor, tied to the system's classification tier, not a one-time procurement checkbox.

**Produces**
A caught change in vendor terms or sub-processors within the re-attestation window, not whenever someone happens to reread the contract.

**Tradeoff**
Re-attesting every vendor on the same schedule wastes effort on low-tier dependencies. Tie the interval to the tier the vendor actually supports.

**Prove it**
p95 vendor attestation age, tracked against the interval each vendor is supposed to sit on.

#### Track what data may cross which boundary, per system

Continuous

**What it covers**
A live answer to which categories of data a given system is allowed to send to which provider or region.

**How to build it**
A data-flow map per system, recorded on the register entry and checked against the provider terms pinned above.

**Produces**
A direct answer to a residency or data-transfer question, without tracing the call path by hand.

**Tradeoff**
The map is only as good as its last update. A new data source added to a system without updating the map reopens exactly the question it was built to answer.

**Prove it**
The data-flow map for a system matches its actual current inputs, checked, not assumed from the original design.

#### Treat open weights and libraries as part of the model boundary

Continuous

**What it covers**
Whether a self-hosted open-weight model or a third-party library counts as a governed dependency, the same as a hosted API.

**How to build it**
Include self-hosted models and any library that materially shapes model behavior in the same register and re-attestation process as an API vendor.

**Produces**
One consistent boundary instead of a governance program that only sees the dependencies that send an invoice.

**Tradeoff**
There's no procurement contract to trigger the review, so it has to be pulled in deliberately at registration instead of arriving automatically.

**Prove it**
Self-hosted models and behavior-shaping libraries appear in the register with the same fields as an API vendor.

[Compare: Open-weight vs. frontier API](https://customlabs.io/compare/open-weight-vs-frontier-api/)

### 06 Monitoring, incidents and change control

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.

#### Post-deployment monitoring someone owns, not a dashboard nobody opens

Continuous

**What it covers**
Whether a named person is actually watching the system's live behavior, rather than whether a dashboard merely exists.

**How to build it**
Assign the owner named in the register to check specific, named metrics on a defined cadence, with an alert path when they cross a threshold.

**Produces**
A caught regression the week it starts, not the quarter someone happens to open the dashboard.

**Tradeoff**
Monitoring that alerts on too much gets tuned out. Alert on the metrics that actually predict a governance failure, not everything measurable.

**Prove it**
The named owner can show the last time they acted on an alert from this system, beyond confirming the dashboard exists.

[Pattern: Trace-first observability](https://customlabs.io/patterns/trace-first-observability/)

#### Define what an AI incident is and who declares one

Periodic

**What it covers**
A written definition specific enough that two people looking at the same event agree on whether it's an incident.

**How to build it**
Name the categories that qualify: a harmful output that reached a user, an unattended action outside its allowed list, a confirmed injection. Name who has the authority to declare one, too.

**Produces**
A declared incident within the same day it happens, instead of a debate about whether it counts as one.

**Tradeoff**
A definition too broad turns routine bugs into incident-response events; too narrow and a real one gets waved off as ordinary.

**Prove it**
Declaration-to-report latency, measured from a real incident, not a tabletop exercise alone.

#### Rehearse rollback across model, prompt, index and tool config

Periodic

**What it covers**
Whether reverting a system to its last known-good version, versioned as one release above, actually works when tried.

**How to build it**
Run a real rollback drill on a schedule, rather than relying on a documented procedure nobody has executed.

**Produces**
A rollback that takes minutes because it's been done before, not one improvised for the first time during an actual incident.

**Tradeoff**
Rollback drills take engineering time on a schedule, whether or not anything is currently wrong.

**Prove it**
Time to complete a rollback drill, tracked per drill, not assumed from the runbook.

[Failure mode: Unbounded agent loop](https://customlabs.io/failure-modes/unbounded-agent-loop/)

#### Re-run the review when the system, the data or the rules change

Triggered

**What it covers**
Whether a substantial change, as defined in the inventory surface above, actually triggers a fresh pass through classification, oversight design, and disclosure.

**How to build it**
Wire the substantial-change trigger directly to a required re-review step, not a note to revisit it eventually.

**Produces**
A governance program that stays current with what the system actually became, not what it was at launch.

**Tradeoff**
Every re-review is real review time again. This only holds together if the substantial-change definition itself is neither too broad nor too narrow.

**Prove it**
Every substantial change in the last period has a matching, completed re-review on record.

No controls match that combination. Clear a filter to see more.

Five ways a governance program lies

## A policy is a claim, not an artifact.

Every one of these looks like a passing program right up until someone asks to see the evidence.

### A policy with no producible artifact

**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 →](https://customlabs.io/governance/#evidence-pack-procurement-can-read)

### Rubber-stamp oversight

**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 →](https://customlabs.io/governance/#design-checkpoint-for-real-disagreement)

### Logs without versions

**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 →](https://customlabs.io/governance/#version-release-as-one-unit)

### A hand-maintained register, stale within a quarter

**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 →](https://customlabs.io/governance/#register-of-systems)

### Vendor assurance frozen at the procurement date

**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 →](https://customlabs.io/governance/#reattest-vendors-on-a-clock)

The scoreboard

## Six numbers, and how each one lies.

Every one of these is measurable today. None of them is trustworthy read alone. Pair it with the number next to it.

### Register coverage

**Why it matters**
Whether "what AI do we run" has a one-lookup answer or a round of Slack messages.

**How it misleads**
A high coverage number can still describe a register nobody has reconciled against what's actually deployed for months.

**Pair with**
Days since the register was last verified against production

### Share of decisions with a retrievable trace

**Why it matters**
The direct measure of whether the records surface is a real capability or a policy document.

**How it misleads**
A high share can still hide a slow retrieval: the trace exists, but nobody has actually timed how long it takes to pull one.

**Pair with**
Median time to retrieve a named trace

### Oversight override rate

**Why it matters**
The number that separates a checkpoint that catches real problems from one that only ever agrees.

**How it misleads**
A healthy-looking override rate can still come from one overworked reviewer overriding everything near a deadline, not the checkpoint design working as intended.

**Pair with**
Reviewer time spent per checkpoint decision

### Time to reconstruct a named past answer

**Why it matters**
The most concrete test of whether the records surface actually works, run against one real decision instead of a policy claim.

**How it misleads**
A fast reconstruction time for one convenient, recent decision says nothing about whether an older one, near the edge of the retention window, still resolves at all.

**Pair with**
Retention window remaining for the decision reconstructed

### p95 vendor attestation age

**Why it matters**
How stale the oldest-checked fifth of your vendor commitments actually are, which the median alone won't show.

**How it misleads**
A young median age can still hide a handful of long-forgotten, high-tier vendor dependencies sitting well past their re-attestation window.

**Pair with**
Number of sub-processors added by a vendor since its last attestation

### Declaration-to-report latency for an AI incident

**Why it matters**
How long it takes a declared incident to reach whoever has to act on or disclose it.

**How it misleads**
A fast latency paired with zero incidents declared in a long period is at least as often a sign the definition is too narrow as a sign nothing went wrong.

**Pair with**
Number of incidents declared in the same period

What this is built from

## Verifiable, not claimed.

No invented compliance stats. Just what's already documented on this site, and what a real diligence pass actually found.

- The AI Security Review is questionnaire prep to get one feature past InfoSec, Privacy, Risk, and Procurement once. This page is the standing regime underneath it: the register, the checkpoint, the records that still have to hold a year after that review passed. [AI Security Review](https://customlabs.io/security-review/)
- The threat model behind [prompt injection](https://customlabs.io/glossary/prompt-injection/) is exactly the kind of thing a system card and a disclosed limits statement exist to have already answered before a reviewer asks. [Insight: Prompt injection is a data problem](https://customlabs.io/insights/prompt-injection-threat-model/)
- A two-week technical diligence pass found $1.4M of undisclosed re-platform cost behind an "AI-native" claim, because no register, eval framework, or vendor-concentration answer existed before the deal team asked. Classification and third-party assurance are what would have surfaced that earlier, for free. [Case study: The AI-native target that wasn't](https://customlabs.io/case-studies/ai-diligence-flagged-replatform-cost/)
- The AI Readiness Scorecard turns the classification and oversight questions on this page into a scored, documented read before you commit budget to a new system, rather than after it's already in the register. [AI Readiness Scorecard](https://customlabs.io/tools/ai-readiness/)
- The Delivery Record publishes six real defects this codebase shipped and the build-time check each one left behind. It's the same records-and-traceability discipline this page argues for, evidenced from our own history instead of asserted. [The Delivery Record](https://customlabs.io/delivery-record/)
- What actually moved in the EU AI Act's 2026 timeline change, and why the register, the traces, and the system card are worth building on the earlier schedule regardless of the deferral. [Insight: What actually moved in the AI Act deadline](https://customlabs.io/insights/ai-act-high-risk-deadline-moved/)

### Sources

- [EUR-Lex - Regulation (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng) The regulation text our governance page's compliance claims are checked against. Retrieved 2026-08-24.
- [European Commission - AI Act Service Desk: Article 113](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113) The official guidance on the entry-into-force article our governance page cites. Retrieved 2026-08-24.
- [NIST - AI Risk Management Framework (AI RMF 1.0)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf) 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.

Not sure what you could actually produce today

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.

[Book a Ship Audit →](https://customlabs.io/diagnostic/ship-audit/) [See the security review →](https://customlabs.io/security-review/)

Questions

## Before you tell a regulator or a buyer 'we have this.'

What teams ask us before they stand up an AI governance program.

01 We're not building a high-risk system. Do we need any of this? +

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.

02 Isn't this the same thing as the security review? +

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.

03 Who actually owns AI governance in a 200-person company? +

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.

04 What actually changed with the EU AI Act in 2026? +

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.

05 Do we need ISO 42001 certification? +

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.

06 What do we actually hand an auditor on day one? +

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.

Check the register, not the memory

A hand-maintained register usually goes stale within a quarter, and rubber-stamp oversight rarely gets caught until it matters. AI Readiness scores your own program against the same six surfaces this page maps.

[Score your governance program →](https://customlabs.io/tools/ai-readiness/) [Talk to us about readiness →](https://customlabs.io/services/readiness-diligence/)