AI-enabled fraud is not a separate fraud category for internal audit. It is a force multiplier: phishing becomes personalised, invoices and contracts can be fabricated, voice approvals can be spoofed, applicant records can be synthetic, and malicious code can move faster. This checklist turns those risks into internal-audit preparedness tests, control questions and source-evidence checks.
The strongest 2026 signal is not that AI proves more fraud. It is that internal audit teams expect the risk to grow faster than their tools, skills and evidence routines. Use the numbers below as global and North America-heavy risk signals, then tailor the audit programme to the entity's India obligations, systems, contracts and DPDP exposure.
IIA/AuditBoard reported that fewer than four in ten surveyed senior internal audit leaders believe their functions are adequately prepared to detect or respond to AI-enabled fraud.
AI-powered phishing was the most cited concern in the same survey, followed by fabricated invoices or financial documents and automated social engineering.
Internal audit teams expect to use more AI themselves, which makes governance, source verification and reviewer discipline part of the fraud-readiness file.
ACFE Occupational Fraud 2026 analysed 2,402 real cases across 143 countries and territories, giving the baseline fraud-risk context behind AI-enabled variants.
A red flag is only a starting point. The useful internal-audit question is which control was intended to address the scenario, what source evidence supports the reviewer conclusion, and which owner must respond if the evidence is missing or inconsistent.
| AI-enabled threat | Control weakness to test | Source evidence to inspect |
|---|---|---|
| AI-powered phishing | Payment, bank-master or credential-reset workflows that rely on email authenticity without callback or ticket evidence. | Payment request, approval trail, callback log, bank change ticket, email header or security alert, and final bank file. |
| Fabricated invoices or financial documents | AP accepts invoice PDFs, vendor declarations or support documents without source-system, GSTIN, PO/GRN or vendor-master verification. | Vendor master, PO, GRN, e-invoice/GST trail where applicable, invoice metadata, payment voucher and approver evidence. |
| Automated social engineering | Employees can bypass approvals when a message appears urgent, senior or commercially sensitive. | Delegation matrix, exception approval, helpdesk/security ticket, training record and incident escalation trail. |
| Deepfake audio or video impersonation | Treasury, payroll or vendor payment release accepts voice/video confirmation as sufficient evidence for exceptional approval. | Secondary written approval, maker-checker release, call-back evidence, bank portal log and board/committee ratification where relevant. |
| Malicious code inserted with AI assistance | Application or report changes move to production without code review, change ticket, access segregation or deployment approval. | Change request, code review, deployment log, privileged access log, rollback evidence and post-implementation review. |
| Forged contracts or legal documents | Procurement, revenue or treasury teams rely on unsigned drafts, unauthenticated PDFs or unsupported amended terms. | Executed contract, version history, board/contract approval, counterparty confirmation, obligation register and revenue/payment linkage. |
| Fabricated applicants or employee profiles | Hiring and payroll onboarding accept generated resumes, identities or references without independent verification. | Background verification, PAN/bank/PF/ESI checks, joining approval, employee master change log and first salary release. |
| Synthetic identity fraud | Customer, vendor or employee onboarding lacks duplicate, related-party, bank-account and document-authenticity checks. | KYC/registration documents, bank validation, duplicate master checks, related-party screening and transaction history. |
AI-generated emails, PDFs, contracts, voice notes, screenshots and summaries can look complete while being unsupported. Internal audit should separate three things in the workpaper: the red flag, the source evidence inspected, and the reviewer conclusion. If the conclusion depends only on generated content, the evidence file is weak.
Can an independent reviewer trace this exception to an original system record, third-party confirmation, approved ticket, immutable log, bank portal record or signed source document without relying on the generated artefact itself?
These examples do not prove fraud. They create recurring exception queues for reviewer conclusion and follow-up. Use the full monitoring library for broader P2P, O2C, R2R, H2R, treasury, compliance and ITGC rules.
| Cycle | Rule example | Data source |
|---|---|---|
| P2P | New vendor + first payment within 7 days + high-value or round invoice amount | Vendor master, AP ledger, payment run, invoice metadata |
| P2P | Vendor bank account changed within 10 days before payment release | Vendor master audit log, bank file, approval ticket |
| Treasury | Urgent manual transfer with email approval and no callback evidence | Bank portal log, treasury register, email/ticket trail |
| H2R | New employee with duplicate bank account, missing statutory ID or no attendance record | HRMS, payroll, bank file, PF/ESI/PT records |
| R2R | Manual journal with attached support created outside the source process | GL, journal attachment, source system, approver log |
| ITGC | Privileged deployment or script change without ticket/code review | Change system, repository log, deployment log, privileged activity |
Build the AI inventory, owner RACI and governance test file before assessing AI-enabled fraud exposure.
Download the wider cycle-wise exception-rule library for P2P, O2C, R2R, payroll, treasury, compliance and ITGC.
Turn fraud-readiness risks into controls, tests, evidence and reviewer columns.
Track test status, evidence blockers, exceptions and reviewer conclusions.
Escalate missing source evidence before a red flag is treated as an audit observation.
Convert validated exceptions into a report pack only after evidence and root cause are reviewed.
These sources support risk awareness, threat taxonomy and preparedness design. They do not endorse CORAA, create an India-specific legal standard, prove fraud in any entity or replace professional judgement.
AI-enabled fraud means a fraud risk where artificial intelligence is used to scale, disguise or accelerate deception: phishing, fake invoices, forged contracts, deepfake approvals, synthetic identities, fabricated applicants, malicious code or generated support documents. Internal audit should treat these as red flags that need source verification, not as automatic fraud conclusions.
No. This is a preparedness and control-testing checklist for internal audit before or around an incident. It does not determine who committed fraud, quantify legal loss, preserve evidence for court or replace a forensic investigation.
A generated document by itself should not be treated as sufficient evidence. The auditor should verify the source record, system log, approval trail, counterparty confirmation or original transaction population behind it, then document the reviewer conclusion.
No. The survey was based on senior internal audit leaders in North America. It is useful as a current risk signal, but Indian internal audit teams should tailor procedures to their own systems, contracts, DPDP obligations, sector rules and fraud-risk assessment.
Start with the AI governance workpaper, then route selected risks into the RCM, monitoring rules, fieldwork tracker and observation report only after source evidence is reviewed.
