AI in IT Audits: What Has Changed, What Has Not, and What Auditors Are Getting Wrong

The debate about whether AI should be used in IT audits is over. It is being used. Microsoft Copilot is summarising audit documentation in most large financial institutions. AI-powered anomaly detection is running across transaction datasets. LLM tools are being used to draft audit findings, cross-reference control frameworks, and triage evidence. The question auditors need to be asking in 2026 is not whether to use these tools. It is whether they are using them in a way that produces defensible, accurate, high-quality audit work, or whether they are producing audit outputs that look efficient and are actually unreliable.

The harder version of the same question: if AI is inside the systems you are auditing and inside your own audit toolkit, what does professional skepticism actually mean now?

The Dual Challenge Most Audit Functions Are Not Addressing

IT auditors face two separate AI-related challenges that are almost always conflated and need to be kept distinct.

The first is auditing AI-powered systems. Copilot in Microsoft 365, AI models in credit decisioning, LLM agents in customer service, algorithmic trading systems, GenAI tools in procurement. These are now standard audit scope items in financial services. The control questions (model governance, access permissions, explainability, bias testing, evidence quality for AI-assisted decisions) are substantively different from traditional IT controls. The methodology for auditing generative AI systems is covered here.

The second is using AI tools inside the audit process itself. This is the less-examined challenge. When an auditor uses Microsoft Copilot to summarise a policy document, they are relying on a model that can hallucinate, misconstrue scope language, and miss nuance that a careful read would catch. When an AI anomaly detection tool flags 60 transactions as suspicious and the auditor reviews 15 of them, the coverage claim in the audit report needs to be honest about what was actually examined. When an LLM drafts a finding from structured audit notes, the auditor signing off is responsible for every word in that finding regardless of how it was produced.

The risk is not that AI tools are being used. The risk is that they are being used in a way that creates false confidence in the coverage and reliability of audit work.

Where AI Genuinely Helps

Data analytics is where AI delivers the clearest, most defensible value in IT audit. Processing complete populations rather than samples, identifying statistical outliers in access logs, detecting configuration drift across cloud environments at scale. These are tasks where AI tools produce outputs that would take weeks of manual work and where the methodology is auditable and the results are verifiable.

Document analysis is the second genuine use case. Reviewing a 200-page SOC 2 Type II report, mapping controls to DORA obligations, cross-referencing a vendor's security policy against contractual minimum requirements. AI tools can do this faster than any human reviewer and with consistent coverage. The output needs human validation, but the initial triage is legitimate.

Evidence structuring is emerging as a third. Taking interview notes, system screenshots, configuration extracts, and test results and building a coherent evidence package for a finding is mechanical work that AI can assist with. The auditor still has to verify that the evidence supports the finding and that the finding is accurately framed.

In each of these use cases, the auditor is using AI to process more data or work faster. The professional judgment (what the data means, whether the finding is material, whether the control is adequate) remains with the auditor.

Where AI Creates Risk in the Audit Process

The ISACA IT Audit Framework 2024 update is explicit that professional skepticism cannot be delegated to a tool. The IIA Standards (2024 revision) require that internal auditors exercise due professional care, which includes evaluating the reliability of information used to support conclusions. When that information was produced or curated by an AI tool, the auditor needs to understand what the tool does, what it can get wrong, and how to verify its outputs.

Three specific failure modes are appearing in AI-assisted audit work.

The first is coverage miscommunication. An AI tool processes a dataset and an auditor reports population-level testing when what actually happened was the AI flagged anomalies and the auditor reviewed a subset of them. The distinction matters for assurance statements and for regulators who are increasingly asking exactly this question. DORA Article 19 requires ICT-related incident testing documentation to be accurate, and the FCA has been explicit in its own guidance that audit reliance on automated tools requires documentation of how those tools work and what their limitations are.

The second is hallucination in documentation. LLMs produce confident, well-structured text that can be factually wrong. An AI-drafted finding that mischaracterises a regulatory requirement, overstates the control gap, or attributes a risk to the wrong system is a finding the auditor signed off on. The reputational and professional liability implications of that are the same as if the auditor had written the error themselves.

The third is context blindness. AI tools do not understand organisational context. A tool that flags an access anomaly may not know that the user in question is a shared service account with deliberately broad access by design. A tool that summarises a policy may not pick up that the policy was superseded by a management instruction issued outside the formal documentation process. Human auditors with organisational knowledge catch these things. AI tools do not.

What Professional Skepticism Means in an AI-Assisted Audit

Professional skepticism in an AI-assisted audit environment means three things in practice.

First, knowing what your tools actually do. If you are using an AI anomaly detection tool, you need to understand the model's sensitivity and specificity, what data it was trained on, and what classes of anomaly it is likely to miss. Vendor documentation is the starting point. Independent testing on your environment is the standard.

Second, verifying AI outputs before relying on them. This does not mean checking every output manually, because that defeats the purpose. It means defining a validation approach: sample-based spot checks for documentation outputs, independent verification for high-stakes findings, population reconciliation for data analytics results.

Third, being accurate in audit documentation about what AI did and what you did. If the AI processed the population and you reviewed the flagged exceptions, say that. If the AI drafted the finding and you reviewed and approved it, that is fine, but the finding needs to be accurate. The documentation of methodology needs to match the reality of how the work was done.

None of this is a reason to avoid AI tools. The audit functions that are doing this well are producing more coverage, finding more issues, and doing it faster than those still working entirely manually. The difference is that they are using AI deliberately, with clear methodology, and with human judgment applied where it matters.

The Regulatory Direction

Regulators are starting to ask about AI in the audit process, not just AI in the systems being audited. The FCA's review of internal audit functions in financial services has included questions about automation in audit methodology. The EBA's guidelines on internal governance (EBA/GL/2021/05) include requirements that internal audit functions maintain competence relevant to the complexity of the institution, and for institutions with significant AI deployment, that now includes understanding AI risks and AI-assisted audit methodology.

DORA Article 9's ICT risk management requirements cover the tools used in risk management and assurance functions. An AI tool used in the audit process that produces unreliable outputs without adequate validation is itself an ICT risk management failure. That framing will become more common in regulatory dialogue over the next two years.

The direction is clear: AI in audit is expected, accepted, and increasingly required for coverage at scale. What is also expected is that auditors who use it know what they are doing with it.