Design · Audit

Audit trails for AI decisions

Most systems log plenty. Almost none log the thing that matters after a bad decision: enough for an outsider to reconstruct what happened, why, and who was answerable. A trail only the vendor can read is not an audit trail.

A useful AI audit trail is one that a regulator and a wronged customer can both follow. That two-reader test is the whole standard. Plenty of systems produce logs, but a log written for engineers, dense and partial, is not the same as a record that lets an outsider reconstruct a decision and find the human behind it. Auditability is the trust property, and the audit trail is where it lives, so it has to be built for the people who will need it, not just the people who built it.

What it must contain

Four things, legibly: the inputs the decision used, the rule or model version applied, the output, and the accountable human if one was involved. With those, an outsider can answer the questions that matter after a harm: what did the system do, on what basis, and who could have changed it. Without them, the trail records activity but not accountability.

Why most logs fail the test

Because they were built for debugging, not for answering to anyone. They capture what the engineers needed and omit what a regulator or a customer would ask, especially the human in the loop and the basis for the call. A trail that cannot be read by the people a decision affected is documentation of a system talking to itself.