Human-in-the-loop means a person checks the AI's work before it counts. That only works if the checkpoint is built so the person can really catch errors. A tick on a screen the reviewer has no time or means to challenge is not a control.
Last reviewed: 17 October 2026. Facts checked. We opened OWASP's LLM06:2025 Excessive Agency and LLM01 Prompt Injection pages, which both recommend human approval for high-impact actions. We opened NIST's AI Risk Management Framework page. We ran a web search on AI use in accounting and its controls, and one on LLM evaluation; those were practitioner and vendor pages and we cite no figures from them. We did not open the ICAI standards, so we do not quote them.
What the phrase means
"In the loop" means a person sits inside the process and can stop or change the result. That differs from a person who sees a summary afterwards. OWASP's pages use human-in-the-loop controls for privileged or high-impact actions, with the person approving before the action is taken.
Why a bad checkpoint fails
People tend to accept what looks fluent and complete. A reviewer who is tired, rushed or shown only the answer will often approve it. Fluent wrong answers are the hardest to spot. Our guide on AI hallucinations in audit explains why.
Common design faults:
- The reviewer sees the answer but not the source.
- The volume is too high to check in the time allowed.
- The reviewer lacks the skill for the task.
- Approval is one click, with no record of what was checked.
- The reviewer is also the person who built the tool.
Design questions for each checkpoint
| Question | Good answer |
|---|---|
| What exactly is the reviewer deciding? | Accept, correct or reject a defined item |
| What does the reviewer see? | The AI output next to the source text, row or cell |
| How much must they check? | Everything, or a stated sample, chosen by risk |
| Can they change the result? | Yes, in the same screen, with the change logged |
| What skill is needed? | Named level, such as senior for judgement items |
| How is the review shown? | Name, date, items checked, decisions |
| What stops a rubber stamp? | Sample re-performance by a second person |
Choose the review depth by risk
Not every output needs the same attention.
- Low risk and easy to verify (document sorting): review a sample. Track the error rate and raise the sample if errors rise.
- Medium risk (figures extracted for a working paper): review every item against the source.
- High risk (a conclusion, an observation, an adjustment): the reviewer re-performs the key step, not just reads the output.
- Actions (sending, posting): approval before the action, as OWASP advises for high-impact actions.
Set the depth in advance, in writing, and base it on test results. Our LLM test plan shows how to get those results.
Show the source beside the answer
The most useful single design choice is to put the AI's claim beside the exact page, cell or paragraph it came from, with a link. Then the reviewer checks one thing: does the source say this? If the tool cannot point to a source, treat the output as a lead, not as evidence.
Measure the reviewers too
A control that is never tested decays. Ways to test it:
- Seed a few known errors in a batch and see whether they are caught. Do this openly as a training and quality exercise, not as a trap.
- Have a second person re-review a small sample.
- Track how often reviewers change or reject AI output. If it is never, ask why.
- Track review time. Very short times may mean no real review.
Evidence to keep
For each AI-assisted working paper, keep:
- The task, model and version.
- The input and the output.
- The reviewer's name and date.
- What was checked, and how.
- Corrections made.
- Any items escalated.
SA 500 asks the auditor to consider the reliability of information used as audit evidence. A search of ICAI-hosted study material described reliability as including accuracy and completeness. A well-evidenced checkpoint is how you show you did that for AI output. Confirm the exact wording in the standard before citing it.
Who is accountable
The firm, and the signing partner, remain responsible for the work. A tool cannot take that over. NIST describes its AI Risk Management Framework as voluntary, with a Govern function for accountability. In plain terms, name the owner of every AI use and the approver of every checkpoint design. The AI governance internal audit workpaper provides a place to record it, and the AI use policy template gives you the firm-level rules.
A short checklist
- Is the decision the reviewer makes clearly defined?
- Does the reviewer see the source beside the answer?
- Is the review depth set by risk and by test results?
- Is the reviewer qualified for the task?
- Is the review recorded with name, date and what was checked?
- Is the checkpoint itself tested?
Frequently Asked Questions
What does human-in-the-loop mean in audit?
A qualified person reviews and approves AI output before it is relied on or acted on.
Is reviewing a sample enough?
For low-risk, easy-to-verify tasks it can be, if the sample size is set from test results and raised when errors rise. For judgement items, review all of it.
Can the preparer of the AI output also be the reviewer?
It weakens the control. Use a different person where you can.
How do we prove the review happened?
Record who reviewed, when, what they checked against and what they changed.
Does human review remove the need for testing the model?
No. Testing tells you where to put the review effort.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error