Govern the designing and building of the AI system.
- ✓Plan in the IAPP order: problem, use case, laws, gaps and risks, then data.
- ✓Make the business case (why AI, costs and benefits) and check feasibility (technical, data, organizational readiness).
- ✓A good use case names purpose, users, affected people, setting, success measures and boundaries.
- ✓Documented approved uses are your defense against scope creep.
- ✓By-design activities belong in planning and design, never after deployment.
- IAPP planning order:
- Business problem → use case → applicable laws → gaps and risks → data needed.
- Use case:
- A specific description of what an AI system will do, for whom, in what setting, and within what boundaries.
- Baseline:
- How the task performs today without the AI, used to judge whether the system is actually an improvement.
- Scope creep (function creep):
- Gradual expansion of a system into uses that were never assessed or approved.
- MAP function (NIST AI RMF):
- The NIST function that establishes context: intended purpose, settings, laws, norms and potential impacts.
- Business case:
- The argument for an AI project: the problem, why AI beats simpler options, measurable objectives, and direct and indirect costs weighed against benefits.
Exam tips: Ordering questions: business problem → use case → applicable laws → gaps and risks → data. Any option that starts with data, vendors or models is a trap. · Watch FIRST vs. NEXT. If the stem says the problem and use case are already defined, the answer is 'identify applicable laws', not 'determine the business problem'. · Laws attach to the use and the jurisdiction, never to the tech stack or the cloud provider. · 'A simpler, non-AI solution fits better' can be the BEST answer. A business case asks 'why AI?', and a failed feasibility check (technical, data, organizational readiness) is a valid reason to stop.
- ✓Perform or review an impact assessment before building; reassess after significant changes, after incidents and on a schedule.
- ✓Its job is to locate the greatest risks so mitigation is targeted.
- ✓AI impact assessment, DPIA and FRIA overlap but have different scopes and owners.
- ✓Good documentation covers stakeholders, affected demographics, technical choices, harms and mitigations.
- AI impact assessment:
- A structured review, done before build and revisited over time, of how an AI system could affect people, groups and society.
- DPIA:
- GDPR's data protection impact assessment, required of controllers before personal-data processing likely to result in high risk.
- FRIA:
- The EU AI Act's fundamental rights impact assessment, a duty on certain deployers of high-risk systems before first use.
- ISO/IEC 42005:
- International guidance (2025) on how to conduct AI system impact assessments across the life cycle.
Exam tips: Timing tell: impact assessments happen BEFORE build and deployment. 'After launch, once we have real data' is the wrong-stage trap. · 'The DPIA already covers it' is synonym bait. Privacy is one slice of AI impact. · FRIA = deployer. A vendor's conformity assessment never discharges the deployer's own FRIA. · LEAST-necessary questions: stakeholder concerns, demographics and algorithm details stay. Budgets and marketing plans go.
- ✓Turn AI principles into concrete requirements during design.
- ✓Requirements cover what the system does and how it must behave.
- ✓Model selection weighs explainability, complexity, control and security, and the rationale is recorded.
- ✓Check data availability, representativeness and proxies before committing to a design.
- ✓Diverse teams catch biased assumptions early.
- Ethics by design:
- Building ethical requirements into an AI system from the plan-and-design phase rather than reviewing them at launch.
- Requirements gathering:
- Collecting what a system must do and how it must behave, including legal, fairness, privacy and explainability needs.
- Interpretable model:
- A model whose decision logic people can follow directly, such as a scorecard or a small decision tree.
- Proxy variable:
- A seemingly neutral input, like postcode, that stands in for a protected trait, like ethnicity.
- Build, buy or adapt:
- The choice between training your own model, buying a vendor system and fine-tuning an existing model.
Exam tips: Design-stage bias question? A diverse, cross-functional team beats 'collect more data' and 'buy a fairness toolkit'. · Accuracy vs. explainability: the BEST answer weighs the trade-off with evidence and documents it. It doesn't let one metric decide. · 'Purpose of AI' includes asking whether AI is needed at all. · Any ethics-by-design step scheduled 'at deployment' or 'after an incident' is the wrong-stage trap.
- ✓In, on, out of the loop: pick by severity, reversibility and volume. Human-in-command sits above all three.
- ✓Automation bias can hollow out human review, so design against it.
- ✓Set performance, fairness, confidence and action thresholds before building.
- ✓Feedback channels and operational controls (override, stop, fallback, escalation, logging) are designed in, not added later.
- Human-in-the-loop:
- A person reviews or approves each AI output before it takes effect.
- Human-on-the-loop:
- The AI acts on its own while a person monitors and can intervene or override.
- Human-out-of-the-loop:
- The AI operates fully automatically with no real-time human involvement.
- Automation bias:
- The tendency to over-rely on automated outputs, even when they are wrong.
- Operational controls:
- Mechanisms built into a running system, such as overrides, stop functions, fallbacks, escalation thresholds and logs, that let humans steer it.
- Human-in-command:
- Oversight in which people decide whether, when and how an AI system is used at all, and can overrule or switch it off.
Exam tips: 'By design' in the stem points to controls specified during design: overrides, thresholds, feedback channels. 'Sort out oversight after launch' is the trap. · An annual or periodic audit is NOT an operational control. It's assurance after the fact. · A human who approves everything isn't oversight. Look for designs that force independent judgment, like rating before seeing the AI's answer. · Match oversight to severity and reversibility. 'Remove humans because the model beats the benchmark' is an absolute-abdication trap.
- ✓Risks and contributing factors come from inside and outside the organization.
- ✓Probability × severity ranks harms against risk tolerance; AI severity includes scale and reversibility. Respond by corner: act, mitigate, plan for contingencies, or review.
- ✓Prohibitive, major, moderate: unacceptable risk means stop safely until it's managed.
- ✓Stakeholder mapping finds the high-impact, low-influence groups.
- ✓Mitigation hierarchy: avoid, reduce, restore, compensate, in that order of preference.
- Harms matrix:
- A probability × severity grid used to rank potential harms so the worst get attention first.
- Risk tolerance:
- The level of risk an organization is willing to accept in pursuit of its goals.
- Risk mitigation hierarchy:
- An ordered preference for responses: avoid the risk, then reduce it, then restore, and compensate as a last resort.
- Stakeholder mapping:
- Identifying everyone affected by or influencing a system, including people who never use it.
- Residual risk:
- The risk that remains after mitigations are applied, which must be accepted, transferred or further treated.
- Contributing factor:
- A condition, such as a rushed timeline or skills gap, that makes harm more likely or more severe.
Exam tips: The matrix RANKS, the hierarchy picks the RESPONSE, the stakeholder map shows WHO is affected (including people who never touch the system). If the stem asks how to respond to ranked risks, the answer is the hierarchy. · HIGHEST in the hierarchy = avoid or eliminate at source. Disclaimers, warnings, insurance and compensation sit low. · Rare but catastrophic → contingency plan, never 'ignore'. Unacceptable (prohibitive) risk → NIST says cease development or deployment in a safe manner until it's managed. · Quantifying risk never makes an organization 'immune', and AI risks belong in the same enterprise risk register as cyber and privacy risks.
- ✓Use-case evaluation asks whether to proceed, and repeats whenever the use changes.
- ✓Benchmark against a baseline and break results down by group.
- ✓Pilots are limited, criteria-driven trials with real users and an exit plan.
- ✓Document purpose, requirements, assessments, trade-offs, oversight and evidence as you go.
- ✓Documentation establishes compliance, manages risk and preserves accountability.
- Use-case evaluation:
- Assessing whether a specific use of AI is lawful, beneficial and within risk tolerance before proceeding, and again whenever the use changes.
- Benchmarking:
- Comparing a system's performance offline against a reference such as the current process, another model or a standard test set.
- Pre-deployment pilot:
- A limited, controlled trial with real users and pre-agreed success criteria before the go/no-go decision.
- Shadow mode:
- Running an AI alongside the existing process so its outputs can be compared without driving real decisions.
- Technical documentation (EU AI Act):
- The record a high-risk system's provider must prepare before placing it on the market and keep up to date.
Exam tips: Real users + realistic conditions + before go/no-go = pilot. Offline comparison = benchmarking. Live production data = post-deployment. · Same model, new use → new evaluation and assessment. 'Just update the model card' is too narrow. · Documentation questions reward the option that captures the WHY (rationale, alternatives, trade-offs), recorded at the time. · A benchmark win never 'proves' a system safe or 'permanently' settles anything.
- ✓HUDERIA, EU AI Act Art. 9(5), ISO/IEC Guide 51 and the hierarchy of controls all rank designing the risk out first and warning, remedying or accepting last.
- ✓NIST's avoid/mitigate/transfer/accept and the four Ts are menus of the same options; transfer never protects the affected person.
- ✓Incident orders vary, but all prepare, contain early, preserve evidence, notify on time and learn last.
- ✓Performance testing = speed and scale; validation testing = meets requirements, including accuracy.
- EU AI Act Art. 9(5) order:
- For high-risk providers: eliminate or reduce risks by design, then add mitigation and control measures, then give deployers information and, where appropriate, training.
- ISO/IEC Guide 51 three-step method:
- The safety-standards order for reducing risk: inherently safe design, then protective measures, then information for use.
- Four Ts:
- A business risk-response menu: treat, transfer, tolerate or terminate.
- Risk transfer:
- Shifting a risk's financial consequences to another party, such as an insurer or contractor; it doesn't reduce the harm to affected people.
- Performance testing:
- Testing whether a system meets speed and scale targets, such as latency, throughput and resource use under load.
Exam tips: Different ladders, same direction: design it out → control it → warn, train, remedy or accept. Pick the option on the highest tier, whichever vocabulary it uses. · Transfer (insurance, contracts) moves cost, not harm. It is never the BEST answer for protecting the people affected. · Incident lists differ, but containment comes early when harm is ongoing, evidence is preserved, notification runs in parallel and lessons come last. An early 'communicate' step means internal escalation. · 'Performance testing' on the exam usually means speed and scale (latency, throughput, load). Accuracy, precision and recall against requirements belong to validation.
- ✓Engagement process: salience, diversity, positionality, level, methods, AI actors, communication plans.
- ✓Match engagement depth to impact: inform, consult, involve or collaborate, empower.
- ✓Optionality keeps alternatives, including non-AI ones, genuinely available.
- ✓Redress means people can contest, reach a human who can change the outcome, and get things put right.
- Stakeholder salience:
- How much weight a stakeholder's voice should get, judged by power, legitimacy, urgency and how heavily the system affects them.
- Positionality exercise:
- A structured reflection in which a team states how its members' backgrounds and roles shape what they notice, to surface blind spots before design choices.
- Optionality:
- Keeping feasible alternatives open, including non-AI options and opt-outs to a human route, and avoiding lock-in.
- Redress:
- The means for people to report, contest and get correction of an AI system's harmful or wrong outcomes, designed in from the start.
Exam tips: Salience isn't just power: a low-influence group facing severe impact ranks high. Options that only engage the vendor, executives or business partners are traps. · Positionality = how the team's own backgrounds shape what it sees. The fix is diverse voices and stated vantage points, not 'more data'. · Optionality includes a non-AI option (NIST MANAGE 2.1) and, where feasible, an opt-out to a human route with equal service. · Redress is designed in: contest, human review with power to change the outcome, correction, the ability to halt. Disclaimers or compensation alone aren't redress.
Independent study aid, not affiliated with the IAPP. Written with AI from primary sources; laws change, so check the sources. Last updated 7 Nov 2026.
AIGP Quest