What belongs in your AI audit log

Every enterprise AI platform should produce an audit log. Few teams think carefully about what that log should contain until they need it for something — a compliance audit, a security incident, a cost dispute, or an internal investigation — and discover that their log is either too sparse to be useful or too verbose to be searchable.

This post covers the specific fields that belong in an AI audit log, the retention and access control requirements that make it trustworthy, and the export patterns that integrate it with your existing compliance infrastructure.

The three purposes of an audit log

An AI audit log serves three distinct audiences with different needs:

Compliance reviewers need evidence that controls are operating as designed. They want to see that PII guardrails triggered when they should, that budget policies were enforced, and that access was limited to authorized users. They care about coverage and immutability — every request is logged, and the log cannot be altered.

Security and incident response teams need to reconstruct sequences of events. If a user sent a prompt containing sensitive data that bypassed a guardrail, they need to find that request, understand why the guardrail didn’t trigger, and determine what the model received. They care about completeness and searchability.

Platform engineers and FinOps teams need cost attribution and usage patterns. They want to know which team sent which requests, to which model, at what token counts. They care about accuracy and structure.

A single log format needs to serve all three.

Required fields for every request event

ManyLayers Gateway writes a structured JSON record for every request. The record includes:

{
  "event_id": "evt_01j8k3m9p2q...",
  "event_type": "request",
  "timestamp": "2026-07-03T14:22:41.803Z",
  "team_id": "team_data_engineering",
  "user_id": "user_fkhan@example.com",
  "alias": "chat-production",
  "resolved_target": "openai/gpt-4o",
  "model": "gpt-4o",
  "prompt_tokens": 847,
  "completion_tokens": 312,
  "total_tokens": 1159,
  "cost_usd": 0.00926,
  "latency_ms": 1843,
  "status": 200,
  "guardrails": {
    "pii_firewall": "pass",
    "budget_check": "pass"
  },
  "request_id": "chatcmpl-9Xk3mP..."
}

Note what is absent: the prompt text and the completion text. For most compliance and cost attribution use cases, you don’t need the content. Storing it creates a liability: the log itself becomes a repository of potentially sensitive data, subject to the same data governance requirements as any other sensitive data store.

When to log content

There are legitimate reasons to log prompt and response content: certain regulatory frameworks require it for specific use cases, and some internal audit programs need content-level review. If you log content:

• Apply the same PII firewall to the logged content as to the forwarded prompt. Never log redacted content in its pre-redaction form.
• Restrict read access to the content fields to a narrow set of authorized roles. Token counts and metadata should be broadly accessible; content should not be.
• Set a shorter retention period for content logs than for metadata logs. 30 days for content, 2 years for metadata, is a common policy.
• Document the legal basis for content logging and get sign-off from legal before enabling it.

Guardrail decision records

Every guardrail evaluation generates its own log entry, linked to the request by event_id:

{
  "event_type": "guardrail_decision",
  "parent_event_id": "evt_01j8k3m9p2q...",
  "guardrail": "pii_firewall",
  "pattern_matched": "ssn",
  "action_taken": "block",
  "matched_span_logged": false,
  "confidence": 0.99
}

The matched_span_logged: false field records that the actual matched text was not stored — providing evidence of compliance with data minimization requirements without exposing the sensitive data in the log.

Immutability requirements

A compliance audit log must be immutable: once written, it cannot be modified or deleted. ManyLayers Gateway appends to the audit log only — there is no update or delete operation. Configure the export target to enforce immutability:

• S3-compatible storage: enable Object Lock in COMPLIANCE mode with a retention period matching your regulatory requirement (typically 1–7 years depending on framework).
• Postgres: use an append-only table with a trigger that prevents UPDATE and DELETE operations. Grant the log writer role INSERT only.
• Splunk/Elastic: ingest via a write-only service account; restrict index deletion to a compliance administrator role.

Retention periods

Different log event types have different regulatory-driven retention requirements:

Event type	Typical retention
Request metadata	2 years
Guardrail decisions	2 years
Authentication events	3 years
Team provisioning changes	5 years
Budget policy changes	5 years
Prompt/response content	30–90 days

Configure retention in Platform Settings → Audit → Retention Policies. ManyLayers can automatically expire content-class log entries at a shorter retention horizon than metadata entries within the same export.

Export integration

The audit log is most useful when it flows into your existing security and compliance tooling. ManyLayers supports three export modes:

Streaming export — log entries are forwarded in near-real-time to a configured endpoint (S3, Kafka, or a webhook). This is appropriate for SIEM integration where you need prompt detection of anomalous patterns.

Batch export — log entries are exported on a schedule (hourly, daily) as JSONL files to an S3-compatible bucket. This is appropriate for cold storage and long-term retention.

Query API — the audit log is queryable via the Gateway management API. This is appropriate for incident investigation where a security engineer needs to run ad-hoc queries against recent events.

Configure export in Platform Settings → Audit → Export. Run a test export and verify the records in your target system before your compliance review window — discovering a misconfigured export during an audit is a stressful way to find out.