Auditing AI governance means testing whether an organization can explain which AI systems it uses, who is accountable for them, which risks are acceptable, which policies apply, and whether governance controls operate in practice. An audit should go beyond checking for an “AI policy” document. The objective is to determine whether decisions, ownership, evidence, and oversight are strong enough for the organization’s actual AI use.

The current ISACA AAIA content outline assigns 33% of the exam to AI Governance and Risk and explicitly covers governance, program management, risk, privacy, data governance, ethics, regulation, and standards. That makes governance an auditable operating system for AI, not a presentation layer around technical projects.

Define the audit universe before testing controls

Start by determining what the organization considers an AI system and which uses fall within the audit scope. The inventory may include predictive models, machine-learning pipelines, generative AI assistants, embedded vendor features, recommendation engines, fraud models, autonomous workflows, coding assistants, and AI capabilities purchased inside SaaS products.

Shadow AI is a governance problem. Business teams may activate vendor features or use public services without registering them centrally. Compare the official AI inventory with procurement records, cloud usage, API gateways, expense data, application inventories, data-loss alerts, and interviews to identify missing systems.

For each system, capture owner, business purpose, users, model or provider, data sources, decision impact, integrations, deployment status, jurisdiction, risk classification, and key control owners. Without an inventory, the rest of the governance program cannot reliably know what it is governing.

Test accountability and decision rights

Every material AI system should have accountable business and technical ownership. The audit should identify who approves use, who owns risk, who can stop the system, who validates data, who monitors performance, who handles incidents, and who accepts residual risk. A committee can coordinate governance, but it should not become a place where individual accountability disappears.

Review charters, RACI matrices, approval records, model cards, risk assessments, change records, and meeting evidence. Then interview owners and ask them to describe their responsibilities. If the policy assigns an owner but the named person does not know the system exists, the control is not operating effectively.

Escalation paths also matter. Teams need thresholds for when legal, privacy, security, risk, compliance, or executive review is required. High-impact decisions should not rely on informal judgment by one project manager.

Evaluate policy hierarchy and risk classification

A governance framework should connect enterprise principles to practical rules. High-level commitments such as fairness, transparency, privacy, security, and human oversight need standards and procedures that tell teams what evidence, testing, approvals, and monitoring are required.

Risk classification is often the mechanism that scales those requirements. A low-impact internal summarization tool may need lighter controls than an AI system that influences credit, employment, health, safety, or legal rights. The audit should verify that the classification method considers impact, autonomy, data sensitivity, affected populations, model uncertainty, external exposure, and regulatory obligations.

Sample systems from different risk tiers and verify that the resulting control requirements were actually applied. If every system is classified “low risk,” challenge whether the scoring method or incentives are biased toward avoiding governance effort.

Audit data governance and privacy as AI inputs and outputs

AI governance depends on data governance. Test whether teams know which data is used for training, fine-tuning, retrieval, prompting, evaluation, monitoring, and logging. Determine whether the organization has rights to use the data for that purpose and whether sensitive data is minimized, protected, retained, and deleted according to policy.

AI data privacy practices should translate PII requirements into concrete controls over collection, training, access, retention, sharing, and deletion. During an audit, the important question is whether those requirements can be traced to actual controls in the AI lifecycle.

Test data lineage for a sample of systems. Can the team identify where training or retrieval data originated, how it was transformed, which consent or contractual terms apply, and who approved its use? For generated outputs, determine whether personal or confidential information can be reproduced, inferred, or exposed to unauthorized users.

Examine human oversight and decision authority

“Human in the loop” is not meaningful unless the human has enough information, time, authority, and competence to challenge the AI result. Audit the workflow rather than the label. Does the reviewer see the evidence behind a recommendation? Can the reviewer override it? Are overrides tracked? Is the reviewer measured in a way that encourages rubber-stamping?

For high-impact decisions, sample cases where humans accepted and rejected AI recommendations. Compare the rationale, escalation path, and outcome. If every reviewer always accepts the AI, investigate whether the control is truly independent.

Human oversight also includes system owners and operators. Someone must decide when model drift, harmful outputs, security incidents, or regulatory changes require suspension or retraining. A control that can detect a problem but cannot stop the affected workflow is incomplete.

Review third-party and supply-chain governance

Many organizations consume AI through external models, SaaS features, data providers, open-source components, or managed platforms. Governance should therefore extend to procurement and third-party risk. Review contracts, due diligence, data-use terms, model change notifications, security evidence, privacy terms, incident obligations, audit rights, subcontractors, and exit arrangements.

Ask what happens when the provider changes the underlying model without changing the product name. Does the organization revalidate critical behavior? Can it detect a change in output quality, latency, or safety? Does the contract provide enough notice or control for regulated use?

Open-source components create a different evidence problem. The organization may control deployment but still depend on model provenance, licenses, training-data claims, community maintenance, and external libraries. Governance should identify who accepts those risks.

Test metrics, monitoring, and governance reporting

Effective governance needs indicators that show whether risk is changing. Metrics can include inventory completeness, percentage of high-risk systems with current assessments, unresolved critical issues, model-performance drift, privacy incidents, harmful-output rates, security findings, override rates, vendor exceptions, and overdue reviews.

Audit the data behind the dashboard. A green metric is meaningless if teams can omit unregistered systems or if issue aging resets whenever a ticket is reopened. Trace a sample from executive reporting back to source evidence and recalculate it.

Metrics should drive action. Review meeting minutes and issue records to see whether threshold breaches led to investigation, remediation, risk acceptance, or system suspension. Reporting without decision consequences is monitoring theater.

Distinguish control design from operating effectiveness

A policy can be well designed and poorly operated. During design assessment, ask whether the control would address the identified risk if performed as intended. During operating-effectiveness testing, gather evidence that the control occurred consistently, at the required frequency, by authorized people, with exceptions handled appropriately.

For example, a policy may require annual AI risk assessments. Design may be adequate for stable low-risk systems, but operating effectiveness fails if half the systems have no assessment or if the assessment is a copied template with no system-specific evidence.

Sampling should cover different business units, technologies, risk tiers, vendors, and lifecycle stages. AI governance can look mature in a central innovation team while business-unit deployments operate outside the process.

Regulatory mapping should be tested as evidence rather than assumed from a policy statement. Identify which jurisdictions, sector rules, privacy obligations, contractual commitments, and internal standards apply to a sample of AI systems. Then trace those requirements into concrete controls, approvals, notices, retention rules, testing, and reporting. A central register that merely lists laws without showing their effect on system design is weak evidence.

Change governance is equally important because AI systems can change without a traditional software release. Model versions, prompts, retrieval sources, safety settings, data pipelines, vendor features, or decision thresholds may alter behavior. Audit whether the organization defines what counts as a material change, who approves it, what regression testing is required, and when risk classification must be revisited.

Issue management should preserve accountability after the audit. For significant findings, verify the remediation owner, target date, compensating controls, acceptance authority, and retest criteria. AI issues can be easy to postpone because the technology is experimental; governance should prevent “pilot” status from becoming a permanent exemption for systems already influencing real users or decisions.

Training and awareness should be risk-based as well. Developers, model owners, procurement teams, auditors, and end users face different AI risks and need different guidance. Sample training records and interview users to determine whether they understand data-handling rules, prohibited uses, escalation paths, and the limits of AI outputs rather than merely confirming that a generic course was assigned.

Report governance issues in terms of business risk

Audit findings should connect the control failure to plausible impact. “Model inventory incomplete” is more useful when the report explains that unregistered systems can bypass privacy review, security testing, incident response, and regulatory assessment. “Human oversight weak” should identify which decisions can be made without effective challenge and who could be harmed.

Rank issues using the organization’s audit methodology, considering impact, likelihood, exposure, compensating controls, and regulatory significance. Avoid inventing a special AI severity scale unless it improves consistency and is governed like other audit criteria.

Across ISACA certifications, a defensible AI-governance audit produces traceable evidence: an inventory, clear ownership, risk-based policy requirements, controlled data use, effective human oversight, third-party governance, meaningful metrics, and documented remediation. The objective is not to prove that AI is risk-free; it is to prove that risk is identified, owned, controlled, monitored, and escalated.