All 100 essential facts from the four AIGP domains on one page, condensed from the full study guides. Skim it the night before and the morning of your exam. Free, no login, and printable.
Domain I carries 16–20 questions per the BoK v2.1 exam blueprint (min 16, max 20; counts can shift across BoK versions); competency I.C is the heaviest (6–8), with strong overlap into Domain III.
Domain I establishes the foundations: what AI is, why it needs governance distinct from other technology, and the organizational scaffolding (roles, policies, procedures) that makes governance operational.
The OECD (updated) and EU AI Act definition (technically separate documents, since aligned): a machine-based system that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments.
The root governance challenge is the shift from authored rules to learned behaviour: traditional software is Input + Rules to Output, machine learning is Input + Data to Model to Output.
That shift produces opacity, probabilistic outputs, and data dependency, which is why AI governance differs from traditional IT governance.
AI types: narrow/weak (task-specific, most deployed AI today) versus general/AGI (theoretical); and classic versus generative versus agentic.
Agentic AI plans and executes multi-step actions toward a goal, often invoking tools, with limited human intervention.
AI can harm individuals, groups, organizations, and society; be ready to name a harm at each level.
Three governance challenges the BoK emphasizes (as examples, not an exhaustive list): misalignment (optimizing a proxy that diverges from intent), ethics and bias, and complexity and scalability (small harms compounding across millions of decisions).
Common AI-specific security threats include (supplementary to the BoK, not an exhaustive list): prompt injection, data poisoning, model extraction, membership inference, adversarial examples, model inversion.
A useful set of seven characteristics drives the need for governance (the BoK lists these with an "e.g.," so treat them as a memory aid, not a closed set): complexity, opacity, autonomy, speed and scale, potential for harm or misuse, data dependency, probabilistic outputs.
The six responsible-AI principles the BoK names: fairness; safety and reliability; privacy and security; transparency and explainability; accountability; human-centricity.
Contestability, sustainability, and inclusiveness are emphasized in other frameworks rather than forming part of the BoK's six core principles.
Responsible-AI principles can be in tension (transparency versus security, one fairness metric versus another); the skill is recognizing the trade-off and documenting how it was resolved.
Governance must be cross-functional and proportionate to context; one use case can raise privacy, security, employment, IP, and ethics questions at once.
Accountability is assigned to identifiable roles: board (owns AI risk appetite and oversight), executive sponsor or equivalent leadership (owns the program), governance lead or committee (day-to-day), supported by legal, privacy, security, data governance, ethics, product, engineering, audit, and HR.
Training is tiered: all employees (acceptable use, generative-AI hygiene), builders (bias testing, secure development), reviewers (impact assessment, risk classification), executives and board (strategic and regulatory).
Tailor the program to company size, maturity, industry, products and services, objectives, and risk tolerance; there is no one-size-fits-all.
Developer, provider, deployer, and user describe tasks, not fixed legal categories, though some laws (notably the EU AI Act) attach obligations to them; one organization may occupy several.
A deployer cannot assume the developer's documentation discharges all its responsibility.
Seven pillars of a governance program (a teaching synthesis, not a BoK-enumerated list): governance structure, policies and standards, risk management, lifecycle controls, training and awareness, monitoring and assurance, incident management.
Policies align to life-cycle stages: use-case assessment, risk management, ethics by design, data acquisition and use, model development, training and testing, deployment and monitoring, documentation, incident management.
As sound governance practice, each policy should state who owns it, who must comply, what is required, how compliance is evidenced, and what happens when it is not met.
Update, do not duplicate existing policies for AI (a BoK I.C performance indicator: evaluate and update existing policies for privacy, security, data governance, and IP): privacy, information security, data governance, intellectual property, acceptable use, and records management.
Third-party risk management: pre-contract due diligence, contractual protections (audit rights, data-use limits, IP indemnity, change-notification, exit), ongoing monitoring after model updates, and supply-chain visibility up to the foundation-model provider.
Domain IIHow Laws, Standards and Frameworks Apply to AI
GDPR lawful bases for AI: consent, contract, legal obligation, vital interests, public task, legitimate interests.
Purpose limitation and lawful basis are the two most-tested privacy concepts in AI contexts.
DPIA is required for AI processing likely to result in high risk to data subjects.
Article 22 establishes rights related to solely automated decision-making, not a verbatim "right to explanation."
Special categories under GDPR include biometric data used for identification, health data, and others. Inference of special categories can bring processing into special-category scope.
Anti-discrimination law reaches AI through disparate-treatment and disparate-impact theories, employment, credit, housing, insurance.
NYC Local Law 144 requires bias audits of automated employment decision tools.
Colorado AI Act (SB 24-205, 2024) was replaced by SB 26-189 in May 2026, effective Jan 1 2027: a narrower transparency and disclosure framework for automated decision-making that dropped the original duty of care, risk-management, and impact-assessment obligations.
Consumer protection law (e.g., FTC) reaches deceptive AI claims and undisclosed AI use.
EU Product Liability Directive (revised) extends product liability to software including AI.
EU AI Act risk pyramid: Prohibited → High-Risk → Limited → Minimal.
Prohibited practices include social scoring by public authorities, manipulative systems, untargeted biometric scraping, and certain real-time remote biometric identification in publicly accessible spaces.
High-risk = (a) safety component in regulated products or (b) Annex III standalone domains.
Annex III domains: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice.
Limited risk primarily triggers transparency obligations (chatbots, deepfakes, biometric categorization, permitted emotion recognition). Note: emotion recognition in workplaces and educational institutions is prohibited, not limited-risk.
Provider obligations (RD-TLC-P): Risk management, Data governance, Technical documentation, Logging, Conformity assessment, Post-market monitoring. The mnemonic under-covers BoK II.C, which also names human oversight, transparency and notification, and a quality management system; CE marking and instructions for use are further EU AI Act specifics.
Deployers use the system, ensure human oversight, monitor, and conduct FRIA where applicable.
A deployer becomes a provider by branding, substantial modification, or repurposing into a high-risk category.
GPAI is a separate track from the risk pyramid. All GPAI providers owe training-data summary and downstream-info duties; systemic-risk GPAI owes more.
CE marking indicates EU AI Act conformity for in-scope high-risk systems.
AI Office has particular responsibility for GPAI at EU level.
EU AI Act phasing: entry into force Aug 2024 → prohibitions Feb 2025 → GPAI Aug 2025 → Article 50 transparency duties and GPAI enforcement Aug 2026 (not delayed) → Annex III standalone high-risk Dec 2027 → Annex I embedded high-risk Aug 2028 (per the Digital Omnibus, approved June 2026).
OECD AI Principles = 5 values + 5 policymaker recommendations.
NIST AI RMF functions: Govern (center), Map, Measure, Manage. Voluntary, not law.
Governance begins before code is written, with the use case definition and impact assessment.
The use case definition captures: business objective, intended purpose, affected populations, data needs, ethical considerations, workforce readiness, and performance requirements.
A design-stage impact assessment evaluates potential harms, affected rights, risk severity/likelihood, mitigations, and residual risk. It is distinct from a DPIA, FRIA, and conformity assessment, all may be required for the same system.
Ethics by design means fairness, transparency, and human-oversight requirements are embedded in design specifications from the outset, not added at the end.
The probability/severity matrix (BoK-named) classifies risks by likelihood and severity; the standard interpretation prioritizes response as critical → manage → monitor → accept (the four labels are the common reading, not BoK text).
Data governance for AI requires assessing lawful rights to collect and use, and assessing data quality, quantity, integrity, fit-for-purpose, representativeness, and bias sources.
Data lineage = where data came from and how it was transformed. Data provenance = the origin and history of data including rights basis. Both are BoK III.B-named; exact definitions vary slightly across frameworks.
The full testing suite is: Unit, Integration, Validation, Performance, Security, Bias, Interpretability.
Train/validation/test split discipline: the test set must be held out and remain unseen until final evaluation. Using it during iteration is a governance failure.
Overfitting = high training performance, materially lower test performance. The model has memorized rather than generalized.
Bias testing evaluates whether the model produces systematically different outcomes for identifiable subgroups.
Interpretability testing evaluates whether outputs can be explained in terms meaningful to relevant audiences.
Release is a governance gate, a designated approver reviews documented evidence that all criteria are met. Passing tests is necessary but not sufficient.
A model card is an important transparency artifact at release (one of several, alongside technical documentation and instructions for use): intended use, performance, known limitations, ethical considerations, caveats for deployers.
Continuous monitoring covers performance, fairness, data drift, model/concept drift, error patterns, and usage patterns.
Data drift = inputs have changed distribution from training. Model/concept drift = the real-world relationship the model was trained to capture has changed. Both cause degradation; they have different diagnoses.
Periodic assessments (audits, red teaming, threat modeling, security testing) layer on top of continuous monitoring and go deeper.
Red teaming in AI includes bias elicitation, harmful-output testing, oversight-bypass attempts, and edge-case failure testing, not just cybersecurity probing.
An AI incident is an event where the system causes harm, violates law or policy, falls outside expected performance, or raises significant fairness/rights concerns.
The incident response sequence is: Detect → Contain → Assess → Remediate → Report → Learn.
BoK-named incident root causes: brittleness, lack of robustness, lack of quality data, insufficient testing, model drift, data drift.
Cross-functional collaboration for root-cause analysis is a BoK-explicit requirement, not optional.
Public disclosures to meet transparency obligations: the BoK III.C names technical documentation (for regulators), instructions for use (for deployers), and the post-market monitoring plan; model cards and user transparency notices are additional audience-specific artifacts the guide folds in.
Governance is continuous, from use-case definition through retirement. Deployment is the beginning of a new governance phase, not the end.
Adaptation techniques: as-is, fine-tuning, RAG, agentic, each with distinct governance costs.
Substantially modifying a third-party model (which some fine-tuning amounts to, and some does not) can make a deployer a provider, inheriting provider obligations.
RAG reduces fabrication and keeps knowledge current without retraining, but the retrieval source must be governed.
Agentic systems act in the world, they need stronger oversight, guardrails, and a stop control.
The deployer performs an in-context impact assessment (and a FRIA where applicable), distinct from the developer's.
Vendor contract terms to scrutinise: liability, data reuse, silent updates, audit rights, security, exit.
A liability disclaimer reallocates cost between companies; it does not transfer accountability to regulators or affected people.
Deploying your own proprietary model brings increased obligations and higher potential liability that is harder to transfer.
Deployment controls: data governance, risk management, issue management, user training.
Continuous monitoring covers performance, fairness, data drift, model/concept drift, error and usage patterns.
Data drift = inputs shifted; model/concept drift = the real-world relationship changed; a behaviour change with unchanged inputs suggests a silent vendor update.
Maintenance and retraining run on a schedule and on trigger.
Periodic assessment: audits, red teaming, threat modeling, security testing, deeper than continuous monitoring.
Post-market monitoring is a documented, forward-looking process, not just live dashboards.
On serious incidents, the provider commonly holds the primary reporting duty, but the deployer must notify the provider and comply with its own applicable obligations, never "do nothing."
Secondary and unintended uses must be forecast and controlled; validation for one purpose does not license reuse for another.
External communication plans (incident and stakeholder) are prepared in advance, who is told what, and how.
A deactivation / localization control is required regardless of validation, for suspension orders, malfunctions, exploitation, or performance failure.