In a recent conversation with a fellow professional, I mentioned that at Kaption we have spent a lot of time thinking about how AI could support the audit workflow. I was asked whether I had anything written down on it. I didn't, so this piece is my attempt.
The question I hear most often is where to start with AI, and what it takes to go further. So in this article I will walk through the audit one step at a time. For each step, I look at what a team can do today with the tools it already has, what needs dedicated people and data to build, and where the limits are.
The audit today, end to end
Before looking at where AI fits, it helps to lay out how an audit runs today. Methodologies differ between teams, but most follow a shape close to the one in the IIA's Global Internal Audit Standards:
- Plan. Usually once a year, the team builds a risk-based plan of which areas to audit.
- Understand the process. Through interviews and walkthroughs, the auditor learns how the work is really done. Along the way they look for controls that are documented, controls that people perform but have never written down, and gaps where a risk has no control at all.
- Gather evidence. The auditor requests documents, reports and data on those controls, and on areas where they suspect a gap.
- Test. The auditor checks whether each control works, on a sample or the full population. If the result is unclear, they ask for more samples before concluding.
- Conclude and report. Workpapers are completed, findings are agreed with management, and a report sets out actions and owners.
- Follow up. The team checks that the agreed actions have been carried out, and what they learn feeds the next plan.
Now let's go through each step.
1. Planning
Today. Most teams set an annual plan, often within a three-year cycle, and move areas around as new risks emerge. Building it means reading the risk register, past audit reports, board papers and regulatory updates, and speaking with senior management. Much of the time goes into gathering and summarising, not deciding.
Planning is also where many teams have started with AI. As one internal audit leader at a UK financial services firm told me:
We started with planning. So I'd say we mostly use it at planning and a little bit of reporting. We've embedded it quite well within the planning process.
What they started with is not a special tool. It is a small set of standard prompts the whole team uses, covering questions like "what are the key risks for this area?" and "which regulations apply?"
Quick wins with the tools you already have. Many organisations already have an approved enterprise AI tool (Copilot, ChatGPT, Claude). With that alone, a team can:
- Write down how you plan. Describe in a simple file how your team approaches planning: the sources you read, how you rank risks, what makes an area a priority (time since the last audit, recent change, incidents, regulatory focus), and the format you want back. Give that file to the assistant as its instructions, for example as the instructions of a Copilot agent, so every planning task starts from your methodology rather than a blank prompt. Keep it in one place and improve it after each cycle.
- Summarise the inputs. Point the assistant at last year's reports, the risk register and recent committee papers. Ask for themes, repeat findings and areas not audited recently, and ask it to name the document behind each point.
- Draft a one-page brief per area. Why it matters, the key risks, the last audit and its outcome, open actions, and a suggested scope.
- Prepare for stakeholder meetings. Draft questions for senior management from the risk register, and, with consent, summarise the risks they raise afterwards.
- Check coverage. Give it the draft plan and the risk register, and ask which high risks have no planned work.
Going further: builds that need dedicated talent. At this level, the value sits less in the AI model and more in the data and integration behind it. The aim is to give an agent the context it needs to help refine and evolve the plan throughout the year.
- How the wider world has changed. New regulation, events in the sector and emerging risks.
- How the business has changed. Incidents and new risks raised in management meetings, discussions at the risk and audit committees, new systems, restructures, and findings from audits already completed this year.
Most of this already exists, but it is scattered across conversations, minutes, registers and inboxes. One audit professional described the problem well:
Having an agent to do planning that can look at all of my risk registers, because at the moment it's very siloed when you do an audit.
The advanced work is building the connections that gather this context regularly, and an agent that reads it against the current plan. With that context in place, the agent can also score each area against agreed criteria and propose changes, with its reasoning, for the chief audit executive to review.
Done well, every change to the plan comes with a clear record of why it was made. That makes the plan far easier to defend in front of the audit committee.
Building this needs people who can work with data, system integrations and AI agents, whether in-house or through a partner. It also depends on things a prompt cannot fix: access to the right sources, approval to connect to them, clear rules on what the agent may read, and someone to maintain it.
The limits. The plan is still a judgement about where the organisation is most exposed and what the board cares about. Much of that lives in conversations, not documents, and AI can only weigh what it is given. On the business side, some planning inputs are sensitive, so deciding what the AI can see is a decision in itself. And for the advanced builds, the output is only as consistent as the data underneath: if risk registers are kept differently across the business, the scores will be too.
2. Understanding the process and its controls
Today. The auditor interviews the people who run the process and walks through how the work is done. From this they build a picture of the process and look for three things: documented controls, controls that are performed but never written down, and gaps where a risk has no control. Spotting these depends heavily on experience, and on knowing what a good process looks like and where things usually go wrong.
The internal audit leader I quoted earlier put it simply when I asked where his team's time goes:
Where my team would spend a lot of their time is really understanding the end-to-end process and then where the controls sort of come in.
Quick wins with the tools you already have. With an approved AI assistant and a meeting tool that transcribes, a team can already:
- Transcribe the walkthrough. With the consent of the people in the room, record the meeting and keep the transcript. Many meeting tools already do this.
- Turn the transcript into a process map. Give the assistant the transcript and any written procedures, and ask for the process step by step. Many assistants can draw it as a flowchart, or produce text a diagram tool can import.
- Ask the map audit questions. Turning the walkthrough into a flowchart is the simple part. The value comes from working through the map: ask the agent where the approvals are, where one person both creates and approves, and where data moves between systems by hand.
- Compare what was said with what is written. Give it the written procedure alongside the transcript and ask where they differ. The differences are often where undocumented controls, or gaps, sit.
- Prepare the follow-up. Ask for a short list of points to confirm and evidence to request in the next conversation.
Going further: builds that need dedicated talent. The next step is to give an agent the same reference points an experienced auditor carries in their head. Two things matter most:
- A clear audit methodology, written as instructions for the agent. How your team identifies key controls, judges whether they are well designed, checks segregation of duties and decides what counts as a gap. Few teams have this written in a form an agent can follow, so it needs to be developed on purpose.
- A risk and control library that stays current. Some businesses already keep a good risk and control matrix; others are less mature. If your organisation already has one, connect the agent to where it is stored and keep it updated as controls change. This lets the agent see which controls already exist and focus on what is new or missing.
For many teams, that library is still being built as they go. As another audit professional told me:
Most of our controls were kind of documented ourselves as part of the audit. And then testing them.
With both in place, a reviewing agent can work alongside the mapping step. It reads each new process map against the methodology and the latest library, and returns what an auditor would look for:
- where the key controls sit
- which are performed but not documented
- where segregation of duties breaks down
Further out. Some teams are exploring an agent that runs the walkthrough itself. The auditor points it in a direction, and the agent interviews the process owner, asks follow-up questions and builds the map as it goes. It is an ambitious idea, with obvious questions about trust and judgement, but it is being explored.
The limits. A walkthrough captures what people say, which is not always what they do. An agent can spot a missing control against a library, but it cannot notice hesitation in an interview, or know the team was restructured last month unless someone tells it. On the business side, recording interviews needs the consent and trust of the people being interviewed, and some will speak less freely on the record. And a reviewing agent is only as good as the methodology and library behind it; an out-of-date library will point to controls that no longer exist.
3. Gathering evidence
Today. The auditor sends request lists, then chases and files whatever comes back. Evidence usually arrives as a mix of screenshots, reports and emails. It can be incomplete or for the wrong period, which leads to rounds of back and forth. As one risk and controls professional told me:
The information collection can take time and we often have to go back for more.
This is where much of the elapsed time in an audit goes, with little of the value.
Quick wins with the tools you already have. The easiest place to start is the request itself. With an approved AI assistant, a team can:
- Draft the request list from the controls in scope. Give the assistant the control descriptions and the testing approach, and ask for a request list per control that says what is needed, for which period and from whom.
- Spell out what good looks like. Ask it to add the detail that saves a second round, such as the exact date range and the report settings to use.
- Write the request in plain language. Turn the list into a clear message for each control owner that explains why each item is needed. People respond faster when they understand what is being asked.
- Learn from last year. Compare the new list with last year's requests and what came back, to drop items that are no longer relevant.
Going further: checking evidence as it arrives. The next step needs a dedicated team. When evidence comes back, an agent pre-assesses it straight away, before the auditor opens it, by asking three questions:
- Is it complete, covering every item and period requested?
- Is it what was actually asked for?
- If it is a system report, can it be relied on?
These are checks auditors already do by hand.
Anything that fails is flagged immediately, so the auditor can go back to the team while the request is still fresh, rather than finding the gap weeks later during testing.
The bigger step: connecting to the systems. The larger vision is to connect directly to the systems where evidence lives, starting with the ERP, so the agent pulls what it needs instead of asking people for it. That saves time for auditors, but most of all for frontline teams, who today often step away from their day jobs to hand over the same evidence to several assurance teams in turn. One head of internal audit described how audits have often landed on the business:
People within the organization just kind of had an audit dumped on them.
Data pulled straight from the system of record is also stronger evidence than a screenshot of it.
The limits. The technology to draft requests and check evidence is fairly mature. The barriers are mostly on the business side, starting with access. Connecting to source systems needs security approval and the agreement of system owners, and many organisations will not grant that early on. Teams often begin with something narrower, such as a restricted shared folder, before any system connection. Pre-assessment also depends on clear rules for what good evidence looks like. Where those are not written down, an agent will either miss issues or flag too many.
To be continued
Looking across these first three steps, one pattern stands out. The quick wins are already within reach of most teams, using tools many of them already pay for.
The bigger gains take longer. They come from giving AI the context an experienced auditor carries in their head. It is also about giving the system good data, connections to the right systems, and people dedicated to building and maintaining them.
In part two, I will walk through the remaining steps: testing, concluding and reporting, and follow-up.
