AI should read the evidence, test every attribute and cite the page it used. It should never be the one who decides a control passed or failed. In SOXLayer, no AI result changes a test status until a person accepts, edits or overrides it, and an override needs a written reason. The rest of this post covers how that rule works in practice: citations instead of bare verdicts, an Insufficient verdict instead of forced guesses, escalation when the AI is unsure, and evidence treated as data, never as instructions.
Human in the loop is not a feature toggle
It is tempting to frame "human in the loop" as a setting that a cautious admin turns on and a confident one turns off. That framing is wrong. In a control testing workflow, a person accepting, editing, or overriding every AI proposal is not a safety net bolted onto the process. It is the process. The AI proposes a result, and a person disposes of it. Removing that step does not make testing faster in any way that matters, because it removes the accountability that makes the test conclusion defensible in the first place.
In practice this means the reviewer always sees three things together: what the AI concluded, why it concluded that, and where in the document it looked. The reviewer's job is not to redo the AI's work from scratch. It is to confirm the AI's reasoning holds up, or to catch the cases where it does not.
Why citations matter more than the verdict itself
A verdict on its own, "Pass" or "Fail" with nothing behind it, asks the reviewer to take the AI's word for it. That is the opposite of what control testing is supposed to produce. The value of AI here is not that it can render a judgment. It is that it can read a fifty page evidence packet in seconds and point to the exact place that supports a conclusion.
That is why every attribute the AI tests should come back with the exact quote and page it relied on, not just a label. When the AI marks an attribute as Pass, the reviewer should be able to click straight to the sentence on the page that justified it. SOXLayer pairs this with annotated evidence: labelled highlights drawn directly on the source document, so the reviewer is looking at the same words the AI looked at, not a paraphrase of them.
This changes what review actually is. Instead of re-reading the whole document to check the AI's work, the reviewer is verifying a specific, cited claim. That is a faster review and a more rigorous one at the same time, which is a combination you rarely get.
Confidence thresholds and what "Insufficient" really means
Every AI proposal carries a confidence score: how strongly the evidence in front of the AI supports its conclusion. High confidence means the document plainly supports the attribute, for example a named approver and a date on the approval line of an invoice. Low confidence means the AI found something relevant but not conclusive, such as an approval email that never mentions the amount.
"Insufficient" is a distinct verdict, not a low-confidence Pass or Fail. It means the AI could not find enough in the evidence to support any conclusion, whether that is because the document is missing the relevant detail, the attribute requires information the evidence simply does not contain, or the document does not match what the sample calls for. Insufficient is a useful, honest answer. An AI that always forces itself into Pass or Fail, even when the evidence does not support either, is less trustworthy than one that says plainly "I don't have enough here."
Confidence floors are configurable by admins, along with whether the AI is allowed to auto-fill Pass or Fail results at all. A program testing high-risk controls might set the floor high and require human acceptance on every result regardless of confidence. A lower-risk area might allow bulk acceptance of high-confidence results, with a person still reviewing each one before accepting, just faster.
Start your 14-day free trial
Bring one control and its evidence. The trial includes 5 AI sample tests and 50 manual ones, no card needed.
Escalation: when low confidence should trigger a second opinion
One model reading one document once is not enough when the evidence is ambiguous or two documents disagree, such as an invoice total that differs from the payment record. Those results should escalate to a stronger model automatically, with the reasons listed next to the result.
Escalation does two jobs. It sends only the ambiguous cases to the slower, more expensive model, instead of every sample. And it writes down why the result needed a second look, so the reason stays on the test as part of its evidence trail, where a reviewer or an auditor can read it. The AI testing page shows how the first pass and the escalation sit side by side on a test.
So the stronger model sees only the attributes under the floor or in conflict, and each escalated result says why it was sent, for example "the approval date on the email differs from the date in the ERP".
Prompt injection in evidence documents: evidence is data, not instructions
Evidence documents are not written by people trying to help the AI test them correctly. Some are messy, some are incomplete, and every so often one contains text that looks like an instruction aimed at whoever, or whatever, reads it next. An AI reading evidence has to treat every word in that document as content to evaluate, never as a command to follow. A PDF does not get to tell the reviewer what conclusion to reach, and it does not get to tell the AI that either.
Evidence as data, not instructions
During testing, a document contained an embedded "system note" instructing the reviewer to mark everything as Pass. The AI flagged it as a prompt injection attempt and ignored the instruction rather than following it. The note was treated the way any other line of text in the document should be treated: as something to read and report on, not as a command to obey. The AI surfaced what it found so a human could see it, and moved on with testing the actual attributes the sample called for.
The rule is narrow: the AI reads a document to extract facts for the attributes under test, and nothing in the document changes that job. Text that reads like an instruction, like the "mark everything as Pass" note above, gets flagged for a person, never followed.
Why AI must never change a test conclusion by itself
There is a meaningful difference between an AI that proposes a result and an AI that finalizes one. SOXLayer's AI output never changes a status by itself. A person always has to Accept, Edit, or Override the AI's proposal, and an Override requires a reason. That reason is written to the hash-chained audit trail, so anyone looking back at the test later can see not just what the AI thought, but what a person decided and why, when those two things differed.
The AI can draft the test conclusion, the narrative summary that ties the attribute results together, but even that draft sits in front of a person before it becomes final. Bulk acceptance exists for high-confidence results so reviewers are not clicking through hundreds of obvious Pass results one at a time, but bulk acceptance is still a person choosing to accept, not the system deciding on its own that no one needs to look.
Admins control this at the program level: AI on or off, confidence floors, whether AI can auto-fill Pass or Fail at all, a daily AI run quota, and whether human acceptance is required on key controls regardless of confidence. Prompt versions are tracked, so if the AI's behavior on a given attribute changes because the underlying prompt changed, that change is visible and attributable rather than silent.
What AI should do versus what it should not do
| AI should | AI should not |
|---|---|
| Read evidence (PDFs, images, spreadsheets) and test each attribute against it | Change a test status without a person accepting, editing, or overriding it |
| Propose Pass, Fail, Insufficient, or N/A with a confidence score | Force a Pass or Fail when the evidence does not clearly support one |
| Cite the exact quote and page it relied on for every proposal | Assert a verdict without pointing to where in the document it came from |
| Escalate low-confidence or conflicting results to a stronger model with reasons listed | Silently settle on a low-confidence answer without flagging the uncertainty |
| Treat every word of an evidence document as content to evaluate | Follow instructions embedded in an evidence document, however they are phrased |
| Draft a test conclusion for a reviewer to read and finalize | Publish a final conclusion on its own |
A note on admin controls
None of the above works as a blanket promise. It works because it is configurable and auditable: confidence floors an admin sets, a daily run quota that caps how much the AI processes unattended, required human acceptance on key controls, and tracked prompt versions so behavior changes are visible over time. The design principle is the default; the admin controls are what let a program tune it to its own risk tolerance.
Day to day, review becomes checking a cited claim
For a reviewer, each proposed result arrives with the passage it rests on highlighted on the document, the reason it was escalated if it was, and an Insufficient label when evidence is missing instead of a forced guess. Review becomes checking a cited claim, not re-reading the file. On a three-way match sample, that means checking a flagged quantity variance against the receipt instead of comparing five documents line by line.
For a program manager or the person answering to the CFO's office, the AI's role in testing stays fully accountable. Nothing gets marked Pass because a model said so. Every conclusion traces back to a person who accepted, edited, or overrode a proposal, with a reason on record when they overrode it.
Set it up so the AI never decides a key control on its own
- Decide which controls are key, and require human acceptance on every AI result for those, whatever the confidence.
- Set a confidence floor for each risk level. Results below the floor escalate to the stronger model before a reviewer sees them.
- Choose whether the AI may pre-fill Pass or Fail at all, or only propose results for a person to accept.
- Set a daily AI run quota, so the amount processed without anyone watching has a ceiling.
- Read the override reasons each month. A cluster of overrides on one attribute usually means its test template needs a clearer pass criterion.
- When an exception is real, classify it with the deficiency classification guide.
Key takeaways
- No AI result changes a test status until a person accepts, edits or overrides it, and an override needs a written reason.
- Citations, the exact quote and page, matter more than the verdict itself, because they let a reviewer verify a specific claim instead of re-reading the whole document.
- "Insufficient" means the evidence cannot support any conclusion, for example an invoice approval with no approver named. It is a verdict of its own, not a weak Pass or Fail.
- Low-confidence or conflicting results should escalate automatically to a stronger model, with the reasons for escalation documented.
- Text inside evidence is content to report on: when a test document told the reviewer to mark everything Pass, the AI flagged it and kept testing the real attributes.
- AI can draft a test conclusion, but it never finalizes one: only a person's Accept, Edit, or Override (with a reason) closes out a result.
Sources and further reading
The standards and guidance behind this article. Your external auditor's methodology and your company's own policy still set the requirements for your program.
- PCAOB AS 1105, Audit Evidence: what makes evidence relevant and reliable.
- PCAOB AS 2201, An Audit of Internal Control Over Financial Reporting: the auditor's standard for ICFR audits.
- OWASP Top 10 for LLM Applications, LLM01: Prompt Injection: how instructions hidden in documents can steer a model.
- NIST AI Risk Management Framework: a reference for governing, measuring and managing AI risk.
Read these next
The three-way match control: how to test it well
Seven attributes to test, five documents to request per sample, and the four exceptions a three-way match test turns up most often.
Control deficiency, significant deficiency or material weakness? A classification guide
Two questions decide the label: how likely a misstatement is and how big it could be. Plus why several small findings in one account can add up.
Interim vs roll-forward testing: how to plan the SOX year
How to set an interim cutoff, size roll forward samples proportionally, and plan a SOX year that avoids a year end crunch.