The audit log is the product. The AI is just what fills it in.

Here is the sentence that kills more AI deployments than any accuracy figure: "and if a customer disputes this in a year, what do we show them?"

It gets asked late, usually by someone in finance or legal who was not in the earlier meetings, and if the answer is a shrug the project stops there. Rightly. It is the correct question.

What has to be in it

Not application logs. Not model traces. A decision record, in business terms, that someone non-technical can read. One row per event, append-only:

event_id      evt_8f21c9
timestamp     2026-07-14T15:22:09Z
action_type   credit.short_shipment
target        invoice INV-224871 / account TRD-3390
change        $184.00 credit, 4 units HX-4410
evidence      ticket:118422, pod:1Z9V…signed_qty=8,
              invoice:INV-224871:qty=12,
              policy:credits#short-shipment-under-250
proposed_by   agent v2026.06.3  (confidence 0.96)
approved_by   d.rowe@…  at 15:22:31Z  (9s to decide)
executed_at   15:22:31Z
reversible    yes → credit.void
prev_hash     3a91…  /  hash  c40e…

Six properties make it worth having, and each of them is load-bearing:

1. Append-only and hash-chained. No edits, no deletes; each row includes the hash of the one before. If the chain verifies, the history has not been rewritten. This is the difference between a log and a claim about a log.

2. Evidence, not reasoning. Store the documents, records and policy clauses the decision rested on — things that will still make sense in a year. A paragraph of model reasoning is worth very little in a dispute; a signed proof of delivery showing eight units against an invoice for twelve is worth everything.

3. Actor identity, human or machine. Which agent version, or which person. When accuracy shifts after a model change you need to know precisely which rows came from which version.

4. The rejections too. Most systems log what happened. Log what was proposed and refused, with the reason. That is the record that proves the control was working, and it is the first thing a good auditor asks for.

5. The reverse handle. Every executed action names how to undo it. An undo you have to invent during an incident is not an undo.

6. Exportable in a boring format. CSV and PDF, per account, per date range, by anyone with permission and no engineering ticket.

Who actually uses it, and for what

This is the part that surprises people. The ledger is not a compliance tax — it becomes the most consulted surface in the deployment.

• Support leads pull a customer's full history in one view — every automated and human touch in sequence — instead of stitching together three systems.
• Finance reconciles automated credits against the general ledger without asking engineering for a query.
• The AI team uses rejections and recalls as the primary improvement signal. This is the training data. It does not exist anywhere else.
• Legal answers a discovery request in an afternoon.
• The customer gets told exactly what happened to their account and when, which resolves most disputes before they become disputes.

The organisational effect, which is the real point

An operations director who says no to AI is not being irrational. They are being asked to accept unbounded, invisible risk on behalf of a system nobody can interrogate. That is their job.

The ledger converts unbounded invisible risk into bounded, inspectable, reversible risk. Once the conversation moves from "can we trust it" to "let's look at what it did last week", the whole dynamic changes — and it is the same reason double-entry bookkeeping beat trusting the clerk. Not because the clerk was dishonest. Because a system you can check is a system you can extend.

Ask any vendor to show you the ledger before they show you the model. Watch what happens.