From auditor to audit engineer: the skillset shift internal audit cannot afford to ignore

I spent a lot of time with internal auditors while building a data access control layer across Instacart's data platform stack in preparation for their IPO. The best auditors understood where risk was likely to hide, but their process was working against them. I was building controls across Databricks, Snowflake, S3, and several other components, and every walkthrough call started the same way: whiteboarding the system architecture, the components, and how they all connected. At the same time, the audit team was spending hours reviewing the same PDFs, screenshots, emails, and exports just to confirm whether a control attribute was present. After drawing the same diagram for the third or fourth time, I thought: There has to be a better way to do this.

The issue was never auditor capability, but the day-to-day demands they were forced to take on. Control environments are expanding, while headcount is not. The IIA's 2026 North American Pulse of Internal Audit found that only 23% of teams reported a budget increase, while 19% faced a cut. And the work that eats most of an auditor's time–collecting evidence, testing attributes, documenting results–is exactly the kind of bounded, repetitive execution that AI agents can now do well.

Internal audit work is separating into two categories: execution that can be automated, and judgment that still depends on human experience. The people who will thrive in this new model are the ones I call audit engineers: professionals who know how to scope what an agent can own, define the boundaries around evidence, and focus their own time on the open-world work that requires enterprise context and professional skepticism.

This is bigger than a tooling change. It affects how teams scope work, how auditors spend their time, and what leaders should look for when hiring and developing talent.

What makes someone an audit engineer

The term is borrowed from software engineering, and the parallel is deliberate.

In software, the shift from manual QA testing to test engineering happened over the past decade. Testers who once clicked through every screen and logged results by hand became engineers who wrote automated test suites, defined coverage thresholds, and focused their own attention on edge cases the automation could not reach. The testers did not lose their jobs. They gained better ones, but only if they developed the skills to operate in the new model.

Internal audit is going through the same transition. I am not arguing that every team should create a new job title. I am describing how the best auditors are already operating: professionals who understand both the audit methodology and the technology used to execute parts of it. They know which controls qualify for autonomous testing and which require human judgment. They can frame a testing procedure so an agent can execute it cleanly. And they spend the hours they reclaim on the work that actually differentiates audit: root cause analysis, risk interpretation, and advising the business on where exposure is growing.

The distinction I have found most useful is the one between closed-world and open-world work. A closed-world task has bounded evidence and stable rules. For example, a three-way match is a closed world. User access testing is also a strong candidate for autonomous execution when the evidence source, review criteria, and approval standard are clearly defined.

Open-world work is different. The evidence is incomplete or ambiguous, the procedure does not answer every question, and the auditor's judgment becomes the deciding factor. Root cause analysis of why a control failed, or classifying a deficiency as a gap versus a material weakness, is open-world. That work stays with the auditor.

An audit engineer knows how to separate automatable testing from judgment-heavy review, then design a workflow that uses both well.

The internal audit skills that change

The traditional internal auditor's skillset was built around execution: sampling, walkthroughs, tick-and-tie testing, work paper documentation, etc. Those skills are no longer sufficient, but that does not mean that they’re obsolete. As agents take on more of the bounded execution work, the skills that matter most are the ones that sit above and around it.

Scoping and boundary-setting

An agent can only finish a task that has been properly bounded. That means the audit engineer needs to be precise about what constitutes acceptable evidence, where the evidence lives, and what the pass/fail criteria look like. Vague standards like "approval is required" leave too much room for the agent to guess and the reviewer to step in. Defining the exact form that approval must take, and where it must appear, narrows the world around the task and lets the agent own more of it.

This is really a procedure-design skill, and most audit teams just need to up their training beyond executing test steps, learning to translate those steps into something a machine can run.

Data and systems fluency

Audit engineers do not need to write production code. But they do need to understand how systems connect, how data flows between them, and how to evaluate whether an agent is reading evidence correctly. When I was at Instacart, one of the first things I built was a chatbot connected to our engineering documentation that could help the audit team prepare for walkthrough calls. Instead of starting every session by re-explaining how our permissions model worked across Databricks, Snowflake, and S3, the auditors could query the documentation themselves and come in with specific questions. The ones who got the most out of it were the ones who already understood the underlying data architecture well enough to know what to ask next. They could look at a system diagram and tell you where the control gaps were likely to appear.

Exception triage and root cause analysis

As autonomous controls testing handles more of the pass/fail determination, auditors will spend a larger share of their time on what happens after a failure surfaces. That requires a different muscle: the ability to investigate why a control failed, assess whether the failure is systemic or isolated, and recommend a remediation path that accounts for the enterprise context the agent cannot see.

This is the part of the job where audit adds disproportionate value: explaining why something failed, whether it matters, and what should happen next.

Communication and advisory

When the manual execution shrinks, the expectation that audit contributes strategic insight only grows. Audit engineers need to translate findings into a language that the board, the C-suite, and business unit leaders can act on. That means fewer 40-page reports and more concise, prioritized briefings that connect control failures to business risk.

What the internal audit day-to-day looks like now

Today, the most visible change is in how testing cycles are run.

In the old model, an auditor's week during a SOX cycle was dominated by evidence collection and attribute testing. You requested a sample, received a stack of PDFs or system exports, opened each and verified whether the required attributes were present, documented your findings, and moved on to the next one. That process repeated across dozens, or even hundreds, of controls.

In the audit engineer's model, the agent handles the bounded portion of that cycle. It reads the evidence, whether that is a PDF invoice, an email approval, a screenshot of a system configuration, or a spreadsheet export. It interprets unstructured documents, checks whether specific attributes are present, and drafts the work paper with clear sourcing and a full audit trail. Teams using Midship, now part of Optro, report saving time precisely because the evidence collection and attribute verification steps can be bounded: a defined sample, a set procedure, a fixed set of source documents.

What fills the time that comes back is the open-world work the auditor never had enough time for. I have seen this play out in a few ways:

• Exception review and escalation. Instead of spending five hours testing 50 controls and finding three exceptions buried in the last hour, the auditor receives the exceptions up front with the context the agent assembled. The auditor's job becomes investigation rather than discovery.
• Procedure refinement. Audit engineers spend time improving the procedures themselves, tightening evidentiary standards so the next cycle runs cleaner. That means specifying what acceptable evidence looks like, documenting testing deviations centrally, and building a repository that agents and reviewers can check future exceptions against.
• Risk advisory. When the testing backlog no longer consumes every available hour, audit teams can respond to ad hoc risk questions from the business without falling behind on the plan. This is where the strategic advisory role CAEs have been asking for actually becomes possible.
• Agent oversight. Reviewing agent output, validating that the agent handled edge cases correctly, and tuning the workflow when the agent routes an exception to a human. Closed-world tasks do not always stay closed. A document goes missing, an exception surfaces that the procedure did not anticipate, and the task quietly becomes open world. That is why the auditor has to define the escalation path before the exception shows up, not after.

Take a quarterly user access review, for example. In a traditional cycle, the auditor pulls a sample of user accounts, reviews screenshots or system exports, checks whether each access grant was properly approved and appropriate for the role, documents the result, and moves on.

In an agent-assisted model, the agent reads the full population, traces approval evidence, flags exceptions where approval is missing or late, and drafts the work paper. The auditor's time goes to the exceptions that actually matter: Was this an emergency grant? Was the access appropriate for the role? Does the pattern suggest a provisioning weakness that needs remediation?

How audit functions should hire and train for this

The talent challenge is real, and it is compounding. Data analytics tops the list of priority hiring skills across regions, and AI/machine learning is right behind it, alongside cybersecurity and regulatory expertise. But the gap between what audit functions need and what the candidate market supplies is not closing on its own.

I believe the teams that get this right over the next three to five years will share a few things in common.

Hire for adjacent technical fluency, not engineering degrees

You do not need a team of software engineers. What you need are auditors who are comfortable working alongside technical systems and AI agents. In my experience, the strongest candidates can read a data flow, frame a testing procedure with enough precision that an agent can execute it, and evaluate whether the agent's output is reliable. Those skills show up more often in people with analytics backgrounds, systems audit experience, or IT audit credentials than in traditional financial auditors.

The best audit engineers I have seen come from varied backgrounds. Some started in public accounting. Others came from IT risk or data governance. What they share is a willingness to learn how the systems work. When I am evaluating someone for this kind of role, I want to know: Can they translate a narrative control description into clear decision rules? Can they tell the difference between incomplete evidence and contradictory evidence? Can they review agent output critically without rubber-stamping it? Instincts matter more than a specific credential.

Invest in upskilling your current team

Most audit functions cannot hire their way out of this gap. The more practical path is to develop the audit engineers you already have. That means structured investment in three areas:

1. Agent literacy. Every auditor on the team should understand what agents can and cannot do, how to evaluate agent output, and when to escalate. This requires hands-on exposure to the tools and a clear framework for sorting closed-world from open-world work.
2. Evidence design. Train auditors to write testing procedures that are specific enough for an agent to execute. That includes defining what acceptable evidence looks like, specifying where it lives, and documenting known deviations so they do not relitigate the same exceptions every cycle.
3. Advisory and communication. As execution time shrinks, the ability to synthesize findings and communicate them in business terms becomes more important. Invest in presentation skills, stakeholder management training, and structured frameworks for translating audit findings into risk-informed recommendations.

Redesign the performance model

If your performance metrics still reward volume of tests completed or number of work papers produced, you are incentivizing the old model. Audit engineers should be measured on the quality of their risk assessments, the precision of their scoping decisions, the efficiency of their agent-assisted workflows, and the business impact of their advisory work.

The teams that get real value here will redesign workflow, review practices, and talent expectations.

The audit function of the future is already taking shape

The shift from auditor to audit engineer is happening now, in the teams that are sorting their control portfolios into closed-world and open-world work, deploying agents against the bounded tasks, and redirecting their best people toward the judgment and advisory work that the business actually needs.

The profession has been talking about becoming trusted strategic advisors for years. I believe agentic AI is what finally makes that practical. Not by replacing auditors, but by clearing the manual execution work that kept them from the judgment and advisory services they were trained for.