Audit logging for every inference call.
What to log for HIPAA-aware LLM systems, what never to log, how long to keep it, and who can open the trail.
·9 min read
TL;DR
Every inference that can touch regulated data needs an audit event: who triggered it, when, which model/version, what tools ran, and whether it succeeded — without writing raw PHI into the log by default. Retention and access to that trail are product decisions, not afterthoughts.
What should you log for each LLM call?
Log actor identity, timestamp, request ID, model and prompt-template versions, tool names, latency, token counts, success/error class, and pointers to redacted payloads — not unrestricted raw prompts. The goal is reconstructability for incidents and audits without creating a second PHI warehouse in your log vendor.
A useful minimum event shape:
actor_id/ service identitysession_id/request_idmodel+model_versionprompt_template_id+template_versiontools_invoked[]retrieval_corpus_version(if RAG)latency_ms,input_tokens,output_tokensoutcome(ok / refused / error)policy_flags(safety refusal, empty retrieval, etc.)
Store hashes or object-store pointers to redacted prompt/response bodies when you need deeper forensics, with stricter access than the summary trail.
What should you never put in default LLM audit logs?
Never dump full PHI prompts, government IDs, full clinical notes, or secrets into a general-purpose log stream. Default-deny payload logging. If you must retain content for dispute or clinical review, isolate it behind tighter RBAC, encryption, and shorter or purpose-bound retention.
Common failure mode: “we enabled verbose LangSmith / OpenTelemetry and forgot prompts include patient names.”
Treat prompt bodies like production database rows:
- Separate summary audit (wide access for eng on-call) from content archive (narrow access)
- Scrub known identifier patterns before any content lands in the wide trail
- Ban pasting production traces into tickets without redaction
Eval datasets are another leak surface — same rules apply.
How do retention and access make the trail trustworthy?
Define who can read inference audits, how long events live, and how exports are approved. Immutable or append-only storage helps. If everyone on engineering can grep raw prompts, you do not have an audit system — you have a gossip channel.
Brandlabs sets these in Foundation phase:
- Retention windows per log class (summary vs content)
- Role-based access + break-glass procedure
- Alerting on anomalous inference volume or policy refusals
- Export path for customer or regulator requests
Wire the same IDs into postmortems so an incident becomes a regression fixture without rediscovering the request by folklore.
Frequently asked questions
Do we need to log every token of every response?
Usually no. Log enough metadata to reconstruct behavior and spot anomalies. Retain full content only when a documented purpose requires it.
Are vendor dashboards enough?
Rarely. You still need your own trail tied to your users, tenants, and policies. Vendor logs are a supplement, not your system of record.