In my last blog, I looked at where AI can support audit reporting without taking ownership of the judgments behind it. The same distinction matters in control testing. An agent can execute much of the testing sequence, but the two decisions that give the results meaning still belong to the auditor.
When an AI agent tests a control, it executes a defined sequence:
All four steps can be delegated, each with a catch. But two critical judgments cannot be delegated, regardless of how capable the agent is.
In all my years testing controls the slow way, I have not seen a technology change fieldwork this quickly. Audit teams are paying attention because the pressure is real. The IIA's 2026 North American Pulse of Internal Audit documents escalating capacity constraints: staffing reductions increased from 11% in 2024 to 18% in 2025, while budget cuts soared from 11% to 19%. Yet adoption remains uneven. Some functions are experimenting with AI-supported testing, while others are still trying to understand where automation fits and where professional judgment must stay firmly with the auditor.
Exception characterization and deficiency evaluation sit at the heart of control testing. An agent can help identify potential issues, but deciding what they mean and whether they rise to the level of a deficiency remains a matter of auditor judgment..
Most of the disagreement about AI in control testing comes from people talking about different parts of the process without realising it.. One person might say an agent can test controls. Someone else might say that is reckless. Both are describing real things. The first person is usually thinking about activities such as population analysis, sample selection or attribute comparison on a well-defined population, where the work is largely procedural. The second is usually thinking about exception characterization and deficiency evaluation where the auditor has to determine what a result actually means and whether it matters.
They are both right about the part of the process they have in mind. The problem is that "control testing" gets used as though it describes a single activity, when it actually covers several very different ones.
To understand where automation fits, it helps to walk through the process step by step.
The agent reads the control as written in the risk and control matrix and converts it into testable attributes. This works better than most auditors expect, and it exposes something uncomfortable: A large share of control descriptions in production RCMs are not testable as written. "Management reviews the reconciliation monthly" does not specify what evidence of review looks like, or what monthly means at period end. An agent forced to derive attributes from that sentence will either produce weak attributes or ask for clarification, and functions that pilot this consistently report that the first real output is a cleanup list for the RCM. Per the Global Internal Audit Standards, Standard 13.4 places the identification of relevant and adequate criteria on the internal auditor, and Standard 13.6 requires a documented, approved work program before execution. The agent derives. The auditor approves.
The agent connects to the source system and defines the population the control operates over. This is where silent failures do the most damage. An agent that pulls from a replica, a filtered view, or a stale extract will produce internally consistent results that are entirely wrong. An agent can reconcile a population against a control total if told which total to use, but it cannot know on its own that the reporting environment excludes intercompany entries or that a subsidiary migrated systems in August. The agent extracts and reconciles. The auditor validates that it is the right population.
For attribute testing, the agent applies the sampling methodology. For full-population testing, this step disappears, and that disappearance is the honest case for continuous monitoring: When the marginal cost of examining item 10,000 approaches the cost of examining item 40, sampling stops being a constraint and becomes a choice. The agent executes whichever method it is given. Deciding whether sampling or full-population testing is appropriate, and documenting why, is not something the agent decides for itself.
The agent examines each selected item against every attribute and records the result. Human attribute testing degrades with volume, fatigue, and time pressure. An agent's twelve-thousandth comparison is identical to its first. This one has no catch. Given solid inputs from the first three steps, the comparison itself is genuinely and fully delegable.
An item fails a test. Someone still has to decide what that means.
The agent can record that item 4,417 lacked evidence of approval. It cannot tell you whether that is a control failure, a documentation failure, a system logging gap, or a legitimate exception under a policy carve-out it has never seen. Those four outcomes look identical in the data and lead to completely different conclusions. This is the point where the work stops being mechanical, and no amount of additional training data changes that, because the missing information is not in the data at all. It is knowledge about this organization's history, its systems, and the carve-outs nobody wrote down. Standard 14.1 requires the auditor to apply professional skepticism in evaluating whether information is reliable and to determine whether additional information gathering is necessary. An exception that has not been characterized has not been evaluated.
Whether the exception rate constitutes a control deficiency, and what its significance is, is a judgment about this organization, at this time, against this risk appetite. An agent can propose a rate against a rubric. It cannot decide if the rubric is wrong for this situation, or that a 2 percent exception rate matters more this quarter because of something happening upstream that never made it into the control description. This holds for the same reason across governance and reporting processes: someone has to be able to defend the call.
These two decisions are why "an agent tested this control" is not, by itself, a complete sentence.
The phrase gets used loosely. Moving from periodic testing to continuous monitoring requires four things to already be true, and most functions have one or two.
That third condition is where most pilots stall. Continuous monitoring changes exception handling from a scheduled activity into an operational one. Someone has to own the exception queue on an ongoing basis. If nobody does, the backlog grows until people stop paying attention to it. The parallel challenge in agentic environments is the same ownership problem. I have watched this failure sink two otherwise well-built pilots. Both times the fix was organizational, not technical.
Documentation demands increase rather than decrease.
Standard 14.6 requires documentation sufficient to support engagement results and to enable a competent person to reperform the work, and requires CAE review and approval. When part of the testing was performed by an agent, reperformance means someone must be able to reconstruct what the agent did, on what data, under what version of its configuration. That means logging the model or system version, the configuration in effect, the population definition and its reconciliation, the attribute set and who approved it, every exception and its characterization, and the reviewer. Functions that treat agent output as a black box and document only the conclusion will not survive an external quality assessment on this point.
Take one high-volume, well-defined, system-based control. Run it both ways for a full cycle. Compare not just the results but the exceptions each method found that the other missed. That comparison is the most useful artifact you will produce in the first year, and it is what you show your audit committee when they ask how you know this works. The good news is that I have run this exact pilot with three audit functions this year, and the pattern holds every time: The value shows up in the exceptions the two methods disagree on, not in the ones they agree on.
This is just one example of how AI can support internal audit without replacing auditor judgment. So far in this series, we've looked at PBC requests, audit reporting and control testing. Next, I'll explore a tougher question: Can AI help identify the blind spots that often exist in control self-assessments? And if it can, where should the line between machine insight and human accountability be drawn?
Mike Levy is a former Chief Audit Executive and CEO of Cherry Hill Advisory, a practitioner led internal audit, risk, and assurance firm focused on helping organizations build modern, standards-aligned audit and risk functions, built on a human-led, AI-enabled approach to modern assurance.
