How to Build an AI Audit Work Program

An artificial intelligence audit work program can look comprehensive and still be impossible to execute. Add enough questions about bias, privacy, cybersecurity, explainability, third parties, and human oversight, and the document quickly becomes impressive. The problem appears later, when the team cannot explain which risk a test addressed, what evidence was needed, or how the result supports a conclusion.

The quality of an AI audit program is not measured by the number of topics it contains. It is measured by traceability.

In this article, “AI audit program” means the engagement work program used by internal audit, not the annual internal audit plan. That distinction matters because Standard 13.6 of the Global Internal Audit Standards specifically governs the engagement work program.

Do not start with an AI checklist

The Global Internal Audit Standards provide the professional discipline. Standard 13.2 requires internal auditors to understand the activity under review and assess relevant risks. Standard 13.4 addresses evaluation criteria. Standard 13.5 requires consideration of the resources needed for the engagement. Standard 13.6 requires internal auditors to develop and document a work program designed to achieve the engagement objectives.

The requirements in Standard 13.6 call for the work program to be based on planning information and to identify evaluation criteria, tasks, methodologies and tools, and the internal auditors assigned to perform the work. The work program also requires review and approval before implementation. In the considerations for implementation, The IIA explains that auditors may link identified risks and controls to the testing approach and, later, to findings and conclusions. That distinction matters: traceability is a strong way to operationalize the Standard, not a mandatory template prescribed by it.

For AI-specific content, The IIA's Artificial Intelligence Auditing Framework, 2nd Edition adds a second layer. It organizes the subject around Governance, Management, and Internal Audit and provides practical considerations on strategy, accountability, risk, data, access, cybersecurity, third parties, policies, testing, and monitoring. The IIA describes its practitioner checklist as a quick-start guide that should be customized to the organization.

The combination is powerful: the Standards tell you how to structure and perform the engagement; the AI framework helps you decide which AI risks and controls deserve attention.

Start with the assurance question

Before writing procedures, define the decision your report should enable.

A weak objective is: “Review artificial intelligence controls.” It does not say what the auditor intends to conclude.

A stronger objective might be:

Assess whether the organization identifies, approves, operates, and monitors material AI uses through defined accountability, risk criteria, and controls that keep relevant exposures within accepted levels.

That objective forces a scope decision. Are you auditing enterprise AI governance, a portfolio of AI use cases, a business process that relies on AI, one application, or a third-party service? It also makes exclusions explicit. A governance review can assess inventory, ownership, policies, and escalation without claiming to perform mathematical model validation.

The assurance question then drives the priority risks. For an AI system used in customer decisions, those risks may include incorrect use-case classification, unsuitable data, excessive access, unreviewed decisions, unauthorized change, or ineffective monitoring. For an internal generative AI assistant, the emphasis may shift toward confidentiality, permissions, source quality, accuracy, acceptable use, and human validation.

Build a chain that works in both directions

A practical work program can be designed around six connected elements:

Element	Design question	AI audit example	What happens if it is missing
Objective	What do we need to conclude?	Does the organization control material AI uses?	Tests do not converge on a conclusion.
Risk	What could prevent the objective?	AI use cases are missing or misclassified.	The program becomes a generic checklist.
Expected control	What should happen to reduce the risk?	Every use case has an owner, classification, and approval.	There is no expected state to evaluate.
Evidence	What demonstrates design and operation?	Inventory, approvals, change records, exceptions.	Document requests are mistaken for assurance.
Procedure	How will we verify the evidence?	Reconcile sources, sample cases, reperform checks.	Inspection is confused with testing.
Conclusion	What can the result support?	Material use cases are consistently identified and approved.	Findings remain disconnected from the objective.

The quality test is simple. From a conclusion, another reviewer should be able to trace backward to evidence, procedure, control, risk, and objective. From each objective, the reviewer should also be able to trace forward to executable tests.

Six modules cover much of the AI control surface

There is no universal AI work program. Still, six modules provide a useful starting point for many engagements. They should be tailored to the system type, impact, jurisdiction, lifecycle stage, and organizational maturity.

Area	Primary risk	Expected control	Initial evidence
Governance and accountability	AI decisions lack ownership or oversight.	Defined roles, decision forums, and escalation.	Mandates, RACI, minutes, policies, board reporting.
Inventory and classification	AI uses sit outside governance processes.	Complete inventory and risk-based classification.	Inventory, procurement, SaaS, architecture, risk assessments.
Lifecycle and change	Deployment or change occurs without appropriate review.	Risk-proportionate approvals and change controls.	Gates, approval files, testing, versions, change records.
Data, access, and third parties	Unsuitable data, excessive access, or unmanaged dependency.	Defined and monitored requirements for data, access, and vendors.	Lineage, permissions, contracts, vendor reviews, logs.
Performance and human oversight	Incorrect outputs or automated decisions lack effective challenge.	Metrics, limits, human review, and exception handling.	Test results, metrics, reviews, overrides, escalated cases.
Monitoring and incidents	Degradation, incidents, or emerging risk goes undetected.	Monitoring, alerts, response, and periodic reassessment.	Dashboards, logs, incidents, corrective actions, reviews.

The IIA framework can help populate these modules, but it does not replace professional judgment. An organization buying an AI service from a vendor does not need the same program as one training models internally. An agent authorized to execute transactions requires different testing from an informational chatbot.

Design the evidence request before fieldwork

A useful evidence request is not “send all AI documentation.” It should anticipate the audit procedure.

To test inventory completeness, for example, request the official AI inventory, SaaS application lists, technology procurement records, vendor records, and selected expense categories. The procedure is not to read each source separately. It is to reconcile populations and investigate exceptions.

To test use-case approval, select a sample from the inventory and trace each item to its owner, risk assessment, approval, and imposed conditions. Then reverse the direction: select solutions from procurement or architecture and verify that they appear in the inventory.

To test monitoring, committee presentations are weak evidence if they cannot be connected to operational data. Trace metrics, alerts, or incidents to decisions, accountable owners, and follow-up actions.

Standard 14.1 reinforces this discipline by requiring the information used for analysis and evaluation to be relevant, reliable, and sufficient. In AI engagements, that makes it especially important to corroborate management assertions with system records, data, configurations, or independent evidence where feasible.

Do not write tests your team cannot perform

A work program is also a resourcing decision. Standard 13.5 requires internal auditors to consider whether the human, financial, and technological resources available are appropriate and sufficient to achieve the engagement objectives.

This prevents a common failure: procedures such as “validate that the model is unbiased,” “confirm model robustness,” or “perform adversarial testing” are inserted without defining a method, criterion, dataset, competency, or specialist owner. They sound technical, but they are not executable audit procedures.

A general internal auditor can assess governance, accountability, inventory, approvals, policies, validation evidence, monitoring, and the way the organization manages exceptions. Deeper work on model performance, statistical fairness, adversarial security, or specialized architecture may require support from data science, cybersecurity, privacy, legal, or model-risk specialists.

Specialist support does not weaken the audit. The audit team should still own the assurance question, define what evidence it needs from the specialist, and explain how that evidence affects the engagement conclusion.

The best work program ends where it started

An AI audit work program is well designed when the team can answer three questions at the end of fieldwork: what were we trying to conclude, what evidence did we obtain, and why is that evidence sufficient to support the conclusion?

The technology will change. So will providers, risks, and regulation. The professional structure is more durable: objective, risk, criterion, control, evidence, procedure, and conclusion.

The most useful AI audit program, therefore, is not the one with the most AI controls. It is the one that turns a complex subject into a clear, executable, and reviewable chain of assurance.