AI Audit Log Schema Template: 21 Fields, Annotated (JSON + CSV)

An AI audit log schema needs four groups of fields: attribution and scope (who, when, where), request and model (what ran, via which path), a content plane (what the record carries, declared explicitly), and lifecycle (policy outcome, retention class, export state). The vendor-neutral template below has 21 fields, renders in full on this page, and is free to copy as JSON or CSV. As of 2026-08-28.

What this schema is, and what it is not

The audit trail requirements checklist covers the ten controls examiners actually ask about — attribution, model identity, coverage, retention, export, and the rest. This page is its implementation companion: the record you build so that each of those questions has a field that answers it. Where the checklist says "every request should carry a stable user identity," this schema says the field is actor_id, it is required, and here is what a good value looks like. Read the checklist for what to demand; use this template for what to build.

It is deliberately vendor-neutral. Nothing in it depends on PrivateStack or any other product — it flattens to a CSV, extends with your own fields, and maps onto whatever gateway or workspace you run. The supports column against each field says which control or rule family the field supports or maps to, so the schema can be defended line by line rather than as a lump.

Four design decisions the schema encodes

One record per event, not per conversation. Prompts, completions, uploads, retrievals, admin actions, and exports are separate rows sharing one shape. Conversations are reconstructed by sorting on session_id and timestamp — they are not the storage unit.

The content decision is a recorded field, not an assumption. content_mode declares whether this record carries full content, redacted content, or hashes only — per event, because different workspaces defensibly run different modes. Which mode to run is its own subject: the zero retention and audit logs guide maps precisely where each of the three fails.

Hashes are computed before redaction. request_sha256 and response_sha256 fingerprint the exact bytes, in every mode. That keeps integrity evidence independent of the content decision. The honest limit: an unkeyed digest stored beside the record supports export-consistency checks, but cannot by itself reveal rewriting by a privileged writer with access to both the record and its hash — organisations that need that assurance should layer keyed digests (HMAC) or signed batch manifests on top of this schema.

Every field is a scalar. The schema flattens to one CSV row per event with no nesting, because the export that matters most is the one a reviewer opens in a spreadsheet. Extend it with your own scalar fields rather than nesting objects into it.

The schema

The full template, grouped the way the fields earn their place. Types are written as they appear on the wire; Conditional means presence is governed by content_mode.

Copy it: JSON

One complete example record, in hash_only mode — the strictest of the three content modes, so every field is present and the nulls are honest.

{
  "schema_version": "1.0",
  "event_id": "018f3c2e-9a41-7c2b-b8d1-5f6a2e9c4d10",
  "timestamp": "2026-08-28T14:32:09.114Z",
  "actor_id": "u_7f2d91",
  "actor_type": "human",
  "workspace_id": "ws_finance-research",
  "session_id": "s_c3aa17",
  "event_type": "completion",
  "access_path": "ui",
  "model_id": "llama-3.3-70b-instruct",
  "model_provider": "self-hosted",
  "content_mode": "hash_only",
  "request_content": null,
  "response_content": null,
  "request_sha256": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
  "response_sha256": "60303ae22b998861bce3b28f33eec1be758a213c86c93c076dbe9f558c11c752",
  "token_count_input": 412,
  "token_count_output": 187,
  "policy_decision": "allowed",
  "retention_class": "audit-6y",
  "export_batch_id": null
}

Copy it: CSV header

The same 21 fields as a header row. Because every field is a scalar, one event is one row — no flattening logic required. One caution that applies to any audit-log CSV: before an export is opened in spreadsheet tools, prefix-escape content-bearing values that begin with =, +, -, or @, so a logged prompt cannot be interpreted as a spreadsheet formula when the evidence is reviewed (CWE-1236).

schema_version,event_id,timestamp,actor_id,actor_type,workspace_id,session_id,event_type,access_path,model_id,model_provider,content_mode,request_content,response_content,request_sha256,response_sha256,token_count_input,token_count_output,policy_decision,retention_class,export_batch_id

Why the groups are shaped this way

Attribution and scope

The first question in any review is who did what, when, and where. These fields answer it with stable identifiers, not display names: names change, people share screens, and service accounts impersonate nobody. Every identifier here should come from your identity provider or your provisioning system, so a reviewer can join the log against the systems of record you already run.

Request and model

Outputs that cannot be traced to the exact model that produced them cannot be reviewed, validated, or explained later. Record the model actually used at request time — not the current default, which will have changed by the time anyone asks — and the route the request took in, because a trail that covers the chat UI but not the API documents a gap, not a control.

Content plane

The single most consequential design decision in the schema: content_mode records which logging mode this record carries, and the content fields obey it. The hashes are computed over the exact request and response bytes before any redaction, so integrity evidence survives whichever mode you run. Choosing between the three modes is its own subject — the zero-retention-and-audit-logs guide maps precisely where each one fails.

Policy, retention, and export

A record that cannot say how long it lives, or whether it has ever been produced as evidence, forces someone to answer those questions from memory later. retention_class names the schedule applied to this record — a deliberate policy, not a vendor default — and export_batch_id closes the loop by recording when the record itself became evidence.

For the values retention_class should actually hold — which instrument sets which period for which record type — the prompt log retention crosswalk maps seven record types against their governing instruments, with a worksheet for turning the map into your own schedule. Where the question is whether an interaction is a required record at all — the decision upstream of every field in this schema — the FINRA generative AI recordkeeping guide draws that line.

How PrivateStack relates to this schema

A PrivateStack workspace records each request with user identity, timestamp, model identity, and request context, and audit logs export date-ranged and machine-readable from the console — the same information this template organises, without a support ticket in the path. The Evidence Pack export bundles the audit log with a model inventory, retention summary, and team roster for date-ranged reviews. The honest limit: this template is a starting point you own, not a claim about any vendor's wire format — including ours. Adapt the fields to your records schedule, then hold every vendor, us included, to producing the substance of them. The full control set is on the security page.

Questions people actually ask

What fields should an AI audit log schema include?

Four groups: attribution and scope (a schema version, a unique event id, a UTC timestamp, a stable actor identity and type, the workspace, and an optional session id), request and model (event type, access path, the exact model and its provider), the content plane (a content_mode flag, the content fields it governs, and SHA-256 hashes of the raw request and response), and lifecycle (policy decision, a named retention class, and an export batch id). The full template on this page is 21 fields.

Should the audit log store the actual prompts and responses?

That is a per-deployment decision, not a schema decision — which is why this schema records it explicitly in content_mode instead of hard-coding one answer. Store content verbatim where the interaction is itself a required record; mask fields where you must supervise without warehousing identifiers; keep hashes only where minimisation binds. The companion guide on zero retention and audit logs maps precisely where each mode fails.

Why hash the content if the content is also stored?

Because the hash is computed over the exact bytes before any redaction or truncation, it stays useful in every mode: in full mode it lets an exported record be checked against the stored original, in redacted mode it proves the unmasked original existed in a specific form, and in hash_only mode it is the only integrity trace you keep. One field, computed once, serving three designs.

JSON or CSV for audit log exports?

Produce JSON as the system of record — it preserves types, nulls, and nested extensions — and derive CSV from it when a reviewer asks for a spreadsheet. The schema on this page flattens cleanly to CSV because every field is a scalar; that is deliberate, and worth preserving if you extend it.

How long should records in this schema be retained?

Long enough for the obligation that applies to the record, and no longer than your documented schedule allows — that is what retention_class exists to record. Books-and-records obligations commonly run three to six years; documentation retention under 45 CFR 164.316(b) runs six years; minimisation pushes the other way where no obligation binds. The point of the field is that every row can say which schedule governs it.

Evaluating platforms against what this schema needs from them? The closed-API comparison covers what each deployment model can and cannot log — including where the closed API wins.

Primary sources

Every rule number in the supports column traces to one of these publications. Read them before any vendor's interpretation — including ours.

• 17 CFR 240.17a-4 — Records preservation for certain exchange members, brokers and dealers — retention periods and the electronic recordkeeping requirements in paragraph (f), including the complete time-stamped audit trail provision.
• FINRA Rule 4511 — General requirements — books and records: make and preserve books and records, six-year default retention, preservation in a format and media that complies with SEA Rule 17a-4.
• 45 CFR 164.312(b) — Security Rule audit-controls standard: mechanisms that record and examine activity in information systems that contain or use electronic protected health information.
• 45 CFR 164.316(b) — Security Rule documentation standard and its retention specification: required documentation kept six years from creation or last effective date, whichever is later.
• Regulation (EU) 2016/679, Article 5 — Principles relating to processing of personal data: data minimisation (5(1)(c)), storage limitation (5(1)(e)), and accountability (5(2)).
• NIST SP 800-53 Rev. 5, AU family — Audit and Accountability controls: AU-2 Event Logging, AU-3 Content of Audit Records, AU-9 Protection of Audit Information, AU-11 Audit Record Retention.
• RFC 3339 — Date and Time on the Internet: Timestamps — the timestamp profile this schema uses, in UTC.