Governed AI Deployment

What should an AI audit trail record, and how do you show it was not altered?

An AI audit trail should record each event a reviewer will ask about: who or what acted, when, on which input and model, what came out, and who approved it. To show it was not altered, chain each record to the one before it by a hash, refuse edits and deletes, and verify the chain over the period.

David McMillan, Governed AI Deployment. Checked against the sources on .

§01Art. 12, Art. 19, Art. 26(6), GDPR Art. 5(2)

What the law asks a log to do

For a high-risk system, Art. 12 says what its logs must make possible. In its words:

In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for:

(a) identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification;

(b) facilitating the post-market monitoring referred to in Article 72; and

(c) monitoring the operation of high-risk AI systems referred to in Article 26(5).

Art. 12

Art. 19 and Art. 26(6) say who keeps those logs, and for how long. Where a system handles personal data, the controller must be able to demonstrate compliance with the data protection principles (GDPR Art. 5(2)), so the trail is also how it shows what happened to that data.

§02Art. 12, GDPR Art. 30

What each record should hold

In the kit’s audit log, each event records who or what acted, when, the action, what it acted on, the model call, incident or approval it belongs to, a hash of its content, and the hash of the event before it. The model call itself is a row in the spend ledger: the time, the subject, the model version, the estimated and actual cost, and the outcome. An approval names who decided, when, what they saw and what they decided.

The sample evidence pack shows these records from the kit’s seeded data, marked SAMPLE.

§03Art. 12, GDPR Art. 5(2)

How to show it was not altered

Each event’s hash covers its own fields and the hash of the event before it, so changing or removing one breaks the link to the event after it. The database refuses an edit or a delete, except the erasure of an expired record’s content, which leaves its hash in place so the chain still checks. A verifier recomputes the chain over a period and names the faults it finds, among them a rewritten record, a removed one and a gap in the sequence.

A chain that verifies shows that no record was edited or removed in place. It cannot show that the chain was not rewritten, with every hash recomputed, from some record onward; that needs the latest hash published somewhere the system’s operators cannot rewrite, which the kit does not do yet. A record removed at either edge of the period checked leaves no trace in that check, so periods should overlap.

§04

Sources

§05

Book a scoping call

Thirty minutes on one system: what it does, who is asking about it, and which engagement fits. Nothing to prepare. For firms in the UK and Europe.

Book a 30-minute scoping callEmail a question