AI record-keeping and audit trail

What it does

It preserves what the system did, in a form that can answer a question asked long afterwards. For each decision or output of consequence the record shows what came in, which versions were in force, what went out, what a person then did, and when. The system owner is accountable for the record, engineering implements it and records management sets retention. It is designed in at build and operates on every transaction.

How to implement it

• Decide what must be reconstructable, starting from complaints, legal claims and regulatory duties.
• Capture inputs, outputs, versions of model, prompt and configuration, and human overrides.
• Set retention periods from limitation and regulatory periods, not from storage cost.
• Obtain logs held by suppliers, or contract for their retention and access.
• Protect records from alteration and restrict access.
• Test by reconstructing a past decision from the records alone.

Evidence it operates

Design: a record-keeping standard and retention schedule for AI systems. Operation: sample records containing all required fields; a successful reconstruction test; contract terms on supplier logs; archived model versions that can be retrieved.

Where it fits

Built at design and running throughout operation and after retirement. It is the primary control for record-keeping and logging failure and, with agent action tracing, for untraceable agent actions. It builds on AI system monitoring and logging.

Limits

Records show what happened and not why a model produced it. Keeping inputs means keeping personal data, so retention has to be balanced against data protection duties to minimise and delete. Logs held only by a provider are outside the organisation's control. Records nobody has tried to use tend to be incomplete in ways discovered only when they are needed.