What to log when AI touches a business process
Six fields. If you record these from the first day, you can answer any question about an AI-assisted decision in two years. If you do not, you cannot reconstruct it at all.
The question arrives eighteen months later, and it always sounds the same. « Why does this booking say 8.1 per cent? » Or: « Who approved this quotation? » Or, from an auditor: « Show me how this figure was arrived at. »
If an AI step was involved and you logged nothing, the honest answer is that you cannot say. That is a bad answer to give a fiduciary, and a worse one to give a customer.
The six fields
- What went in. Which document, which record, which version. Not the full text necessarily — an identifier is enough, provided the source still exists.
- What came out. The proposal the system produced, before any human edit. This is the field most often skipped and most often needed, because without it you cannot tell whether a person corrected the machine or introduced the error themselves.
- Which system and version. Model and configuration. Behaviour changes when a provider updates a model, and « it worked differently in March » is only provable if you wrote down what March was using.
- Who confirmed it. A named person, not a service account. If nobody confirmed it, log that too — that is a fact about your process.
- When. Obvious, and routinely stored in a local format that becomes ambiguous the moment someone reads it in another country.
- What changed between proposal and final. If the person edited the output, keep both. This single field answers most disputes.
What this is not
It is not a full audit trail in the accounting sense, and it does not need tamper-proof storage for most SMEs. A table with six columns in the system that already runs the process is sufficient, and enormously better than nothing.
It is also not a surveillance record of your staff. Log the confirmation, not the person’s working pattern. If your log could be used to measure how fast someone works, you have built the wrong thing and created a new problem under employment and data protection law.
Why start now rather than later
Because logging is trivial to add when a process is built and awkward to retrofit afterwards. And because the value is entirely retrospective: you will never be glad of it on the day, only eighteen months later, exactly once, when it saves you an argument you would otherwise lose.