Key Takeaways
- By default, LLM pipelines emit no compliant audit record; audit-ready LLM logging must capture identity, timestamp, run context, tool calls, and policy enforcements per call.
- One unified log schema can satisfy HIPAA, SOC 2, and GDPR together when it reconciles the strictest retention window and records tamper-evidence.
- Redactions and decision lineage are the audit evidence that proves a call was compliant, without writing PII or PHI into the log.
The Production Problem: Every LLM Call Is an Unlogged Decision
A healthcare payer runs a claims-triage agent in production. An auditor asks a direct question: who accessed member M-4471's protected health information (PHI) through the model on March 3? The team opens its logs and cannot answer.
That is the failure mode. Modern agents are first-class actors. They pull data inbound, not just push prompts outbound. They reach through Model Context Protocol (MCP servers), tool endpoints, and retrieval calls that can return PHI into model context.
Standard application logs were not built for this. They record latency, errors, and throughput. They omit which identity issued the call, which context was assembled, which tool output returned, and which policy decision shaped the result [1].
The consequence is specific to regulated work. A claims-triage decision touches eligibility, benefits, and member records. When an auditor asks the payer to reconstruct one decision, latency graphs and error rates cannot rebuild what the model actually saw or did.
The problem is hard for three reasons:
- Non-determinism: identical inputs can produce different outputs.
- Runtime context: prompts are assembled on the fly from many sources.
- Inbound exposure: sensitive data can enter through tool calls before review [1].
This is where the principle matters: observability must precede autonomy. You cannot oversee an agent whose decisions you cannot reconstruct. The Fiddler AI Observability and Security Platform is built on that premise. The discipline still starts with the log itself.
Why Standard Logging and LLM Gateways Fall Short for Auditors
Teams reach for three things first: the large language model (LLM) gateway's request log, a security information and event management (SIEM) export, and per-framework tracing. Each breaks in a predictable way.
Gateway request logs usually attribute every call to a shared service account or one API key. In our experience, individual attribution is the hardest audit requirement to satisfy, and a shared credential erases it. The auditor wants a named person; the log names a robot.
Then comes the retention swing. Zero data retention (ZDR) settings protect privacy by discarding request and response bodies. That protects members, but it also destroys the evidence an auditor needs.
Teams then oscillate between two bad options:
- Logging everything creates PII risk.
- Logging nothing leaves no trail.
Per-framework tooling adds a third problem. A team might run one stack for claims triage, another for member support, and a third for coding. Each produces its own logging setup, leaving three disconnected records instead of one defensible trail.
Underneath all of this is a distinction worth stating plainly. Observability is capturing signals. Control is enforcing a policy decision and recording it.
A log that shows what happened, without recording which policy was applied, documents behavior but not compliance.
What Audit-Ready LLM Logging Must Capture
Audit-ready LLM logging starts with the record itself. A naive log stores prompt, response, and latency. An audit-ready record stores who, what, which version, which sources, which tools, and which action.
At minimum, capture these fields for every call:
- Request identity: the individual principal, never a shared service account.
- Timestamp: the request time recorded in UTC.
- Run context: a conversation or run ID linking the call to its session.
- Model and version: the exact pinned build, not a family name.
- Retrieval provenance: the sources that fed the prompt.
- Tool and MCP calls: name, arguments, permissions, and outputs.
- Policy enforcement: the guardrail decision applied to input and output.
Each field earns its place. Request identity answers who; retrieval provenance and tool calls answer what happened and how.
The policy enforcement answers whether the call was permitted. Together, these fields let you replay a decision instead of guessing at it.
Model version pinning is easy to underestimate. A family name like GPT-4 is insufficient. Behavior changes between builds, so pin the exact dated version so an auditor can reproduce the conditions of the call.
{
"request_id": "req_9f2c",
"timestamp": "2026-03-03T14:22:07Z",
"principal": {
"user_id": "u_3381",
"role": "claims_adjuster",
"auth_method": "oidc"
},
"run_id": "run_5522",
"model": {
"name": "gpt-4o",
"version": "2024-11-20"
},
"retrieval_sources": ["claims_db:member_records"],
"tool_calls": [
{
"name": "eligibility_lookup",
"arguments_ref": "sha256:8ad0...e91",
"permissions": ["read:claims"],
"output_ref": "sha256:12bf...7ac"
}
],
"policy_enforcement": { "input": "redact", "output": "allow" },
"storage": "append_only"
}
Two properties make this record defensible. First, tamper-evidence: write to append-only or WORM-style (write once, read many) storage so entries cannot be altered after the fact. Second, interoperability: the OpenTelemetry GenAI semantic conventions already define spans and traces for LLM and agent calls. They give teams a vendor-neutral field vocabulary [1].
Structurally, each call is a span. Span-level telemetry rolls up into aggregate insights across the agentic hierarchy, so the log becomes decision lineage rather than a flat event stream.
Mapping One Log Schema to HIPAA, SOC 2, and GDPR
One record, three evidence sets. The same fields answer different regulators, which is why parallel logging stacks are unnecessary.
The mapping is direct:
- HIPAA: audit controls under §164.312(b), plus authentication of individual users under §164.312(d) [2].
- GDPR: records of processing under Article 30, accountability under Article 5(2), and meaningful information about the logic of automated decisions under Article 22 [3].
- SOC 2: access controls under CC6 and system monitoring under CC7 [4].
- EU AI Act: automatic event logging over the system lifetime under Article 12, and at least six months of deployer log retention under Article 26(6) [5].
Article 22 is the reason an enforcement matters more than an output. An automated decision affecting a member needs a logged rationale, not just a returned answer [3].
Retention is where teams get burned. Design to the strictest applicable window, not the shortest:
- HIPAA: six years from creation or the date the record was last in effect, whichever is later [2].
- SOC 2: Type II observation periods typically run six to twelve months [4].
- EU AI Act: at least six months for deployers of high-risk systems under Article 26(6) [5].
Windows vary by jurisdiction and system risk class. Confirm the class before you set a policy. Setting retention to satisfy HIPAA's six years generally covers the shorter SOC 2 and EU AI Act minimums as well.
Tamper-evidence is the common thread across all three frameworks. Each regime expects records that cannot be quietly altered after the fact. Append-only storage and individual attribution turn a log into evidence rather than an internal note.
One schema then produces three evidence sets from a single defensible record.
Logging Policy Enforcements and Decision Lineage Without Storing PII
AI guardrails operate at two points on the request and response path. Define each before combining them.
- Pre-LLM guardrails: intercept inputs before they reach the model.
- Post-execution guardrails: inspect outputs before they are returned or acted on.
Used together, these guardrails let you log the enforcement, not the value. Record whether the decision was allow, block, or redact.
Use redact for PII, PHI, and secrets, so the request proceeds with the sensitive content removed. Reserve block for full rejection, such as a prompt injection attempt. The evaluation behind each enforcement can score checks such as PII and PHI detection, prompt-injection risk, and response groundedness.
This framing keeps data exposure broad. Data exposure covers any external service, API call, log store, or trace export that receives agent inputs or outputs. It is not limited to prompts sent to a model provider.
{
"request_id": "req_9f2c",
"timestamp": "2026-03-03T14:22:07Z",
"principal": "u_3381",
"guardrail": "pre_llm",
"enforcement": "redact",
"entity_type": "phi.member_id",
"match_count": 1,
"redacted_value_ref": "sha256:6b1f...a04",
"raw_value_stored": false
}
The record proves a decision was made without containing the sensitive value. A salted hash gives a non-reversible reference an auditor can correlate, while the raw PHI never touches the log.
Decision lineage is what ties these entries together. Capturing tool calls, retrieval provenance, and policy enforcement turns a stream of events into a reconstructable record of why the agent acted. Span-level telemetry rolls up across the agentic hierarchy, so a single member's decision path can be traced end to end.
This is where inline enforcement matters. Fiddler applies allow, block, and redact at the request and response path, before data leaves your network.
Those evaluations run on Fiddler Centor Models (formerly Fiddler Trust Models). Their Out of the Box and Customizable evaluators are batteries-included and run in-environment, making no external API calls and returning an enforcement in under 80ms response time. Centor Models are also framework, model, and cloud agnostic.
Running policy evaluation locally, rather than calling an external model to judge each output, avoids the Evaluation Trust Tax. That is the per-call cost external evaluation adds to your provider bill. The record then arrives as a byproduct of enforcement, not a separate logging effort bolted on afterward.
What to Watch For in an Audit
Auditors probe the same weak points. Watch for these five:
- Shared-account attribution: the log names a service account, not the individual who triggered the call.
- The vendor-log trap: your provider's log is not automatically your audit trail; you own the record.
- Over-redaction: stripping so aggressively that the record no longer proves what happened. Log the enforcement and a non-reversible reference instead.
- Confidence as reasoning: a confidence score is not an explanation; capture an explainable rationale instead.
- Loosest-window retention: setting retention to the shortest framework window rather than the strictest applicable one.
What Audit-Ready Logging Makes Possible Next
Audit-ready LLM logging changes what a compliance program can do. Once every call is a reconstructable, tamper-evident record, audit prep changes shape. It shifts from an evidence scramble into a query you can run in minutes.
Governance is the primary lens here, and security is a subset of it. Mature programs move beyond audit logs alone toward enterprise-wide visibility over every live, testing, and retired AI system. That AI registry view is the substance of Auditable Governance.
One problem remains open. Standards for logging multi-agent orchestration are still forming. The OpenTelemetry GenAI conventions cover single LLM and agent spans today.
Extensions for orchestration, shared memory, and sub-agent handoffs are proposed and under consideration, not yet shipped [1]. Until they settle, teams building multi-agent systems should log handoffs and sub-agent actions explicitly, rather than wait for a convention to define the fields.
Conclusion
Return to the claims-triage team. With a unified, tamper-evident record, the auditor's question about member M-4471 becomes a single query, not a week of forensics. The identity, the tool calls, and the redact inputs/outputs are all already on file.
The discipline is simple to state and hard to retrofit. Audit-ready LLM logging is a design choice made up front, not a cleanup task afterward.
Three steps turn this into a design choice rather than a cleanup task:
- Define the log schema first.
- Set retention to the strictest applicable window.
- Wire policy enforcement into the record from the first call.
Log the decision, not just the output.
References
[1] Microsoft, "Observability for Generative AI and agentic AI systems," Microsoft Learn (Secure Future Initiative), Mar. 17, 2026. [Online]. Available: https://learn.microsoft.com/en-us/security/zero-trust/sfi/observability-ai-systems
[2] Amazon Web Services, "Building a HIPAA-ready generative AI architecture for healthcare on AWS," AWS Industries Blog, Jun. 16, 2026. [Online]. Available: https://aws.amazon.com/blogs/industries/building-a-hipaa-ready-generative-ai-architecture-for-healthcare-on-aws/
[3] Microsoft, "Microsoft Support and Professional Services accountability readiness checklist for the GDPR," Microsoft Learn, May 5, 2026. [Online]. Available: https://learn.microsoft.com/en-us/compliance/regulatory/gdpr-arc-prof-services
[4] Towards Data Engineering, "Enterprise Data Pipeline Controls Checklist: Security, Auditability, and Compliance," Medium, Apr. 21, 2026. [Online]. Available: https://medium.com/towards-data-engineering/enterprise-data-pipeline-controls-checklist-security-auditability-and-compliance-b1b11f48cf95
[5] Atul, "The Complete Guide to EU AI Regulatory Compliance in 2026," Medium, Jan. 23, 2026. [Online]. Available: https://atul4u.medium.com/the-complete-guide-to-eu-ai-regulatory-compliance-in-2026-everything-you-need-to-know-about-the-ai-720a8947496e