An audit trail for an AI-assisted decision answers four questions: what did the model produce, what exact configuration produced it, who saw it, and what did they decide? None of this is exotic — it is the same discipline you apply to any system of record. What surprises many teams is the first hard fact: you cannot reconstruct this later from the provider's side, so the record has to be built into your application from day one.
Why the provider's logs won't save you
Anthropic's stated default for the Claude API is to automatically delete inputs and outputs on its backend within 30 days of receipt or generation, and conversation content is not retained by default for API features. Organizations with a zero-data-retention (ZDR) arrangement go further: customer data is not stored at rest after the API response is returned, except where needed to comply with law or combat misuse. On Amazon Bedrock and Google Cloud, the cloud provider — not Anthropic — is the data processor, with its own retention policies.
The upshot is the same on every platform: if a Claude output influenced a business decision, the durable record of that output must live in your systems. Treat the API as stateless from an evidence perspective.
When to record
Recording every API call verbatim is usually overkill and creates its own data-protection burden. A workable rule: create an audit record whenever a Claude output is presented to a decision-maker or acted on automatically in a way that affects money, people, or external commitments. Drafts a human rewrites entirely, internal brainstorming, and throwaway queries generally don't need decision-grade records — request-level operational logging is enough there. For help drawing that line, see defining high-stakes outputs and risk tiering.
What metadata to capture
| Field | Why it matters |
|---|---|
| Response ID and timestamp | Correlates your record with provider-side billing and support investigations. |
| Model ID from the response | Every Claude model ID is a pinned snapshot, so the ID names the exact model version that answered — record it, don't assume it. |
| System prompt version | Behavior depends on the prompt as much as the model. See system prompt version control. |
| Input reference or hash | A pointer or cryptographic hash of the input; store raw text only if your data-handling rules allow it. |
| The output itself | The thing the decision rested on. Store it verbatim. |
Usage fields (incl. inference_geo where applicable) | On the Claude API and Claude Platform on AWS, the response usage object reports where inference actually ran — useful for residency questions. |
| Human reviewer and disposition | Who read it, and whether they accepted, edited, or overrode it. |
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="acme-ai", region="global")
msg = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
messages=[{"role": "user", "content": case_summary}],
)
audit_record = {
"response_id": msg.id, # provider-issued identifier
"model": msg.model, # pinned snapshot that answered
"prompt_version": "credit-memo-v14",
"output_text": text_of(msg), # store verbatim
"reviewed_by": reviewer_email, # filled in at decision time
}How long to retain the record
This is a legal question, not an engineering one. Retention obligations vary by industry, jurisdiction, and the kind of decision involved — confirm the required period with your counsel before setting a deletion schedule. As a rough calibration point, Anthropic's own Compliance API retains its Activity Feed data for six years, and financial-services and employment contexts often carry multi-year expectations; but do not treat any figure here as a regulatory conclusion. Whatever period you choose, pair it with a deletion process: an audit trail full of personal data has its own privacy obligations (see handling PII and retention and deletion).
Practical build notes
Keep the audit store append-only and separate from the application database, so a bug or a cleanup job can't silently rewrite history. Log the record at the moment of decision, not asynchronously from a queue that might drop entries. And reconcile occasionally against provider-side usage reporting (the Admin Usage API on the Claude API side, or your cloud provider's metering on Bedrock, Vertex AI, and Foundry) to confirm your logging captures everything that actually ran — see audit logging Claude usage.
Where to go next
Pair this with documenting your evaluation results so you can show not just what the model said, but that it had been tested for the job. The production checklist covers the wider launch picture.