How do you audit an AI system?

You audit an AI system the way you audit any process: agree what it is supposed to do, identify the controls that keep it doing that, and test them against evidence. The difference is in the five areas the controls fall into: governance (who owns it and who approved it), data (what went in and whether anyone was allowed to use it), the model (how it was built or bought, evaluated and changed), use (whether people can and do override it), and monitoring (whether anyone would notice it going wrong). The criteria now exist to test against, which was not true three years ago.

Start with an inventory, because there is not one

The first finding of most AI audits is that nobody knows what the organisation is using. Ask three sources and compare: IT's list of approved tools, procurement's list of contracts that mention AI or machine learning, and a short survey of department heads asking which tools their teams use for work. The gap between the first list and the third is your real scope. What staff should not be pasting into any of those tools is in whether ChatGPT is safe for audit work.

Classify each system by what it touches: customers, employees, money, regulated decisions, or internal convenience. The EU AI Act gives one usable scale: prohibited, high-risk (its Annex III lists uses such as recruitment, credit scoring and essential services), limited-risk with transparency duties, and the rest. You do not need to be in the EU to borrow the categories. In India, the Digital Personal Data Protection Act 2023 and its rules, notified in November 2025 with a phased start, decide the personal-data side of the same question.

The criteria to test against

An audit needs criteria, and for AI these are the ones auditors and regulators are converging on.

• The IIA's AI Auditing Framework, updated in September 2024, is written for internal auditors. It is built on the Three Lines Model and the Global Internal Audit Standards, covers governance, management and the auditing of AI, and ends with a practitioner's checklist for an initial assessment. If you read one document first, read this.
• NIST's AI Risk Management Framework (AI RMF 1.0, January 2023) organises the work into four functions: Govern, Map, Measure, Manage. Its generative AI profile (NIST AI 600-1, July 2024) adds the risks specific to language models. It is voluntary and widely used as a control catalogue.
• ISO/IEC 42001:2023 is the management-system standard for AI, in the same family as ISO 27001: policy, roles, risk assessment, controls, monitoring, improvement. Useful as criteria even for an organisation that will never certify, because it says what "managed" looks like.
• The EU AI Act entered into force on 1 August 2024. Its prohibitions and the AI literacy duty (Article 4) have applied since 2 February 2025; the obligations for general-purpose models since August 2025; the high-risk obligations phase in after that. For a European organisation the Act is a compliance criterion; for everyone else it is a well-organised list of what regulators care about.
• The Global Internal Audit Standards themselves. Standard 13.2 requires an engagement risk assessment built on reliable, relevant and sufficient information about the activity, and Standard 14.1 says what reliable information is: obtained directly or from an independent source, corroborated, and from a system with effective controls. A vendor's assurance slide is none of those.

For India, the ICAI's Internal Audit Standards Board revised its Technical Guide on Risk-Based Internal Audit in March 2026 and names artificial intelligence and data analytics among the changes it now accounts for; the Standards on Internal Audit from the same board set the documentation and evidence expectations.

A first audit programme

Pick one material system, not the whole inventory. Seven steps, each with a question, evidence and the control you are testing.

1. Ownership and approval. Who is accountable for this system's decisions, and who approved its use for this purpose? Evidence: a named owner, an approval record, a stated purpose. Control: the system cannot be put to a new use without a new approval.
2. Purpose and risk classification. Was the risk assessed before deployment, and does the classification match what the system does today? Evidence: the assessment, the category, the date. Control: re-assessment on change.
3. Data. Where did the training and input data come from, was its use permitted, and is personal data in it minimised or masked? Evidence: data lineage, consent or legal basis, retention. Control: access to the data is restricted and logged.
4. The model. Built or bought? How was it evaluated before go-live, against which test set, with what results? How are changes (a new model version, a new prompt) tested and approved? Evidence: evaluation results, a change log, version pins. Control: no change reaches production without a recorded evaluation.
5. Human oversight. Can a person override the system's output, and do they? A review step that approves 100% of suggestions in under two seconds each is not oversight. Evidence: override rates, sampled decisions, the time a reviewer takes. Control: the override is real, and its use is measured.
6. Monitoring and incidents. Would anyone notice drift, a spike in errors or a complaint pattern? Evidence: monitoring metrics, thresholds, an incident log, a kill switch. Control: a stop condition exists and has been tested.
7. Third parties. For a bought system, what has the vendor committed to on data use, training on your data, sub-processors and region? Evidence: the contract and the data-processing terms, read, not summarised by the vendor. Control: the terms match how the system is actually set up.

Write the findings in the normal structure. "The recruitment screening model was retrained in March with no recorded evaluation; 3 of 3 changes sampled had no test results attached" is a condition anyone can act on. "AI governance is immature" is not.

Where it sits in the audit universe

An AI system that affects customers, employees or money is an auditable entity in its own right, with an owner, a scope and a risk score. Shadow use of consumer tools is a cross-cutting theme that belongs in every process audit: when you audit procurement, ask what the buyers paste into chatbots. The post on building a risk-based annual plan covers how an entity like this gets scored against the rest.

One more thing to put in scope: your own function's AI. If the audit team uses an assistant to draft findings or search its history, the same seven steps apply, and the audit committee will ask. The post on how audit teams use AI and where it fails sets out what a defensible setup looks like.

How AuditEase Pro fits

In AuditEase Pro, an AI system is an entity in the audit universe like any other, with its owner, its questionnaire and its place on the heatmap, and the seven steps above become RCM rows and work papers with test cases and evidence attached. The findings go through the normal observation, response and issue flow.

The product's own AI is built to pass the audit it would get. It is off until an administrator names a provider; every suggestion is a ledger row with the model, the prompt version, the tokens and the person's decision; every decision is an audit event; retrieval starts from the records the person may see; and a test in the codebase proves no AI code can take a workflow step. If your function wants to audit the assistant it uses, the evidence for steps 1, 4, 5 and 6 is already there.

The live demo holds a fictional organisation with its audit universe and RCM in place, so you can add an AI system as an entity and walk the programme through.