Domain 2: AI Governance, Ethics, Risk, and Compliance (17% of exam)
2.1 Establish AI Governance, Frameworks, and Policies
EU AI Act: EU regulation that classifies AI systems by risk tier (unacceptable, high, limited, minimal) and imposes obligations scaled to that risk — the most comprehensive binding AI law referenced on this exam.
NIST AI RMF (Risk Management Framework): voluntary US framework organized around four core functions — Govern (culture/policy), Map (context/risk identification), Measure (analyze/assess risk), Manage(respond/prioritize). Memorize these four words — they get reused as a mental model across governance questions.
ISO/IEC 42001: the AI management system standard — same structural idea as ISO 27001 (information security management systems), but scoped to how an organization governs AI responsibly across its lifecycle.
GDPR: EU data protection law — relevant here because AI training/inference often processes personal data; GDPR principles (lawful basis, data minimization, right to erasure) apply directly to AI systems.
AI governance vs. traditional IT governance: traditional IT governance assumes deterministic systems with stable behavior; AI governance must also account for non-determinism, drift, emergent behavior, and model-specific risk (not just uptime/change control).
AI use-case inventory: a centralized, maintained list of every AI system/use case in the organization — needed so leadership knows what AI exists and can govern it (you can't govern what you haven't inventoried — think "shadow IT" but for AI models).
Organizational AI roles: Chief AI Officer (executive accountable for AI strategy/risk), AI Ethics Officer (oversees responsible AI principles), AI Champions (embedded advocates/points of contact within business units).
2.2 Apply Responsible AI Principles and Ethics
Core Responsible AI principles: fairness, reliability, safety, privacy, inclusiveness, transparency — a recurring checklist; expect questions asking which principle a described scenario violates.
fairness - Ensuring that AI systems treat all individuals and demographic groups equitably without producing systemic, unjustified, or discriminatory bias
reliability - The ability of an AI system to perform its intended functions consistently, accurately, and predictably under normal and stressed operating conditions
safety - Designing and operating AI systems to prevent physical, digital, psychological, or operational harm to humans, infrastructure, and society.
privacy - Protecting personal, proprietary, and sensitive data throughout the entire AI lifecycle—from data collection and ingestion to storage and inference.
inclusiveness - designing AI solutions that empower and serve a diverse population, accommodating different physical abilities, languages, cultures, and socioeconomic backgrounds.
transparency - Making the operation, data sources, decision paths, and limitations of an AI system clear and understandable to users and stakeholders.
Algorithmic bias mitigation: actively testing/adjusting a model so it doesn't produce systematically unfair outcomes across protected groups (race, gender, age, etc.).
Transparency vs. explainability (distinction matters): transparency = disclosing that AI is being used and how, generally; explainability = being able to articulate why a specific model made a specific decision.
Systemic impacts/sustainability: considering broader societal effects of AI deployment — energy/compute consumption, job displacement, concentration of power — beyond just the immediate use case.
2.3 Implement AI Risk Management and Assessments
AI risk quantification/mapping: translating AI-specific risks (bias, drift, hallucination, autonomous action) into measurable/comparable terms, same discipline as traditional risk registers, applied to AI.
Impact assessments: evaluating potential harm — includes "blast radius" (how far-reaching a failure could be) and risk from autonomous actions (an agent acting without human review carries more inherent risk than one requiring approval).
Use-case risk tiers: categorizing AI systems by combining human impact (how much harm could result) and technical complexity — higher-impact/higher-complexity use cases get stricter controls (echoes the EU AI Act's risk-tier logic).
Risk treatments: the standard options (avoid, mitigate, transfer, accept) applied specifically to AI components.
Reassessment triggers: events that should force a fresh risk review — model updates, detected behavioral drift, new vulnerability disclosures. Key idea: AI risk assessment isn't one-and-done, it's continuous/triggered.
2.4 Ensure Data Privacy, Protection, and IP Rights
Regulated/sensitive data types: PII (personally identifiable info), PHI (protected health info), financial data, export-controlled data — know these categories exist and that AI systems processing them inherit those regulatory obligations.
IP/copyright and training data fair use: legal risk around whether training data was lawfully obtained/licensed — a live, unsettled legal area referenced because AI orgs face real exposure here.
Data derivation / regulatory contamination: risk that a model trained on regulated data "absorbs" that regulated status into its outputs — e.g., a model trained on PHI might leak PHI-like patterns even without directly storing records.
Data retention and deletion management: AI systems need defined lifecycles for how long training/inference data is kept and how it's properly deleted — complicated by the fact a trained model may "remember" data you intended to delete.
Consent mechanisms: ensuring data used for training/inference (including public data) was collected with appropriate consent or legal basis.
2.5 Manage Third-Party and AI Supply Chain Risks
Third-party AI due diligence: vetting external AI vendors' security controls before adopting their models/platforms.
Procurement controls / security SLAs / incident notification rights: contract-level protections — e.g., requiring a vendor to notify you within X hours of a breach affecting your data/models.
AIBOM (AI Bill of Materials): same concept as 6.3's AI-BOM — inventory of AI component dependencies (data, models, libraries) so you know what's inside a system you didn't build from scratch.
Shared responsibility models: clarifying what the AI vendor secures vs. what you (the customer) are responsible for securing — same logic as cloud shared-responsibility models, applied to AI services.
Data center security / Trusted Execution Environments / confidential computing: hardware-level protections ensuring data stays encrypted/isolated even while being actively processed — relevant when AI workloads run on infrastructure you don't fully control.
2.6 Enforce Accountability, Human Oversight, and Auditing
HITL vs. HOTL: Human-in-the-Loop = human actively reviews/approves each action; Human-on-the-Loop = human monitors and can intervene, but isn't required to approve every action (more autonomy allowed, oversight is supervisory rather than gatekeeping).
Intervention/override/sign-off authorities: clearly defined roles for who can stop, reverse, or approve an AI system's actions.
Shadow AI detection: finding unauthorized/unsanctioned AI tools or models in use within the organization that governance doesn't know about (directly tied back to the 2.1 use-case inventory concept — this is how you catch what's missing from it).
Governance artifacts: the paper trail — model documentation, decision logs, exception records — that prove governance is actually happening, not just declared on paper.
AI interaction labeling: disclosing when content is synthetic/AI-generated (e.g., deepfake disclosure requirements) so humans know they're interacting with or viewing AI output.
Internal/external audits: periodic formal review of AI systems for compliance, bias, drift, and whether they're actually delivering the claimed business outcomes.
2.7 Develop AI Security Education and Awareness
Skills assessments/gap analyses: evaluating whether staff operating AI systems (data scientists, approvers, security staff) actually have the competence needed for their role.
Role-based training: tailoring AI security/ethics training to the specific role (e.g., developers need different training than executives approving use cases).
Training effectiveness metrics: measuring whether training actually changed behavior/reduced risk, not just whether people sat through it — tied to building a "risk-aware culture."