Design the record around the decision you may need to investigate: its inputs, system version, review and resulting action.
Book an AI Risk & Efficiency Audit
An AI audit trail should show which system produced an output, what information it used, who reviewed it and what action followed. Record enough to investigate a specific result without retaining sensitive material unnecessarily.
- What was decided or predicted?
- Which model (and version) produced it?
- What inputs and context were used?
- Who saw it, acted on it, or overrode it?
- Can we reproduce the outcome (or explain why we cannot)?
Explore Managed AI Governance & Support
Below is a practical checklist you can use to design or audit your own AI audit trail.
1) Event identity and timestamps (the minimum viable audit record)
Choose a stable identifier for each event you need to trace, and use consistent time metadata across the participating systems.
- Event ID: unique ID per prediction/recommendation/decision event
- Created at: when the event was generated
- Processed at: when downstream systems acted on it (optional but useful)
- Timezone/clock source: how timestamps are generated (NTP-synced, etc.)
- Actor: system user/service account that requested the model output
Tip: standardise on ISO-8601 UTC timestamps and record the originating service name so you can trace distributed systems.
2) Model identity, provenance, and versioning
Record the model used and the deployment decision. Include training and build provenance where you control it; for a hosted service, record the identifiers and evidence actually available.
- Model name and model version (semantic version or hash)
- Model registry reference: artefact ID in your registry (MLflow, SageMaker, Vertex, custom)
- Training-data reference, where available and relevant: identify the version or provenance evidence the firm can actually obtain, distinguish supplier statements from checked records, and record gaps. A deployer is not assumed to hold a proprietary model's training snapshot.
- Training code version: git commit or build ID
- Hyperparameters and key configuration
- Deployment context: environment (prod/staging), region, container image digest
If you run multiple variants (A/B tests, canary releases), log the routing decision too: why this request hit this version.
3) Input data: what the model saw (and what you allowed it to see)
Decide how the record will identify the inputs used without copying sensitive information into unnecessary locations.
Log inputs in a privacy-aware way:
- Feature values used for inference (raw or transformed, depending on sensitivity)
- Source references: record IDs, table names, document IDs, file hashes
- Input schema version: so you can interpret features later
- Pre-processing pipeline version: code hash/build ID
- Data quality signals: missingness, out-of-range flags, validation errors
Privacy note: assess whether an access-controlled reference can provide the evidence needed. Where exact payloads are necessary, protect the authoritative record with appropriate access, storage and retention controls. Use redaction for a display or sharing copy without presenting that copy as exact replay evidence.
4) Output data: the decision, score, and supporting signals
For outputs within the audit scope, choose the fields needed to investigate the result and compare relevant versions. Confidence, probability, calibration and explanation fields apply only where the system provides meaningful evidence for them.
- Predicted class/label or numeric score
- Confidence or probability distribution (where applicable)
- Thresholds used to convert scores into actions
- Top features / explanation artefacts (e.g., SHAP summary, rationale template)
- Calibration version (if you calibrate probabilities)
For LLM systems, treat the model output as a first-class artefact:
- Prompt template ID and version
- System prompt version (or reference)
- Retrieval context references: document IDs and chunk IDs returned by RAG
- Safety filters applied and results (blocked/allowed, policy hits)
- Response text or an access-controlled reference to the preserved response; record a hash where integrity checking is needed
5) Human review and overrides
For review decisions in scope, record whether the reviewer accepted, rejected, edited or overrode the output.
- Human decision: accepted/rejected/edited/overridden
- Who made the change (user ID, role)
- When it happened (timestamp)
- What changed: references to access-controlled before/after evidence
- Why: reason code (ideally structured) and optional notes
- Escalation path: if it went to a second reviewer, log that chain
Test whether the review interface records these actions consistently and whether they can be linked to the output and downstream action.
6) Policy, governance, and access controls
Choose access and integrity controls for the audit evidence, alongside its retention policy.
- Access control logs: who accessed audit records and when
- Retention policy: how long you keep records, and why
- Integrity controls appropriate to the workflow, such as append-only logs, WORM storage or cryptographic signing
- Data classification: what is sensitive, what is anonymised/pseudonymised
- Incident linkage: tie events to incident tickets when something goes wrong
7) Reproducibility (or a clear statement of what is not reproducible)
State what can be replayed, what can only be inspected and which dependencies were not preserved. Choose the following fields to match that boundary.
- Inference code version and runtime dependencies
- Random seeds and determinism settings (where applicable)
- External service dependencies (APIs, feature stores) and their versions
- Snapshot references to input data at time of decision
Test whether the workflow can replay the recorded input, context, configuration and result. If exact replay is unavailable, document the missing evidence and the limits it places on the investigation. Do not present an incomplete log as proof of the original decision.
Use the checklist to test a sample record
- Unique event ID + consistent timestamps
- Model name, version, registry artefact reference
- Training data and code provenance (where relevant)
- Input references (IDs/hashes), schema and pipeline versions
- Outputs (scores, labels, confidence) + thresholds
- Explanations (feature importance or rationale artefacts)
- Human overrides with protected change evidence, who/when/why
- Access logs, retention and appropriate integrity controls
- Reproducibility metadata or explicit limits
Common mistakes (so you can spot them in an audit)
- Logging everything (including sensitive data) without a retention plan
- No model versioning, so you cannot compare outcomes across releases
- Inconsistent IDs across services, making traceability impossible
- Missing human override logs, which leaves accountability gaps
- Audit records editable by the same systems they are auditing
Where to go next
Select a sample output and trace its input references, model version, review decision and downstream action. Record missing evidence, access problems and replay limits, then assign the changes needed for the chosen workflow.
Need a safer AI route for your firm?
For an audit-trail review, bring a sample output and its input, version, reviewer and action records. Identify the missing evidence and retention decisions before choosing implementation support.