AI Governance Audit

An audit may be appropriate when the board or Audit Committee requests assurance, Internal Audit includes AI governance in its plan, customer or contractual scrutiny increases, a regulated activity depends on AI, material incidents occur, or leadership needs confidence that remediation and controls operate. The trigger should be connected to a decision and assurance need, not a desire to use the word audit.

Organizations often benefit from an assessment or expert review first. A baseline can reveal that the AI inventory is incomplete, criteria are undefined, or evidence cannot support testing. Addressing those conditions before fieldwork reduces disruption and allows the audit to examine control operation instead of spending its scope reconstructing the system population.

Audit timing should reflect lifecycle and change. Testing immediately after a new control is introduced may establish design but not sustained operation. Waiting too long can leave significant exposure unexamined. Internal Audit, Risk, Compliance, CIO, CISO, Head of AI, Legal, DPO, and business owners should agree which systems, periods, events, and decisions make the work material.

An AI governance assessment identifies broad maturity signals, gaps, and priorities. It is useful when leadership needs orientation across visibility, ownership, risk, controls, and evidence. Its conclusions are limited by scope and supplied information, and it does not ordinarily test control operation over a defined period.

An AI governance review examines evidence and operating practice through interviews, document requests, and selected traces. It can provide expert, board-ready findings without representing formal assurance. A review is valuable when the organization needs an external perspective, wants to prepare for audit, or needs material gaps translated into management decisions.

An AI governance audit uses defined criteria, methodology, testing, sampling, evidence standards, independence expectations, ratings, and reporting. It asks whether controls are appropriately designed and operated within scope. The label should match the work. Presenting a review as an audit can mislead boards, clients, or regulators about confidence and independence.

Audit scope should identify entities, business units, geographies, system categories, lifecycle stages, period, processes, and control domains. It should state exclusions and dependencies. Enterprise-wide language is inappropriate when only a sample or one business unit is examined. Clear boundaries allow readers to understand where findings and conclusions apply.

Criteria may come from approved policies, control frameworks, contractual commitments, legal or regulatory requirements, risk appetite, governance standards, and defined procedures. Criteria should be suitable, available to responsible parties, and specific enough to test. Auditors should avoid converting broad principles into implied requirements without agreeing how compliance will be evaluated.

The audit population begins with the enterprise AI inventory. Auditors should assess completeness and select systems based on materiality, risk, lifecycle, vendor dependency, exceptions, incidents, data, affected users, and change. Sampling only the best-documented systems creates selection bias. Unknown systems and inventory limitations should influence scope and findings.

Ownership testing asks whether named business, technical, vendor, risk, and control owners understand and exercise their responsibilities. Evidence may include approval decisions, meeting records, escalations, risk acceptance, monitoring review, exception approval, and remediation closure. Interviews support testing but should not substitute for records when the control requires evidence.

Risk evidence should connect the actual use case to scenarios, data, affected people, output reliance, human oversight, vendor dependency, regulatory relevance, controls, residual risk, and acceptance authority. A score copied from a vendor or inherited across several uses is weak. Auditors should trace whether material changes triggered reassessment and whether unresolved uncertainty was visible to decision-makers.

Common findings include orphaned systems, owners without authority, approvals after deployment, overdue reassessments, and high residual risk accepted by the wrong level. These are not merely documentation issues. They indicate that governance decisions may not be accountable, timely, or aligned with risk appetite.

Control testing distinguishes design from operating effectiveness. Design testing asks whether inventory, approval, vendor, data, access, testing, oversight, monitoring, incident, exception, change, and evidence controls could address the defined risks. Operating testing examines whether the controls ran consistently, at the right time, by authorized people, and produced reliable outcomes.

Methods can include walkthroughs, inspection, observation, reperformance, configuration review, log analysis, and sample tracing. For example, an auditor may select material systems and trace them from intake through risk assessment, approval, vendor review, human oversight, monitoring, and change. Exceptions and incidents deserve targeted samples because they show how controls behave under pressure.

Control evidence should be system- and period-specific. A policy, template, or training deck proves design intent, not operation. Screenshots without context, undated approvals, and documents assembled during fieldwork require challenge. Internal Audit should identify whether evidence comes from an authoritative workflow, can be altered, and agrees with related records.

Vendor evidence may include due diligence, contracts, model or service dependencies, data terms, sub-processors, security, testing, logging, incidents, change notices, and exit provisions. Auditors should also test whether application owners reviewed material feature changes and whether the organization documented controls it retains. Supplier assurance does not cover every local use.

Human oversight testing should determine whether reviewers receive appropriate information, have competence and authority, can intervene, and record their decisions. A human-in-the-loop statement is insufficient if reviews are rushed, alternatives are unavailable, or overrides are discouraged. Evidence may include sampled decisions, challenge records, overrides, escalations, and monitoring of reviewer behavior.

For copilots and AI agents, testing should examine permissions, connectors, tool access, transaction limits, approval checkpoints, logging, interruption, and recovery. An agent's authority may change through configuration without a new procurement event. Audit procedures should compare current capability with the system record, risk assessment, and approval conditions.

Monitoring evidence should reflect material risk scenarios. Auditors may examine output-quality trends, overrides, complaints, access anomalies, data-policy events, drift, vendor changes, control failures, and overdue reviews. They should determine whether thresholds trigger investigation, whether owners review results, and whether management reporting includes unresolved exposure.

Incident evidence should connect detection, triage, containment, affected parties, root cause, governance decisions, and corrective action. Security, privacy, legal, operational, and model-quality processes may contribute separate records, but the audit trail should show coordinated accountability. Repeated incidents may indicate weak monitoring, control design, training, or supplier management.

Exception records should identify requirement, rationale, risk owner, approval authority, duration, compensating controls, review, and closure. Auditors should challenge expired, repeatedly renewed, or undocumented exceptions. A high exception rate can signal that the standard control is impractical or that management is accepting risk without transparent governance.

Audit findings should state criteria, condition, evidence, cause, risk, rating, owner, and expected action. Severity should reflect consequence and control significance rather than the number of missing files. A system with no accountable risk acceptance can be more material than several minor record-format issues. Reporting should also identify scope limitations and inventory uncertainty.

Management responses should define outcomes, owners, dates, dependencies, interim measures, and closure evidence. Internal Audit should retain authority to evaluate whether proposed actions address the finding. Remediation should change operating practice: assigning decision rights, redesigning workflow, improving evidence capture, restricting use, strengthening vendor terms, or implementing monitoring.

Closure testing should verify completion and, where relevant, sustained operation. A new procedure is not closed merely because it was published. Boards and Audit Committees need visibility into overdue high-risk actions, accepted residual exposure, repeated findings, and systemic root causes. Clear reporting turns audit work into accountable improvement rather than a point-in-time compliance exercise.

Preparation begins with a reconciled AI inventory and agreed scope. Management should identify control owners, map controls to risks and evidence, review exceptions, confirm system and vendor records, and test retrieval. A readiness review can surface gaps without manufacturing artifacts after the fact. Evidence created during fieldwork should be labelled honestly.

Teams should prepare walkthroughs around real systems and decisions. CIO and Head of AI explain technology and delivery; CISO and DPO address security and data; Legal and Compliance explain obligations; Procurement covers suppliers; Risk shows classification and acceptance; business owners explain purpose and consequences. Internal Audit needs a coherent account, not identical language from every stakeholder.

Audit readiness is sustained through ordinary workflows. Inventory updates, risk reviews, approvals, monitoring, incidents, exceptions, and remediation should produce evidence as work occurs. Periodic control testing and governance review can identify drift before formal audit. The objective is not a perfect evidence pack assembled once, but an operating system capable of explaining and improving its decisions.