Everyone in the room said yes.

How AI risk and compliance actually runs inside a large European enterprise today — an inventory kept by asking around, evidence as attachments, verification as a "yes" in a meeting — and what a record would look like instead.

Oct 18, 2026 · Upendra Bhandari · Compliance

The room

It is the quarterly AI risk review. Fourteen people, one deck.

Slide nine lists the AI systems in scope. The CV screener, the customer-support assistant, the credit pre-check. Each row has an owner, a risk tier and a status column. Every status is green.

The compliance lead asks the platform owner whether human oversight is in place on the CV screener. "Yes, every rejection gets reviewed." Model risk asks whether it was evaluated before the last release. "Yes, we ran the test suite." Someone asks whether the guardrails are still running. "They are."

Minutes are taken. The deck is filed. The programme is on track.

Nothing said in that room was a lie. And nothing said in that room was evidence.

What the process actually is

Strip away the governance language and the AI risk process at most large enterprises is four things that do not touch each other.

An inventory kept by asking around. The register of AI systems is a spreadsheet someone fills in by emailing teams. It lags the estate by a quarter. It does not know that an agent was renamed, that a second one was added to the same workflow, or that one was quietly retired.

Obligations as a checklist. Legal mapped the Act to a list of controls. The list lives in a GRC tool or a wiki. Each control has a status, set by a person during a review cycle, with a free-text comment as the justification.

Evidence as attachments. When someone asks, the team produces a screenshot, a test report exported to PDF, a page describing the oversight procedure. It describes what the system is supposed to do. It was produced for the review, by the people being reviewed.

Verification as conversation. The check that any of it is true is the question in the room, answered by the owner, from memory. The second line asks, the first line says yes, and the minutes record that the question was asked.

Each piece is reasonable on its own. The failure is between them. The inventory does not know what runs. The checklist does not know what the inventory holds. The evidence is connected to neither. And the verification is a verbal commitment, made in good faith, by someone describing the system as they understood it the last time they looked.

The two failures this produces

The first is quiet drift. A control that was true in March stops being true in June, and nothing in the process can notice. The oversight step gets bypassed under load. The evaluation suite stops running when a CI job is disabled "temporarily". The judge behind a guardrail starts timing out, and the guardrail, configured to fail open, keeps reporting that it passed. The slide stays green, because it was never connected to the thing it describes.

The second is the question the process cannot answer. Not "do you have a policy for human oversight?", which it answers well, but "show me that it operated on this system, on these dates." A supervisor, an internal auditor, a counterparty's due-diligence team, a claimant's lawyer. The honest answer, from a process built on attestations, is that the firm believes so, and here is the paragraph that says it should.

Most organisations are a long way from that question. The readiness surveys published this year put a majority of firms at few or no concrete steps, many without an inventory at all. And the high-risk obligations of the EU AI Act now land at the end of 2027 for most standalone systems. That is not a reprieve so much as a window. Whether it is enough depends on which process you build inside it.

The principle

Here is the distinction that decides the whole thing.

Proof of compliance is a judgement. Proof of what the system did is a record.

A compliance verdict, that a control is satisfied, is a judgement that carries legal accountability, and it should stay a human one. But that judgement has to rest on something, and the something is where the current process fails. A sentence in a document is not a record of a system's behaviour. A test report produced by the team being tested is not a record that the test still runs. A "yes" in a meeting is not a record at all.

The record is the behaviour itself. The run that paused, and the person who resolved it. The evaluation that executed against this version, and the verdict it returned. The guardrail check that ran on this request and what it decided, or that it could not run and the traffic went through anyway. Those things happen whether or not anyone is compiling a deck. The question is whether anyone keeps them, binds them to the obligation they serve, and notices when they stop.

Three properties follow.

1. The evidence is drawn from the running system, not written about it afterwards.
2. The evidence is bound to a specific obligation on a specific system, so an unbacked verdict is visible as unbacked.
3. The binding is checked continuously, so a control that stops operating is found by the process, not by the next review, and not by an auditor.

What good looks like

Picture the same quarterly review, run on a record instead of a deck.

The inventory is the set of agents actually sending telemetry. Each belongs to exactly one registered system. A new agent that belongs to no system shows up as unassigned today, not as a surprise six months from now.

Each system is classified, and the classification decides which obligations apply. The compliance lead records a verdict on each one, as before. But every verdict is marked as evidence-backed or not. "Human oversight: satisfied" sits next to the human-approval records from the last quarter that back it, each linked to the run it came from, frozen when attached so it cannot be edited into shape afterwards.

The programme score is not a count of green rows. It counts the controls satisfied, and separately how many of the positive verdicts have anything behind them. Four satisfied controls with no evidence is a line on the home page, not a discovery during an audit.

And the process watches itself. A sweep runs every fifteen minutes. A safety control that errored while requests kept flowing becomes a finding against the system, with the runs behind it, without anyone filing it. A system that has gone thirty days without a passing evaluation gets a finding too. When the evidence comes back, the finding closes itself.

Every one of those acts, the registration, the classification, the verdict, the attachment, the finding, lands in an append-only, hash-chained ledger, written in the same transaction as the act itself. The record you hand an auditor is not compiled for the audit. It was already there.

The meeting still happens. It is shorter. Nobody is asked whether the guardrails are running. The question has a page.

The line that stays

None of this decides compliance for you. No verdict is set by software. Every status is a person's judgement, with their name on it in the ledger. What changes is what that judgement rests on: not a conversation, but a record of what the system did, kept continuously, bound to the obligation, and impossible to edit quietly.

That is the difference between a programme that can say yes and a programme that can show it.

FastAIAgent Enterprise is a control plane for governing AI agents, deployable on-premises or as managed SaaS. The companion film walks through the three acts above, the room, the drift and the record, on a live plane. Everything shown is the product running; nothing is a mock-up.

If your AI risk review still runs on a deck, get in touch. Happy to show you what the same review looks like on a record.

The companion piece, on binding evidence to the running system rather than the room it is reviewed in: Evidence, not attestation.