Generative AI is already inside most internal audit functions, whether the function decided that or not. Auditors paste a policy into an assistant to summarize it, ask for a first draft of a finding, have a model write the SQL they were going to write themselves, or use the assistant built into their office software without thinking of it as AI at all. The question has moved from whether to use these tools to where they help, where they fail and what the auditor has to check before relying on anything they produce. The answer differs by phase of the engagement, because the risk of a wrong output differs: a hallucinated regulatory citation in a planning memo wastes an hour, the same citation in a final report issued to the audit committee is a credibility event.
This guide walks the audit lifecycle phase by phase. It covers what the models are good at and bad at, the rules that come before the tools, the use cases in planning, scoping, fieldwork, analysis, reporting, follow-up and function management with the human-review gate for each, the failure modes with the cases that made them famous, confidentiality and data classification, how to document AI use in workpapers, a worked pilot at Halberd Software, a 90-day adoption plan and how to measure the benefit without inventing it. It pairs with the AI usage policy for internal audit (the rules), the AI prompts for internal auditors guide (the prompts) and the guides on auditing AI itself: AI governance, agentic AI and algorithms. Those are about auditing other people’s AI; this one is about the function’s own use.
In this guide
- What the models are good at, and what they are not
- The rules before the tools
- Use cases by phase, with the review gate for each
- Planning and risk assessment
- Fieldwork: documents, code and classification
- Analysis, findings and reporting
- Follow-up and running the function
- The human-review gates in detail
- Failure modes and the cases behind them
- Confidentiality and what goes into the model
- Documenting AI use in workpapers
- A worked pilot: Halberd Software’s FY27 quote-to-cash audit
- A 90-day adoption plan for the function
- Measuring the benefit without inventing it
- Questions about generative AI in internal audit
- Related guides
What the models are good at, and what they are not
Large language models transform text. Given material, they summarize, restructure, translate between registers, compare, extract, classify and draft, and they do these things quickly and at a quality that is usually good enough to start from. They also write code competently in the languages auditors use (SQL, Python, Power Query’s M, VBA), explain code they are shown, and propose test attributes, interview questions and risk statements that a tired auditor would not have thought of at 4 p.m. What they do not do reliably is know facts. A model’s statement about what a regulation says, what a standard requires, what a court held or what a number is comes from patterns in its training data, not from a lookup, and it produces a fluent, confident sentence whether or not the fact behind it exists. It does arithmetic by pattern unless it has a tool to compute with, it has no knowledge of anything after its training date unless given it, it does not reliably know what it does not know, and it tends to agree with the person it is talking to. Every use case below follows from this split: use the model on material the auditor supplies and verify anything it asserts about the world. The evidence and reasonable assurance essays on this site argue about what this does to the profession’s foundations; this guide stays at the level of Tuesday afternoon.
The rules before the tools
Four things need to exist before the function uses generative AI on engagement work. First, an approved tool: an enterprise-tier assistant (the business editions of the major assistants, or the organization’s own deployment) whose terms exclude training on the organization’s data, with administrative controls, logging and a retention setting the function understands; the consumer version of the same product is a different legal object and the usage policy should say so. Second, a data classification rule that says what may be submitted: the confidentiality section gives one. Third, the review principle, which the Global Internal Audit Standards already contain without naming AI: due professional care (Standard 4.2), the chief audit executive’s responsibility for appropriate technology and its use (Standard 10.3), the requirement that information used for analyses be reliable, relevant and sufficient (Standard 14.1) and the documentation requirement (Standard 14.6). Nothing in the Standards lets an auditor outsource a judgment, and nothing a model produces is evidence until an auditor has made it so. Fourth, a documentation convention for when AI use is recorded in workpapers, covered below. Functions that adopt tools before these four exist are the ones that later discover a restricted dataset in a consumer chatbot’s history or a fabricated citation in an issued report.
Use cases by phase, with the review gate for each
| Phase | Use case | Human-review gate | Residual risk after the gate |
|---|---|---|---|
| Annual planning and risk assessment | Summarize regulatory developments and news the auditor has gathered; draft risk statements for the universe; summarize prior reports and open issues for an entity; generate interview question sets for risk assessment conversations | Every external fact traced to a source the auditor opened; risk statements edited by the auditor who owns the assessment; the model never rates a risk | Low: planning outputs are internal and revised many times |
| Engagement planning and scoping | Draft the scoping memo structure from the planning notes; map process documentation to criteria; propose test attributes for a control; draft the work program from the risk and control matrix | Criteria checked against the actual standard or policy text; every proposed control confirmed to exist; the program reviewed by the lead as if a junior wrote it | Low to medium: an invented control or criterion that survives review distorts the fieldwork |
| Fieldwork: documents | Summarize long policies and contracts; compare two versions of a procedure and list the changes; extract defined fields from a set of documents; draft walkthrough notes from a recorded interview’s transcript; translate | Summaries spot-checked against the source for anything that becomes a fact in a workpaper; extractions sampled and reconciled; the auditor, not the summary, is the evidence | Medium: a summary that drops an exception clause changes a conclusion |
| Fieldwork: code and data | Write and explain SQL, Python and Power Query for population extraction and analytics; debug; document the logic; build reconciliation checks | Code reviewed line by line, run on a known sample with expected results, and completeness-tested against control totals as the analytics evidence guide requires | Low once tested: code either works on the test or it does not |
| Fieldwork: classification | Classify free-text populations (journal entry descriptions, hotline reports, expense narratives, change tickets) into categories for risk-based selection | Classification treated as a screening tool, never as the test: a sample of each class checked by the auditor and the error rate recorded; selections from the risky class tested normally | Medium: misclassification hides items; mitigated by sampling the “not risky” class too |
| Analysis and findings | Draft condition, cause and effect from the auditor’s notes; stress-test a finding by asking for management’s strongest rebuttal; propose root cause hypotheses; check a finding against the five Cs | Every fact in the draft traced to a workpaper reference; cause and effect are the auditor’s judgment, with the model’s suggestions treated as hypotheses to test | Medium: fluent drafts hide thin evidence |
| Reporting | Tighten the executive summary; cut length; adjust reading level; propose alternative orderings; check consistency between the summary and the findings; draft the audit committee one-pager | No new facts may enter at this stage; the issuing reviewer compares the edited text to the approved findings; tone and rating language stay the function’s | Low if the no-new-facts rule holds; high if it does not |
| Follow-up and issue validation | Summarize management’s evidence packs; draft the closure memo structure; compare the action plan to the evidence provided and list gaps | The validator inspects the evidence directly; the summary is a reading aid, and the validation workpaper records what the auditor examined | Medium: a pack summarized as complete when a document is missing |
| Function management | Draft QAIP self-assessment prep, training materials, methodology updates, job descriptions, the quarterly pack narrative; analyze time data; prepare CPE content | Normal management review; nothing about the function’s performance is asserted without the underlying data | Low |
Planning and risk assessment
Planning is where generative AI earns its keep with the least risk, because planning outputs are internal, provisional and revised by many hands. The useful work is synthesis: the auditor gathers the material (the prior three reports on an entity, the open issues, the regulatory alerts of the year, the strategy document, the risk register extract) and asks the model to produce an entity profile, a list of what changed, candidate risk statements in the function’s format and interview questions tailored to each stakeholder. The risk assessment and engagement-level risk assessment guides describe what good risk statements look like; a model produces plausible ones quickly, and the auditor’s job is to cut the generic ones and sharpen the rest with what they know. Two rules keep this safe. Facts about the outside world (a new rule’s effective date, a peer’s enforcement action, a standard’s requirement) are checked at the source before they enter a planning document, because a planning memo that cites a regulation wrongly propagates into the work program and the report. And the model never rates anything: likelihood, impact and the resulting ranking are the function’s judgment and the committee is approving the function’s judgment, not a model’s. The scoping memo guide shows the document a model can draft the skeleton of and the auditor must fill with real decisions.
Fieldwork: documents, code and classification
Three fieldwork uses carry most of the value. Document work: a 90-page vendor contract, a 40-page credit policy, two versions of a procedure a year apart. The model summarizes, extracts (every clause about audit rights, every approval threshold, every reference to a named committee) and compares, and the auditor reads the extract with the source open. The rule is that the summary is never the evidence: when a workpaper says “the policy requires dual approval above $50,000,” the auditor saw that sentence in the policy, and the summary was how they found it faster. Code: a model writes a population extraction in SQL from a plain description of the tables and the auditor’s intent, explains a stored procedure the auditee’s developer wrote, converts an Excel formula chain into Power Query steps, and adds the reconciliation checks the auditor asks for. The SQL for auditors guide gives the language; the discipline is to treat generated code exactly like code a junior wrote: review it, run it on a known sample with a known answer, test completeness against control totals, and save the version that ran with the output, as the analytics evidence guide lays out. Classification: 6,000 journal entry descriptions, 900 hotline narratives, 2,400 change tickets. A model classifies them into the categories the auditor defines (manual top-side, unusual counterparty, outside business hours, vague description) far faster than a keyword list and with more nuance, and the auditor then samples each category to measure how often the classification is wrong, records the error rate, and selects for testing from the risky class with an eye on the “not risky” class too. Classification is screening; the test is still the test. The journal entry analytics and procurement fraud analytics guides show where this slots in. For interviews, a transcript from a recorded and consented conversation can be turned into structured walkthrough notes in minutes; the interview techniques guide’s point stands that the auditor’s own contemporaneous notes remain the record, with the model’s version a tidy second draft.
Analysis, findings and reporting
Findings are where the models are both most useful and most dangerous. Useful: an auditor with good notes and a clear condition can get a well-structured draft of condition, criteria, cause, effect and recommendation in the function’s house format in a minute, can ask the model to argue management’s side (“give me the three strongest reasons this is not a finding”) and discover the weak joint before the auditee does, and can ask for root cause hypotheses that go beyond “the control was not performed.” Dangerous: the draft is fluent whether or not the evidence supports it, and a reviewer reading a polished paragraph is less likely to ask what sits behind each sentence than a reviewer reading a junior’s rough draft. The gate is mechanical: every factual sentence in a finding carries a workpaper reference before it leaves the draft stage, and the condition, cause and impact guides are the standard the draft is edited to. Cause and effect are the auditor’s judgment; the model’s suggestions are hypotheses the auditor confirms or discards with evidence. In reporting, the rule is that no new fact enters: the model tightens, reorders, cuts, adjusts reading level and checks that the executive summary says what the findings say, and the issuing reviewer compares the edited text to the approved findings. Rating language, the opinion and anything the committee will quote stay in the function’s own words. The anatomy of a report guide describes the document the model is editing; it should not be the document the model wrote.
Follow-up and running the function
In issue validation, management’s evidence packs arrive as folders of screenshots, policies, tickets and emails, and a model summarizes the pack against the action plan and lists what appears to be missing in a fraction of the time. The validator still opens the evidence, because a pack summarized as complete when the approval screenshot is from the wrong system is the kind of error that undoes a closure. The validation workpapers guide gives the record the validator keeps. In running the function, the uses are the ordinary ones of any knowledge job: the QAIP self-assessment prep (the self-assessment guide shows the conformance mapping a model can draft from the methodology documents), training materials, methodology updates, the narrative sections of the quarterly pack, job descriptions and time analysis. Small functions benefit most here: the one-person shop and small-team software guides describe functions where the chief audit executive is also the methodology team, and an assistant that turns a bullet list into a methodology section recovers hours those functions do not have.
The human-review gates in detail
| Gate | What the reviewer checks | Who | What is retained |
|---|---|---|---|
| Source gate | Every statement about the world (a regulation, a standard, a case, a figure, a date) has been checked at the source by a person, and the source is cited, not the model | The auditor using the tool | The source reference in the workpaper; nothing about the model |
| Evidence gate | Nothing produced by the model is itself evidence; summaries and extractions were checked against the underlying document for anything that becomes a fact | The auditor, then the reviewer | The underlying document and the auditor’s tickmarks; the summary at most as a reading aid |
| Code gate | Generated code reviewed, run on a known sample with expected results, completeness-tested, version saved with output | The auditor and a second person who can read the code | Script version, run log, control-total reconciliation |
| Classification gate | A sample of each class checked; error rate recorded; the “not risky” class sampled; selections tested normally | The auditor | Classification scheme, error rate, sample results |
| Judgment gate | Ratings, cause, effect, conclusions and the opinion are the auditor’s; model suggestions treated as hypotheses tested with evidence | The lead and the reviewer | The reasoning in the finding; no model attribution needed |
| No-new-facts gate | Report editing introduces no fact, figure or claim that is not in the approved findings | The issuing reviewer, comparing edited text to approved findings | The comparison, in the review notes |
| Confidentiality gate | Material submitted matches the classification rule; approved tool used; restricted data not entered or redacted | The auditor, with tool logging as the check | Tool logs; redaction notes where relevant |
Failure modes and the cases behind them
| Failure mode | How it shows | A case that made it concrete | Control |
|---|---|---|---|
| Fabricated citations and quotations | A regulation section, a court case, a standard paragraph or a quotation that does not exist, stated with full confidence | Mata v. Avianca (S.D.N.Y., June 2023): lawyers who filed a brief with cases invented by a chatbot were sanctioned $5,000; a public database of court decisions involving fabricated AI citations grew from a handful in 2023 to hundreds by 2025. In October 2025 Deloitte Australia agreed to partially refund a government department for a report found to contain fabricated references and a misquoted court judgment | Source gate: no citation enters a workpaper or report that a person has not opened |
| Confident wrong summaries | A policy summary that drops the exception clause; a contract summary that misses the audit-rights carve-out | Routine in practice; rarely public because it is caught (or not) inside organizations | Evidence gate: anything that becomes a fact is checked in the source |
| Confidentiality breach | Restricted data, personal data or privileged material submitted to a consumer tool with retention or training terms | In 2023 Samsung restricted employee use of public chatbots after staff pasted internal source code and meeting notes into one | Approved enterprise tool; classification rule; logging; the data privacy guide’s principles applied to the function’s own practice |
| Indirect prompt injection | A document the auditor asks the model to summarize contains text addressed to the model (hidden instructions in a PDF, white text in a spreadsheet), and the output is steered | Demonstrated repeatedly in security research; the enterprise incidents are catalogued in the agentic AI guide | Treat outputs from untrusted documents with the evidence gate; never let a model act (send, approve, change) on the basis of a document |
| Arithmetic and counting errors | Totals that do not foot; a count of exceptions that differs from the list | Routine without tool use | Numbers come from the data tools, never from the model’s prose; the code gate |
| Agreement with the user | Asked whether a finding is strong, the model says yes; asked whether it is weak, it also says yes | A known behavior of assistant models | Ask for the opposing case, not for confirmation; the judgment gate |
| Fluency hiding thin evidence | A polished finding paragraph with two facts behind it | Internal, and common | Workpaper references on every sentence before review |
| Version and recency drift | The same prompt gives a different answer after a model update; the model’s knowledge predates the rule it is asked about | Routine | Record the tool and date for anything that influenced a conclusion; supply current material rather than asking the model to recall it |
| Deskilling | Juniors who have never drafted a finding unaided cannot judge the draft | A risk the profession is debating | Drafting unaided remains part of training; reviewers ask juniors to explain every sentence |
| Over-reliance on classification | The “not risky” class is never looked at | Internal | Classification gate with sampling of every class |
The common thread is that every failure mode is a failure of review, not of the tool. The tool behaved as a text transformer behaves; the person treated its output as something it was not. This is why the gates are framed as review steps rather than as prohibitions: a function that bans the tools pushes use underground, where there are no gates at all, and the usage policy guide argues for permission with conditions on exactly that ground.
Confidentiality and what goes into the model
Internal audit handles the organization’s most sensitive material (investigation files, pre-announcement financial information, personal data, privileged legal analysis, security findings) and the function’s AI use has to be at least as careful as the rules it audits others against. A workable classification rule: public and internal material (published policies, the function’s own methodology, generic process descriptions) may go into the approved enterprise tool freely; confidential material (auditee process documents, draft findings, contract terms) may go into the approved tool with its retention and no-training terms confirmed, and never into a consumer tool; restricted material (personal data beyond what the task needs, material non-public financial information, privileged material, investigation subjects’ identities, security vulnerabilities, credentials) does not go into any general-purpose model unless the organization’s own deployment has been approved for it, and is redacted or tokenized first where the task allows (“Employee A”, “Vendor 1”). The approved tool’s administrative settings matter as much as the rule: who can use it, whether conversations are retained and for how long, whether they are discoverable, whether data leaves the jurisdiction, and whether the organization’s data loss prevention controls see the traffic. Auditee data is a separate question from the function’s data: a process owner who shared a dataset for an audit did not consent to its submission to a third-party service, and the engagement letter or the function’s standing data agreement should say what the function does with data. The data privacy audit guide and the AI governance guide give the frameworks (the NIST AI Risk Management Framework and its generative AI profile, ISO/IEC 42001, the EU AI Act’s transparency and general-purpose model obligations in force from August 2025) that the function’s own practice should be able to pass.
Documenting AI use in workpapers
Standard 14.6 requires documentation sufficient for an experienced auditor to understand the work and support the conclusions, and the question functions ask is whether AI use must be recorded. A proportionate convention: when the model was a drafting or reading aid and the output was fully reviewed against sources (a summary the auditor checked, a draft the auditor rewrote, a tidied set of notes), no record is needed beyond the normal workpaper, just as nobody records that a spreadsheet was used to sort a list. When the model’s output influenced a conclusion in a way a reviewer would want to understand (a classification used for selection, a generated script used for a population, an extraction relied on across many documents), the workpaper records the tool and version or date, the purpose, the prompt or scheme used, the review performed (sample size, error rate, test results) and the reviewer. When the model produced a conclusion-bearing output that could not be fully verified, that output is not used. The workpaper example and workpaper best practices guides show where this sits in the file, and the audit evidence guide is the standard against which any AI-assisted output is judged: sufficient, reliable, relevant and useful, obtained and evaluated by the auditor. The external quality assessor and the regulator will ask how the function controls its AI use; a written convention and a few workpapers that follow it are a better answer than a policy nobody applied.
A worked pilot: Halberd Software’s FY27 quote-to-cash audit
Halberd Software is the mid-size enterprise software company used in the technology examples on this site: it listed on the New York Stock Exchange in September 2026 as an emerging growth company, and its five-person internal audit function is working through an 18-month build plan under a newly appointed chief audit executive. Halberd’s own product teams use generative AI heavily, the company has an enterprise deployment of a major assistant with no-training terms, logging and a 30-day retention setting, and the audit function adopted the usage policy model in the first quarter of FY27. The chief audit executive chose the FY27 quote-to-cash audit (order management, contract terms, billing, revenue recognition under ASC 606, collections) as a controlled pilot: six use cases, each with its gate, hours tracked against the prior year’s comparable audit, and every near miss logged.
| Use case | What happened | Gate result and hours |
|---|---|---|
| Contract extraction: 180 customer contracts, extract non-standard terms (acceptance clauses, termination rights, usage-based pricing, most-favored-customer clauses) | Extraction completed in a day against an estimated six; the auditor sampled 30 contracts and found 2 missed clauses (an acceptance clause embedded in an order form, a termination right in an amendment not in the main contract), an error rate of 6.7 percent | Gate: extraction treated as screening; all 180 amendments and order forms added to the input set and rerun; second sample of 30 found 0 misses. Hours: 11 against 48 planned |
| Revenue recognition criteria mapping: draft the test attributes for the five-step model from Halberd’s revenue policy | The draft cited a paragraph of ASC 606 that does not exist for the treatment of a specific variable consideration constraint; the auditor caught it at the source gate | Gate: every citation checked in the codification; the near miss logged and used in training. Hours: 4 against 8 |
| Population extraction: SQL across the billing and ERP systems for FY27 invoices, credits and manual revenue adjustments | Generated SQL ran but double-counted credit memos reissued after a system migration; the known-sample test (a month with a hand-reconciled total) exposed it; corrected and completeness-tested to the general ledger | Gate: code gate did its job; the error would have inflated the credit population by 9 percent. Hours: 6 against 14 |
| Classification: 2,100 manual revenue adjustment descriptions into categories | Classification sampled: 8 percent error in the “routine true-up” class, 3 percent in “non-routine”; selections drawn from non-routine plus a 40-item sample of routine, which surfaced two misclassified non-routine items | Gate: classification gate; both items tested; one was a finding. Hours: 5 against 20 |
| Finding drafting: four findings from the lead’s notes | Drafts were well structured; one draft asserted an “effect” (potential misstatement of quarterly revenue) the evidence did not support; the lead rewrote it as a control design weakness with no misstatement identified | Gate: judgment gate; workpaper references on every sentence. Hours: 3 against 6 |
| Report editing: executive summary tightened from 900 to 420 words | The edit introduced a sentence implying the finding count had risen year on year; it had not; the no-new-facts comparison caught it | Gate: no-new-facts gate. Hours: 2 against 4 |
The pilot saved about 69 hours on an audit that had been budgeted at 420, roughly 16 percent, with four near misses, all caught by the gate designed for them. The chief audit executive reported it to the audit committee in those terms: the saving, the near misses and the fact that the gates held, which is a better story for a committee than a productivity claim. The function’s conclusion was to extend the tools to all engagements with the same gates, to keep logging near misses as the function’s own key risk indicator for AI use, and to add unaided drafting to the junior development plan after noticing that the two newest staff could not say why the fabricated ASC 606 citation was wrong. The technology and SaaS pillar places the pilot in Halberd’s wider program, and the agentic AI guide covers the FY27 engagement in which the same function audited the company’s AI agents.
A 90-day adoption plan for the function
| Weeks | Work | Output |
|---|---|---|
| 1 to 2 | Confirm the approved tool and its terms (training, retention, logging, jurisdiction); adopt the usage policy; write the classification rule and the documentation convention; brief the team | Policy, classification rule, documentation convention, tool settings documented |
| 3 to 4 | Train the team on the capability split and the gates, with exercises that include a planted fabricated citation and a planted dropped clause; agree the near-miss log | Training record; near-miss log opened |
| 5 to 9 | Pilot on one or two engagements: choose six use cases across phases, track hours against the plan and the prior year, apply every gate, log near misses | Pilot record with hours, gate results and near misses |
| 10 to 11 | Review the pilot with the team and the methodology owner; decide which use cases to standardize, which gates to tighten, which uses to restrict | Decisions recorded; methodology updated; prompt library started (the prompts guide gives a starting set) |
| 12 to 13 | Report to the audit committee: the policy, the pilot results, the near misses, the controls and the plan; add AI use to the QAIP’s internal assessment scope | Committee paper; QAIP scope updated |
Measuring the benefit without inventing it
The vendors’ productivity claims are not the function’s evidence, and a chief audit executive who tells the committee that AI made the team 40 percent more productive without time data has made exactly the kind of unsupported assertion the function exists to challenge. Measure what can be measured: hours on comparable tasks against the plan and the prior year, rework (review notes per report, report iterations), cycle time from fieldwork end to report issue, and quality indicators the function already tracks (findings accepted without dispute, management satisfaction, QAIP results). Measure the risk side too: near misses caught at each gate, confidentiality incidents, and the share of workpapers with the required AI documentation when the convention calls for it. Report both sides, and expect the benefit to be real but smaller than advertised in the first year and larger as prompts, habits and the tool mature. The evaluating AI in audit software guide applies the same skepticism to the AI features in audit management platforms, and the rise of AI in audit tools article gives the longer view. The function that measures candidly will have something to say when the committee asks, as it will, whether the auditors are using the tools responsibly; the function that does not will have an anecdote.
Questions about generative AI in internal audit
Can internal auditors use ChatGPT or similar tools on audit work?
Yes, within a policy: an approved enterprise-tier tool whose terms exclude training on the organization’s data, a classification rule for what may be submitted, human-review gates appropriate to each use, and a documentation convention. Consumer versions of the same tools are not appropriate for confidential or restricted material.
Where does generative AI help most in an audit?
Document summarization, extraction and comparison; writing and explaining analytics code; classifying free-text populations for risk-based selection; drafting findings and tightening reports from the auditor’s own notes and facts; and synthesis in planning. It helps least, and is riskiest, when asked to supply facts about regulations, standards or cases from memory.
Is AI output audit evidence?
No. Evidence is the underlying document, data or observation the auditor obtained and evaluated. A model’s summary, extraction or classification is a tool that helps the auditor get to the evidence faster; the auditor’s inspection of the source, the tested code and the sampled classification are what the workpaper relies on.
Do we have to document AI use in workpapers?
Record it when the output influenced a conclusion in a way a reviewer would want to understand: classification used for selection, generated scripts, extractions relied on across documents. Record the tool and date, the purpose, the prompt or scheme, the review performed and the reviewer. Pure drafting and reading aids that were fully reviewed against sources need no special record.
What are the biggest failure modes?
Fabricated citations and quotations (the Mata v. Avianca sanctions in 2023 and the Deloitte Australia partial refund in 2025 are the public cases), confident wrong summaries that drop exceptions, confidentiality breaches through consumer tools, indirect prompt injection from documents, arithmetic errors, the model agreeing with the user, and fluent drafts that hide thin evidence. Each is controlled by a review gate rather than a prohibition.
How should the chief audit executive report AI use to the audit committee?
With the policy, the tool and its terms, the gates, measured results (hours, rework, cycle time) and the near misses caught, and with AI use included in the quality program’s internal assessment. A measured account with near misses is more credible than a productivity claim.
Related guides
- AI usage policy for internal audit — the rules before the tools.
- AI prompts for internal auditors — a starting prompt library.
- Auditing AI governance — the frameworks the function’s own use should pass.
- Auditing agentic AI — when models act, not just write.
- Auditing AI and algorithms — fairness, transparency and control.
- Documenting analytics as audit evidence — the code gate in full.
- SQL for auditors — the language the model writes for you.
- Audit evidence — the standard every AI-assisted output must meet.
- Audit workpaper example — where the documentation sits.
- Workpaper best practices — consistency across the department.
- Issue validation workpapers — follow-up records.
- Internal audit risk assessment — planning synthesis.
- Engagement-level risk assessment — the risk statements a model can draft.
- The engagement scoping memo — the document the model drafts the skeleton of.
- Audit interview techniques — transcripts and notes.
- Journal entry analytics — where classification fits.
- Procurement fraud analytics — more classification targets.
- Writing finding conditions, cause statements and impact — the standard drafts are edited to.
- The executive summary — the no-new-facts gate.
- Anatomy of an internal audit report — the document being edited.
- Data privacy audit — confidentiality principles applied to the function.
- Internal audit self-assessment — AI use in the QAIP scope.
- The one-person internal audit shop and audit software for small teams — where the hours matter most.
- Evaluating AI in audit software — vendor claims with the same skepticism.
- The rise of AI in audit tools — the longer view.
- AI and audit evidence and AI and reasonable assurance — the foundations debate.
- Internal audit in technology and SaaS — Halberd’s wider program.
Leave a Reply