Turning AI logs into evidence auditors accept

Every AI system we run in production produces a lot of logs. The gateway records each model call and tool invocation, the orchestrator records each step an agent takes, the evaluation suite records each release candidate's scores, and the approval screens record who said yes. When an auditor, a regulator or an enterprise customer's risk team asks "show me how this system is controlled", none of those logs on its own is an answer. Logs are raw material. Evidence is a log that is attributable, complete, tamper-evident, retained for the right period and tied to a specific control.

The pressure to produce that evidence is now concrete. The EU AI Act has applied its prohibitions and AI literacy duty since 2 February 2025 and its general-purpose AI model obligations since 2 August 2025. The Digital Omnibus on AI, adopted as Regulation (EU) 2026/1744 and in force since 27 July 2026, moved the main high-risk obligations: stand-alone Annex III systems now apply from 2 December 2027 and systems embedded in Annex I regulated products from 2 August 2028 (summary of the amended text; Gibson Dunn analysis). That is extra time, not a reprieve, and building an evidence trail retrospectively is far harder than building it as you go. Meanwhile, customers are already asking for ISO/IEC 42001 certification and answers framed around the NIST AI Risk Management Framework.

This article describes how we turn agent, gateway and evaluation logs into an evidence base that serves all three frameworks at once, what auditors actually ask for, and where the approach strains. It is not legal advice; which obligations apply to you depends on your role (provider or deployer) and how each system is classified, and that analysis needs your counsel.

Three frameworks, one evidence base

The three frameworks differ in legal force and vocabulary, but they ask for overlapping things. The EU AI Act is law, with specific duties for high-risk systems: a risk management system (Article 9), data governance (Article 10), technical documentation (Article 11 and Annex IV), automatic record-keeping of events over the system's lifetime (Article 12), human oversight (Article 14), accuracy, robustness and cybersecurity (Article 15), a quality management system (Article 17), and post-market monitoring (Article 72). Providers must keep automatically generated logs for at least six months (Article 19), and deployers of high-risk systems have the same minimum for logs under their control (Article 26).

NIST AI RMF 1.0 is voluntary and organised around four functions: Govern, Map, Measure and Manage. Its Generative AI Profile (NIST AI 600-1) adds risks and suggested actions specific to generative systems, such as confabulation and information integrity. ISO/IEC 42001:2023 is a certifiable management system standard in the same family as ISO 27001: it requires an AI policy, risk and impact assessment, operational controls, monitoring, internal audit and management review, with a set of reference controls in Annex A.

We do not run three compliance programmes. We keep one inventory of systems, one control library and one evidence store, and map each control to the clauses it satisfies. The table shows how a few common evidence types line up.

What auditors actually ask for

The questions are less exotic than the frameworks suggest. In management-system audits, and in the questionnaires enterprise customers send their AI suppliers, the requests cluster around a handful of themes.

1. An inventory: every AI system, its owner, its purpose, its risk classification and why.
2. The risk assessment for a chosen system and the controls that address each risk.
3. Proof that each control operated over the period, not just that it was designed.
4. A trace of one specific decision, chosen by the auditor, from input to outcome.
5. The evaluation results that justified the version in production when that decision was made.
6. Incidents, how they were found, and what changed afterwards.

Items three and four are where most programmes fall down. Design evidence (a policy, a diagram, a control description) is easy to write. Operating evidence requires showing that the control ran every time, over months, and that exceptions were caught. And the sampled trace tests whether your logs join up: can you go from a customer complaint about one decision to the model version, the prompt version, the retrieved documents, the tools called, the approver and the evaluation run that cleared the release?

From logs to evidence

We treat evidence as a pipeline with its own design. Logs from each layer are normalised into a common event schema, linked by trace and version identifiers, written to an append-only store, and queried by control tests that produce evidence packs. Figure 1 shows the flow.

Five properties turn a log line into evidence. It must be attributable: every event carries the human or agent identity that caused it, issued by the identity provider rather than self-declared, which is why we route agent tool calls through AgentGate with per-agent credentials. It must be complete: the gateway logs every call, including refusals and errors, and a reconciliation job compares counts across layers so gaps are detected. It must be linked: each event carries a trace ID and the versions of model, prompt, tool set and retrieval index in force. It must be tamper-evident: our Ledger accelerator chains each batch of events with a hash of the previous batch and anchors the chain head periodically, so a deleted or altered record breaks verification. And it must be retained for a stated period per system, at least the six months the Act sets for high-risk logs and usually longer to cover contract and limitation periods.

On the format, we follow the OpenTelemetry semantic conventions for generative AI for model and agent spans, extended with governance attributes. The conventions are still marked as in development, so we pin a version and map forward when they change. Using a standard schema means the same traces serve engineers debugging latency and auditors sampling decisions.

A worked example: tracing one decision

Take an illustrative case. A customer-service agent runs at the Approve level: it can draft a credit note for a disputed delivery, but a named person must approve anything above a threshold before it posts to the ERP. Months later, a customer disputes a refusal, and an auditor picks that case for sampling.

The evidence query starts from the ticket ID and returns a linked record set. A condensed version of the approval event looks like this:

{
  "event": "approval.decision",
  "trace_id": "4f2c9a1e7b",
  "ts": "2026-09-14T10:22:41Z",
  "system_id": "cs-credit-agent",
  "autonomy_level": "approve",
  "actor": { "type": "human", "id": "idp:u-20931", "role": "cs-supervisor" },
  "proposed_by": { "type": "agent", "id": "agentgate:cs-credit-agent" },
  "decision": "rejected",
  "reason_code": "evidence_insufficient",
  "versions": { "model": "m-2026-07", "prompt": "credit-v14", "tools": "cs-tools-v9", "eval_run": "ev-1187" },
  "evidence_refs": ["pod:SHP-77120", "ticket:CS-44102"],
  "prev_hash": "b81e...", "hash": "09ad..."
}

From that record the auditor can follow the trace ID to the agent's steps (which documents it retrieved, which tools it called, what it proposed), the eval run ID to the scores that cleared prompt version 14 for release, and the actor ID to the supervisor's role and training record. Personal data stays in the source systems; the evidence store holds references and pseudonymous IDs, which keeps the store useful for audit without turning it into a second copy of every customer conversation.

Continuous control testing

Evidence packs assembled by hand the week before an audit tend to show what the team hoped happened. We write each control as a test that runs on a schedule against the evidence store, through our Assure accelerator, and keep the results. A control such as "every Approve-level action above the threshold has a recorded human decision before execution" becomes a query that looks for execution events without a preceding approval event in the same trace. Zero results is the pass condition; any result opens an incident.

Other controls follow the same pattern. Every production release has an evaluation run that met its gate. No agent called a tool outside its allow-list (the gateway would have blocked it, and the test confirms blocks are logged and reviewed). Revocation of a user's access propagated to retrieval within the agreed time. Retention jobs deleted what they should and nothing else. The output of a quarter's runs is the operating evidence auditors ask for in item three above, and it costs almost nothing to produce on the day.

Where it breaks

Logging everything collides with data protection. Full prompts and outputs can contain personal data, trade secrets and the content of privileged documents. Keeping them for years to satisfy one regime can breach the data minimisation and storage limitation principles of another. Our default is to log full content for a short, defined window for debugging and incident response, then keep only structured events, hashes and references for the long retention period. Where a regulator or contract needs the content itself, that system gets an explicit exception with access controls of its own.

Third-party models and tools are the second gap. If a hosted model provider changes behaviour under the same model name, your version record is wrong without your knowing. Pin model versions where the provider allows it, record provider-reported identifiers on every call, and run a small canary evaluation daily so drift shows up as a score change rather than as a customer complaint.

The third is classification drift. A system is assessed as low-risk at launch, then someone adds a feature that ranks job applicants or scores creditworthiness, and it quietly becomes an Annex III use case. The inventory has to be tied to change control: a change that alters a system's purpose, users or decisions triggers reassessment before release, not at the next annual review.

Finally, tooling does not make a management system. ISO/IEC 42001 auditors will ask about management review, competence, internal audit and continual improvement, and no evidence store answers those for you. We would start smaller than most programmes do: one inventory, five controls tested continuously on the highest-risk system, and a rehearsed sampled trace, before any attempt at certification.

A starting checklist

For each AI system in production, confirm the following before your next audit or customer review:

1. It is in the inventory with an owner, purpose, risk classification and the reasoning for that classification.
2. Every model call, tool call and approval carries an identity from your identity provider and a trace ID.
3. Every event records the model, prompt, tool set and index versions in force, and each release links to an evaluation run.
4. Events are stored append-only with a hash chain you can verify, for a written retention period of at least six months.
5. At least the key controls run as scheduled tests against the evidence store, with results kept.
6. You have rehearsed tracing one randomly chosen decision end to end in under an hour.

The last item is the best single test of readiness. If the trace takes a day and three engineers, the logs exist but the evidence does not.