Compliance and internal audit
Every mapping says this feature helps evidence that clause. None says installing it makes you compliant.
This is already on your desk.
- 01
The obligations phase in while the agents are already running
High-risk deployer duties arrive on 2 December 2027 for the uses listed in Annex III and on 2 August 2028 for products under Annex I. Retrofitting logging onto agents that have run ungoverned for a year is the expensive path, because the year you most need to evidence is the year nobody recorded. - 02
Your evidence has to survive being handed to someone who does not trust you
An exported log file proves nothing to a party who assumes you could have edited it. A bundle breaks the link at a known sequence number instead, against an edit that is casual or accidental, because at the unkeyed default an operator who recomputes every hash still verifies clean. - 03
You are asked for an AI inventory and handed a spreadsheet
An inventory maintained beside the runtime is updated by whoever remembers; the runtime is updated by whoever ships. The registry here is the record the gateway enforces against on every request, which is the only structural reason it cannot drift.
- 01
Does installing this make us compliant with the EU AI Act?
No, and the documentation says so above the mapping table. Every entry is phrased as this feature helps evidence that clause. Deciding risk tiers, running a fundamental-rights impact assessment and notifying authorities remain your duties, and the software is a compensating control that discharges no obligation you owe. What it produces is the artefact shape those clauses ask for: an enforced inventory, a declared purpose and named owner per agent, recorded approvals, a scoped stop capability, an exportable event record.
- 02
Is the evidence export signed?
No. Trace and compliance envelopes are digest-sealed: the recipient recomputes SHA-256 over the canonical JSON of the bundle and separately reads the embedded chain verification. That catches accidental and post-export edits, and it does not prove origin. Origin evidence comes from two things that must travel with the bundle: keyed audit, where entry digests are MACs under a key held outside the database, and an Ed25519 anchor retained independently of the database it attests.
- 03
Who says the head you are showing me is the head you showed me last month?
Not Token Observe, and that is what the anchor is for. The key that verifies a MAC is the key that could forge it, so the head is periodically signed with an Ed25519 key whose private half never leaves the signer, and published off-box. The claim it supports is one sentence: any copy of the anchors you kept off-box beats any rewrite made after you took it. What it does not close: key theft signs any history, and no anchor covers what came before the first.
Cloud custody and optional customer-hosted controls are described separately. The 24 limits we publish, and the 9 risks a named person has to accept in writing, are on one page.
What we do not claimSee which obligations the evidence covers.
Data and model poisoning is out of scope, because the product governs runtime traffic rather than training pipelines. Vector and embedding weaknesses are out of scope, because there is no retrieval layer. Improper output handling and misinformation are partial. The Article 12 entry carries its limit in the same sentence as its claim: a flight recorder and a hash-chained governance log, with no recording of hidden model reasoning.
- Art 14(4)(e), the stop capability
- A kill switch scoped to one agent, a team or everything, requiring an attributable actor and a reason. Evaluated first, and it beats every other gate.
- Art 26(1) and 26(2), instructions and oversight
- A declared purpose per agent, required at creation, and a named human owner rather than a team alias. Approver identity is recorded on every decision.
- Art 26(9), impact assessments
- The agent record carries a DPIA or FRIA reference in its metadata, and that reference travels into the recertification snapshot and the export.
- NIST AI RMF
- Govern is versioned, audited policy records; map is the registry's purpose, risk tier and grants; measure is the cost ledger and shadow findings; manage is circuit breakers, the kill switch and approval gates.
- beat 01Name the caller
- 1Authenticate
- 2Resolve the agent
Nothing is decided for an anonymous caller. The key resolves to one registered agent with a named owner, and its roles, its ceilings and any stop switch in force are read live from the store on every request, not from a cached copy, so a suspension takes effect on the next call instead of after a redeploy.
- beat 02Start the record, then read what is being sent
- 3Open the trace
- 4Sanitise
- 5Scan
The trace is opened before anything can refuse the request, which is why a blocked call is recorded as thoroughly as one that went through. Only then is the text normalised and scanned, in that order, so the detectors see what the model will read rather than what a human reviewer can see.
- beat 03Decide once
- 6Govern
- 6bIntersect with the named human
- 7Enact
One function returns one verdict: allow, block, or hold it for a named person to approve. Every check lives in that one place rather than scattered along the path, which is what makes it possible to read your rules and know what they do.
- beat 04Send it, and only then spend the money
- 8Route
- 9Call upstream
Routing fixes which provider and model will serve the call, so where an agent has a USD ceiling it is tested against the price you will pay, not the one the caller typed. Routing is also the last step that can still refuse locally: after it, the request has left your network.
- beat 05Govern the answer, then count the cost
- 10Govern the response
- 11Meter and record
A tool call the model proposes is judged before it reaches your agent. Metering runs last and on every ending, including the refusals and the streams a client abandoned halfway, because the tokens were spent either way and a partial trace is still evidence.
Step names and their grouping are the product’s own, and the order is encoded in the evaluator rather than drawn for the page.
Verify the chain without trusting the party under audit.
An offline verifier ships with the product: it touches no database and makes no network call, so it runs on a locked-down machine. You give it an anchor export and, out of band, the Ed25519 public key. It is required, because a signature checked against a key read out of the artefact being verified proves nothing.
It is not a substitute for the endpoint, and the endpoint is not a substitute for it. The endpoint walks the entry chain and confirms today's history is intact, but it is served by the party under audit. The verifier, run against a copy you took months ago, confirms that today's history is the one you were shown then.
This is what does the work.
Audit chain
Every administrative act hash-chained, and anchored with a signature your auditor can check alone.
Flight recorder
Every governed request in a timeline a compliance officer can read, and a search box that never writes SQL.
Human approvals
One human decision, bound to one exact payload, spendable once.
Questions
What is inside a compliance export?
Traces and their events for the period you requested; approvals with approver identity, timestamp and rationale; audit-log entries for every governance-plane change; a chain verification result; and a SHA-256 digest taken at a recorded time. Hidden reasoning is in none of it, from any provider. Model response text is in it only where conversation capture has been switched from its metadata default to redacted.
Is the audit log the same thing as the flight recorder?
No, and conflating them is the most common misreading. The flight recorder holds governed request evidence (routing and policy decisions, usage and, where conversation capture has been switched on rather than left at metadata, mask-redacted prompt, reply and tool text), and it is what retention and erasure act on. The audit log holds governance-plane changes only, never payloads, and is never touched by retention.
How does the product prove human oversight happened?
An approval is bound to one exact action payload, is single-use, and expires; consuming it requires the same payload hash, so it cannot be reused for a slightly different action. The record carries the approver's identity, time and rationale. Gates are risk-tiered so approvals stay rare enough to be read, because a queue nobody reads is worse than no gate at all.
Bring the objection that is not on this page.
Create a cloud account and workspace. No card or server installation. Model calls and Google BigQuery scans can incur separate provider charges.