How to pass AI Governance Professional (AIGP)

How this exam thinks

What each domain tests and how to study it

The AIGP blueprint is split across 4 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.

1. Understanding the foundations of AI governance

   21% of exam

   What you must be able to do. Apply the responsible AI principles and the developer-provider-deployer-user roles to a scenario, and place an oversight control at the correct life-cycle stage.

   In one sentenceThe conceptual base the rest of the exam assumes: what AI is, why its traits demand governance, the responsible AI principles, and who owns which role across the life cycle.

   Recall check: answer these from memory first

   • List the responsible AI principles, then apply two of them to a hiring model that screens CVs.
   • Distinguish the developer, provider, deployer, and user, and say which role owes the conformity assessment under the EU AI Act (the provider) and which owes due diligence and monitoring (the deployer).
   • Name two characteristics of AI (such as opacity or autonomy) that make a dedicated governance approach necessary, and why each one defeats ordinary IT controls.

   What it tests. The conceptual base of the whole exam: accepted definitions and types of AI, the risks and harms AI poses to individuals and society, and the characteristics of AI (opacity, autonomy, probabilistic outputs, speed and scale) that make a dedicated governance approach necessary. It also covers the common responsible AI principles, the stakeholder roles in a governance programme, how governance differs by organisation size and risk tolerance, and the policies that provide oversight across the AI life cycle.

   How to study it. Get the vocabulary exact first because every later domain leans on it, especially the developer-provider-deployer-user distinction, which decides who owes which obligation in countless scenario questions. Learn the responsible AI principles (fairness, safety and reliability, privacy and security, transparency and explainability, accountability, human-centricity) as a checklist you can apply to any case. Treat the AI life cycle as a loop with named stages, since questions routinely test which stage a control belongs to.

   Easy to confuse

   • Provider versus deployer. The provider builds or substantially modifies the system and places it on the market under its own name, owning design-stage duties like the conformity assessment and technical documentation; the deployer puts it into use under its own authority and owns due diligence, human oversight, and monitoring. A developer that only builds becomes the provider once it places the system on the market. Most scenarios cast you as the deployer, so the build-stage obligations are usually the wrong answer.
   • Transparency versus explainability. Transparency is disclosing that AI is in use and how it works at a system level; explainability is making a specific output understandable to a person affected by it. A chatbot disclosure satisfies transparency; a reason for a declined loan satisfies explainability.
   • AI principle versus legal obligation. A responsible AI principle (fairness, accountability) is an ethical commitment; a legal obligation (a DPIA, a conformity assessment) is a binding requirement under a named law. The exam tests whether a scenario calls for a principle to apply or a specific statutory duty to discharge.

   Worked example from the AIGP bank

   lock_openFree sampleUnderstanding the foundations of AI governanceeasy

   A facilities team builds a heating controller whose behaviour is fixed entirely by rules a programmer wrote, such as switching the boiler on whenever a sensor reads below 18 degrees. A governance lead is asked why this controller does not meet the widely used OECD and EU AI Act definition of an AI system. Which characteristic, present in that definition, does the controller lack?

   • AIt infers from the inputs it receives how to generate outputs such as predictions or decisions, rather than only executing rules a human wrote.check_circle Correct
   • BIt runs continuously rather than only when an operator manually triggers each individual action through the interface.
   • CIt connects to the internet so that it can transmit its sensor readings to a remote server for storage.
   • DIt stores a historical log of past temperature readings that an engineer can later download and inspect.

   An AI system, under the OECD and EU AI Act definition, infers outputs from inputs rather than only executing human-written rules. The shared OECD and EU AI Act definition hinges on inference: the system derives outputs such as predictions, recommendations or decisions from the input it receives, which distinguishes it from deterministic software whose every response is hand-coded by a programmer.

   Why A is correct: The OECD and EU AI Act definition centres on a system that infers from input how to produce outputs like predictions, content, recommendations or decisions, which a fixed rules-only controller does not do.

   Why B is wrong: Running continuously is tempting because people associate AI with always-on services, but autonomous scheduling is not what the definition turns on, and many simple automated devices run continuously without being AI.

   Why C is wrong: Network connectivity sounds modern and AI-like, yet the definition says nothing about connectivity, and an offline model is still AI while a connected thermostat is not.

   Why D is wrong: Keeping a data log feels relevant because AI uses data, but merely recording readings is passive storage and is not the inference of outputs that the definition requires.

2. Understanding how laws, standards and frameworks apply to AI

   25% of exam

   What you must be able to do. Classify a system into its EU AI Act risk tier, recall the obligation that tier triggers, and name the framework or standard (NIST AI RMF, ISO/IEC 42001, 42005) that fits a stated need.

   In one sentenceHow existing privacy law and AI-specific regimes apply to AI, plus the EU AI Act risk tiers and the NIST, OECD, and ISO frameworks you must match to a need.

   Recall check: answer these from memory first

   • Name the four EU AI Act risk tiers in order and give one example system in each.
   • State the headline obligations for a high-risk system under the EU AI Act: name three.
   • Say in one line each what the NIST AI RMF, ISO/IEC 42001, and ISO/IEC 42005 are for.

   What it tests. How existing and AI-specific law and the major frameworks apply to AI systems. This spans privacy law concepts (transparency, lawful basis, purpose limitation, data minimisation, privacy by design, automated decision making), controller obligations such as DPIAs, cross-border transfers, data subject rights and breach notification, and adjacent regimes covering intellectual property, nondiscrimination, consumer protection and product liability. It then tests the EU AI Act risk classification (prohibited, high, limited, minimal), its key requirements, other AI laws such as the South Korean AI Basic Law, and the OECD principles, the NIST AI RMF, and ISO 22989, 42001 and 42005.

   How to study it. This is one of the heavier domains, so give it real time. Build a one-line mental summary of each named instrument: what the NIST AI RMF organises around, what ISO 42001 certifies, what ISO 42005 covers, what the OECD principles assert. Drill the EU AI Act risk tiers until you can classify a system on sight and recall the headline obligations for high-risk systems (human oversight, technical documentation, conformity assessment). Map privacy concepts you may already know onto AI contexts rather than relearning them from scratch.

   Easy to confuse

   • Prohibited versus high-risk (EU AI Act). Prohibited practices (social scoring, untargeted scraping of facial images to build recognition databases, most real-time biometric identification in public) are banned outright; high-risk systems are allowed but heavily regulated with conformity assessment, oversight, and documentation. If the scenario asks what controls make it compliant it is high-risk; if it asks whether it may run at all it is prohibited.
   • NIST AI RMF versus ISO/IEC 42001. The NIST AI RMF is a voluntary, outcome-based framework organised around govern, map, measure, and manage; ISO/IEC 42001 is a certifiable management-system standard you can be audited against. Reach for the RMF to structure risk work, for 42001 when the scenario wants formal certification.
   • GDPR DPIA versus EU AI Act conformity assessment. A DPIA assesses risk to personal data and rights under privacy law; a conformity assessment proves a high-risk AI system meets the AI Act before it goes to market. They can both apply to one system, but they answer different laws, so match the obligation to the regime named in the scenario.

   Worked example from the AIGP bank

   lock_openFree sampleUnderstanding how laws, standards and frameworks apply to AIhard

   A provider is preparing a high-risk recruitment-screening system for the EU market and is allocating the human oversight obligations under the EU AI Act. The deploying employer insists that oversight is purely its own concern once the system is purchased. How does the EU AI Act actually allocate the human oversight duty for a high-risk system?

   • AOnly the deployer bears any oversight duty, because oversight happens during use and the provider's responsibility ends once the system is placed on the market.
   • BThe provider must design the system so that natural persons can effectively oversee it, and the deployer must then assign competent persons with the authority to intervene.check_circle Correct
   • COversight may be delegated entirely to an automated monitoring component, so no identified natural person needs the authority to intervene in individual decisions.
   • DHuman oversight is only recommended guidance for high-risk systems, so a provider that documents strong testing may omit oversight measures altogether.

   Recognise that human oversight of a high-risk EU AI Act system is a shared duty: the provider designs it in and the deployer staffs it. Under the EU AI Act, human oversight is not a single party's job. The provider must design and build the high-risk system with oversight measures so that natural persons can monitor it, interpret its output, and intervene or stop it. The deployer must then assign people who are competent, trained, and given the authority to exercise that oversight in real use. Because the obligation spans design and operation, it cannot rest on the deployer alone, be handed to an automated component, or be skipped on the strength of testing.

   Why A is wrong: This matches the employer's intuition and the fact that oversight occurs in operation, but it is wrong because the provider must build oversight measures into the system before placing it on the market, so the duty is shared rather than the deployer's alone.

   Why B is correct: Article 14 requires the provider to build in oversight measures appropriate to the risks and the deployer to entrust oversight to people who are competent and empowered to act, so responsibility runs across both roles.

   Why C is wrong: Automated monitoring is attractive because it scales, but it contradicts the Act's premise that effective oversight is exercised by natural persons who can understand and override the system, not by another automated layer.

   Why D is wrong: Treating oversight as optional is tempting where validation looks rigorous, but for high-risk systems oversight is a binding requirement that testing cannot substitute for, so omitting it is non-compliant.

3. Understanding how to govern AI development

   27% of exam

   What you must be able to do. Place a development control at the correct stage, pick the testing type that catches a stated defect, and tell data drift from model drift in a monitoring scenario.

   In one sentenceGoverning a system you build through design, data, testing, release, and monitoring, with controls that must sit at the right life-cycle stage.

   Recall check: answer these from memory first

   • Put the development stages in order from business context to post-market monitoring, and say where the model card belongs.
   • Match each defect to its test: a discriminatory outcome, a prompt-injection weakness, a black-box output you cannot explain.
   • Define data drift and model drift in one line each, and say which control detects them after release.

   What it tests. Governing an AI system through design, build, and release. It covers defining the business context and running impact assessments, applying ethics by design, and managing internal and external risks with tools such as harm probability and severity matrices, risk mitigation hierarchies and stakeholder mapping. It includes data governance for training and testing (lawful rights to data, data quality, lineage and provenance), the testing programme (unit, integration, validation, performance, security, bias and interpretability), release governance such as model cards and conformity, and ongoing monitoring, audits, red teaming and incident handling including model and data drift.

   How to study it. This is a top-weighted domain, so spend the most time here alongside the deployment domain. Learn the development life cycle as an ordered sequence and be able to place any control in the correct stage, because the exam often asks what should happen next or what was skipped. Memorise the testing types and what each catches, and keep drift clear in your head: data drift is the input distribution shifting, model drift is degrading performance over time, and both demand continuous monitoring rather than a one-off sign-off.

   Easy to confuse

   • Data drift versus model drift. Data drift is the input distribution shifting away from the training data; model drift (concept drift) is the model's predictive accuracy degrading as the world changes. Retraining on fresh data addresses drift; the scenario's symptom tells you which one is in play.
   • Bias testing versus interpretability testing. Bias testing checks whether outcomes differ unfairly across groups; interpretability testing checks whether a human can understand why the model produced a given output. One protects fairness, the other protects explainability, and the exam keys the answer to which the scenario is worried about.
   • Validation testing versus a model card. Validation testing is an activity during build that confirms the model meets its requirements; a model card is a release artefact that documents the model's purpose, performance, and limitations for downstream users. A test proves readiness; the card communicates it, and they sit at different stages.

   Worked example from the AIGP bank

   lock_openFree sampleUnderstanding how to govern AI developmentmedium

   A bank collected customer transaction records under a privacy notice that stated the data would be used to operate accounts and detect fraud. The data science team now wants to reuse those same records to train a marketing propensity model. Under the GDPR principle of purpose limitation, what must the team establish before proceeding on this basis?

   • AThat the marketing model will, as a secondary benefit, improve the accuracy of the existing fraud detection model for the same customers
   • BThat the records have been pseudonymised so that direct identifiers are replaced with tokens before training begins
   • CThat the new marketing purpose is compatible with the original purposes, or otherwise obtain a fresh lawful basis such as consent for the reusecheck_circle Correct
   • DThat the resulting model will be evaluated for demographic bias before any marketing campaign is launched

   Recognise that reusing personal data for a new AI training purpose requires a compatibility assessment or a fresh lawful basis under GDPR purpose limitation. GDPR purpose limitation restricts data to the purposes specified at collection. Further processing for a new purpose is lawful only if that purpose is compatible with the original one, judged on factors such as the link between purposes, the context, and reasonable expectations. Where the new purpose is not compatible, as a marketing model usually is not relative to fraud detection, the controller must obtain a separate lawful basis such as consent before training on the data.

   Why A is wrong: This is tempting because linking the new use to the original fraud purpose sounds like a compatibility argument, but a marketing propensity model is a distinct commercial objective, so an incidental fraud benefit does not make the marketing use lawful under the original notice.

   Why B is wrong: Pseudonymisation is a useful safeguard and can support a compatibility assessment, but on its own it does not authorise a new incompatible purpose because pseudonymised data remains personal data subject to purpose limitation.

   Why C is correct: Purpose limitation permits further processing only where it is compatible with the purposes for which data was collected, and where it is not compatible the controller must secure a separate lawful basis such as fresh consent before reusing the records.

   Why D is wrong: Bias evaluation is good governance and may be required for fairness, but it addresses model outputs rather than the lawfulness of reusing the data, so it does not resolve the purpose limitation question about whether the reuse is permitted at all.

4. Understanding how to govern AI deployment and use

   27% of exam

   What you must be able to do. Reason from the deployer's seat: choose the right model type and fit technique, evaluate vendor and licensing risk, and decide when to pause, localise, or shut a deployed system down.

   In one sentenceGoverning AI you adopt rather than build, where vendor due diligence, the right fit technique, and incident and deactivation policy decide the answer.

   Recall check: answer these from memory first

   • Say when retrieval augmented generation beats fine-tuning, and name one risk an agentic architecture adds.
   • List three terms in a vendor or licensing agreement a deployer must check before adopting a proprietary model.
   • Give two conditions under which a deployed AI system should be paused, localised, or deactivated.

   What it tests. Governing the deployment and use of AI you did not necessarily build. It covers evaluating a deployment use case (business objectives, performance needs, data availability, workforce readiness), comparing model types (classic versus generative, proprietary versus open source, small versus large, unimodal versus multimodal), and deployment options across cloud, on-premise and edge plus fit techniques such as fine-tuning, retrieval augmented generation and agentic architectures. It then tests vendor and licensing risk, impact assessment on a chosen system, operational governance (user training, continuous monitoring, periodic audits), and managing incidents, downstream harms, external communication, and policies to deactivate or localise a system.

   How to study it. This domain is weighted equally with development, so treat the pair as the core of your revision. Anchor on the deployer's perspective: most scenarios put you in the shoes of an organisation adopting a third-party or proprietary model, so vendor due diligence, licensing terms and contractual risk allocation matter. Know when retrieval, fine-tuning or an agentic design is the right fit, and be ready to reason about downstream and secondary harms and the conditions under which a deployed system should be paused, localised or shut down.

   Easy to confuse

   • Fine-tuning versus retrieval augmented generation. Fine-tuning retrains the model's weights on your data to change its behaviour; RAG leaves the model fixed and feeds it your data as context at query time. RAG suits fresh or proprietary knowledge you must keep current; fine-tuning suits a durable change in style or task.
   • Proprietary versus open-source model risk. A proprietary model concentrates risk in the vendor relationship: licensing terms, data handling, and lock-in; an open-source model shifts risk to you for security, maintenance, and provenance of the weights. The scenario's risk type points to which model class it is testing.
   • Deactivation versus localisation. Deactivation shuts the system down entirely; localisation restricts or adapts it for a specific jurisdiction or context while keeping it running. Reach for deactivation when the harm is unacceptable everywhere, for localisation when the problem is confined to one market or use.

   Worked example from the AIGP bank

   lock_openFree sampleUnderstanding how to govern AI deployment and useeasy

   A governance lead is categorising the AI systems in use across a bank. One system drafts new marketing copy from a short brief, while another scores loan applications as approve or decline. What distinguishes the copywriting system as generative rather than classic AI?

   • AIt produces new content by sampling from patterns it has learned, whereas the classic system assigns inputs to predefined outcome categories.check_circle Correct
   • BIt runs on cloud infrastructure, whereas classic systems are always installed and operated entirely on local hardware.
   • CIt was trained on labelled examples, whereas classic systems are built only from unlabelled data with no human supervision.
   • DIt guarantees factually accurate outputs on every request, whereas the classic system can return scored predictions that are occasionally incorrect.

   Distinguish generative AI, which creates new content, from classic AI, which classifies or predicts from fixed categories. Classic AI is typically discriminative: it learns a boundary that maps an input to one of a set of predefined outcomes, such as approve or decline. Generative AI learns the underlying distribution of its training data and samples from it to produce new content such as text or images. The defining contrast is creating novel output versus selecting among fixed categories, not where the system runs or how accurate it is.

   Why A is correct: Generative AI synthesises novel artefacts such as text by modelling the data distribution, while classic discriminative AI maps an input to one of a fixed set of labels such as approve or decline.

   Why B is wrong: Deployment location is tempting because hosting often differs in practice, but where a model runs has no bearing on whether it is generative or classic; both kinds run on cloud or local hardware.

   Why C is wrong: This inverts the truth and is tempting because supervision is a real distinction; many classic classifiers use labelled data, and generative models often learn in a self-supervised way, so the contrast is wrong.

   Why D is wrong: This is tempting because accuracy matters to governance, but generative models do not guarantee correctness and can hallucinate, so reliability does not define the generative category.

A study plan that works

1. Map the blueprint and set a date

   Day 1

   Read the official IAPP Body of Knowledge and the four domains with their weights. Book a provisional exam date now: a fixed date converts open-ended study into a plan and is the strongest predictor of actually sitting the exam.

2. Lock the foundations (Domain 1)

   Week 1

   Get the definitions, the responsible AI principles, and above all the developer-provider-deployer-user roles solid before anything else, because the law and life-cycle domains assume them. Aim to recite the principles and roles without notes.

3. Build the legal and framework map (Domain 2)

   Weeks 2-3

   Work through privacy-law-applied-to-AI, the EU AI Act risk tiers and obligations, and the NIST, OECD and ISO frameworks. Make a single-page summary that names each instrument and its core purpose, then test yourself by classifying example systems into risk tiers.

4. Go deep on the two life-cycle domains (Domains 3 and 4)

   Weeks 3-4

   Development and deployment carry the most weight and overlap heavily. Spend the bulk of your time here on impact assessments, the testing programme, model cards, monitoring and drift, vendor and licensing risk, and incident and deactivation policy. Use scenario questions, not flashcards alone.

5. Practise on scenarios with worked explanations

   Week 5

   Move to full practice sets and read the explanation for every question, including those you got right. The exam tests judgement between plausible options, so understanding why a distractor is wrong for the stated context is where the marks are.

6. Find and close your weak domains

   Week 5

   Use per-domain accuracy to drill the areas dragging you down rather than re-reading what you already know. Repeat until every domain clears the pass line with margin, paying particular attention to the role and risk-tier distinctions that trip people up.

7. Sit a timed mock and review it

   Week 6

   Take at least one full timed mock to rehearse pacing and the flag-and-return habit across the time limit. Treat the score as a readiness signal, then review every missed question before booking or sitting the real exam.

Know when you're ready

Exam-day tips

• Read the last line of the question first. It tells you what is actually being asked, so you can read the scenario hunting for the answer rather than absorbing every detail.
• Identify the actor and the role before you choose. Whether the scenario casts you as developer, provider, deployer or user usually decides which obligation or control is correct.
• Pin the life-cycle stage. Many options are right controls in the wrong place, so ask whether this is a design, build, release, or post-market problem before answering.
• Classify the risk tier early. For EU AI Act scenarios, settling whether a system is prohibited, high, limited or minimal risk often eliminates half the options at once.
• Watch for absolutes such as always, never, guarantees, and fully automated with no oversight. In governance scenarios these are usually wrong because AI is probabilistic and human oversight is a recurring requirement.
• Flag and move on. Do not burn time on one hard item when easier marks are waiting; cover every question first, then return to the flagged ones.
• Eliminate two options fast. Most questions carry two clearly weaker choices; removing them turns a guess into a coin flip at worst.

Frequently asked questions

Related certifications

Other Ai certifications with a study guide.

• AWS Certified AI Practitioner (AIF-C01) study guideAmazon Web Services
• NVIDIA-Certified Associate: Generative AI LLMs (NCA-GENL) study guideNVIDIA
• NVIDIA-Certified Associate: AI Infrastructure and Operations (NCA-AIIO) study guideNVIDIA
• NVIDIA-Certified Associate: Generative AI Multimodal (NCA-GENM) study guideNVIDIA
• NVIDIA-Certified Associate: Accelerated Data Science (NCA-ADS) study guideNVIDIA
• Google Cloud Professional Machine Learning Engineer (PMLE) study guideGoogle Cloud
• GitHub Copilot (GH-300) study guideGitHub