Audit-ready AI: how GRC teams prove every automated decision

If your organisation uses AI to make decisions - approve a loan, triage a claim, screen a candidate, route a support ticket, flag a transaction - then at some point an auditor, a regulator, or your own risk committee will ask a deceptively simple question: can you prove what that system decided, and that the record hasn't been changed? Analyst firms increasingly frame this as a board-level risk: Gartner predicts responsible AI will be a board-level priority by 2026, and McKinsey argues trustworthiness is the precondition for scaling generative AI.

For most enterprises, the honest answer today is "not really." The decision happened inside a model or an agent, the surrounding logs are fragmented across vendors, and nothing is signed in a way an outsider can verify. This guide is for the people who own that gap: auditors, governance, risk and compliance (GRC) teams, and the enterprises that answer to them.

What "auditable AI" actually means

"Auditable" is not a dashboard. It is a property of evidence. A decision is auditable when an independent person can take the record and confirm, without trusting the system that produced it:

1. Authenticity - the record was produced by your organisation's own key.
2. Integrity - the record cannot be edited after the fact without that edit being obvious.
3. Time - the decision is anchored to a trustworthy moment.
4. Provenance - the model version, prompt, inputs and routing outcome are captured.
5. Retention + erasure - content can be deleted on request without destroying the audit trail.
6. Verifiability - anyone can check the above offline, with no account.

If any one of these is missing, you don't have audit evidence - you have a story someone told you about what happened.

For the legal and architectural basis of these properties, see The Forensic Witness: why automated decisions need an independent record.

The evidence auditors actually need

When GRC teams review an AI control, they are looking for a small, specific set of guarantees. Here is the checklist, translated into plain language.

• Signed, not stamped. Each decision is signed with your organisation's own asymmetric key (Ed25519). A signature proves the record came from you and was not altered in transit or at rest.
• Chained, not stacked. Every entry is cryptographically linked to the one before it. Tamper with entry #42 and entries #43, #44, … all break. Auditors can detect tampering by re-checking the chain - no database required.
• Time-anchored. An independent RFC 3161 timestamp authority proves when a decision was signed. This turns "we think it was Tuesday" into "it was signed at 2026-07-14T09:31:02Z, independently witnessed."
• Logic captured. The record includes the model version, the relevant inputs (references, not raw PII), confidence or risk scores, and the routing outcome. That is the "meaningful information about the logic used" that transparency rules ask for.
• Verifiable erasure. When retention expires, content is redacted but a signed erasure proof keeps the chain anchor. Deletion is demonstrable; the rest of the evidence stays intact.
• Offline, trustless verification. Auditors can verify a receipt against your published public key with no login and no trust in the platform. The same check runs in a script, in court, or in a regulator's office.
• Portable. The evidence is in an open format your organisation controls, not locked inside one vendor's database.

Mapping to the frameworks you already report against

The good news: the same evidence satisfies several frameworks at once. You are not building a new control per regulation - you are building one evidence chain that multiple frameworks reuse.

If your control library already cites these, a verifiable decision record slots straight into the existing evidence matrix.

What a minimal evidence record contains

You don't need to store the model or the raw payload. You need a signed, canonical summary - the dkr-1 format Decision Keep uses is a good mental model:

• Organisation and receipt IDs - who, and which record.
• Canonical content hash - a reproducible hash of the decision inputs and outputs.
• Chain hash - links this entry to the previous one.
• Signature - your Ed25519 key over the chain hash.
• Timestamp token - an independent RFC 3161 proof of when.
• Governance capture - model version, confidence/risk scores, routing outcome, actor type.

Only the hash is published; the raw payload stays with you. That keeps the evidence useful without becoming a second copy of personal data.

How verification works (and why auditors trust it)

Verification is deliberately boring. Given a receipt and your published public key, the checker recomputes:

1. The content hash from the stored decision.
2. The chain hash and its link to the previous entry.
3. The signature against your public key.
4. Chain continuity back to the genesis entry.
5. The timestamp (if present).
6. The erasure proof (if the entry was deleted).

If all six hold, the record is authentic and intact. If any step fails, the checker says so - and says exactly where the chain broke. No trust in the platform required.

A record you can only verify by logging into the vendor's console is not auditable. Auditability means an auditor can prove your claims against you, not through you.

Common pitfalls GRC teams should watch for

• Plain logs presented as evidence. Editable logs prove intent, not fact.
• Screenshots and PDF exports. Easy to forge, impossible to re-verify.
• Vendor lock-in. If the only way to see the evidence is the vendor's UI, you don't own the evidence.
• PII in the audit trail. Storing full payloads creates a second compliance problem. Store references and hashes, not raw personal data.
• No time anchor. Without an independent timestamp, "when" is your word against theirs.

A five-step path to audit-ready AI

1. Inventory the decisions your AI systems make that carry risk or regulatory weight.
2. Capture each one as a signed record with model version and routing outcome.
3. Chain and timestamp so integrity and time are provable.
4. Verify offline on a schedule - treat a failed verification as a severity-1 control failure.
5. Retain and erase on policy, keeping signed erasure proofs.

None of this requires ripping out your models. It sits beside them, quietly producing the evidence your GRC team already needs.

A quick checklist for auditors reviewing an AI vendor

When a vendor says their AI is "auditable" or "governed," ask for:

• A sample receipt you can verify offline against a published public key.
• Proof the records are hash-chained and that tampering is detectable.
• Whether decisions are independently timestamped (RFC 3161).
• How erasure works and whether it leaves a signed proof.
• Whether the format is open and the evidence is exportable.
• Evidence the control runs in production, not just in a demo.

If a vendor can't do these, "auditable" is marketing.