LLM Audit Trail: What to Log for Every Model Call

The short answer: for every model call, record who asked and for which customer, which model and prompt version answered, which documents were retrieved, which tools were called, what the guardrails decided and whether a human approved the result, all under one request ID, in an append-only store with a retention period you chose on purpose. That record is what lets you answer the question every serious buyer eventually asks: show me what happened.

An Audit Trail Is Not Observability

Teams that already run tracing tools often assume they have an audit trail. They have something adjacent. Observability exists so engineers can find out why an answer was slow or wrong this week; the tools for that are compared in LLM observability and evaluation tools. An audit trail exists so that someone who does not trust you can establish what happened, possibly a year later.

Observability compared with an audit trail
	Observability	Audit trail
Reader	Your engineers	Auditors, customers, regulators
Coverage	Sampled is fine	Every event, no gaps
Mutability	Can be edited or dropped	Append-only
Retention	As long as it is useful	A defined period, written down

Keep them in separate stores joined by the request ID. Trying to make one tool serve both usually ends with either an audit store full of debug noise or a tracing tool whose retention nobody is allowed to change.

The Record for Every Model Call

These are the fields I put in the per-call record. Most cost nothing to capture at the moment of the call and are impossible to reconstruct afterwards.

Fields to record in an LLM audit trail for every model call
Field	Why it is there
request_id	Joins this record to every service log, trace and guardrail event for the same request.
timestamp	When the call started and ended, in UTC.
tenant and user	Which customer and which person. The first question in every incident.
action	What was attempted: an AI query, a document read, a permission change, a tool call.
model and version	The exact model identifier, not a friendly alias that silently moves.
prompt version	A version or hash of the system prompt and template, so the behaviour can be reproduced.
retrieved sources	Document and chunk IDs that went into the context window, not their text.
tool calls	Tool name, arguments and outcome for every call the model made or proposed.
guardrail decisions	Which input and output checks ran, and whether each passed, blocked or only logged.
human approval	Who approved a consequential action, and when. Empty is itself a finding.
tokens and latency	Input and output tokens and duration: cost attribution and anomaly detection.
outcome	Success, refusal, error or fallback, including which provider served a failover.

Two fields do most of the work. The request ID, generated at the edge and carried through every service, is what turns scattered logs into one story. The retrieved source IDs are what let you show whether a bad answer was the model inventing something or a document saying it, which is also the first question in any prompt-injection investigation.

Log the Actions Around the Model Too

An AI incident is rarely only about the model. Sign-ins, document uploads and downloads, permission changes and exports belong in the same audit store with the same request ID, so that “who uploaded the document that steered this answer” is a query rather than an investigation.

On an AI platform for pharmaceutical manufacturers, the starting point before its enterprise pilots was no audit trail and no AI traceability at all. The fix was an audit logger with standardised fields covering more than twelve critical actions, from authentication and document changes to every AI query; request IDs propagated across services; a trace record per model call holding the tenant, user, request ID, latency and token counts; and 365-day append-only retention. It took a dedicated two-week milestone of a seven-week engagement. Built in from the start, most of it would have been close to free.

Agents Need Step-Level Records

A chatbot makes one call per question. An agent makes a chain of them, and the dangerous part is not what it says but what it does. Give the whole run one trace ID and record each step under it: every model call, every tool call with its arguments and result, every guardrail decision, and every human approval or the absence of one.

If a tool can send, write, pay or delete, the approval record matters more than anything else in the log. “The agent did it” is not an answer an auditor accepts; “the agent proposed it, this person approved it at this time” is.

What Not to Put in the Audit Store

Full prompts and answers are the most useful evidence you hold and the most sensitive, because they contain whatever users pasted in. Putting them into an append-only store with a long retention period creates a record you cannot delete when a person asks you to.

The pattern that resolves this: the structured metadata above goes in the append-only audit store for the full retention period, and the full text goes in a separate store with tighter access, shorter retention and a working deletion path, joined by the request ID. The erasure side of that design, including embeddings, is covered in right to erasure in vector databases.

What the EU AI Act, SOC 2 and ISO 27001 Expect

EU AI Act, Article 12. High-risk systems “shall technically allow for the automatic recording of events (logs) over the lifetime of the system”, to trace risks, support post-market monitoring and monitor operation (AI Act Service Desk). Article 19 (providers) and Article 26(6) (deployers) set a retention minimum of six months unless other law says otherwise. Whether your product is high-risk, and whether you are the provider or the deployer, is worked through in the EU AI Act for UK and US companies.
ISO/IEC 27001:2022. Annex A control 8.15 is titled Logging: produce, store, protect and analyse logs of activities and events. An AI query is an activity; auditors increasingly expect to see it logged like any other.
SOC 2. Auditors test that you monitor your system and can evidence it over the audit period. For an AI product, the model calls are part of the system.
Regulated life sciences. 21 CFR Part 11 has its own audit-trail requirements; how they apply to LLM systems is in validating LLM systems for Part 11.

How to Check Yours in an Afternoon

Pick one real AI answer from last week. Can you find its record from the answer alone?
From that record, can you name the model version, prompt version and source documents?
Try to edit or delete the record with the application’s own credentials. It should fail.
Find the retention setting. Is it a decision someone wrote down, or a default?
Pick a user. Can you delete their prompt text without breaking the audit record?

Five yeses is rare. Each no is a small piece of work now and a large one after an incident.

Frequently Asked Questions

What is an LLM audit trail?

A tamper-resistant record of every model call and every security-relevant action around it: who asked, on behalf of which customer, which model and prompt version answered, which documents were retrieved, which tools were called and what the guardrails decided. Its purpose is to answer, months later and to someone who does not trust you, what the system saw, what it produced and who acted on it.

What is the difference between LLM observability and an LLM audit trail?

Observability is for engineers debugging quality and latency this week; it is sampled, mutable and kept for as long as it is useful. An audit trail is for auditors, customers and regulators after the fact; it must be complete, append-only and kept for a defined period. The same request ID can join them, but they should not be the same store, because the retention and mutability rules conflict.

Does the EU AI Act require logging of LLM calls?

For high-risk AI systems, yes. Article 12 says high-risk systems shall technically allow for the automatic recording of events over the lifetime of the system, so that risks, post-market monitoring and operation can be traced. Article 19 requires providers, and Article 26(6) deployers, to keep those logs for a period appropriate to the intended purpose of at least six months, unless other law says otherwise. Systems outside the high-risk tiers are not bound by Article 12, but enterprise customers increasingly ask for the same capability.

Should you log full prompts and responses?

Log them deliberately rather than by default. Full prompts and answers are the most useful evidence and the most sensitive data you hold, because they contain whatever users pasted in. A common pattern is to keep the structured metadata of every call in the append-only audit store for the full retention period, and keep the full text in a separate store with access controls, a shorter retention period and a deletion path, joined by the request ID.

How do you audit an AI agent that calls tools?

Give the whole run one trace ID and log every step under it: each model call, each tool call with its arguments and result status, each guardrail decision and each human approval. The question an auditor asks of an agent is not what the model said but what it did and who allowed it, so tool calls and approvals matter more than the text of the model’s reasoning.

Cheap Now, Impossible Later

Every field in this record is nearly free to capture at the moment of the call and nearly impossible to recover afterwards. The audit trail is one of six areas in the LLM security checklist. If you want someone to check yours, and the rest of the design, before an enterprise customer or regulator does, an AI security and architecture review covers it for teams in the UK, US and Europe.