Audit trail logging for an AI detection system means writing one record per detection (what the model saw, what it output, at what confidence, under which model version, against which threshold, and when) into a store where any later edit, deletion or reordering becomes visible to someone who does not have to trust you. A detection log is audit-grade when three things hold: each entry is cryptographically chained to the one before it, the chain sits on storage that refuses overwrites for the whole retention window, and an outside party can rerun the verification with open tools. Retention comes from the regime that governs the deployment, such as the EU AI Act’s minimum of six months for logs from high-risk AI systems, not from a log-rotation default. Because the evidence has to be regenerated on demand and defended in front of people who are not engineers, we treat it as an engineering output with its own pipeline, not a document pulled together after an incident.
Audit trail vs audit log for a detection system
NIST defines an audit trail as a chronological record that reconstructs and examines the sequence of activities surrounding or leading to a specific operation, procedure or event, from inception to final result. The FDA’s guidance on computerised systems in clinical trials adds the properties that make it evidence: a secure, computer-generated, time-stamped electronic record that allows reconstruction of the creation, modification and deletion of a record.
An audit log is the raw material: individual event records written by one component. The trail is what you get when those records can be put back into one ordered, complete and verifiable sequence across every component that touched a decision. One practitioner write-up on LLM audit evidence (Openlayer, 2026) makes the same point bluntly: raw logs capture that something happened, while the EU AI Act’s Article 12 expects inference-level evidence tied to specific outputs.
NIST SP 800-12 says an audit trail should hold enough information to establish what events occurred and who or what caused them, with each record specifying when, the identity involved, the program used and the result.
What each AI detection record should contain
Article 12 of the EU AI Act requires high-risk AI systems to technically allow the automatic recording of events over the lifetime of the system. The logs must support identifying situations that may present a risk or a substantial modification, post-market monitoring, and monitoring of the system’s operation. For a camera or edge detector, that translates into a per-event record along these lines.
| Field | Why it is there |
|---|---|
| Event ID and sequence number | The Decision Event Schema (Solozobov, 2026) makes a decision identifier and a sequence number required fields of every event. |
| Occurred-at and recorded-at timestamps | A minimal AI audit record carries both when the decision happened and when the logging layer wrote it. |
| Input reference (frame snapshot, or its hash) | Reviewers need the exact input to reconstruct a specific inference. |
| Raw model output and confidence | The raw output before post-processing shows whether enforcement gates fired. |
| Threshold or decision logic active at that moment, and the resulting flag | Scores are only interpretable against the threshold value active at inference time. |
| Model version hash | It must trace back to the registry entry, evaluation and approval that put the model in production. |
| Device or system identity | The Decision Event Schema paper reads NIST SP 800-53 as bundling each log event with a generating system identifier, signature and timestamp. |
| Human override record | Whether an override occurred is a required field in the Decision Event Schema. |
| Previous hash, current hash, algorithm | These fields carry the chain’s integrity for each event. |
| Retention policy metadata | The schema records a minimum retention period per event, for example six months for Article 19. |
For remote biometric identification systems, Article 12 goes further and names minimum contents: the period of each use, the reference database checked, the input data that produced a match, and the people who verified the result.
The frame snapshot raises a choice. Hashing inputs that contain personal data preserves the ability to prove the same input was used, but not to reconstruct what the input showed; where an auditor must be able to see the frame, the Decision Event Schema recommends encrypted payloads with escrowed keys instead. For a detection system whose disputes are usually about what was in the frame, we would default to encrypted snapshots for flagged events and hashes for the rest.
How much to capture is a cost decision as well as a compliance one. NIST SP 800-12 ties the depth of logging to the sensitivity of the application and the costs and benefits of logging, and the Decision Event Schema formalises this as lightweight, sampled and full evidence tiers matched to decision risk and throughput. The trade-offs behind those tiers are worked through in audit logging granularity and cost modelling for automated decision systems.
How do we hash-chain detection logs so any gap or edit shows?
Make every record carry the hash of the record before it, so changing any historical entry breaks every hash that follows. In the Decision Event Schema the current hash is computed over the canonicalised payload (per RFC 8785) with the hash field excluded, and the algorithm, for example SHA-256, is recorded alongside it. The guarantee rests on collision resistance: with a well-designed hash function it is not feasible to find two messages that produce the same hash value.
A Merkle-tree pipeline stores the root hash in a trusted anchor and generates inclusion proofs for single entries in logarithmic size. A 2026 evaluation of such a pipeline for IoT edge logs reports a mean proof size of 1,006 bytes and an average of 21.92 ms per proof for a 10,000-entry tree. The Accountability of Things scheme (Koisser and Sadeghi, 2023) builds a hash tree around log timestamps and localises tampering to sub-second resolution with a constant overhead of about 8 KB per hour per device.
Two caveats matter in practice. A plain chain does not by itself reveal deletion of the newest entries, which the EmLog work names as a truncation attack; anchoring historical roots at known entry counts is what lets a verifier see that the current log holds fewer entries than it should. Reordering whole blocks is the second gap, which EmLog closes by also chaining each epoch’s root to past epochs, giving a two-dimensional chain. Either way, the security of the whole pipeline reduces to the integrity of the root anchor, so roots should be committed to a remote append-only store or sealed in a TPM.
Hash-chaining makes any modification of an entry detectable after it is written. It says nothing about whether the frame, score or timestamp was correct at capture.
Can an audit trail be deleted or altered once it is written?
Yes, unless the storage stops it. NIST SP 800-12 is explicit that signatures do not prevent deletion or modification of an audit trail; they provide an alert that it has been altered. Write-once devices are the second integrity control NIST names alongside signatures.
The write-once property has to be enforced by the storage layer, not by application discipline. In Amazon S3 Object Lock compliance mode, a protected object version cannot be overwritten or deleted by any user, including the account’s root user, and the retention period cannot be shortened. A legal hold blocks deletion with no fixed end date until it is removed. A retention policy that a privileged role can still modify is unsuitable for compliance-grade audit logs.
Write-path separation closes the remaining gap: the AI application itself has an explicit deny on writes to the audit store, so compromising the detector gives no path to its own records. NIST SP 800-53 control AU-9 asks for exactly this, protection of audit information from unauthorised modification and deletion plus alerts when it is detected, and the FDA’s guidance says personnel who create or modify records should not be able to modify the audit trail.
What an outside verifier needs to check the chain without trusting you
Investigators, auditors and defence experts should be able to verify the log with nothing from the vault vendor except the data. AWS describes this for CloudTrail: because it uses openly available algorithms, customers can write their own validators that check RSA signatures on digest files and walk the chain of previous digests back in sequence. Certificate Transparency (RFC 9162) does the same at internet scale with consistency proofs showing a later tree is an append-only extension of an earlier one, and signatures on those structures stop a log from denying its own misbehaviour.
A verifier’s kit, as a checklist:
- an open, inspectable verification script (a closed verifier just moves the trust problem);
- the public keys and certificate chain needed to check signatures, so third parties can authenticate the origin of entries without any private key;
- signed, published tree heads or anchored roots at known sizes, so consistency between them can be proven;
- inclusion proofs for the specific records in dispute;
- a manifest listing every exported file with its SHA-256 hash.
In Sigstore’s Rekor, a public transparency log, auditors monitor the log to confirm it stays append-only and that entries are never mutated or removed.
Timestamps that hold up when challenged
A Time Stamp Authority under RFC 3161 provides proof that a datum existed before a given time; it must use a trustworthy time source, give each token a unique serial number, and time-stamp only a hash of the data. Using a nonce in each request lets replays be detected. On the device side, the FDA encourages synchronising system clocks to trusted third parties and documenting any change to date or time. One legal-technology firm (Bernstein) notes that under the EU eIDAS Regulation a qualified electronic timestamp is presumed accurate in all 27 member states.
Will this log format survive a Daubert-style challenge?
No log format guarantees admissibility; a court decides that, usually with expert testimony. In US federal courts, Rules 902(13) and 902(14), effective December 2017, allow electronic records and data authenticated by a process of digital identification such as hash values to be self-authenticating by certification, which shifts the burden of going forward (not the burden of proof) to the opponent, who may still retain a forensic expert to challenge it. NIST SP 800-12 likewise flags that audit trail integrity becomes particularly important when trails are used as legal evidence.
Our judgement is that a documented, reproducible chain that any expert can recompute gives a court far more to stand on than a timestamping scheme that only the vendor can vouch for, but technical soundness is necessary, not sufficient. Where job metadata from compute clusters must be part of the evidence, we would put it inside the same chain rather than in a parallel record.
Building one audit trail from logs on many devices and back-end systems
A trail spanning cameras, gateways, inference servers and storage needs per-source sequencing and explicit gap detection, because wall-clock order across devices is not trustworthy enough on its own. RFC 5848 (signed syslog) is a useful template: it adds origin authentication, message integrity, replay resistance, message sequencing and detection of missing messages to a log stream. Each signer keeps a reboot session ID that strictly increases on every restart, message numbers restart at one in each session, and the authenticated log implicitly shows every gap through its missing numbers. With signature blocks and message timestamps, a reviewer can recover the original order of out-of-sequence messages.
Devices can hold proof about each other. The Accountability of Things scheme lets interacting devices keep log receipts proving an event was logged, even if the original set of logs is later destroyed. The Decision Event Schema adds a decision-boundary field group for cross-system coupling, so the hand-off between, say, an edge detector and a back-end rule engine is part of the event rather than an inference made later.
We recommend that every event carry its source’s sequence number plus a correlation ID that follows the detection from capture to export, and that a missing number be treated as a finding to explain, never as noise to filter. The schema authors name the failure this prevents, coverage erosion, in which trace coverage shrinks as integration points multiply.
How long should detection traces be kept to support a post-mortem?
Keep traces for the longest review window that could need them, counted from when an incident might be reported rather than from when it happened, and never by the default log rotation. TechnoLynx designs this tracing as part of its AI governance and trust work: agreeing with you what counts as a reviewable incident, defining the trace schema and instrumenting the detection pipeline to emit it, setting storage and retention against the review window, and confirming it works by replaying known past events before relying on it.
To judge whether the detector should have fired at a given moment, the trace should preserve the raw model output and the threshold active at that time, not just the final flag. Tracing only the outcome makes it impossible to tell a model error from a threshold choice. NIST describes this use directly: reviewing audit trails to pinpoint how, when and why normal operations ceased.
The FDA’s guidance for computerised systems in clinical trials requires audit trails to be kept at least as long as the electronic records they pertain to. A trace that expires before a delayed complaint arrives has foreclosed the review it existed for.
Completeness has a price. The Decision Event Schema paper estimates that full governance capture becomes infeasible above roughly 100,000 decisions per second even with the highest-throughput mechanisms (TEE and binary hash trees), and far lower with linear hash chains, so high-rate systems must accept lighter evidence for most events. For live video, that means sampling or compressing traces, and any sampling policy should be recorded in the trail itself as a known replay gap. None of this says whether the model is accurate enough; it only makes its behaviour reconstructable afterwards.
What goes into the evidence pack for each escalation, and how long must it be kept?
An escalation evidence pack holds the fields the reviewing body signs against, for example an input distribution snapshot, the model version, the drift calculation (PSI or similar), the confidence score and the classification outcome, retained for as long as the governing examination regime requires. TechnoLynx builds these packs with the risk committee and compliance owners: fixing the exact evidence schema they need for sign-off, implementing capture at inference time on the deployment hardware, linking each escalation to the underlying scores across repeated runs, validating the pack against sample audit scenarios, and sizing storage for the mandated period. We build this as engineering evidence a committee can read and defend, not as policy advice or certification.
The field list varies by regulator and risk framework, so treat the list above as a baseline to confirm, not a standard. Practitioner guidance on EU AI Act evidence points to the same building blocks: model version identifiers traceable to the approval that authorised deployment, and post-market monitoring data including drift indicators and flagged outputs, plus records showing when thresholds were set, when alerts fired and what followed. Following a model version back to its training data and approval is its own subject, covered in audit trails and lineage for compliance and root cause.
Retention by regime
| Regime | Minimum retention for logs or audit evidence |
|---|---|
| EU AI Act, Article 19 (providers of high-risk AI systems) | At least six months, unless other Union or national law provides otherwise. |
| EU AI Act, Article 19 (financial institutions) | Kept as part of the documentation required under financial services law. |
| Medicare Advantage or Part D contracts | Ten years for logs and records evidencing compliance, per one compliance vendor’s recommendation (Syskit). |
| FDA, computerised systems in clinical trials | At least as long as the subject electronic records. |
Litigation holds and contract terms can extend any of these, and disposal after expiry must still protect what the logs contain. Picking the wrong regime risks both under- and over-retention.
A document-level log across two runs
Comparing an original run with a re-run is only meaningful if each record is keyed by document ID and run ID, and the model version and input snapshot were captured at inference time rather than reconstructed afterwards. The test for the pack is reproducibility: given the same time window and the same system version, it should regenerate identically.
Where did this clip come from, and does the trail survive a trim?
An automated pipeline can answer “where did this clip come from” instantly if it logs the source feed, the timecode span and the detection confidence at the moment of detection, and if the editing step writes to the same trail. A manual registry kept beside a live production workflow is slower and more error-prone, and is best kept as a fallback for edge cases the automated logger misses.
The FrameProv research proposal takes the approach we find most defensible: rather than detecting tampering, it lets the publisher edit openly and declare the edits, and any undeclared edit fails the integrity check. A structured change log that records the actor, the action, before-and-after snapshots, a rationale code and a pointer to the raw export makes each trim replayable. If the trimming tool is not integrated with the trail, provenance degrades to an approximation, and an error in the original detection carries straight into the provenance claim.
What are audit logging best practices for long-term verifiability: keys, certificates and software versions?
A chain verified today must still verify years from now, after keys rotate and certificates expire. Time-stamping a signature proves it was made before a given time, so a verifier can tell whether it predates a later certificate revocation. RFC 3161’s verification steps need the signer’s certificate, its validity period and the revocation information at the time of stamping. In practice, the archive has to keep the public keys, certificate chains, TSA certificates and revocation data alongside the logs.
When a log is closed, RFC 9162 has it publish a final signed tree head so that no entry can be added afterwards without detection; the same habit works for retiring a detection log. The software that produced each detection matters too: the FDA expects measures ensuring the software versions in use are the ones stated in the documentation. We would retain the exact model artefacts and firmware or container images (or at least their hashes, with the images in controlled storage) referenced by the records’ version fields, because “model v3.2” means nothing once the build is gone.
Personal data and immutability can coexist. Encrypting personal data with per-subject keys allows erasure by revoking the key, while the hash chain and governance metadata stay intact. Keeping the logs is not the end of the duty either: HIPAA expects logs to be reviewed, not just stored.
Regenerating the evidence pack from raw logs instead of assembling it by hand
Yes: evidence pack automation generates a defensible, repeatable set of artefacts from systems of record such as telemetry, decision logs, registries and evaluation pipelines. Reproducibility depends on versioning the pack generator and pinning its data sources. We would build the generator to run these steps:
- Fix the scope: in-scope systems, required artefacts and measurable acceptance criteria.
- Export untouched originals and record the exact query and parameters used.
- Validate the digest file first, then the log files it references.
- Write a machine-readable manifest of every file with its size and SHA-256 hash.
- Bundle verification scripts that recheck checksums and compare outputs against expected results.
- Render both human-readable and electronic copies suitable for inspection.
The same records double as release evidence: each detection’s model version identifier traces to the approval that authorised its deployment.
The field list and the retention clock depend on a named regulator, contract or court, and that question is worth answering before the first schema is frozen.
FAQ
Is hashing used for integrity?
Yes. A cryptographic hash condenses its input, and CloudTrail validates log files by comparing recomputed SHA-256 hashes. HIPAA-focused guidance (Syskit) describes pairing hashing of log batches with WORM-style storage.
What is digest in hashing?
A message digest is another name for the output of a hash function, along with hash value and digital fingerprint.
What is it called when two hashes are the same?
Two different inputs producing the same hash is a collision; a well-designed hash function makes finding one infeasible, which is called collision resistance.
What is the best hash algorithm for file integrity?
There is no single answer, but SHA-256 is what CloudTrail digest validation and evidence-pack manifests use.
