Where the questions cluster: III.C and IV.C drills

Lesson 3 of 3 in AIGP Domains III–IV Recap: Governing Development and Deployment.

Add them up: III.C carries 8–10 questions and IV.C carries 9–11. Roughly a fifth of the whole exam lives after launch. Both competencies test the same conviction from two seats: deployment is where governance obligations begin, not end. Continuous monitoring with scheduled maintenance and retraining; periodic audits, red teaming, threat modeling, and security testing; documented incidents; post-market monitoring plans; external communication plans for users, regulators, and the public; and — unique to IV.C — controls to deactivate or localise a system when regulation or performance failure demands it.

Two vocabulary distinctions decide several questions. Red teaming vs threat modeling: threat modeling is the analytical exercise — enumerate attackers, attack surfaces, and failure paths on paper; red teaming is the adversarial exercise — real people actively attacking the live system. Both are periodic assessments, and an option that swaps them is wrong. Model drift vs data drift: data drift means the inputs no longer resemble training data; model drift means the input-output relationship itself has shifted. Either way the exam’s tell is the same: performance decays silently, with no code change — and the missing control is always monitoring with retraining triggers.

Root cause: brittleness

The system performs well inside a narrow envelope and fails abruptly just outside it — a vision model defeated by a slightly rotated image. Exam phrasing: worked in the pilot, collapsed on ordinary real-world variation. Governance answer: broaden test coverage and define the operating envelope in the instructions for use.

Root cause: lack of robustness

Cousin of brittleness, tested under perturbation: noise, adversarial inputs, edge cases. A scenario featuring deliberately crafted inputs that flip the output is pointing here — and at security testing that should have caught it.

Root cause: poor data quality

Garbage in, incident out: mislabeled records, stale data, unrepresentative sampling. The root cause sits back in III.B — which is the exam’s point. Incident root-cause analysis is cross-functional and often lands upstream of where the incident surfaced.

Root cause: insufficient testing

The failure mode was discoverable — a testing type from the seven was skipped or under-scoped. Exam tell: the incident type maps cleanly onto a named testing type (a subgroup disparity that bias testing would have caught; an injection attack security testing would have found).

Root cause: model or data drift

Performance was genuinely fine at launch and decayed as the world moved. Nothing was skipped pre-release — the missing control is post-release: monitoring, drift metrics, retraining triggers. Distinguish this from insufficient testing: drift incidents were not discoverable at launch.

Post-launch triage: pick the governing response

Interactive decision tree — outcomes:

  • Correct — drift, caught by monitoring

    Gradual, silent decay is drift’s signature. The governing control is continuous monitoring with defined metrics and retraining triggers — established at release, not invented after the incident.

  • The one-and-done trap

    A pre-launch report cannot detect what happens after launch. Whenever a one-time artifact is offered against an ongoing failure mode, the continuing control wins.

  • Correct — secondary-use governance

    IV.C explicitly makes forecasting and reducing secondary or unintended uses a deployer duty: monitor actual use, retrain users, update the acceptable-use policy, and reassess impact for the new use.

  • Accountability does not dissolve downstream

    Blaming users is never the credentialed answer. The deployer must anticipate foreseeable misuse and act on what monitoring reveals.

  • Correct — kill-switch governance

    Deactivation and localisation controls are built and tested in advance: who can trigger them, on what criteria, with what communication plan. Regulators and courts do not wait for a feasibility study.

  • Too late to design the brake

    If stopping the system requires an emergency meeting, the IV.C control was missing. The exam rewards the answer where the procedure pre-exists the crisis.

Tool: AIGP Exam Simulator — Drill Domains III and IV under blueprint weighting — the exam simulator samples III and IV at 21–25 questions each, exactly like the real thing.