Prepare for the AIGP by anchoring every domain to an AI system lifecycle you draw yourself, classifying the actor's role before listing any obligations, and separating risk management, impact assessment, bias evaluation, and monitoring by trigger, timing, and output. Rehearse these steps with worked scenarios and grade an end-to-end case against a written rubric to find your weakest domain.
Build Your Study Spine Around the AI System Lifecycle
Treat the AI system lifecycle as your filing system: every AIGP topic, from data governance to post-market auditing, attaches to a specific stage, so mapping the domains to stages turns six broad areas into one connected structure.
AI governance obligations and controls are stage-specific. Data provenance and quality questions concern collection and preparation; documentation and validation concerns arise at development; human oversight and disclosure attach at deployment; drift detection and incident response belong to operation. When a practice question presents an AI system, locate the stage in play before choosing an answer. A question about notifying affected workers and a question about model retraining may look similar on the surface, yet they belong to entirely different lifecycle phases with different actors and controls.
Build the map yourself rather than copying one. Draw the stages you can defend: problem definition and scoping, data sourcing and preparation, model development and validation, deployment, operation and monitoring, and retirement or decommissioning. Then assign each AIGP domain topic to at least one stage, and mark the stages where two topics overlap, such as risk management spanning development through operation. This map becomes your retrieval structure for flashcards, practice questions, and the end-to-end case at the end of this guide.
Learn the Technical Vocabulary AI Governance Work Assumes
Governance work leans on named technical concepts — training, validation, and test data; data provenance; model drift; feedback loops; foundation models — and you need each term's governance consequences, not model-building skill.
Each term carries a governance consequence. Data provenance connects to privacy, intellectual property, and quality risks in training data. A feedback loop, where user interactions feed back into the system, explains why a deployed model can change behavior without anyone editing code, which is precisely why monitoring exists as a governance control. Foundation models raise questions about upstream suppliers and limited control over training data that task-specific models may not. Knowing the mechanism lets you reason about the control; without it, technical scenarios become guesswork.
Drill with a two-column notebook: term on the left, governance consequence on the right. For example, validation data sits apart from training data so that performance claims are tested on unseen examples; the governance consequence is that unsupported performance claims signal a validation gap. When you miss a practice question, diagnose whether the miss was vocabulary or governance reasoning, and route it to the right column. Technical fluency here is definitional and applied, never implementation-level.
Compare Global Frameworks by Trigger and Required Output
Organize legislative and regulatory frameworks by three questions — who is bound, what triggers the obligation, and what artifact or conduct is required — instead of memorizing jurisdiction-by-jurisdiction lists that blur together under study pressure.
A risk-based framework such as the EU AI Act conditions obligations on risk classification and actor role, while principles-based instruments like the OECD AI Principles set expectations for trustworthy AI without binding enforcement in the same way. Sectoral rules, national strategies, procurement requirements, and professional codes apply more selectively still. The comparison skill is recognizing which type of instrument a scenario describes: binding risk-tiered regulation, principles guidance, or a sector-specific rule, because each implies a different compliance response.
Keep a one-line profile for each framework you study: addressees, trigger, and required output, such as documentation, transparency to affected people, or registration. Guard against cross-jurisdiction import — an obligation that exists under one framework does not transfer to another with a similar purpose. The IAPP's Global AI Law and Policy Tracker, referenced on iapp.org, illustrates how jurisdictions diverge; use such resources to see structure, and keep your profiles conservative where your source material is general.
Scenario One: Classify the Actor Role Before Listing Obligations
Before drafting any compliance response, establish whether the organization develops and supplies the AI system or deploys one built by another party, because role classification shapes nearly every duty that follows.
Scenario: a staffing firm buys a third-party résumé-ranking tool, adds its own branding, and begins shortlisting candidates. Its compliance lead starts assembling provider-style deliverables — technical documentation and pre-market conformity steps — before realizing the firm did not develop the system. The better sequence is to classify the role first: the firm deploys a system supplied by a vendor, so its duties center on using the system within its intended purpose, maintaining competent human oversight, and informing affected workers. It matters because the firm would build the wrong deliverable list while deployer duties go unaddressed.
Watch for role-shifting facts. Rebranding a product as your own, or substantially modifying a system, can move a party toward provider status depending on a framework's definitions. In drills, make role classification an explicit first step: ask who develops, who places the system into service, and who uses it in their own operations. Annotate every practice scenario with your role conclusion and a one-line rationale, so the habit holds when you face a fresh fact pattern.
Scenario Two: Pair Impact Assessments with Ongoing Risk Management
Impact assessments and risk management are distinct instruments: an assessment examines a specific system and context at a point in time, while risk management is a continuous, documented process spanning the lifecycle.
Scenario: a retailer launches a demand-forecasting tool that also flags employee productivity. The team completes an AI impact assessment at launch and files it. Months later, the model's inputs shift and employee complaints arrive, but nothing in the paperwork triggers review. The mistake was treating the assessment as a closed artifact. The better decision pairs it with a risk management process that owns thresholds for concern, re-assessment triggers after significant changes, and reporting lines for incidents.
The two instruments answer different questions at different moments. An impact assessment interrogates this system in this context — affected populations, decisions made, oversight arrangements — before harm occurs. Risk management runs continuously, feeding monitoring results back into treatment decisions. In practice questions, read the timing cue: facts set before deployment steer you toward assessment, while facts about changing behavior in operation point to risk management and monitoring. Use this table to keep the instruments separate:
| Instrument | Core question | Typical timing | Primary output | Natural owner |
|---|---|---|---|---|
| AI risk management process | What risks does this system create across its lifecycle, and how are they treated? | Continuous, from design through operation | Documented, iterative risk treatment and monitoring plan | Governance or risk function with the product team |
| AI / fundamental rights impact assessment | How does this deployment context affect people's rights and interests? | Before deployment, revisited on significant change | Context-specific assessment with mitigations and sign-off | Deployer or project owner |
| Bias / fairness evaluation | Does performance differ across affected groups? | Pre-deployment and re-evaluated after updates | Disaggregated performance results and remediation decisions | Model or data science team with governance review |
| Post-market monitoring | Is the system behaving as intended after release? | Ongoing operation | Monitoring metrics, incident records, review reports | Operations with governance oversight |
Convert Trustworthy AI Attributes into Observable Evidence
For fairness, transparency, and explainability, move beyond definitions: know how each attribute can conflict with the others and what evidence demonstrates that an organization actually addressed it.
Fairness is not a single metric: different fairness definitions can be incompatible with one another, so a governance answer must identify which fairness concern matters in context and demand disaggregated performance results rather than average accuracy. Transparency concerns disclosure — that people know they interact with an AI system and understand its limits. Explainability concerns reasons: the explanation owed to a data subject, an operator, and an auditor differ in depth and vocabulary, and a strong answer names its audience.
Exercise: for each attribute, write the artifact you would request as a reviewer. Fairness: performance broken down by relevant groups, plus a documented choice of fairness criteria. Transparency: user-facing notices and system documentation describing capabilities and limits. Explainability: sample explanations per audience, plus a note on why the chosen method suits the model type. Then test trade-offs: improving explainability of a complex model may reduce accuracy, and a scenario may ask which value the organization should prioritize and how to justify that choice.
Close the Loop: Monitoring Practice and Readiness Checks
Finish preparation by working one end-to-end paper case — from role classification through monitoring design — and grading yourself against a rubric, which reveals whether your knowledge connects or stays siloed by domain.
Exercise: take a paper scenario — a city housing agency using a third-party model to prioritize inspection requests — and produce, in under an hour: the actor roles with rationale; the lifecycle stage where each governance instrument applies; two fairness questions the deployment raises; and a monitoring plan naming metrics, a documented review cadence, and incident escalation. Expected observations: you should hesitate at exactly one or two steps, and those steps identify your weakest domain rather than a reason to restart your whole plan.
Grade each output 0–2: 2 means stated with rationale, 1 means stated without rationale, 0 means skipped. A learning milestone is that every item scores at least 1 and no domain scores 0 across two different cases; these are self-check milestones, not predictions of any exam result. Ready-to-sit signals: you classify roles unprompted, you distinguish the four instruments in the table from one-line fact patterns, and you can name a monitoring metric for any system you are shown.
- Classify provider and deployer roles for a fresh scenario, with a written rationale.
- Distinguish risk management, impact assessment, bias evaluation, and monitoring by trigger, timing, and output.
- Match each AIGP domain to at least one lifecycle stage on your own map, from memory.
- State one fairness definition, one way it conflicts with another, and the resulting governance consequence.
- Produce a monitoring plan for an unfamiliar system, including metrics, review cadence, and escalation.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.