Quick answerA company should keep a permanent, append-only log of every prompt or model version change to a production AI agent that records what changed, who approved it, why it was made, and what evaluation results justified it, kept separately from the version-control history so it survives even if the code repository is rewritten or the branch is deleted.
Why version control alone is not a compliance record
Prompt versioning and rollback solves an operational problem: how do you get back to a known-good state quickly when a change misbehaves. That is necessary, but it is not the same thing as a compliance-grade audit trail, and treating git history as your audit trail is a common and risky shortcut.
Git history can be rewritten, branches get deleted, commit messages are written by whoever happened to be pushing the change and are rarely written with an auditor in mind. A regulator, an insurer investigating a claim, or your own legal team after an incident needs answers to different questions than "what did the code look like at commit X": who approved this specific change, what business or technical reason drove it, what evaluation results existed before it shipped, and whether it was rolled back or superseded later.
What the record needs to contain
A compliance-grade change log is a separate, append-only record, ideally outside the code repository entirely, that captures one entry per production change with five fields: the exact prior and new prompt or model version identifiers, the name of the person or role who approved the change, the stated business or technical reason, a link to or summary of the evaluation results that supported the decision, and the effective date and time the change went live.
This overlaps with, but is distinct from, legal and compliance sign-off before launching an AI agent, which covers the one-time review before an agent first goes live. The ongoing audit trail is the ledger of every change after that, not a single gate at the start.
From the team
We build production AI systems for startups.
LLM pipelines, RAG, and agent workflows that hold up under real traffic — not just in the demo.
Who should be able to write to it, and who should not
The integrity of the record depends on the people making changes not being the only people who can edit the log of those changes. A common failure pattern is an audit trail stored in the same tool and under the same access permissions as the deployment pipeline, so the engineer who pushes a risky change can also quietly edit the entry describing it. The fix is boring but effective: the log should be append-only at the infrastructure level, written automatically by the deployment system rather than typed in by hand after the fact, and reviewable by someone outside the engineering team, such as whoever owns regulator audit readiness for the company.
How long to keep it, and how this supports other processes
Retention should match your longest plausible dispute or regulatory look-back window, not your typical incident retrospective window, which is usually much shorter. A customer dispute or regulatory inquiry can reference behavior from over a year ago, and if the entry for the prompt version active at that time has already been purged, you cannot reconstruct what the agent was actually instructed to do.
This record also directly supports explaining an AI agent's reasoning to auditors: explainability at the level of a single conversation is much easier to produce credibly when you can also show, with a timestamp, exactly which prompt and model version produced that conversation in the first place.
FAQ
Is this the same as the rollback mechanism?
No. Rollback is about restoring a prior working state quickly. The audit trail is a permanent record of every change, kept even after a change is rolled back, so there is always a complete history of what ran in production and when.
Does every prompt tweak need a full approval record?
Small, low-risk wording changes can go through a lighter process, but anything that changes what the agent is authorized to do, how it makes decisions, or which model powers it should go through the full record. Set the threshold explicitly rather than leaving it to individual judgment.
Where should this log actually live?
Outside the code repository and outside the deployment pipeline's own write access, ideally in a system with its own access controls, so the people who can make changes are not the same people who can edit the record of those changes.