AI Governance Evidence vs Audit Trail: What's the Difference and Why It Matters

If your regulator asked you to demonstrate exactly what an AI agent in your environment was doing eighteen months ago (what data it accessed, what outputs it produced, whether a human reviewed its decisions, and whether its behaviour matched its stated classification) could you do it?

Most organisations believe the answer is yes. They have logs. They have audit trails. They have activity records. In many cases, they have all three.

Most organisations are wrong. Logs, audit trails, and activity records are not governance evidence. The distinction is not semantic. It is the difference between satisfying a regulator and failing a supervision visit.

This article defines the distinction, explains why it matters under Article 26 of the EU AI Act and the ICO AI Governance Framework, and describes what AI governance evidence actually looks like in practice.

This is the foundational article in the AETHER Pulse content series. It defines the category that AETHER Pulse is built around.

What an Audit Trail Is

An audit trail is a chronological record of events in a system: who did what, when, in what sequence. Audit trails are a standard feature of enterprise software. Your CRM has one. Your cloud storage platform has one. Your identity provider has one.

Audit trails are useful. They support incident investigation, internal review, and basic accountability. They are not, however, governance evidence in the regulatory sense, for four specific reasons:

1. Audit trails are mutable

Log files can be edited, overwritten, or selectively deleted by anyone with sufficient system access. Without cryptographic verification, there is no way to confirm that the audit trail presented for review is identical to the audit trail that existed at the time of the events it records. A supervisor or auditor who receives log files cannot, without additional verification, confirm their integrity.

2. Audit trails are platform-specific

Your Google Workspace audit log records events within Google Workspace. Your Microsoft 365 logs record events within Microsoft 365. Your Salesforce activity log records events within Salesforce. None of these logs records cross-platform patterns: what an AI agent did across multiple platforms in a single operation.

For organisations where AI agents operate across multiple platforms (which describes most regulated enterprises in 2026) this means no single audit trail captures the full picture of what the agent did.

3. Audit trails are not reproducible in the regulatory sense

Presenting a log file in a supervision visit is not the same as presenting verifiable evidence of what the system was doing. A log file tells you what the system recorded. It does not tell you whether the record is complete, whether it has been altered, or whether it accurately captures the system's behaviour rather than the system's record of its behaviour, which may differ.

4. Audit trails do not capture governance context

An audit trail records events. It does not record the governance context in which those events occurred: whether a human reviewed the AI agent's output, whether the agent was operating within its classified risk parameters, whether the appropriate oversight function was active. Governance evidence captures both the events and the governance context around them.

What AI Governance Evidence Is

AI governance evidence is a structured, signed, verifiable artefact that captures the state of an AI system's deployment, risk classification, operational behaviour, and oversight at a specific point in time, in a form that can be verified as unaltered under examination at any future point.

The key properties that distinguish governance evidence from an audit trail are:

Cryptographic signing

A governance evidence pack is signed at the point of generation using a cryptographic algorithm (HMAC-SHA256 is the current standard) with a signing key specific to the tenant generating it. The signature is computed over the full content of the evidence pack in canonical form. At any future point, the signature can be re-computed over the presented content. If the content matches the signature, the evidence has not been altered. If it does not match, the content has been modified since signing.

This is not a feature of audit logs. It is what transforms a record into evidence.

Canonical serialisation

For a signature to be reproducible, the content being signed must be serialised in a canonical form: a deterministic, consistent representation that produces the same output regardless of when or where the serialisation occurs. JSON with consistent key ordering is a common approach. Without canonical serialisation, the same content can produce different byte sequences on different occasions, making signature verification unreliable.

Completeness: capturing governance context, not just events

A governance evidence pack captures more than what the AI agent did. It captures: the agent's risk classification at the time of the evidence generation, the human oversight status (who is responsible, whether oversight occurred), cross-platform findings that no single admin surface reveals, and the methodology by which findings were generated, so that the reasoning, not just the conclusion, can be reviewed.

Reproducibility under examination

Governance evidence must be reproducible. Not in the sense that the same events will recur, but in the sense that the evidence pack can be presented to a supervisor 24 months after generation, the signature verified, and the content confirmed as the same document that was generated at that time. This is what "reproducible under regulatory examination" means in practice.

AI governance evidence is not about having more records. It is about having records that can be verified as genuine, complete, and unaltered, by someone who was not present when they were created.

Why the Distinction Matters to Regulators

The regulatory standard for AI oversight documentation is not "we have logs." Under Article 26 of the EU AI Act, the standard is that deployers maintain records of AI system operation sufficient for regulatory examination. Under the ICO AI Governance Framework, Control 4 requires transparency and accountability documentation that demonstrates active governance, not just passive recording.

In a supervision visit, the question an FCA or ICO supervisor will ask is not "do you have audit logs?" It is: can you show me, in a verifiable form, what this AI system was doing on a specific date, who was responsible for its oversight, what findings your governance programme identified, and what actions were taken? Audit logs answer some of these questions. Signed governance evidence answers all of them.

There is also an insurance dimension. Cyber insurers and professional indemnity insurers are increasingly asking regulated firms to demonstrate AI governance capability as a condition of coverage. Governance evidence (signed, reproducible, comprehensive) is a materially stronger response to an insurer's due diligence questions than a folder of log files.

What an Evidence Pack Actually Contains

A well-structured AI governance evidence pack contains the following components:

• Agent inventory: a complete list of AI agents discovered in the environment at the time of generation, including platform, grant type, data access scope, and external communication status
• Risk classification: each agent's risk classification and the reasoning behind it, based on a documented methodology
• Cross-platform findings: toxic-combination patterns identified across platforms, with the specific agents and patterns involved
• Human oversight status: for each agent, whether human-in-the-loop oversight is in place and who holds that responsibility
• ICO / regulatory readiness scorecard: mapping of findings to specific regulatory controls
• Signing metadata: the timestamp, signing algorithm, key identifier, and signature value, sufficient to verify the pack's integrity

The entire pack is serialised in canonical JSON and signed before delivery. The signature is stored alongside the pack. Verification requires only the pack content, the signature, and access to the public component of the tenant signing key.

A Three-Question Test: Evidence or Logs?

Apply these three questions to your current AI governance documentation to determine whether you have evidence or logs:

1. If a regulator asked to see what an AI agent in your environment was doing twelve months ago, could you produce a document, signed at the time of generation, that has not been altered since? If not, you have logs, not evidence.
2. If your AI governance documentation was presented in a legal or supervisory proceeding, could an independent party verify that the documents are genuine and unaltered, without access to your internal systems? If not, you have logs, not evidence.
3. Does your current documentation capture cross-platform AI agent behaviour (what agents are doing across Google, Microsoft, Salesforce, and other platforms simultaneously) or does it reflect what each platform's own admin console shows? If the latter, you have partial logs, not evidence.

If any of these questions revealed a gap, you are not alone. Most regulated firms have logs. Almost none have governance evidence in the sense described here, yet. Article 26 changes that.

Further reading: How to Build an AI Agent Inventory on the inventory component of the evidence pack.

How AETHER Pulse Generates Governance Evidence

AETHER Pulse was designed from the ground up around the evidence generation requirement. Its architecture makes three specific choices that distinguish it from governance tools that generate audit trails:

• Deterministic findings logic. AETHER's toxic-combination detection uses deterministic rules, not probabilistic machine learning. This means the same input always produces the same finding, making findings reproducible and verifiable under examination. Probabilistic systems cannot make this guarantee.
• HMAC-SHA256 signing at generation. Every evidence pack is signed before it leaves the generation pipeline, using per-tenant signing keys. The signature covers the full canonical JSON content of the pack.
• Cross-platform stitching. AETHER connects to seven platforms and detects patterns across them, producing findings that no single platform's admin surface can generate.

Published methodology: aetherpulse.app/methodology

Frequently Asked Questions

Is HMAC-SHA256 signing sufficient for regulatory purposes?

HMAC-SHA256 is a well-established cryptographic signing algorithm used in financial services and regulatory contexts. It provides integrity verification (confirming that content has not been altered since signing). It does not provide non-repudiation (proof of who signed) in the way that PKI-based digital signatures do. For most AI governance evidence purposes, integrity verification is the primary requirement. Firms with specific non-repudiation requirements should assess whether additional signing infrastructure is needed.

What is canonical JSON?

Canonical JSON is JSON serialised with consistent, deterministic key ordering and formatting, so that the same data always produces the same byte sequence regardless of the implementation or platform used to generate it. Without canonical serialisation, JSON serialisation is non-deterministic (key order may vary), making cryptographic signature verification unreliable.

How often should governance evidence be generated?

Monthly generation aligned to risk committee meeting cycles is a defensible minimum for most regulated firms. Higher-risk deployments may warrant more frequent generation. The key is that the cadence is documented, followed, and evidenced, not that it is maximally frequent.

Can we use existing log management tools for AI governance evidence?

Existing log management tools (SIEM, SOAR, cloud logging services) can capture log data but typically do not sign it at generation or produce canonical, cross-platform governance evidence. They can supplement an evidence programme but are not a substitute for it.

See how AETHER Pulse generates signed governance evidence →