Where AI Design Risk Hides
Ask an AI governance team when their risk work begins and the answers scatter. Some start at the pilot. Some start at the model card, days before release. AI design risk is settled long before either of those, in the room where somebody decides what the system will do and to whom. The AIGP exam knows this, and it writes questions accordingly.
Why AI design risk starts before the first line of code
Domain III of the AIGP Body of Knowledge covers governing AI development. The Body of Knowledge is the blueprint the IAPP publishes for what the exam may test; every question maps to a line in it, and one of those lines asks you to identify and manage the internal and external risks that come with designing and building an AI model.
Regulators take the same view. Article 9 of the EU AI Act requires a risk management system for high-risk AI systems that is established, implemented, documented and maintained, and it describes that system as a continuous iterative process running across the whole lifecycle. The lifecycle starts at design. So does the obligation.
Internal and external risk are two different lists
Internal risk lives inside your control: data that does not fit the purpose, an architecture chosen for speed, a team with no domain expert in it. External risk lands on people who never touch the system, on the deployer who buys it from you and on the regulator who reads about it later. Stakeholder mapping exists to produce the second list, because nobody in the build meeting is on it.
Scenario questions load the stem with internal detail and hide one external contributing factor in a subordinate clause. The distinction being marked is whether you noticed who was outside the room.
Ranking AI design risk on probability and severity
The probability and severity harms matrix does one job: it stops the loudest risk from winning. Severity asks how bad the outcome is for the person on the receiving end, and whether it can be undone. Probability asks how often the outcome occurs. The two axes are independent, and treating them as one number is the fastest way to lose a mark.
A rare, irreversible harm to a small group outranks a frequent, trivial annoyance to everyone. Candidates who average the axes reverse that order and pick the tidy answer.
What the matrix is for
Ranking is not the same as reducing. The matrix tells you where to spend the mitigation effort you have; it does not tell you the risk has gone. Benchmarking and pre-deployment pilots do something narrower still. They generate evidence about how the model behaves before real users arrive, and evidence is not permission.
The NIST AI Risk Management Framework makes this explicit. Its Map function ends with a decision about whether to design, develop or deploy the system at all, informed by the perspectives of people outside the team. An option that skips that decision is not managing AI design risk; it is postponing it.
The mitigation hierarchy runs in an order
Eliminate first. Change the design, narrow the purpose or drop the feature that carries the harm. Reduce second, with technical controls that shrink probability or severity. Control third, by putting human oversight on what remains. Then transfer, accept and disclose the residual risk, in writing, to somebody senior enough to own it.
That order is the whole point of a hierarchy, and the exam tests it by offering plausible answers from the wrong rung.
Where the marks go missing
Two option types drain marks. The first adds monitoring: sensible, downstream and no help at all if the harm is baked into the training data. The second adds a human reviewer, which sounds responsible and is a control on residual risk, not an elimination of the original one. If the stem describes a design decision, the answer sits at the design rung.
Watch the verbs. "Mitigate", "monitor" and "accept" are three different obligations, and an examiner picks one deliberately. The companion resources to the framework are built around that separation, with Map, Measure and Manage doing distinct work.
Documentation is where the decision survives
A risk you identified and did not record is a risk your successor will meet again. Article 9 puts documentation in the same breath as implementation for a reason: the record of what you considered, rejected and accepted is the only proof that governance happened before deployment rather than after the complaint.
Write down the harms you mapped, the ranking you gave them, the rung of the hierarchy you chose and the person who accepted what was left. That paragraph is worth more than a monitoring dashboard.
For the exam, keep the sequence in your head as a single line: map the harms, rank them, eliminate what you can, control what you cannot and record the lot. A scenario question on AI design risk is asking you to place one step in that sequence.
Our library of AIGP explainers goes deeper on how these design-stage duties connect to the three frameworks the exam expects you to recognise and to the monitoring obligations that follow release. If you want a structured way through Domain III, the study materials at 22academy.com/study are the next step.
