Agentic AI in Internal Audit, What to Automate, What to Keep

 

Consider an illustrative scenario, not a real engagement. A mid-sized distributor connects an audit agent to its ERP, its document repository and its ticketing tool. Within a week the agent has pulled invoices, receipts and approvals for 240 purchase orders and produced a tidy memo saying the procure-to-pay control passed. The audit manager reads it, likes it, and asks the only question that matters: which records did the agent open? Nobody can answer.

The short answer to the sequencing problem is this. Agentic AI should first take bounded, repeatable, evidence-based work: a finite set of documents, stable rules, and output you can check against a known result. It must not decide audit scope, judge whether evidence is sufficient, conclude that a control works, rate a finding, or close an issue. Those decisions belong to accountable auditors, and an agent can only prepare the ground for them.

This article is for internal auditors, chief audit executives and the managers and audit committee members who oversee them. After reading it you will be able to sort audit tasks into automate now, automate with review gates, and keep human. You will also have a short list of access rules, evidence requirements and escalation triggers to put in place before any agent touches a workpaper. The question to ask is not whether AI can replace internal auditors. Ask which audit activities are bounded enough to automate safely, and which decisions need independent professional judgment and a named person who answers for them.

 

What Makes Agentic AI Different for Internal Audit

An agentic AI system pursues a goal through several steps. It chooses which tools to call, retrieves information, drafts output and, in some designs, takes actions in other systems. A chatbot answers one prompt with one reply. An agent asked to test a control might query a database, open forty documents, compare them against criteria, write an exception list and file a ticket, all without a person watching each step. The joint guidance from the cybersecurity agencies of the United States, the United Kingdom, Canada, Australia and New Zealand describes these systems as agents that use large language models to reason, plan, decide and act on their own.

That autonomy changes the risk profile in five ways. Multi-step planning means a small error early in the chain can compound by the end. Tool use means the agent holds credentials, so a mistake or a manipulation becomes an action. Retrieval means it can pull documents that sit outside the approved audit scope if nobody has fenced the search. Dynamic output means the same question on the same data can produce different wording, and sometimes different conclusions, on different days. Action capability means some mistakes cannot be undone. Each of these is manageable. None of them is visible if you evaluate an agent the way you would evaluate a spreadsheet macro.

The Financial Reporting Council in the United Kingdom offers a useful way to think about audit quality risk. Its guidance on generative and agentic AI, written for external audit firms but easy to transfer to internal audit, groups the risks to audit quality into three categories. Deficient output covers hallucination, omission, distortion and faulty reasoning, plus the way errors amplify when agents hand work to other agents. Misuse of output covers an output that is fine but gets misread: a contract review treated as a complete lease summary, or an input to judgment treated as a conclusion. Non-compliant methodology covers a method that fails the auditing standards even when the tool works as designed. The second and third categories are people and design problems, which is why buying a better model does not solve them.

Accountability does not move to the tool. The FRC states that regulatory accountability for deploying AI tools and for the quality of audit outputs stays with the firm and the responsible individuals, and that the guidance does not change this. In an internal audit function the same logic points at the chief audit executive and the engagement leads. An agent cannot own an opinion, cannot be questioned by the audit committee, and cannot explain to a regulator why it concluded what it concluded unless a person built the record that makes the explanation possible. Everything that follows in this article is a way of building that record while still getting the time savings.

How to Decide Whether a Task Is Bounded Enough to Automate

Start with the evidence boundary. Ask whether the task depends on a finite, known set of documents or records: a purchase order, a goods receipt, an invoice, an approval, a bank advice. If yes, you are working in a closed evidence world, and an agent can be pointed at it with confidence. If relevant evidence could come from anywhere, including someone's recollection of a conversation or a fast-moving business context, the world is open. Open-world tasks stay human-led, or a person frames the question first and the agent only gathers material inside that frame.

The second test is whether the rules hold still while you work. A three-way match, a user access review against an authority matrix and a duplicate-payment check all run on criteria that change slowly and can be written down. A task that requires reading a changing business situation, such as judging whether a reorganization weakened a control, cannot be reduced to rules, and an agent asked to do it will produce confident text with no anchor. You can widen the closed world by tightening your evidentiary standard. Approval is required is too vague to automate. Approval must be recorded on this form, in this field, by a person holding this role is a rule an agent can apply and a reviewer can verify. Vague criteria are what push tasks into the open world and turn time savings into exception handling.

The third test is whether you can check the output against a known result. Run the agent on a population where you already know the exceptions, from last year's manual work or from a seeded test file, and see whether it finds them. A task whose output cannot be verified this way should not be automated, because you will have no way to learn how wrong it is. If the answer to the first three tests is no, keep the task human-led or limit the agent to assisted research. Autonomous execution is for work that passes all three.

Four further questions decide how much freedom the agent gets. Is the action reversible, and does the agent need anything beyond read-only access? Can the task stop and hand over when uncertainty appears, with the context already assembled? Can the function keep a complete audit trail of what the agent received, did and produced? Would an error cause material, legal, privacy or reputational harm? A last check is cheap and often skipped: would a rules engine, a query or a robotic process automation script do the job better? Many initiatives labeled agentic are ordinary automation with a new name, and a deterministic tool is cheaper and easier to defend. If a plain script gives the same answer, use the script and keep the agent for work that needs language understanding.

What to Automate First in Internal Audit

The best first wave shares a profile. The evidence set is finite, the rules are explicit, the volume is high, the action is reversible, errors are cheap, and a reviewer can reach the source record behind every output. A sensible order is to begin with productivity and research uses, then move toward fieldwork and reporting as governance, prompts, controls and reviewer skill mature. The table below sorts the common candidates and shows who keeps the judgment.

Use case	What the agent can do	What the auditor owns
Evidence requests	Track requests, send reminders, flag overdue items, list missing documents	Scope, relevance, and whether received evidence is actually usable
Evidence indexing	Classify documents by process, control, period and owner	Validating the classification on a sample
Population preparation	Reconcile files, remove duplicates, flag gaps in records	Confirming the population is complete and fit for testing
Rule-based testing	Run a fixed test such as date, threshold, approval or three-way match checks	Validating test logic and judging the exceptions
Access review preparation	Match users, roles, owners and review records	Deciding whether access is appropriate and investigating exceptions
Contract and policy comparison	Compare documents against defined criteria	Assessing legal or control significance
Walkthrough support	Draft interview guides, transcribe meetings, draft notes	Setting objectives, running the interview, verifying the notes
Anomaly triage	Rank unusual transactions or patterns across full populations	Deciding whether an anomaly points to a finding
Workpaper and report drafting	Prepare first drafts from approved evidence in house style	Reviewing, editing, signing off, and deciding conclusions and wording

Three kinds of work belong in the automate now group. Evidence gathering and reconciliation comes first: pulling the invoice, order, receipt and approval for each selected item and putting them side by side. Request-list management comes next, which is pure coordination overhead with no judgment in it, and it recovers more hours than most teams expect. Uniform IT general control checks such as user access reviews and configuration baselines form the third kind. All three run against closed evidence, produce verifiable output and carry a low blast radius. The design rules are modest. The agent works under its own named, read-only account, the test logic is version-locked, and a rerun on the same data must produce the same exceptions. The agent must never mark evidence as received when it is not on file.

A second group works well with review gates. First drafts of workpapers, risk and control matrices, observations and report sections can be produced in minutes instead of days, which frees time for interviews and root cause work. The rule is that every statement in the draft traces to evidence before a reviewer signs, and a draft never leaves the function as the report. Follow-up testing fits here too: the agent compares management's closure evidence against the original recommendation and lists the gaps, and the auditor decides whether the issue is closed. Continuous monitoring and anomaly triage over full populations extend coverage far beyond sampling, with one condition. An anomaly is a lead, not a finding, and the investigation is human.

A third group should be augmented only. Risk identification, mapping risks to audit objectives, developing findings, scoping choices and assessing control design adequacy all depend on context, and the output looks polished enough to invite automation bias, which is the habit of trusting a fluent answer. Use the agent as an input to professional judgment and record in the workpaper that the content began as a draft. When I review an agent-assisted workpaper, the first thing I look for is the source record behind each statement. If a reviewer cannot reach it in a minute, the workpaper is not ready.

How to Run Three-Way Match Testing With an Agent: A Worked Example

This is an illustrative scenario with assumed numbers, not a documented engagement. A manufacturer has 18,400 supplier invoices in the audit period. The audit team has always tested procure-to-pay by sampling 60 invoices by hand, which covers about 0.3 percent of the population. The team writes a fixed test: the invoice must match a purchase order and a goods receipt, quantity must agree within a stated tolerance, and unit price must agree within a stated tolerance. The test logic is version-locked as version 1.0, the agent gets a read-only account to the three data sources, and a senior auditor signs the criteria before anything runs.

The agent runs the test on all 18,400 invoices and flags 612 exceptions, a rate of 3.3 percent. The auditor opens every one of the 612 and sorts them. Of the total, 431 are timing differences where the receipt was posted after the invoice but within the period. Another 118 are price variances that look like breaches only because the tolerance table in the test was out of date. Forty-one invoices have no goods receipt at all, and 22 look like possible duplicates. The counts add up to 612, and the arithmetic is the first thing the reviewer checks. The auditor also pulls 40 invoices the agent passed, chosen at random, and finds one that should have been flagged: the receipt matched a different line on the same purchase order. That defect is in the test logic, not in the model, so the team fixes the rule, versions it as 1.1, and reruns. The rerun produces identical results on unchanged data apart from the corrected case.

Then the human work starts. The 41 missing receipts and the 22 possible duplicates go to the accounts payable lead with specific questions. The auditor decides whether the explanations are credible, whether the cause is a one-off error or a design weakness in how receipts are posted, and how the result affects the control conclusion. The agent did none of that and was never asked to. The conclusion, the rating and the sign-off remain with the engagement lead and the audit manager. If the explanation for the missing receipts is that the stores system was down for two days, someone has to ask, verify and decide, and no volume of data replaces that conversation.

Field	Entry
Metric	Share of the invoice population tested
Definition	Invoices run through the match test divided by invoices in the period
Baseline	60 of 18,400 by manual sample, about 0.3 percent
Result	18,400 of 18,400 by agent, with 612 exceptions reviewed by a person
Data source	ERP extract, goods receipt log, version-locked test file
Owner	Audit manager
Evidence retained	Source extracts, test version, run log, exception worksheet, signed workpaper

Report what did not improve, because that is where the lesson sits. Review time for exceptions was higher than planned, and most of the load came from an outdated tolerance table, which a pre-run check of the criteria would have caught. The 100 percent coverage figure also says nothing about whether the population itself was complete, which is a separate test the auditor owns. Treat the numbers as a template. In your own function, replace them with your baseline, measure the same fields, and keep the artifacts an external reviewer could ask for.

What You Must Never Delegate to an Agent

The distinction is between assisting with a decision and making it. An agent may organize evidence, point out inconsistencies, propose questions and even draft a preliminary classification. It must not deliver the final decision on the matters below, and the final decision must be recorded as a human one. No technology is permanently barred from helping with these areas. The bar is on delegating the decision itself to an autonomous system.

Judgments About Scope and Evidence

Audit scope and the audit universe belong to the chief audit executive, the audit committee and the accountable audit leaders, based on the mandate, the risk assessment, organizational priorities and professional judgment. An agent can summarize risk information and suggest areas for attention. It cannot decide what the function will and will not examine, because that choice allocates scarce assurance capacity and is part of what the board holds the function to account for.

Sufficiency and appropriateness of evidence is the next line. An agent can report that 212 of 240 sampled items had all three documents. Whether that supports a conclusion about the control depends on reliability of the sources, management representations, the risk at stake and the auditor's skepticism, and none of those fit in a rule. The credibility of explanations is in the same category. When management says a receipt was posted late because a system was down, a person must ask for corroboration and decide whether the explanation holds. Root cause analysis sits here too. An agent finds what happened, and why usually comes from people who know the process.

Judgments About Controls, Ratings and Closure

Whether a control is effective is a professional conclusion. The agent can execute a defined test and list exceptions. The auditor decides whether the control objective was met and whether the exceptions are an isolated error, a design deficiency, an operating failure or a symptom of a broader problem. Ratings work the same way. The significance of a finding depends on likelihood, impact, recurrence, compensating controls, management's risk acceptance, regulatory or contractual obligations and how the finding relates to others. A preliminary rating from an agent can be useful as a prompt. The final rating encodes risk appetite and context, so a person owns it.

The overall audit conclusion balances evidence, uncertainty, limitations and contradictory facts, and a qualified auditor must own and approve it. Closing remediation issues is where automation is most tempting and most dangerous. An agent can track due dates, compare closure evidence against the original recommendation and flag gaps. It must not close an issue because a document was uploaded or a task was marked complete. Uploading a file is an event. Remediation is an outcome, and only a person can judge whether the two are the same.

Allegations, Communication and Oversight Settings

An agent may notice unusual patterns and rank them for investigation. It must not accuse an individual, infer intent, state a legal conclusion or communicate an allegation without human investigation and the function's own governance. The harm from a wrong accusation falls on a real person and is hard to reverse. For the same reason an agent must not communicate results to the audit committee, the board or external parties without approval, and it must not alter production data, access permissions, financial records, HR records or security settings.

One more item is easy to miss: the agent must not set its own level of oversight. Approval thresholds and review points are chosen by accountable people when the workflow is designed, and an agent that can adjust them has been handed the authority it was supposed to be checked against. Standard 4.3 of the IIA's Global Internal Audit Standards, on professional skepticism, is the right test for all of this. An agent can make the auditor faster. It must never make the auditor less questioning, and any workflow where reviewers click approve without opening the source has quietly broken that standard.

Controlling Audit Quality Risks in AI Deployments

Achieving appropriate confidence in audit quality when using generative and agentic AI requires balancing four core pillars: direct human review, staff education and governance, rigorous system design, and formal certification. The balance across these areas is a matter of professional judgment.

Where output serves directly as audit evidence, auditors must evaluate both the quantity and quality of evidence obtained, rather than looking at output reliability in isolation. If an AI-enabled procedure significantly reduces overall audit risk compared to traditional alternatives, accepting a higher initial risk of deficient AI outputs can be acceptable provided the net audit risk remains acceptably low.

Active Human Review and Oversight

Direct human oversight serves as the single most critical safeguard against AI output deficiencies and automated execution drift.

Final Output Review

Reviewers must possess the specific technical competence required for the engagement, combining audit expertise with relevant sector or domain context. Review activities must explicitly evaluate whether final outputs are accurate, complete, internally consistent, and aligned with the reviewer's independent knowledge of the audited entity.

Reviewers must apply professional skepticism, account for automation bias, and remain alert to the model's tendency to state incorrect conclusions overconfidently. Effective review often requires forming an independent baseline judgment to compare against the model's output, such as independently reading source contracts to verify AI-generated summaries or exercising independent professional judgment to draft risk lists before reviewing model recommendations.

Agentic System Oversight and Intermediary Control Points

In multi-step agentic systems, oversight must occur at predefined control points during execution rather than solely at the final output stage. Control points trigger when specific criteria are met, such as when an intermediary work program is drafted, when the system requests permission to call an external tool, or after predefined time or iteration thresholds are reached.

At these control points, human overseers must actively review intermediate outputs, authorize next steps, or re-route execution paths. Establishing control points based on known model failure modes prevents early errors from compounding through the workflow.

Staff Education and Firm Governance

Policy design and continuous workforce education address both deficient system outputs and human misuse of valid AI results.

Workforce Education

Training programs must clearly define both the permissible use cases and the operational boundaries where the tool fails or produces unreliable results.

Training on runtime input construction must emphasize precise task specification and structured context delivery:

• Task Specification: Prompts must clearly communicate scope, state intended boundaries, outline the requested execution sequence (including reasoning modes or intermediate tools to invoke), and mandate specific output schemas. Instructing models to explicitly state uncertainty or highlight missing data points prevents hidden assumptions.

• Supporting Information: Context files, blueprints, and prior workpapers should be uploaded using structured formatting to maximize logical adherence and prevent model distraction.

Staff education must also train auditors to interpret system outputs accurately, recognize tool scope and limitations, and understand how firm methodology directs them to act on AI-generated results.

Governance Policies

Firms can set central boundaries or allow audit teams discretionary latitude when using AI tools. Centralized restriction generally lowers audit risk, though it trades away execution flexibility.

Firms should implement highly prescriptive usage and prompt controls when:

• The tool was built for a single, narrow use case.

• Deficient outputs pose severe risks to overall audit quality.

• Ad-hoc user prompts perform significantly worse than standardized, engineered prompt templates.

• Certification testing was restricted to narrow prompts or configurations.

• Testing shows model performance varies wildly based on minor prompt changes.

• Pilot programs show engagement teams repeatedly misuse the tool or misinterpret outputs.

• Post-execution human review cannot reliably catch output errors.

• Effective review requires rare specialist skillsets.

Structural System Design and Architecture

Engineering safeguards directly into the application architecture mitigates baseline AI model limitations and interaction failures.

Cross-Cutting System Architecture

Architectural design structures how AI components process tasks and manage data:

• Workflow Boundaries: Defining strict parameters ensures AI modules handle tasks aligned with their actual capabilities while routing complex reasoning to human experts. Incorporating conditional branching, looping, synthesis steps, and self-validation against initial goals prevents rigid linear failure and uncoordinated local execution.

• Component Allocation: Matching specific sub-tasks to purpose-built modules reduces performance breakdowns.

• Rules-Based Protocols: Deterministic rules should bound probabilistic LLM behavior. Input/output schemas force output to match precise formatting, fall within expected ranges, or include source citations. Action boundary rules define allowable tool usage and escalation triggers, while issue-response rules dictate safe failover behaviors.

• Version Control: Establishing ongoing monitoring and deployment governance for internal and third-party component updates prevents silent model drift from corrupting audit workpapers over time.

Targeted GenAI Component Safeguards

System architects can apply specific structural controls to compensate for inherent LLM limitations:

• Distributing Cognitive Load: Breaking complex prompts into multi-step chains allows models to allocate more processing capability per sub-task, preventing dropped context and uneven attention.

• Multi-Model Ensembles: Structuring independent LLM review loops (where a second model critiques the first using different prompt priorities) or running parallel generation passes (where multiple outputs are synthesized or filtered) reduces probabilistic variance.

• Model Selection and Configuration: Matching models to tasks based on reasoning capacity, domain training, stability, tool aptitude, and context size optimizes output quality. System settings (such as token budgets, reasoning modes, and temperature settings) must be configured to provide sufficient headroom for complex tasks. Fine-tuning models on curated audit datasets can build domain knowledge, though it requires balancing data curation costs, loss of general model capabilities, and restriction from newer vendor updates.

• Integrated Tool Use: Connecting LLMs to specialized tools directly addresses native execution gaps. Retrieval-Augmented Generation (RAG) grounds responses in verified accounting standards or internal workpapers. Search engines provide dynamic live data retrieval. Code interpreters and computational scripts offload calculations to deterministic calculation tools.

• Prompt Engineering: Standardized system prompts and curated prompt libraries ensure consistency across engagements, particularly when structuring data passed between automated sub-components.

System Combination and Information Safeguards

To prevent errors from magnifying across connected systems, designers must insert early review steps to catch micro-biases before they multiply, prune unnecessary workflow steps to reduce processing noise, and implement standardized data transfer protocols like Model Context Protocol (MCP). Systems should maintain an updated master log of current state, original goal, and intermediate outputs to prevent goal drift during long runs.

For runtime data access, systems must point to verified, complete, accurate, and properly indexed documentation sources.

Tool Certification and Testing

Under ISQM (UK) 1, audit firms must maintain systems of quality management providing reasonable assurance that engagements comply with professional standards. Demonstrating this assurance for AI tools requires a formal certification process evaluated against specific engagement use cases.

Input Evaluation

Certification evaluates the key inputs driving the system:

• Training Data: While third-party base model training data is rarely accessible, firms fine-tuning models must formally evaluate the quality and appropriateness of their custom datasets.

• Prompt Engineering: Central prompt libraries and system prompt templates must be reviewed for clarity, precision, and alignment with auditing standards.

• Runtime Data Repositories: External databases, RAG knowledge bases, and standard libraries must be audited for accuracy, completeness, and search index retrieval consistency.

Architecture and Logic Review

Certification teams must review system architecture against established risk-mitigation patterns and evaluate internal component logic. When third-party components obscure internal mechanics, firms can obtain independent third-party assurance or increase the depth of output empirical testing to compensate.

Empirical Output Testing

Due to model opacity, empirical testing carries heavy weight during certification. Testing must evaluate performance across:

• Standard expected operational use cases.

• Unusual edge cases.

• Diverse multi-scenario test sets to uncover unpredicted failures.

• Known failure points, such as overconfidence or specialized domain knowledge gaps.

Testing requires qualitative scoring against structured evaluation criteria. Individual components within multi-agent systems should be tested independently to identify weak links, guiding necessary architectural updates or highlighting where human control points must be placed. Obtaining third-party tool certifications does not remove the requirement for audit firms to conduct localized use-case testing.

Continuous Life-Cycle Management

Firms must maintain tool reliability after deployment through four ongoing processes:

• Recertification Triggers: Re-evaluating tools when underlying components change, use cases expand, standard policies are updated, or output performance degrades.

• Performance Monitoring: Tracking real-world output consistency, failure trends, and unexpected behaviors to refine tool design and update training material.

• Controlled Pilot Testing: Deploying uncertified tools to limited pilot groups requires audit teams to run traditional audit procedures in parallel to preserve overall audit quality.

• Methodology Alignment: Methodology and technical development teams must collaborate continuously to ensure audit guidance correctly interprets AI outputs and avoids overstating their evidentiary value under professional auditing standards. Adding explainability features, such as forcing models to display clear citations and explicit chains of thought, further guards against misinterpretation.

Integrating AI Tools into Audit Execution

Deploying artificial intelligence across audit engagements requires moving past raw automation toward structured, human-led workflows. Rather than treating AI as an autonomous substitute, effective adoption pairs technical safeguards with professional skepticism to enhance audit quality. Ten concrete framework strategies govern how audit teams practically integrate and operate these tools:

• Adopt the "Copiloted" Audit Model: Keep human auditors firmly in control of the engagement while positioning AI as an audit-focused assistant. AI tools handle heavy data processing, draft initial findings, and highlight potential anomalies, but human auditors must review the output, apply business context, validate findings, and draw final conclusions before anything enters a signed audit report.

• Transition to 100% Data-Driven Continuous Auditing: Move away from traditional manual sampling, which often tests under 1% of transactions, and deploy AI to process entire populations. Running AI across 100% of transactional data exposes hidden patterns, duplicate payments, or split-billing schemes designed to bypass single-transaction approval thresholds that manual sampling misses.

• Ground Outputs with Retrieval-Augmented Generation (RAG): Never rely on raw, standalone LLMs for audit evidence, as ungrounded models produce plausible but fabricated claims. Connecting AI tools to RAG architectures and vector databases forces models to pull directly from verified organizational documents, policy manuals, prior workpapers, and contracts, dropping hallucination rates to single digits and ensuring every finding cites verifiable source material.

• Deploy an Automated Security Gatekeeper Layer: Intercept all data and user prompts through an automated filtering layer before feeding information to internal or external AI models. This gatekeeper automatically redacts personally identifiable information (PII), trade secrets, and sensitive contract terms while preserving enough semantic context for analysis, mitigating privacy exposure when processing audit evidence.

• Utilize Agentic AI and MCP for Multi-Step Investigations: Advance beyond basic conversational chatbots by deploying multi-agent AI systems connected via the Model Context Protocol (MCP). MCP acts as an integration interface, allowing agents to execute multi-step audit programs across live enterprise software, SQL databases, and ERP systems to verify live operational data against company policies in real time.

• Apply Human Judgment at Context Checkpoints: Define explicit workflow checkpoints where human business context overrides automated risk flags. While AI can flag technical non-compliance—such as a missing vendor quote—auditors must evaluate real-world conditions to determine whether the deviation represents an acceptable emergency procurement exception rather than a control breakdown.

• Establish an Internal Knowledge Feedback Loop: Route auditor corrections and validated false positives back into the system’s internal knowledge base. When auditors correct an AI misinterpretation, feeding that decision back into the system builds institutional memory, sharpening model precision for future engagements without exposing proprietary business data to public training sets.

• Assess AI Maturity via Weighted Scoring Models: Avoid evaluating internal AI adoption through simple checklists or equal-weighted averages. Unweighted averages create a masking effect where high scores in basic data reporting disguise poor predictive capabilities. Audit leadership should apply strategic weights that prioritize advanced risk detection over simple automated reporting to reveal true maturity gaps.

• Upskill Teams in AI Orchestration and IT Governance: Shift team capability from manual testing to technology-literate orchestration, process analysis, and prompt engineering. Audit quality improves when auditors possess strong IT backgrounds, enabling them to construct effective prompts, interpret complex algorithmic outputs, and critically evaluate automated risk scores.

• Formalize SOPs, Hybrid Roles, and Clear Accountability: Establish Standard Operating Procedures (SOPs) that specify evaluation criteria, required evidence, and validation rules for AI outputs. Define precise responsibilities for validating findings between audit staff, IT specialists, and AI systems, and introduce hybrid roles such as AI Governance Officers or AI Integration Architects to manage algorithmic accountability. Delivering sanctioned, secured tools prevents staff from resorting to unauthorized "Shadow AI" applications.

How to Limit Access and Keep a Trail You Can Defend

Begin with read-only access and widen it only on a documented case. The joint agency guidance recommends least privilege, a distinct and verifiable identity for each agent, temporary credentials for sensitive actions and human review or approval for high-impact actions. Applied to audit, that means a separate named account for each agent, no shared credentials and no borrowed human logins. It also means a tool allowlist, separated test and production environments, and revocation of access when the engagement ends. Any write capability needs a defined system and purpose, a time limit, logging, a way to reverse it, testing outside production and a human approval gate. An agent must not be able to change its own privileges or add tools to itself.

Treat everything the agent reads as untrusted. Documents, emails and web pages can carry hidden instructions meant to redirect an agent, which is called prompt injection, and the joint guidance singles out prompt injection and related manipulation as a behavior risk specific to agents. An audit agent that reads vendor contracts or supplier emails is exposed to exactly this. Design the agent so that content it retrieves is data and never a command, test it with adversarial documents before go-live, and quarantine any request to delete logs or audit records until a person reviews it. Privacy and privilege belong in the same conversation. Do not place personal, customer, employee or privileged material in an agent until the organization has approved the data classification, access controls, retention rules, supplier terms, encryption, cross-border transfer position and deletion procedure. The organization that decides why and how personal data is used keeps its data protection duties even when a vendor's tool does the processing.

Next comes the evidence problem. An agent summary is an interpretation of evidence, not the evidence. If the agent says a control passed, the auditor must be able to find the source records, the population tested, the procedure, the criteria, the exceptions, the agent configuration and version, the reviewer's evaluation and the final conclusion. The workpaper should let a reader separate four layers: source evidence, machine-generated analysis, human judgment and final approval. A summary that links to no source should not enter the permanent record. This is the practical meaning of the IIA standard on engagement documentation, Standard 14.6, applied to work an agent helped produce.

Reproducibility is what makes the trail defensible. Agentic systems change prompts, models, retrieval sources and workflows, and without logging you cannot say what the agent received, which documents it used, which tools it called, what instructions applied, which model version was active or what the reviewer changed. Keep step-level logs with the working papers, lock the test logic and the approved prompts under version control, and prove that a rerun on the same data returns the same exceptions. Build escalation rules in advance. The agent stops and hands over when evidence is missing, sources conflict, the task is out of scope, a material issue appears, privileged data is involved, a fraud or legal signal shows up, it is asked to change a record, a tool returns something unexpected, or it cannot explain which evidence supports its result. Handing over means sending the context already assembled, not a message that says human review required.

How to Protect Independence When Audit Uses or Advises on Agents

Internal audit has two jobs here, and they must stay separate. The first is using agents inside its own workflow, where the function is the owner and the user. The second is providing assurance over the organization's agent estate, where the function is the independent evaluator. The IIA's AI Auditing Framework is built to support both assurance and advisory work, including assessing AI strategy and the maturity of AI governance and supporting management in developing policies and oversight. The advisory role is legitimate. The line is drawn at management responsibility.

A problematic arrangement is easy to describe. Internal audit designs the organization's agentic AI control framework. It deploys the agent, approves the agent's access, operates the workflow, and later concludes that the workflow is effective. That is a self-review, and it damages the objectivity that makes the later opinion worth anything. Standard 2.2 of the Global Internal Audit Standards requires auditors to recognize and avoid or mitigate actual, potential and perceived impairments to objectivity. An advisory contribution such as sharing a control checklist, explaining risks or challenging a design is fine. Owning and running the controls that internal audit will later audit is not.

Inside the audit function the same principle applies on a smaller scale. The people who develop an agent should not approve their own work. The person who approves an agent's access should not be the person who uses it. Where the function lacks the skills to review the technology, it should co-source or train, because Standard 3.1 on competency means that a team unable to evaluate a tool's output is not entitled to rely on it. Standard 10.3 covers technological resources, and an agent is one of them. The business owns business controls, including any controls over the organization's own agents, and the existence of a second-line AI governance group does not remove the need for independent third-line assurance.

The chief audit executive should confirm a few things on a regular rhythm. Advising on agent design has not created a self-review. Human reviewers have enough competence to challenge the output. Quality assurance reviews AI-assisted engagements as a normal part of the program. The audit committee knows how much AI the function uses and where the bright lines sit. The methodology is updated when models and tools change, because a validation done on one model version says little about the next. These checks cost little compared with the damage of a finding that is later overturned because nobody could show how the agent reached it.

How to Roll Out Audit Agents in Ninety Days

Before the calendar, adopt a simple autonomy scale so everyone uses the same words. Level 0 means no AI and the auditor does the task manually. Level 1 is assistive: the agent drafts, summarizes or searches. Level 2 is supervised execution, where the agent runs a defined test and a person reviews the output. Level 3 is a conditional workflow in which the agent performs bounded multi-step work and escalates uncertainty. Level 4 is high autonomy, with actions across systems inside strict limits. Level 5 is prohibited delegation: final judgment, accountability and irreversible action. Most internal audit use cases belong at Levels 1 and 2. Level 3 can fit carefully bounded evidence workflows, and Levels 4 and 5 need an exceptional justification that you should expect to refuse for any final audit judgment.

In the first thirty days, inventory and set boundaries. Register every agent in the function and every agent you can find in the organization, including those embedded in vendor software and those started as pilots that nobody registered. For each one record the use case, the audit objective, the process owner, the data classification, the systems accessed, the tools the agent can call, permitted and prohibited actions, the human reviewer, the risk rating, the validation method, logging and retention requirements, the escalation triggers and the shutdown procedure. Name a human owner for every entry. Write the two lists from this article into your methodology as policy: what agents may do and what they may never decide.

In days thirty-one to sixty, pilot two closed-world use cases with a low blast radius, for example a three-way match and a user access review. Run the agent in parallel with the manual method on the same population and reconcile the results, because that parallel run is your validation. Test against known cases, edge cases, incomplete evidence, contradictory documents, out-of-scope requests, prompt injection attempts, unauthorized tool requests, sensitive data and failure or timeout conditions. Measure accuracy, completeness, false positives, false negatives, unsupported claims, escalation performance, reproducibility and reviewer correction rate. Build the log, the exception path and the review protocol before go-live, not after. A sound review protocol means the reviewer opens the source records for all exceptions and for a selection of passes, signs the workpaper and records what was changed.

In days sixty-one to ninety, extend to the review-gated work: drafting, follow-up testing and anomaly triage. Publish a shared prompt library so gains are not trapped with one auditor. Start monitoring both technology and audit quality. Track agent error rate, reviewer override rate, unsupported conclusion rate, missed exceptions, escalations, data access violations, injection attempts, time saved, rework and findings later overturned. A high override rate often means the use case was poorly designed, not that reviewers are overcautious. Then open the second track: a readiness review or assurance engagement over the organization's own agents, covering inventory completeness, ownership, approval workflow, guardrail and shutdown effectiveness, identity hygiene and incident response for an agent that fails. Re-validate whenever the model, the version or the tool set changes, and train every user, because competence is a standard and not a nice-to-have.

 

Operational Blind Spots of AI in Modern Audit Engagements

Deploying generative and agentic artificial intelligence across audit engagements shifts fundamental execution models, creating structural exposure across audit quality. Beyond wider organizational risks like skill erosion, cybersecurity threats from cloud processing of entity data, or negative return on investment, the immediate operational concern centers on audit quality. These exposure points divide into three distinct core categories: deficient outputs, human misuse of valid outputs, and non-compliant audit firm methodologies.

The Risk of Deficient Output

A deficient output occurs when an AI tool produces flawed, incomplete, or inaccurate audit artifacts. Deficiencies stem from failure modes in system performance or runtime inputs.

Generative AI Component Performance Risks

Solitary or multi-model setups relying on Large Language Models (LLMs) inherit fundamental architectural constraints. LLMs generate text by matching statistical patterns rather than possessing semantic understanding, context awareness, or formal logical reasoning. They depend entirely on static training data, have finite parameter capacity, and operate within bounded context windows that force uneven attention allocation.

These limitations trigger five specific output deficiency modes:

• Hallucinations: Fabricating transactions, accounting entries, or professional standards.

• Omissions: Dropping critical disclosures, scope parameters, or exceptions.

• Distortions: Misrepresenting the true meaning, emphasis, or severity of audit findings.

• Faulty Reasoning: Forming unsupported, illogical conclusions from valid premises.

• Inconsistencies: Producing internal contradictions within a single workpaper or across sequential iterations.

LLMs perform distinct functional roles depending on prompting, including acting as a researcher, reasoner, writer, summarizer, critic, or orchestrator. In agentic architecture, an LLM acting as an orchestrator interprets human goals, drafts work programs, integrates component outputs, and manages feedback loops.

When output deficiencies strike the orchestrator role, system-wide failure occurs:

• Goal Interpretation Failures: Omitting critical parameters of the audit goal leads to deficient final audit outputs.

• Work Program Design Errors: Faulty logical reasoning results in an ill-suited work plan that fails to meet audit objectives.

• Output Integration Failures: Hallucinated claims or faulty reasoning lead the system to assert overconfident, unsupported conclusions drawn from sub-components.

• Feedback Drift: Context window compression distorts the original prompt during iterations, causing goal drift and generating execution instructions that diverge from human intent.

Non-GenAI Component Performance Risks

Agentic and non-agentic AI systems incorporate non-LLM components whose execution failures compromise system performance:

• Data Acquisition Modules: Connectors, document loaders, optical character recognition engines, search APIs, data mappers, and Retrieval-Augmented Generation (RAG) modules can fail to parse or extract source data accurately.

• Rules-Based Processors: Transformation scripts, calculators, validators, prompt management layers, and workflow engines can contain faulty pre-encoded logic or flawed prompt templates created by system designers.

• Predictive ML Modules: Anomaly detection algorithms and estimation models can misclassify balances or miscalculate risk scores.

• External Action Integrations: Connectors to enterprise transaction databases or email engines can fail during execution.

• Operational Infrastructure: Cloud runtime environments, authenticators, task schedulers, message queues, and storage can drop connections or fail to queue tasks reliably.

In agentic setups, the workflow engine controls system state, component sequencing, template prompt construction, tool allocation, and error recovery. If the workflow engine fails or relies on poorly specified designer templates, the whole system breaks.

System Combination Risks

When components interact or execute iteratively, three system-level combination risks emerge:

• Amplification Risk: Minor, isolated errors or micro-biases in early components magnify exponentially through subsequent processing steps, producing severe output errors.

• Information Distortion Risk: Sequential processing erodes nuance and key context across steps, even when each individual component functions as intended.

• Interface Risk: Data transfer failures or semantic mismatches occur when components interpret data structures or concepts differently.

Runtime System Input Risks

System outputs fail when human inputs or dynamic data sources are flawed at runtime.

Human-in-the-loop input risks include:

• Incorrect Task Specifications: Prompts that fail to instruct the system to evaluate interdependencies or control weakness points, leading to overestimating control environment effectiveness.

• Ambiguous Task Specifications: Vague prompt directives that cause the AI to compress all parts of a complex document equally, omitting critical audit-relevant details.

• Incomplete or Erroneous Context: Uploading outdated prior-year audit memos that distort current-year risk prioritization.

• Flawed Control Point Decisions: Reviewers approving incorrect actions, tools, or execution paths due to automation bias, missing domain knowledge, or incomplete understanding of task scope.

• Inappropriate Operational Configurations: Setting bad runtime parameters, such as improper reasoning modes, restrictive context limits, or wrong tool access permissions.

Information quality risks involve dynamic runtime data sources. Connecting AI tools to internal policy documents, prior workpapers, transaction databases, regulatory standards, external guidance, or web search APIs creates risk if those target repositories contain misleading, outdated, or poorly cataloged information.

The Risk of Misuse of Output

Even when an AI tool generates accurate, well-reasoned outputs, human errors by engagement teams can compromise the audit.

• Misinterpretation of Output: Audit teams misjudge the scope, certainty, or constraints of a generated result. For instance, an auditor using AI to locate lease clauses in contracts might mistake the output for a complete contract review, neglecting to test for contingent liabilities or environmental provisions.

• Misunderstanding of Methodology: Auditors misplace the tool's role within the broader engagement framework. A common example occurs when an auditor treats an AI-driven risk assessment screening as a definitive audit conclusion rather than an exploratory input designed to inform professional judgment.

The Risk of Non-Compliant Methodology

Integrating generative and agentic AI tools into standard audit procedures requires updating firm methodologies. A structural risk arises when firm methodologies permit or advocate AI-driven testing approaches that fail to satisfy standard auditing requirements.

Comparing AI procedures against traditional substantive audit testing presents calibration challenges. For example, an AI system can analyze entire populations rather than small samples, but the depth of evidence for individual transactions across that population may be less conclusive than traditional substantive testing. Because quantitative persuasiveness cannot always be directly compared, audit methodologies must not overstate the evidentiary weight of AI tools, ensuring the overall procedure fulfills professional auditing standards

Which Questions Should the Audit Committee Ask?

The audit committee does not need to read agent logs. It needs to ask questions that expose whether the function and the business can answer for what their agents do. A short set works well in a standing agenda item:

1. Which internal audit tasks are agent-assisted today, and at what autonomy level?
2. What can each agent read, write or execute, and who approved that access?
3. Which decisions are prohibited from delegation, and where is that written down?
4. How is human review demonstrated in a completed workpaper?
5. Can the function reproduce an agent-assisted workpaper from the retained record?
6. Who owns each agent, and who independently reviews it?
7. What happens when the agent is wrong, and how was the last error found?
8. Which quality measures are reported, and what did the last review change, pause or stop?

The same questions apply outward, to the software the business runs. Which systems act without a person approving each step? How many agents can act on production data, and who can stop them? If an agent deleted its own logs, would anyone know? Internal audit's second track exists to answer these, and the answers will be uncomfortable in organizations that adopted agents faster than they built oversight.

Some red flags justify immediate escalation to management and the committee.

An agent has write access by default. Nobody can identify the data behind a conclusion. The organization cannot reproduce a prior result. The same team develops, operates and approves the agent. Output is accepted without anyone checking source evidence. No approved use-case inventory exists. Personal, customer, employee or privileged information is in use without safeguards. The function measures speed and never measures quality. An agent can change audit scope or finding ratings. The agent can communicate findings externally without approval. No shutdown or fallback process exists. Any one of these is enough to pause a deployment.

The red flag that deserves the most attention is the quietest one: management assuming that human in the loop means a person clicks approve. A person who sees only the agent's summary has not reviewed anything. Meaningful review means the person can reach the source, is competent to challenge the result, has the time to do it and is recorded as having done it. If the review step exists only on the process diagram, the organization has automated the judgment while keeping the paperwork of human oversight, which is the worst version of both. Ask for evidence that reviewers change outputs, and be suspicious of a reviewer correction rate of zero.

Final Perspective

The decision in front of most audit leaders over the next year is not whether to use agents but where to let them start. Start where the evidence is closed, the rules are stable and the output can be verified, and make every judgment visibly human. Teams that begin there get real hours back, build reviewer confidence and gather the logs and metrics that justify going further. Teams that begin with scoping, ratings or conclusions spend the saved time cleaning up unsupported statements, and they risk a finding that cannot be defended when someone asks how it was reached.

Take one practical step this week. Pick a single task your team repeats every quarter, run it through the bounded-task tests in this article, and write down the evidence boundary, the test logic, the reviewer and the stop conditions on one page. If you cannot fill in the page, the task is not ready for an agent, and you have learned that cheaply. The sharper question for your next audit committee meeting is simple: if an agent supported one of our conclusions last quarter, could we show the committee, in order, what it read, what it did and which person decided?

References

1. Financial Reporting Council, Generative and Agentic AI Guidance, March 2026, https://media.frc.org.uk/documents/Generative_and_Agentic_AI_Guidance_crosPeBU.pdf
2. Financial Reporting Council, news release on the guidance for audit firms, 30 March 2026, https://www.frc.org.uk/news-and-events/news/2026/03/innovative-new-guidance-supports-audit-firm-adoption-of-emerging-ai-technologies/
3. Canadian Centre for Cyber Security with CISA, NSA, ASD ACSC, NCSC-NZ and NCSC-UK, Careful Adoption of Agentic AI Services, joint guidance announcement, https://cyber.gc.ca/en/news-events/joint-guidance-careful-adoption-agentic-artificial-intelligence-services
4. Mayer Brown, Multi-Agency Guidance on Securing Agentic AI Systems, 10 June 2026, secondary summary of the joint guidance, https://www.mayerbrown.com/zh-hans/insights/publications/2026/06/multi-agency-guidance-on-securing-agentic-ai-systems
5. The Institute of Internal Auditors, The IIA's Artificial Intelligence Auditing Framework, https://www.theiia.org/en/content/tools/professional/2023/the-iias-updated-ai-auditing-framework/
6. The Institute of Internal Auditors, Global Internal Audit Standards, 2024, https://www.theiia.org/globalassets/site/standards/globalinternalauditstandards_2024january9_printable.pdf