ISACA AAIR cheat sheet

AI governance is the system of policies, roles, decision rights, and oversight mechanisms by which an enterprise directs and controls AI use; it answers who decides, who is accountable, and how compliance is evidenced.

Board or executive committee owns AI risk appetite and sets tolerance thresholds; a cross-functional AI governance committee (risk, legal, security, data, business, internal audit) converts appetite into standards and approves high-risk use cases.

Three lines model: business/IT owns and operates AI (first line), risk and compliance functions set and monitor controls (second line), internal audit provides independent assurance (third line); the first line cannot self-certify its own controls.

Policy hierarchy: enterprise AI policy (principles and prohibitions) > standards (model validation, data quality, human oversight) > procedures (workflows, checklists) > control evidence; lower tiers must never relax a higher tier.

AI system inventory/registry is the foundational governance artifact: it records each system's owner, purpose, model type, data sources, affected populations, risk tier, and review dates, and drives scoping of all downstream controls.

Risk tiering decision rule: classify by potential harm to individuals and the enterprise (safety, legal rights, financial, reputational) and by autonomy and scale; higher tier triggers mandatory human oversight, independent validation, and pre-deployment approval.

Accountable executive and business owner must be named for every AI system; 'the AI team' is not an acceptable owner, because accountability must sit with a role that has authority over the use case.

Transparency obligations: notify affected users that they are interacting with AI where required, disclose material limitations, and maintain model documentation (intended use, training data, performance, known failure modes) for regulators and auditors.

Governance effectiveness is monitored through KRIs: percentage of AI systems inventoried, overdue model reviews, exceptions to policy, incidents per system, and percentage of high-risk systems with completed independent validation.

Life cycle stages: ideation and intake > design and data sourcing > development and training > validation and testing > deployment > monitoring and operation > decommissioning; each stage has entry criteria and required evidence.

Intake/business case must document intended use, prohibited uses, affected stakeholders, data sources, and a preliminary risk tier before any development spend is approved.

Data risk controls: verify lawful basis and consent, provenance and lineage, representativeness, labeling quality, and absence of sensitive attributes unless justified; bias testing compares outcomes across protected groups.

Model risk is a function of complexity, autonomy, data dependency, and decision impact; higher model risk requires independent validation, challenger models, and documented performance thresholds before release.

Validation is performed by parties independent of development and tests accuracy, robustness, fairness, explainability, security (adversarial/prompt injection), and human-oversight effectiveness against pre-defined acceptance criteria.

Human-in-the-loop decision rule: the level of oversight scales with harm potential; meaningful oversight requires authority, competence, information, and time to override the AI output, not a nominal click-through.

Deployment controls include staged rollout or shadow mode, rollback plans, version pinning, access controls, logging of inputs and outputs, and documented approval by the accountable owner.

Post-deployment monitoring tracks data drift, concept drift, performance decay, incident trends, and feedback loops; thresholds trigger revalidation, retraining, restriction, or retirement.

Decommissioning requires retiring the model and its data per retention policy, archiving validation evidence, notifying dependent systems, and confirming no residual automated decisions continue.

Program scope: identify, assess, treat, monitor, and report AI risk across the enterprise; the program aligns to the enterprise risk management framework rather than operating as a standalone silo.

Risk assessment method: likelihood x impact scoring mapped to the enterprise risk taxonomy, with inherent risk (before controls), residual risk (after controls), and a documented gap to risk appetite.

Control library should map to recognized frameworks (e.g., NIST AI RMF, ISO/IEC 42001, ISO/IEC 23894) so controls are traceable to external expectations and auditable.

Third-party AI risk: perform due diligence on vendors and foundation-model providers covering training data, security, model change notification, subprocessors, and contractual rights to audit and exit.

Incident management must cover AI-specific events (harmful output, bias incident, model compromise, prompt injection, data leakage) with severity classification, escalation paths, and root-cause analysis.

Reporting to the board and risk committee uses aggregated risk posture: number of AI systems by tier, open findings and aging, incidents, exceptions, and remediation status against agreed timelines.

Training and awareness for developers, business owners, and approvers covers policy obligations, red flags, and escalation routes; completion rates are a program KPI.

Independent audit and continuous improvement: periodic assurance reviews test control design and operating effectiveness, and findings feed back into policy, standards, and the control library.

Metrics must be decision-useful and tied to appetite; a KRI breaching threshold requires a documented response, owner, and date, otherwise the metric is decorative.