Examworthyexamworthy.comAI Governance Professional (AIGP) cheat sheet
IAPP
Free to share. Examworthy is not affiliated with or endorsed by IAPP; AIGP and related marks belong to their respective owners.
At a glance
Format: Multiple choice, online proctored or test centre (Pearson VUE)
Domain weight map
Heaviest first - spend your time hereHow this exam thinks
The exam rewards judgement over memorisation: match the right governance response to the right actor, risk tier, and life-cycle stage.
Spot the trap
Tempting wrong answers, and why they failTempting but wrong
Reusing fraud-detection data to train a marketing model is fine because the marketing model will, as a side benefit, improve fraud detection for the same customers.
Why it fails
An incidental fraud benefit does not make the marketing use lawful. A marketing propensity model is a distinct commercial objective, so linking it loosely to the original fraud purpose is not a valid compatibility argument. The reuse still needs a compatibility finding or a fresh lawful basis such as consent.
Understanding how to govern AI development
Tempting but wrong
Is generative AI distinguished by training on labelled examples while classic systems use only unlabelled data?
Why it fails
No, this inverts the truth. Many classic classifiers train on labelled data, and generative models often learn in a self-supervised way. Supervision is a real distinction but it does not separate generative from classic AI. The real contrast is creating new content versus classifying into fixed categories.
Understanding how to govern AI deployment and use
Tempting but wrong
Once a high-risk system is placed on the market, oversight is purely the deployer's concern and the provider's role has ended.
Why it fails
Wrong. The provider must build oversight measures into the system before placing it on the market, so the duty is shared. Oversight does occur during use, but it depends on design features the provider is obliged to create, so it never rests on the deployer alone.
Understanding how laws, standards and frameworks apply to AI
Tempting but wrong
Keeping a historical log of past readings that an engineer can inspect is enough to make a controller an AI system.
Why it fails
Recording data is passive storage, not inference. The definition requires the system to infer outputs such as predictions or decisions from its inputs. Merely logging temperature readings does no such inference, so it does not meet the definition.
Understanding the foundations of AI governance
Tempting but wrong
Pseudonymising transaction records before training is enough to authorise reusing them for a new marketing purpose under GDPR.
Why it fails
Pseudonymisation is a useful safeguard and can support a compatibility assessment, but on its own it does not authorise a new incompatible purpose. Pseudonymised data is still personal data subject to purpose limitation, so a compatibility finding or fresh lawful basis is still required.
Understanding how to govern AI development
Tempting but wrong
Should use-case framing begin by fixing the exact transformer architecture and parameter count to deploy?
Why it fails
No. Architecture details are an implementation concern that follows from the objective and requirements. They should not be fixed before the problem itself is defined. Framing starts with the business objective and the measurable outcome to improve.
Understanding how to govern AI deployment and use
Tempting but wrong
A general-purpose model below the systemic-risk threshold must be registered as high-risk and pass a third-party conformity assessment.
Why it fails
Wrong. This conflates the GPAI model regime with the separate high-risk system regime. Conformity assessment applies to high-risk systems, not to a sub-threshold general-purpose model, which owes only baseline documentation and copyright duties.
Understanding how laws, standards and frameworks apply to AI
Tempting but wrong
A chatbot that can hold a conversation across many everyday subjects is therefore artificial general intelligence.
Why it fails
Breadth of small talk is not generality. General AI denotes human-level competence across arbitrary tasks, not just conversing on many topics. A bot trained only for support and failing outside that scope remains narrow AI.
Understanding the foundations of AI governance
Key terms
Exam-day rules
- 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.
Revision schedule
- Day 1Map the blueprint and set a date
- Week 1Lock the foundations (Domain 1)
- Weeks 2-3Build the legal and framework map (Domain 2)
- Weeks 3-4Go deep on the two life-cycle domains (Domains 3 and 4)
- Week 5Practise on scenarios with worked explanations