Record the change identifier, the tool and model version, the inputs it was given, its findings with severity, the human decision with reason and time, and any overrides. With those fields you can reconstruct why a change was approved, months later, without relying on memory or screenshots.
Why logs matter more with AI tools
A person leaves a trail: a comment, an approval, a name. An AI reviewer's trail depends on what the tool stores. If its output is shown only in a pull request thread that later gets edited or deleted, you may lose it. And because model output varies, you cannot recreate a past answer by running the tool again.
So the record has to be made at the time, and kept outside the tool if the tool's retention is short.
Fields to capture
| Field | Why it is there |
|---|---|
| Change ID (pull request or commit hash) | Ties the record to the code |
| Timestamp of the run | Establishes order and period coverage |
| Tool name, version, and model identifier if exposed | Lets you reproduce or explain differences |
| Configuration in effect (rules, thresholds, repository scope) | Shows what the check was set to do |
| What was analysed: files, diff size, anything skipped or truncated | Shows coverage and gaps |
| Findings: location, class, severity, explanation text | The actual output |
| Gate result: pass, warn, block | The enforcement outcome |
| Human reviewer identity and decision | Shows a person decided |
| Reason for dismissals or overrides | Turns a click into evidence |
| Exception ID and expiry, if any | Links to the exceptions register |
The truncated or skipped field is easy to forget and valuable. An auditor who sees that a check ran, with no sign that half the diff was skipped, has been misled by omission.
Where to store it
Prefer a store you control, with append-only or tamper-evident properties, and a retention period at least as long as your audit cycle. Ask the vendor how long they keep run history, and whether you can export it through an API. If they cannot, copy the output to your own system at the time of the run, for example by a workflow step that saves it as a build artifact.
Limit who can edit these records. Separate access to change the tool's settings from access to alter the log.
Data minimisation
Logs of AI runs can contain code and prompts. That is sensitive. Store hashes or references where you can, keep full text only as long as needed, and apply the same access controls as source code. This also sits within the vendor questions covered in data handling questions to get in writing.
Check the log once
Take one merged change at random and try to answer: who approved it, what did the AI say, which version said it, and why was each finding dismissed? If you cannot answer in ten minutes, a field is missing.
For a wider view of this idea, see AI code generation audit trail patterns.
Quick check
Is the pull request thread enough as a log?
Often not, since threads can be edited, comments collapsed or repositories archived. Export a copy to a store you control.
Do I need to store the full prompt?
Not always. Keep what you need to explain the result, and treat full prompts as sensitive data with a short retention.
Safeguard includes compliance and evidence automation, which gathers control evidence from connected systems into one place. Try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
