Designing an AI Operating Model for Internal Audit

An internal audit function can have enterprise Copilot access, a private LLM, analytics software, and several agent pilots and still have no real AI capability. The warning signs are familiar: teams experiment independently, review expectations differ by engagement, data rules are unclear, and success is reduced to time saved.

The constraint is not technology. It is the absence of an operating model that turns AI strategy into a repeatable way of working.

For Internal Audit, that model has to answer a harder question than “Which tool should we buy?” It must define how the function will select, govern, use, control, support, and improve AI without weakening professional judgment, audit quality, or organizational independence.

AI does not scale through a portfolio of pilots

The Global Internal Audit Standards do not require a document called an “AI operating model.” They do, however, establish requirements that make a tool-only approach inadequate. Standard 9.2 requires the chief audit executive to develop and implement an internal audit strategy aligned with organizational objectives and stakeholder expectations. Standard 9.3 requires methodologies to implement that strategy. Standards 10.2 and 10.3 address human and technological resources, while Standards 12.1 and 12.2 connect the management of the function to quality, performance measurement, and continuous improvement.

An AI operating model is therefore not a new professional standard. It is a practical translation of Internal Audit strategy into decision rights, capabilities, workflows, and controls.

That distinction matters because many functions struggle at the transition from experimentation to operations. The IIA Netherlands and ISACA Netherlands practice guide on Generative AI explicitly connects adoption to strategy, roadmap, governance, skills, and staged maturity. KPMG reaches a similar conclusion in The Future of Internal Audit with AI, framing sustainable adoption around organizational positioning, people capabilities, and audit processes rather than technology alone.

A mature function is not the one using the most sophisticated AI. It is the one that can explain why AI is being used, who remains accountable, what evidence is retained, and how reliability is monitored.

Start with the mandate, not the platform

Before designing AI-enabled workflows, CAEs should separate two capabilities that are often blended together:

  1. Using AI to perform internal audit work: supporting risk assessment, document review, testing, evidence organization, analysis, and drafting.
  2. Auditing AI used by the organization: providing assurance or advice over governance, risk, data, models, controls, third parties, monitoring, and human oversight.

The two capabilities may share people, knowledge, data access, and technology, but their accountabilities are different. The first requires Internal Audit to govern its own use of AI. The second requires the function to preserve independence from the management processes and controls it may later assess.

The IIA's Artificial Intelligence Auditing Framework is useful here because it distinguishes governance, management, and internal audit responsibilities, while recognizing both advisory and assurance roles for the audit function.

The operating model should therefore begin with the mandate and strategy: what outcomes the board expects, which AI-enabled services support those outcomes, which decisions must remain human-led, and what responsibilities Internal Audit will not assume. Architecture and vendor choices come after those boundaries are clear.

Eight design decisions must work as one system

A practical operating model can be organized around eight components. They are not separate workstreams. They are interdependent choices that together determine whether AI use is coherent and sustainable.

Component Design question Evidence of maturity
Mandate and strategy What audit problem should AI solve and what outcome should improve? Use cases linked to function objectives, priorities, and measures.
Governance Who approves, prioritizes, accepts risk, and can stop a use case? Decision rights, accountable owners, escalation, and periodic review.
People What must auditors know and when is specialist support required? Skills matrix, training, co-sourcing, and product or use-case ownership.
Methodology Where may AI support the audit lifecycle and what review is required? Procedures, review points, documentation, and supervision criteria.
Data What information may be processed and under what conditions? Classification, access, quality, lineage, retention, and approved sources.
Tools What should be bought, built, or reused from enterprise platforms? Approved catalog, architecture, integration, testing, and change control.
Controls How are error, leakage, bias, and overreliance managed? Validation, traceability, logging, limits, monitoring, incidents, and human review.
Support Who keeps the capability running after the pilot ends? IT, security, legal, data, procurement, vendor support, and an operational owner.

The value is in the connections. An approved tool without methodology produces inconsistent use. Methodology without capability produces compliance on paper. Strong models with poor data produce unreliable outputs. A successful pilot without an operating support model becomes dependent on the person who built it.

The IIA-Australia Internal Audit Excellence Framework reinforces this multidimensional view through strategy, governance, people and culture, service delivery, operational excellence, digital enablement, and communication of results. It is nonmandatory guidance, but it provides a useful reminder that digital enablement should sit inside the management of the audit function rather than beside it as a technology project.

Controls should follow the risk of the use case

The opposite of uncontrolled experimentation is not one universal control checklist. A tool that suggests interview questions should not require the same level of validation as an agent that queries enterprise systems, executes actions, or prepares evidence that could influence an engagement conclusion.

The operating model should tier use cases using factors such as data sensitivity, autonomy, impact on an audit conclusion, ability to act on systems, reliance on organizational knowledge, and the difficulty of detecting an error. Higher-risk uses should trigger stronger approval, testing, logging, human review, and monitoring.

One boundary should remain explicit: the auditor retains responsibility for evidence evaluation, professional judgment, and conclusions. AI may search, structure, compare, or draft. It does not turn an unverified assertion into sufficient evidence, and it does not transfer professional accountability to the model provider.

This is also why AI-enabled work belongs inside the quality assurance and improvement program. If AI is used repeatedly in planning, analysis, documentation, or reporting, Internal Audit needs a way to evaluate whether the methodology is being followed, whether controls are working, and whether claimed benefits are materializing without creating unacceptable rework or risk.

Maturity is institutionalization, not technical complexity

The Internal Audit Capability Model (IA-CM) was developed for the public sector and is not an AI framework. Its evolutionary logic is nevertheless useful: capability becomes more mature as practices move from individual effort to institutionalized, managed, and continually improved ways of working.

Applied to AI, this prevents a common category error. A prompt-only environment can be highly mature if tools are approved, use cases are defined, auditors are trained, evidence rules are clear, review is consistent, metrics exist, and lessons are fed back into the methodology. An advanced agent environment can still be immature if nobody can explain who supervises it, what data it uses, or what happens when it fails.

The sensible progression is therefore capability-led: begin with controlled use cases and clear rules; create reusable assets and governed data; integrate AI into audit methodology and systems; then increase automation only when value and control have been demonstrated. The roadmap should advance on evidence of capability, not pressure to adopt the newest model or agent architecture.

What the CAE should decide in the next 90 days

An operating model does not need to begin with a major reorganization. It can begin with a small set of decisions that remove ambiguity:

  • select three to five priority use cases and define the audit outcome each should improve;
  • define approved tools and the classes of data they may process;
  • assign decision rights for sponsorship, operational ownership, security review, methodology, and escalation;
  • add minimum validation, documentation, and human-review requirements to the audit methodology;
  • assess skill gaps and decide what to build internally versus obtain through specialists or co-sourcing;
  • measure value through a balanced set of coverage, quality, cycle time, adoption, rework, incidents, and review effort rather than time savings alone.

The strategic question is no longer whether Internal Audit should “adopt AI.” That is too broad to guide execution. The real question is which capability the function intends to institutionalize, and under what level of control. When mandate, governance, people, methodology, data, tools, controls, and support operate as one system, AI stops being a collection of interesting experiments and becomes a defensible, scalable Internal Audit capability.

Sources