An AI audit trail is a record of how AI is actually used inside an organization: who used which AI tool or agent, what was sent and what came back, when it happened, and whether policy held. A trustworthy one is a tamper-evident audit log, built so that any alteration after capture is visible, rather than a text file that anyone with access could quietly edit. As AI tools and agents take on regulated work, this record has become the substance of AI accountability: the difference between telling an auditor what you believe happened and showing what did.
The question arrives sooner than most organizations expect. A regulator asks what data staff sent to an outside provider. A court asks what an agent did on a specific afternoon. An internal review asks whether a policy that exists on paper was enforced in practice. An agency with no record cannot answer. An agency with ordinary logs can offer an assertion. An agency with a verifiable record can offer evidence.
The four questions an AI audit trail must answer
Strip away the terminology and an audit trail exists to answer four questions about any AI interaction, months or years after it happened:
- Who. Which person or agent, on which device, used which AI tool. Attribution that stops at a service account or a shared credential does not answer this.
- What. The substance of the interaction: what was sent to the provider and what came back, including anything policy redacted or blocked before it left.
- When. A trustworthy timestamp, ordered against every other captured interaction, so a timeline can be reconstructed and defended.
- Whether policy held. What the applicable policy was at that moment, what it decided (ALLOW, REDACT, or BLOCK), and that the decision was enforced rather than merely written down.
Most environments can partially answer some of these from scattered sources: application logs, provider dashboards, browser history. None of those were designed as evidence, and under scrutiny they behave like what they are: operational byproducts, editable, incomplete, and often held by someone else.
What separates a trustworthy record from a text file of logs
Any system can write logs. Four properties turn a log into a record a reviewer can rely on, and each one closes a specific way records fail under scrutiny.
Signed at capture, on the originating device
Each chain entry is signed the moment it is captured, on the device where the interaction happened, so a later edit is detectable. The entry is attributed to the user and device the checkpoint reports. A server can verify the signature when the entry arrives. NIST SP 800-53 rev 5 treats non-repudiation as its own control, AU-10, inside the audit and accountability family that regulated frameworks increasingly map to.
An append-only hash chain
Every entry carries a cryptographic hash of the entry before it. Change one record, insert one, or remove one from the middle, and every hash after it stops matching. Dropping the newest entries is different: spotting that takes an external anchor. The alteration is not prevented; it is made visible, which is exactly what tamper-evident means.
Keys the agency holds
Custody decides who the record actually belongs to. In a trustworthy design, audit content is on a server the agency runs rather than one the vendor runs. The maker of the audit system never receives the interactions at all, so there's no vendor-side copy for anyone to read or to compromise. When a reviewer asks for the record, the agency produces it, and can show it was never readable by anyone else.
Per-user attribution
A record that shows an interaction happened is observability. A record that shows who did it is accountability. Per-user, per-device attribution, recorded at capture from the identity the enrolled device reports, is what lets an agency answer the who question years later. It also keeps oversight proportionate: aggregate numbers for leadership, per-user evidence only when there is cause to look.
| Property | A text file of logs | A tamper-evident audit log |
|---|---|---|
| Alteration | Editable by anyone with access, without a trace | A change to an entry’s signed fields is detectable on verification |
| Attribution | Often a service account or an IP address | Recorded with the user and device identity at capture, in a signed entry |
| Custody | Held by whoever operates the logging system | Held by the agency |
| Standing in review | An assertion to take on trust | Evidence whose integrity can be checked, not assumed |
AI record keeping, mapped to the framework
How long the record must survive is not one number; it is set by the framework you answer to. Under CJIS Security Policy, at version 6.1 as of June 2026 and mapped to NIST SP 800-53 rev 5, audit obligations live in the AU control family, and agencies retain audit records for at least one year, then keep them for as long as they remain needed for administrative, legal, or audit purposes. HIPAA sets a longer horizon: 45 CFR 164.316(b)(2)(i) requires documentation of required actions and assessments to be retained for six years from creation or from when it was last in effect, whichever is later. State law is adding its own horizons: Colorado’s SB 26-189 carries a three-year record-keeping duty for covered AI decisions when it takes effect on January 1, 2027.
One design consequence follows. The record has to remain verifiable across the whole period: a chain you can check in year six is worth more than a backup you can only hope was never touched. Our compliance mappings show the controls the platform supports.
The record Verillian produces
A checkpoint on each device sits between the tool and its provider, decides per policy, and signs every captured interaction into an append-only, hash-chained record. Each device's signing key is minted by your admin server and handed to the device once, at enrollment; the server keeps only the public key. Content is encrypted to your organization's key, created in your administrator's browser. Verillian never receives that key. The admin server runs on the agency's own infrastructure rather than ours, so Verillian never receives your interactions in any form. A change to an entry’s signed fields is detectable.
A policy states what should happen; the record shows what did. If your agency needs to answer the four questions above, start with how the record works and the security architecture behind it.
