IAPP AIGP · Domain III · Governing AI Development

Deploy, Monitor, Respond — The Lifecycle

Domain III is where governance stops being paperwork and becomes operations: rolling systems out safely, watching them degrade, catching incidents, and knowing who answers for what. Every concept here comes with a plain-words example.

4-stage deploy flow Drift simulator 6 incident scenarios 4 frameworks 8 exam traps
How to use this module: read each section, then do the interactive — the drift lab and incident game are the closest thing to the scenario questions. Every topic has an IN PLAIN WORDS example so you can explain it to a non-technical person (which is exactly what the exam asks you to do).
Scroll to begin ↓
1
BoK Domain III.A — From validation to live operation

Deployment: The Four-Stage Flow

Deployment is where a model stops being a promise and starts making real decisions. The exam tests the sequence, the controls at each stage, and the difference between a rollout and a release.

STAGE 1

Pre-deployment checklist

Confirm the model card, test evidence, bias assessment, and sign-off gates are complete. Nothing deploys without a named accountable owner.

Example: a bank's credit model needs the model card signed by the CRO before the API goes live — no signature, no traffic.
STAGE 2

Shadow deployment

Run the new model in parallel with the old one, logging its predictions without acting on them. Compare outcomes before switching.

Example: a fraud model runs alongside the existing rules engine for 2 weeks — if it flags 3× more false positives, it doesn't go live.
STAGE 3

Phased rollout

Release to a small slice of users or geographies first, with monitoring thresholds armed, then expand. Canary releases are the standard pattern.

Example: a chatbot launches to 5% of customers, then 25%, then 100% — each step gated on error-rate and escalation metrics.
STAGE 4

Full deployment + monitoring

System is live. Monitoring dashboards, drift thresholds, rollback triggers, and the incident route are all operational from day one.

Example: the credit model is live, but a dashboard tracks approval rates by demographic group daily — a drift alert fires if any group's rate moves >2%.
Exam anchor — shadow vs canary vs A/BShadow deployment = new model runs in parallel, predictions logged but not used (no user impact). Canary = new model serves a small real slice of traffic. A/B test = two models serve different users and outcomes are compared. The exam loves asking which is which — the tell is whether real users are affected.[AIGP BoK III.A]

Human oversight controls at deployment

ControlWhat it doesPlain-words example
Human-in-the-loop (HITL)No decision executes without human review/approvalA loan officer must approve every AI-recommended rejection before it is sent
Human-on-the-loop (HOTL)System acts autonomously; humans supervise, sample-audit, and can intervene or haltA chatbot answers customers, but a supervisor watches a live dashboard and can kill the bot with one switch
Human-out-of-the-loop (HOOTL)Fully automated; humans review aggregate performance onlySpam filtering — no one reviews individual emails, only monthly false-positive stats
Post-processing bias controlsAdjust or re-rank outputs to meet fairness targets after the model decidesA hiring model's shortlist is re-balanced so no demographic group is under-represented before HR sees it
Override & escalation pathsUsers can challenge or escalate a decision to a humanA customer denied by the credit model can request a manual review within 24 hours
Why this matters in practice: a hospital deploys a sepsis-prediction model. The model fires an alert — but a nurse must confirm before antibiotics are administered (HITL). The alert system itself is monitored by a clinical lead who can disable it if false alarms spike (HOTL). Both controls exist because the cost of a wrong automated decision is a life.

Deployment risks & integration

Integration risk

The model works, but the surrounding system breaks — API timeouts, data-format mismatches, downstream systems receiving unexpected outputs.

Example: a chatbot's response format change crashes the ticketing system that parses its output.

Context mismatch

The model is used in a context it wasn't validated for — the classic deployment-bias failure.

Example: COMPAS recidivism scores designed for sentencing used for bail decisions.

User-notice failure

Users aren't told they're interacting with AI, or the notice is buried in terms of service.

Example: a chatbot that doesn't disclose it's an AI breaches Art. 50 of the EU AI Act.

Rollback gap

No tested rollback path — when the model misbehaves, the team can't revert quickly.

Example: a pricing model goes wrong on a Friday; the team can't restore the old version until Monday.
2
Interactive · Monitoring & drift simulator

Watch the Model Go Stale

Models rot. The world moves, and the model keeps predicting the world it was trained on. This simulator shows a fraud model's accuracy over 12 months — flip the drift switches and watch what happens when you don't monitor.

Simulate 12 months of production
Fraud model — accuracy over time
STABLE
The model is performing as validated. Click the switch to simulate production and see what drift does.

The three drift types — with plain-words examples

Drift typeWhat changesPlain-words example
Data drift (input)The distribution of input features changes — the world the model sees is differentA fraud model trained on card-present transactions suddenly sees mostly online payments after COVID — the input mix shifted, so the model's assumptions break
Concept driftThe relationship between inputs and outputs changes — the "rule" itself movedA spam model learned that "free" means spam; then a legitimate competitor launches a "free" campaign — the same input now maps to a different truth
Label driftThe ground-truth labels shift — what counts as the correct answer changedA defect-inspection model was trained when "defective" meant visible cracks; the factory now uses a stricter standard — the same photo is now labelled defective
Exam memory hook — the three D'sData drift = inputs change. Concept drift = the rule changes. Label drift = the answer key changes. All three silently degrade accuracy — which is why monitoring is a governance control, not a nice-to-have.[AIGP BoK III.B; SEI CMU drift research]

Monitoring: what to watch

Performance metrics

Accuracy, precision, recall, F1 — tracked over time and disaggregated by subgroup. A drop is the first sign of drift.

Example: recall for the 60+ age group falls from 88% to 71% — the model is silently failing older customers.

Input/output distributions

Feature distributions and prediction distributions compared against training baselines. Catches drift before labels arrive.

Example: average transaction amount shifts from $45 to $120 — the model never saw this range.

Feedback loops

Model outputs feeding back into future training can amplify bias — the model's own decisions become the new "truth".

Example: a hiring model trained on its own past shortlists keeps rejecting the same profile types — the bias compounds.

Retraining triggers

Pre-defined thresholds that fire retraining or rollback. The trigger must be set BEFORE deployment, not after the damage.

Example: "if fraud recall drops below 80% for 3 consecutive days, auto-flag for retraining."
3
Interactive · Incident response scenarios

What Do You Do When It Goes Wrong?

Six incident scenarios — pick the right first move. The exam tests whether you know the incident-response lifecycle: detect → triage → respond → recover → review. Speed matters, but the RIGHT first action matters more.

The incident-response lifecycle

PHASE 1

Detect

Monitoring flags an anomaly — a metric breach, an alert, a user complaint, a regulator inquiry.

Example: the drift dashboard shows recall dropped 12% overnight.
PHASE 2

Triage & classify

Assess severity, scope, affected parties, and whether it's a security, safety, bias, or availability incident.

Example: 3,000 loan decisions affected vs 30 — different severity, different response.
PHASE 3

Respond & contain

Kill switch, rollback, or quarantine. Stop the bleeding before investigating the cause.

Example: the chatbot is taken offline within 15 minutes of the harmful-output report.
PHASE 4

Recover & review

Restore service, notify affected parties and regulators, root-cause analysis, update controls.

Example: after the fix, the team adds a new monitoring threshold so the failure can't recur silently.
The kill switch — know it coldEvery high-stakes AI system should have a documented, tested kill switch (also called a stop button or circuit breaker): a named person with authority, a defined trigger condition, and a tested procedure. The exam asks who holds the switch and when it should be pulled — the answer is a named accountable owner, and immediately on confirmed significant harm, not after a full investigation.[AIGP BoK III.C]

Incident types — the taxonomy

Security incidents

Data poisoning, model extraction, prompt injection, jailbreaks, adversarial attacks.

Example: an attacker crafts prompts that make a support chatbot leak another customer's order details.

Safety incidents

The system causes or risks physical or psychological harm.

Example: an autonomous warehouse robot misidentifies a worker and moves toward them.

Bias / fairness incidents

Disparate outcomes across groups surface in production.

Example: a hiring model's shortlist includes 0% of candidates from a particular demographic for 3 weeks straight.

Availability / performance incidents

System down, degraded, or silently wrong at scale.

Example: a pricing model returns NaN for a product category, and the website shows blank prices.

Privacy incidents

Training-data leakage, membership inference, model inversion, or personal data exposure via outputs.

Example: a user prompts a model and it regurgitates a real person's address from training data.

Compliance incidents

Breach of a legal obligation — transparency, notification, documentation.

Example: a deepfake tool ships without the Art. 50 labelling requirement.
4
BoK Domain III.D — The management frameworks

Frameworks: NIST, ISO, Singapore, OECD

Four frameworks, one exam. Learn each one's structure and its exam tell — the mnemonic, the function names, and the plain-words example that makes it stick.

FrameworkStructureExam tellPlain-words example
NIST AI RMF 1.0Govern – Map – Measure – Manage (G-M-M-M)"GMMM" — the four functions; Govern is the core that wraps the othersA bank maps its credit model's risks (Map), measures subgroup performance (Measure), manages mitigations (Manage), and its board sets the risk appetite (Govern)
ISO/IEC 42001:2023Plan – Do – Check – Act (PDCA) AI management system; certifiable"PDCA" + it's the certifiable management-system standard (like ISO 27001 for AI)A consultancy's AI policy: plan the AI programme, do the risk assessments, check via audits, act on findings — then get certified
Singapore Model AI Governance FrameworkInternal governance + human oversight + operations management + stakeholder interaction (2nd ed.); GenAI framework adds 9 dimensions"SG MGF" — risk-weighted human oversight; the 9 GenAI dimensionsA Singapore fintech sets human oversight by weighing harm severity × probability against commercial considerations
OECD AI Principles5 principles: inclusive growth, human-centred values, transparency, robustness, accountability"5 principles" — the international baseline most frameworks referenceA government's national AI strategy cites OECD principles as its foundation for trustworthy-AI policy
Exam memory hooksNIST = "GMMM — Govern wraps the rest". ISO 42001 = "PDCA + certifiable". Singapore = "severity × probability = oversight level". OECD = "5 principles, the baseline". If a question mentions "certification", the answer is ISO 42001; if it mentions "functions", it's NIST.[NIST AI RMF 1.0; ISO/IEC 42001:2023; SG MGF; OECD]

NIST AI RMF — the four functions in practice

Govern

The core: risk-management culture, policies, roles, and accountability. Everything else sits inside it.

Example: the board approves an AI risk appetite statement and appoints an AI governance officer.

Map

Understand the context: use case, stakeholders, benefits, and risks.

Example: the team documents who is affected by the hiring model and what could go wrong for each group.

Measure

Test and evaluate: metrics, bias testing, red-teaming, monitoring baselines.

Example: the model's accuracy is measured per demographic group, not just overall.

Manage

Act on findings: mitigate risks, implement controls, monitor continuously.

Example: a bias finding triggers retraining with rebalanced data and a new monitoring threshold.
5
BoK Domain III.E — Who answers for what

Roles, Inventories & Accountability

You cannot govern what you have not inventoried. This section covers the roles that carry accountability and the register that makes governance visible.

The accountability roles

RoleCore dutiesPlain-words example
AI governance officerOwns the AI governance programme: policy, risk register, training, incident oversightA bank's AI governance officer signs off every new model before it can enter shadow deployment
Accountable executiveA named senior leader with final sign-off authority and budget responsibilityThe CRO personally approves the credit model's go-live — no delegation to a committee
Model owner / product ownerDay-to-day accountability for a specific system's lifecycleThe fraud-model owner is the person paged when the drift alert fires at 3am
Data stewardData quality, lineage, lawful basis, and access control for training dataThe steward can answer "where did this training record come from and under what basis?"
Independent reviewer / auditorChallenges the team's claims — red-teaming, bias audits, pre-deployment reviewAn external auditor runs its own bias tests on the hiring model rather than trusting the vendor's report
Legal / complianceMaps obligations (GDPR, PDPA, EU AI Act), advises on lawful basis and noticesLegal flags that the chatbot needs an Art. 50 disclosure before launch

AI inventories & records of processing

In plain words: an AI inventory is a register of every AI system the organisation runs — like a fire-safety log for models. For each system it records: what it does, who owns it, what data it uses, its risk tier, its oversight pattern, and when it was last reviewed. If you can't list your systems, you can't govern them — and regulators will ask for the list first.

What an inventory entry contains

  • System name, version, purpose
  • Owner + accountable executive
  • Data sources & lawful basis
  • Risk tier & oversight pattern
  • Last review date & next review
  • Incident history

GDPR Art. 30 RoPA

Records of processing activities — the privacy cousin of the AI inventory. Both must exist and be kept current.

Example: a DPO audit starts by pulling the RoPA and the AI inventory side by side.

Value-chain accountability

Accountability follows roles, not contracts — a deployer can't outsource its duties to a vendor.

Example: a hospital buys a diagnostic AI, but the hospital still owns oversight and monitoring duties.
6
Easily confused — exam differentiators

Compare & Contrast

Four pairs the exam loves to blur. If you can fill these from memory, Domain III is largely yours.

6.1 Shadow vs canary vs A/B

ShadowCanaryA/B test
Real users affected?No — predictions logged, not acted onYes — small slice of real trafficYes — users split between versions
PurposeCompare outcomes before any riskGradual, gated rolloutMeasure which version performs better
Exam tell"Runs in parallel, no impact""5% of traffic, then expand""Two groups compared"

6.2 Data vs concept vs label drift

Data driftConcept driftLabel drift
What changesInput distributionInput→output relationshipGround-truth labels
Plain exampleCard fraud → online fraud mix"Free" stops meaning spamStricter defect standard
DetectionCompare feature distributionsTrack performance over timeRe-audit labels periodically

6.3 NIST AI RMF vs ISO 42001

NIST AI RMFISO/IEC 42001
TypeRisk-management framework (voluntary)Management-system standard (certifiable)
StructureGovern–Map–Measure–ManagePlan–Do–Check–Act
Best forDesigning risk processesFormal certification and audits
Exam tell"Functions""Certification", "management system"

6.4 HITL vs HOTL vs HOOTL

HITLHOTLHOOTL
Human roleApproves every decisionSupervises, can interveneReviews aggregates only
SpeedSlowestMediumFastest
Best forHigh-stakes, irreversibleMedium-stakes, reversibleLow-stakes, high-volume
ExampleLoan rejection approvalChatbot supervisionSpam filtering
7
Self-test · Exam traps

Eight Exam Traps

TRUE / FALSE — instant feedback per question, score tallied at the bottom. Best score persists in this browser.

8
Exam-day readiness

Before Thursday — The Checklist

Tap each item as you master it. The goal: fill every box from memory, not recognition.

§
Citation ledger

Sources