Domain III in one pass: governing development
Lesson 1 of 3 in AIGP Domains III–IV Recap: Governing Development and Deployment.
Domain III — Understanding how to govern AI development — carries 21 to 25 of the exam’s 100 questions, tied with Domain IV as the heaviest block on the blueprint. Together they are roughly half your exam. If you allocate study hours any other way, you are studying against the odds.
This module is deliberately thin: a recap at exam weight, not a re-teaching. The canonical treatment of every Domain III control lives elsewhere on this site — the lifecycle in foundations/ai-lifecycle, data governance and artifacts in the operations track, testing in operations/testing-and-evaluation. What you need here is the map: which competency tests what, where you learned it, and where the distractors hide.
The three competencies split the 21–25 questions like this: III.A (design and build governance, 6–8 questions), III.B (data governance plus training and testing, 6–8), and III.C (release, monitoring, and incidents, 8–10). Notice the skew: III.C is the single heaviest competency in the domain. The exam cares most about what happens after the model works.
| Competency | What it tests | Deep-dive module | Classic trap |
|---|---|---|---|
III.A — design and build | Use-case definition before building; impact assessments; probability × severity harms matrix; the risk mitigation hierarchy; stakeholder mapping; human-oversight design; documenting the build | operations/impact-assessments; foundations/ai-lifecycle | Distractors reorder the mitigation hierarchy or start the lifecycle at data collection instead of use-case definition |
III.B — data, training, testing | Lawful rights to training data; quality, quantity, integrity, fit-for-purpose; lineage and provenance; the seven testing types (unit, integration, validation, performance, security, bias, interpretability); documenting results | operations/data-and-documentation; operations/testing-and-evaluation | Options swap testing types — offering validation testing when the scenario describes a bias or security question |
III.C — release, monitor, incidents | Release-readiness review; the model card; conformity requirements; continuous monitoring and retraining schedules; audits, red teaming, threat modeling; incident root-cause vocabulary; public disclosures and post-market monitoring plans | operations/monitoring-and-incidents; eu-ai-act/conformity-and-standards | The one-and-done trap: a single pre-launch check offered where the correct answer establishes a continuing schedule |
Two Domain III structures come up so often they deserve their own recall drill.
The harms matrix. Plot each identified risk by probability and severity of harm. The exam does not ask you to compute anything — it asks whether you know that the matrix is how design-stage risks get prioritised, and that severity includes harms to individuals, groups, organisations, and society (the Domain I harms taxonomy feeding forward).
The risk mitigation hierarchy. Once prioritised, risks are treated in a preference order: eliminate the risk (change or drop the feature), then reduce/mitigate it (controls, testing, oversight), then transfer it (contracts, insurance), and only then accept what remains — documented, with an owner. The order is the point: it is a hierarchy, not a menu.
The III.B testing pipeline — seven types, in order, each with a governance action on failure
- Trained model + system
- Unit testing
Individual components behave as specified. Failure → fix the component before anything downstream means anything.
- Integration testing
Components work together — the model inside the pipeline, APIs, data feeds. Failure here with passing unit tests is a classic scenario tell.
- Validation testing
Does the system meet the requirements defined in III.A? Validation looks backward to the use-case definition — that linkage is exam gold.
- Performance testing
Accuracy, latency, throughput against the metrics and thresholds set at design time.
- Security testing
Adversarial inputs, prompt injection, data poisoning, model extraction. Overlaps with red teaming and threat modeling — but those are periodic assessments in III.C, not this pipeline step.
- Bias testing
Disaggregated performance across subgroups. The metrics themselves are taught in foundations/ethics-and-trustworthy-ai — the exam tests that you test, and document, before release.
- Interpretability testing
Can the system’s outputs be explained well enough for its oversight design and transparency duties to function?
- Release-readiness review
All seven documented → the release decision, the model card, and any conformity assessment can proceed.
Key terms: model card, risk mitigation hierarchy, data lineage, provenance, conformity assessment
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.