AI tools can draft a policy, a questionnaire answer, or a control description in less time than it takes to find last year's version. That is useful. It also moves the risk. The question an auditor or customer cares about is no longer who wrote the text. It is whether someone accountable read it, checked it, and agreed to it.
When approval is real, AI drafting is a productivity gain with a familiar control around it. When approval is a click, you have documents nobody actually stands behind, and an auditor who asks the approver a question about their own policy will find that out quickly.
This article covers what the reviewer should check for each kind of compliance artifact, how to stop approval sliding into a rubber stamp, and what the record should show. For approval gates on agents that take actions in your systems, see governing AI agents with scoped access. This piece is about documents.
The approval is the control
Frameworks already require approval for most compliance documents. ISO/IEC 27001:2022 Annex A 5.1 expects policies to be approved by management. SOC 2 auditors look for evidence that policies were reviewed and approved. None of these requirements care who or what produced the first draft.
That cuts both ways. AI drafting does not create a new compliance obligation for a policy. It also does not lower the existing one. The approver is accountable for every sentence, exactly as if they had written it.
What changes is the reviewer's job. A person reviewing a colleague's draft can assume the colleague knew the facts. A person reviewing an AI draft cannot. The model may have filled a gap with something plausible and wrong.
What the reviewer checks, by artifact
Policies
Does it describe what you do? An AI draft tends toward what organizations in general do. A policy that commits you to a practice you do not follow is a finding waiting to happen.
Are the specifics yours? Review cadences, retention periods, role names, and system names must match reality.
Does it conflict with another policy? Drafts written in isolation often restate a rule another policy already sets, slightly differently.
Is every commitment one you will produce evidence for? If the policy says "quarterly," someone needs to own the quarterly evidence.
Questionnaire answers
Is every factual claim true for the product in scope? Check each one against the source, not against memory.
Is anything absolute that should be qualified? "Never" and "all" are promises.
Does it match your other answers and your contracts? A suggested answer that contradicts your data processing agreement creates a real problem.
The general discipline is in answering security questionnaires. For AI-suggested answers, the extra step is verifying that a suggestion drawn from an older approved answer is still true.
Control descriptions and implementation statements
Does the description match the system? Name the actual tool, setting, or process.
Is the frequency right? Control frequency is what the auditor will test against.
Is the owner right? The named owner should know they own it.
Gathered evidence
An AI tool can also collect evidence: pulling an export, finding the right ticket, or attaching a configuration screenshot to a control. The reviewer checks the collection, not the prose.
Is it from the right period? Evidence from outside the audit period, or from after the sample date, does not support the control.
Is it from the right system? A staging configuration attached to a production control is a common, quiet error.
Is the population complete? If the evidence is a list, such as users or changes, confirm it came from the source system in full and was not filtered along the way.
Is the original attached? The file itself, with its timestamp, should be there, not only a description of it.
Risk entries
Is the risk real for you, in your context? Generated risk lists are long and generic.
Are likelihood and impact your judgment? A model's score has no basis in your environment. The scoring decision belongs to the risk owner.
Keeping approval from becoming a rubber stamp
Approval degrades when the volume is high, the drafts look polished, and rejecting one feels like extra work. Design against that.
Show what changed. For revisions, the approver should see a diff against the current approved version, not the whole document.
Show the sources. A drafted answer should show which approved answer, policy, or record it drew on, so the reviewer can check the claim against its source.
Match approver to content. The person who approves an encryption control description should understand encryption. Approval authority should follow competence, not seniority alone.
Make rejection easy. Reject, edit, and approve should be equally simple. If editing means starting over, people approve drafts they would otherwise fix.
Limit batch approval. Approving 40 answers with one click is not 40 reviews. Require per-item approval for anything external.
Re-review a sample. Periodically, a second person reviews a sample of approved items. Discrepancies tell you whether the first review is working.
What the record must show
An auditor testing an approval control will sample approved items and ask for the record. For each one, keep:
- Not done:
The artifact and its version
- Not done:
That it was AI-drafted, and by which tool or agent
- Not done:
The inputs or sources the draft used
- Not done:
The approver's identity, from your identity provider, not a typed name
- Not done:
The date and time of approval
- Not done:
What the approver changed, if anything
- Not done:
The decision: approved, approved with edits, or rejected
This is the same kind of record auditors ask for on any approval control. The AI fields are an addition, not a different regime.
What not to draft with AI
Some things should not be drafted by a model, however good the review.
Evidence of control operation. Evidence comes from the system: an export, a log, a screenshot with a timestamp. A model's summary of what a log shows is not evidence that it shows it. Keep the original.
Attestations and sign-offs. A management assertion, a risk acceptance, or a management review conclusion records a person's judgment. Drafting the judgment for them undermines the record's purpose.
Incident facts. Timelines and impact statements in an incident record should come from the people and systems involved.
Drafting the surrounding text, such as a template or a summary of sources, is a different matter. The line is between the record of a judgment and the paperwork around it.
Telling your auditor
Tell your auditor that AI drafts some documents, and walk them through the approval process before fieldwork. Most will treat it as one more approval control and test it the usual way. Being open early is easier than having them discover it from metadata.
If you are building toward ISO/IEC 42001, your own use of AI for compliance work is itself an AI use to govern under your acceptable use policy. The ISO 42001 framework page covers the rest.
How TrustLynce helps
TrustLynce's AI agent drafts policies, suggests questionnaire answers, and gathers evidence, with a named person approving every change. Nothing the agent drafts takes effect until that person approves it, so accountability stays with someone who can answer your auditor's questions.