Expect an auditor to ask four things: what the control is, who approved the tool, proof it ran on real changes, and what happened to its findings. Keep a short evidence pack: the policy, the vendor review, configuration screenshots, a sample of runs, and a record of exceptions.
What an auditor is really testing
Auditors do not grade the tool. They test whether you operate a control consistently. For code changes, the control is usually phrased as "changes are reviewed before production." If an AI tool is part of that review, the auditor will ask how it fits, and whether a human still decides.
The NIST Secure Software Development Framework gives useful language. SP 800-218 describes practices to reduce vulnerabilities in released software, including reviewing code and testing it. Many customers use it as a common vocabulary with suppliers. It does not name AI reviewers, so you explain how yours maps in.
The evidence pack
| Item | What it shows | Where to keep it |
|---|---|---|
| Written rule on how AI review is used and who approves merges | The control exists and a human decides | Policy repository |
| Vendor review record: data handling answers, sub-processors, terms | You assessed the tool as a supplier | Vendor register |
| Configuration export or dated screenshots | What is enabled, which repositories, which severity blocks | Evidence folder |
| Branch protection settings | The check cannot be skipped | Screenshot or API export |
| Sample of 10 to 25 recent pull requests with tool output and the human approval | The control ran, and people acted | Linked from evidence index |
| Findings log: opened, fixed, dismissed, with reasons | Findings are handled, not ignored | Ticket system or export |
| Exceptions record, with owner and expiry | Overrides are controlled | Exceptions register |
| Access list for who can change the tool's settings | Configuration is controlled | Identity provider export |
Sampling: what auditors do
They will usually pick changes themselves from a full list, not from your highlights. So make sure you can produce a complete list of merged changes for the period, and for each one show review evidence. The pack above helps, but the underlying data needs to be queryable.
Points that trip teams up
The tool approved it, nobody else did. If the AI check counts as the only review, say so and be ready to defend it. Most teams keep a human approval and treat the AI as an additional check. See should an AI review count as a required approval.
Silent configuration drift. Someone loosens a threshold to unblock a release and nobody records it. Keep a change log for tool settings.
Findings dismissed with no reason. A dismissal with the reason "false positive" and a reviewer name is evidence. A bare dismissal is a question.
Missing period coverage. Evidence must span the audit period. A tool turned on one month before the audit window ends leaves gaps.
Do not overstate
Describe what you do, not what a framework "requires" of AI tools. Avoid claiming compliance or certification because you use a review tool. A tool supports a control. It does not make you compliant.
Try it yourself
Open the framework mapping demo and see how one technical control can be linked to several framework requirements, then think about which of your evidence items support which line.
Click through it at your own pace, or open it full screen.
Quick check
Do I need to show every AI comment?
No. Keep a complete list of changes and a documented sample of tool output, plus the findings log.
Does using an AI reviewer change my SOC 2 or ISO scope?
It can add a supplier to your vendor list and a system to your change management evidence. Tell your auditor early.
Safeguard includes compliance and evidence automation that collects control evidence from connected systems, which can reduce manual screenshot work. Try the free scan at gold.safeguard.sh/scan first.
Sources
Last reviewed: 19 October 2026.
