← Insights

An AI audit trail your examiner can verify, not just read.

A log that an administrator can edit is a narrative, not evidence.

GovernanceAIRA Fusion7 min read

When a regulator or internal auditor asks what an AI system did, most organisations can produce something: application logs, a spreadsheet export, screenshots. The harder question comes next. How do you know nobody changed it?

For most logging stacks the honest answer is that you do not. Anyone with enough database or log-platform access can alter or delete an entry, and nothing in the record would show it. That is fine for debugging. It is not fine for evidence.

What tamper-evidence actually requires

Tamper-evidence does not mean nobody can ever touch the data. It means any change is detectable. That takes three properties working together:

  1. Chaining. Each entry includes a cryptographic hash of its predecessor. Change any entry, and every hash after it stops matching. Deleting one breaks the chain at that point.
  2. Enforcement below the application. The database itself refuses updates and deletes on the audit table (write once, read many), so a bug or a compromised service cannot quietly rewrite history.
  3. Verification on demand. Anyone entitled to can recompute the chain and get a yes or no, rather than trusting the vendor's word.
The goal is not to make an auditor trust you. It is to make trust unnecessary.

The awkward part: legitimate maintenance

Real systems have retention policies. Records must eventually be archived or removed, and a naive WORM design makes that impossible or forces someone to switch the protection off. Switching protection off is exactly the event an auditor worries about.

In AIRA Nexus, maintenance such as retention runs only through an explicit, audited path. That path records itself, performs the operation and re-anchors the chain so that verification remains meaningful afterwards. The exception is part of the evidence rather than a hole in it.

What goes on the record

An audit trail is only as useful as its coverage. For AI, the entries that matter are:

  • every AI run, with the model used, attributed to a person or a service identity;
  • every policy decision, including the refusals;
  • every approval or rejection at a human-oversight gate, with who decided;
  • every administrative change to roles, entitlements, policies and guardrails.

Alongside the chain, per-node run records keep the inputs, model, latency, tokens, cost and output of each step, and past runs re-render exactly as they first appeared. The chain proves integrity; the run records provide the detail.

Try itThe security page has a live chain with real SHA-256 hashes. Edit an entry and watch verification fail at exactly that point.

Getting it out

Evidence that lives only inside the platform is only half useful. The AIRA audit log streams out as CSV or JSON to your SIEM, GRC platform or archive, so your existing controls and retention policies apply, and your auditors can work in tools they already trust.

AIRA does not certify your compliance. What it does is make the evidence behind your SOC 2, ISO/IEC 27001, EU AI Act, DORA or GDPR work something you can prove rather than merely assert.


Start with one workload

Prove it on your infrastructure, against your own criteria.

A scoped pilot runs AIRA Nexus inside your perimeter, on your models and your data, with success criteria written down before we start. Your security team reviews the real system, not a slide.