--- title: "Solution: Compliance and internal audit (by role)" canonical_url: "https://tokenobserve.com/solutions/compliance-and-audit" published: 2026-09-02 last_updated: 2026-10-21 --- # Solution: Compliance and internal audit (by role) Every mapping says this feature helps evidence that clause. None says installing it makes you compliant. ## The argument Token Observe produces the artefacts the AI governance clauses ask for, and it maps them clause by clause: EU AI Act deployer obligations at Articles 12, 14 and 26, ISO/IEC 42001 Annex A controls, the four NIST AI RMF functions, and the OWASP LLM and agentic top tens including the entries marked out of scope or partial. The evidence itself is a bundle covering traces and their events for a period, approvals with approver identity, timestamp and rationale, audit entries for every governance-plane change, a chain verification result, and a SHA-256 digest of the bundle taken at a recorded time. That envelope is digest-sealed rather than signed, and the difference is the first thing an auditor should be told. ## Facts - EU AI Act deployer articles mapped: Art 12, 14(1)–(4), 14(4)(e), 26(1), (2), (5), (6), (9), (12) - Management-system mappings: ISO/IEC 42001 Annex A and NIST AI RMF, control by mechanism - Evidence bundle: Traces, approvals, audit entries and a chain verdict, SHA-256 digest-sealed - Auditor rank: A first-class role; evidence reads are team-scoped and are themselves recorded ## The limit What the export is not: Digest-sealed, not signed: the digest catches accidental and post-export edits, it does not prove origin ## What this reader is under pressure about - 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. - 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. - 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. ## What this reader asks, and the answer Q: Does installing this make us compliant with the EU AI Act? A: 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. Q: Is the evidence export signed? A: 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. Q: Who says the head you are showing me is the head you showed me last month? A: 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. ### See 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. ### 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. ## The capabilities that matter most to this reader, in order - https://tokenobserve.com/platform/audit-chain - https://tokenobserve.com/platform/flight-recorder - https://tokenobserve.com/platform/human-approvals - https://tokenobserve.com/platform/agent-registry - https://tokenobserve.com/platform/effect-contracts ## Questions and answers Q: What is inside a compliance export? A: 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. Q: Is the audit log the same thing as the flight recorder? A: 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. Q: How does the product prove human oversight happened? A: 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.