How to Keep an Audit Trail of AI Use

Log eight things every time an AI system produces an output that someone acts on: when it ran, which system and version, who or what triggered it, what went in, what came out, what happened next, whether a person reviewed it, and the outcome if anything went wrong. Store them in one table, keep them for at least six months, and you can answer nearly every question a customer, an auditor or your own incident review will ask. A folder of screenshots cannot.

Who is obliged, and who merely benefits

Most companies using AI have no statutory logging duty at all. The obligation bites in the EU, on high-risk systems, and it became enforceable on 2 August 2026 alongside the rest of the high-risk regime. If you are running a chatbot that drafts marketing copy, this is good practice. If you are running something that scores job applicants, allocates credit, or makes decisions about access to essential services, it is a legal requirement with a specific shape.

The line between those cases is not always obvious, and the ordinary route to establishing it is documented rather than guessed. Our note on the high-risk deadline and what falls inside it covers the categories; if you are unsure, assume you are closer to the line than feels comfortable.

What the law actually asks for

The relevant text is Article 12 of the EU AI Act, and it is shorter than the commentary around it. Four points do most of the work:

• Automatic. The system must technically allow the recording of events by itself. A person writing entries in a spreadsheet after the fact does not satisfy it.

• Over the lifetime of the system. From putting it into service until it is decommissioned, not just the current version.

• Events relevant to risk. Enough to identify situations where the system may present a risk or has been substantially modified, and to support post-market monitoring.

• At least six months. The retention floor for deployers, longer where the use case or other law requires it.

For anyone building rather than merely using, the practical reading is that logging cannot be bolted on at the end. It is a design requirement, and retrofitting it into a system that never carried request identifiers is considerably more expensive than putting it in on day one.

The minimum viable log

Eight fields. This fits in a database table, a spreadsheet, or the structured logs you already ship, and it is enough to reconstruct what happened months later.

Store a reference to the input rather than the input itself wherever you can. A ticket identifier and a hash let you prove what was processed without turning your log into a second copy of your customer database, which would create a new problem while solving this one.

Where the log should live

• In the application, not the vendor's dashboard. Provider consoles are useful and they are not yours. Retention, export and access are set by someone else.

• Append-only if you can manage it. A log that can be edited answers a question with your own credibility attached.

• Separated from the data it references. Different retention, different access, often different regulatory treatment.

• Somewhere a non-engineer can query. If answering a customer question requires a developer, the answer will be slow and eventually will not happen.

Three things people log that do not help

• Full prompt and response text for everything. Expensive, sensitive, and rarely the thing you needed. Log it for flagged cases and sample the rest.

• Screenshots. Not searchable, not verifiable, and they arrive months later with no context.

• Confidence scores with no threshold attached. A number with no decision rule beside it tells you nothing about why the system acted.

The commonest gap is subtler than any of those: no record of who reviewed what. When something goes wrong, the question is almost never what did the model say. It is whether a person looked, and what they saw when they did. That is also the practical core of who is responsible when AI makes a mistake, and a log without a review field cannot answer it.

Fitting it into something larger

If you want a structure rather than a table, the NIST AI Risk Management Framework organises this into four functions, govern, map, measure and manage, and record-keeping sits under measure. It is voluntary and written for bigger organisations, but the vocabulary is useful when a customer's security questionnaire asks which framework you follow.

Two adjacent habits make the log worth more than it is on its own. Knowing what your vendors retain on their side, which is part of vetting an AI vendor properly, tells you what your log has to cover alone. And knowing which tools are in use at all is a precondition, since unsanctioned AI use produces exactly the activity that will never appear in any record you keep. Both sit inside the broader map of AI risks a small company actually has to manage.

When someone asks for the record

The log earns its existence on the day a customer disputes a decision, a regulator sends a question, or your own incident review needs a timeline. Decide now, while nothing is on fire, who can run the query and what a good answer looks like.

• Name the person who can pull it. Two people, ideally, so a holiday does not become a delay you have to explain.

• Decide what you disclose. A customer usually needs to know whether an automated system was involved and whether a person reviewed it, not your prompt text.

• Keep the query written down. A saved query with a date range and an identifier parameter turns a two-hour job into a two-minute one.

• Note when the log cannot answer. Gaps are survivable if you say so plainly. A confident answer reconstructed from memory is not.

Rehearse it once. Pick a request from last month, answer it end to end from the log alone, and see where you had to guess. Whatever you had to guess is the field you are missing.

How long to keep it

Six months is the floor for high-risk deployers under the Act. In practice, choose a period that matches how long a complaint about a decision could plausibly arrive, which for most commercial disputes is longer than six months and shorter than forever. Write the period down, apply it automatically, and delete on schedule. Logs kept indefinitely by accident become a liability of their own the first time somebody requests them.

Questions people ask

Do I need this if I just use ChatGPT for drafts?

Not as a legal obligation. It is still worth keeping a light record for anything that reaches a customer, because the question you will eventually face is not whether AI was used but what was checked before it went out.

Can I use my vendor's logs instead of my own?

As a supplement, yes. As your only record, no. You do not control retention or export, the logs stop at the boundary of that vendor, and they say nothing about what your staff did with the output, which is usually the part in dispute.

Is this not just normal application logging?

Largely, with two additions: the model version, and whether a human reviewed the output. Most teams already have the rest. The gap is that AI calls tend to be logged as ordinary API requests, so the fields that make them auditable never get recorded.

How do I log without storing personal data?

Store identifiers and hashes rather than content, keep the raw record in the system that already holds it lawfully, and let the log point at it. You get the ability to reconstruct events without creating a second copy of everything under a different retention rule.