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?

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.

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.

Framework	What it expects	How verifiable evidence helps
EU AI Act	Automatic logs and traceability for high-risk AI systems; post-market monitoring.	Signed, timestamped, hash-chained records are the trail; offline verification satisfies the "no trust in the provider" expectation. See Regulation (EU) 2024/1689.
ISO/IEC 42001	An AI management system with accountable, documented processes.	The record chain is the objective evidence of the process actually running, not just a policy on paper. See ISO/IEC 42001:2023.
NIST AI RMF (GOVERN/MEASURE/MONITOR)	Track, measure and monitor AI risks over time.	Immutable history lets you show what was decided and when, supporting continuous monitoring.
SOC 2 / SOX	IT general controls and financial-reporting controls must be complete and unaltered.	Tamper-evident logging is a textbook compensating control for system-of-record integrity.
GDPR / APP 1.7–1.9	Transparency about automated decisions; the right to erasure.	Logic is captured for transparency; verifiable erasure proves deletion while preserving the chain.

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.

Frequently asked questions

Is a decision log enough for an audit? Not on its own. A plain log can be edited after the fact, so it proves what someone claims happened, not what actually happened. Auditors need integrity guarantees — a signed, hash-chained record where changing any entry breaks the chain and is detectable.

How does verifiable AI evidence help with the EU AI Act? The EU AI Act requires providers and deployers to keep automatic logs of high-risk AI system use and to enable traceability and post-market monitoring. Signed, timestamped, hash-chained records give auditors exactly that trail, and offline verification means regulators do not have to trust the platform.

What is "verifiable erasure" and why do auditors care? Under GDPR and similar laws, individuals can demand deletion. Verifiable erasure redacts the content but leaves a signed proof that the chain anchor is preserved, so deletion is demonstrable without destroying auditability of everything else. It reconciles the right to erasure with the need for evidence.

Do we need a trusted timestamp authority? It strengthens the evidence but is not always mandatory. An independent RFC 3161 timestamp proves exactly when a decision was signed, which is hard to dispute. If the authority is unreachable, recording still succeeds; the entry is simply not externally time-anchored.

How is this different from model monitoring or observability? Observability tells you how a system is behaving now; audit evidence proves what a specific decision was, when, by which model version, and whether the record is intact. They are complementary — monitoring is operational, the record is juridical.

The bottom line

Audit-ready AI is not a research project. It is a discipline of producing, for every automated decision, a signed, chained, time-anchored, verifiable record your organisation controls. Build that once, and the EU AI Act, ISO/IEC 42001, SOC 2, SOX and GDPR requests all draw from the same evidence.

That is the whole idea behind Decision Keep: the independent, verifiable witness for AI decisions — self-hosted and sovereign, so the evidence never leaves infrastructure you control.

Where to go next

• See the receipt format. Read the dkr-1 receipt specification to see the exact fields auditors verify.
• Check a real record. Verify a sample receipt against a published key, with no account.
• Map it to your obligations. See how one evidence chain satisfies the EU AI Act, GDPR and Australia's APP 1.7–1.9.
• Hand it to procurement. Our security and procurement pack has the SOC 2 mapping and DPA template.
• Talk to us. Book a demo and we will map Decision Keep to your automated decision obligations.