What an audit-ready AI decision actually looks like

The record, not the summary

An after-the-fact summary can smooth over gaps, omit an inconvenient exception, or simply be wrong about what actually happened. An append-only record can't do any of that, because nothing in it can be edited or deleted once written. That's the property both a regulator and, under GDPR Article 22, a data subject contesting a decision are actually testing for: not "does the company say it reviewed this," but "can it show what was reviewed, when, and by whom."

What legally has to be explainable, and why that shapes what gets captured

The CJEU's SCHUFA ruling (Case C-634/21, December 2023) confirmed that Article 22's protections extend to automated scoring systems whenever their output significantly influences a downstream human decision, and that explaining the logic to a data subject on request means more than a generic "we use AI to assess applications" disclosure. It means being able to show which factors the system weighed and how they led to the outcome. An audit record built to satisfy that standard has to capture five things on the same spine: the inputs the system assessed, which rule from the customer's own decisioning pack applied, any exception path taken, the graded outcome, and the human approval that finalised it. Scatter those five across a rules engine, a CRM, and a spreadsheet, and the explanation a data subject is legally entitled to becomes a manual reconstruction project instead of a query.

Why this has to be structural, not procedural

A written procedure describing how audit trails are supposed to work is not the same as a system architecture that makes an incomplete or edited trail impossible. The former relies on every person, every time, following the process correctly — under deadline pressure, during a system migration, after a staff change. The latter removes the dependency on anyone remembering to do it right, because the append-only property is enforced by the system itself, not by a policy document sitting in a shared drive.

What this looks like in day-to-day underwriting practice

When an underwriter or advisor reviews a case, the decisioning pack surfaces which of the customer's own rules applied and why, before the underwriter signs off. That review — what the underwriter saw, what they had authority to change, and what they actually decided — is written to the same record as the automated assessment that preceded it. If a customer later disputes the outcome, the insurer isn't reconstructing what happened from institutional memory; it's reading a record that was written in real time, the moment the decision was made.

The difference between an audit trail and a security log

It's worth distinguishing an audit trail built for decision explainability from a security log built for intrusion detection. They can share infrastructure, but they answer different questions: a security log tells you who accessed a system and when; a decision audit trail tells you what the system decided, on what basis, and who signed off. An insurer evaluating a vendor's "audit logging" claim should ask which of the two is actually being described, because vendors sometimes use the term loosely to mean whichever is easier for them to provide.

Where this connects to the rest of the pillar

The audit spine described here is the mechanism behind the GDPR-native claim discussed in post 10, the evidence base a board needs behind the accountability discussed in post 6, and the thing an Article 26 deployer will eventually need to point to once the December 2027 deadline arrives (post 2). It's also, not incidentally, the same infrastructure that makes per-tenant data isolation (post 8) auditable rather than merely asserted.