Govern the deployment and use of the AI system.
- ✓Deployment is where policies must operate: data governance, risk management, issue management and user training.
- ✓Production data governance = input rules, minimization, retention limits, input quality, access control, and the transfer and notice duties that go-live triggers.
- ✓Keep the risk register alive with scheduled and change-triggered reviews.
- ✓Issue management needs easy reporting, triage, escalation and closure.
- ✓Role-based, ongoing training is the main defense against automation bias.
- Automation bias:
- The tendency to over-trust an automated system's output instead of exercising independent judgment.
- Risk register:
- A living record of identified risks, each with an owner, rating, treatment and review date.
- Issue management:
- The process for capturing, triaging, escalating and resolving problems with a live system, and learning from them.
- Data minimization:
- Collecting and keeping only the data a defined purpose actually needs.
- Role-based training:
- Training tailored to what each group (end users, overseers, leaders) needs to do with an AI system.
Exam tips: When the stem says the model meets spec but outcomes are bad, the lever is human: training, usage policy, verification duties. · 'Keep everything in case it's useful' is never a purpose. Minimization and retention limits win. · Training is a standing control with refreshers. One-off launch briefings are the distractor. · Banners and disclaimers alone don't change behavior. Prefer options that assign duties and build skills.
- ✓Deployers monitor in their own context: performance, drift, fairness, output quality, oversight signals, usage and vendor changes.
- ✓Every metric needs a threshold, an owner and a planned response.
- ✓Maintenance runs on a calendar plus triggers, under change management.
- ✓Vendor upgrades need re-validation; version pinning buys the time.
- ✓Separate development, staging and production, keep builders out of production, and track every version in a model registry.
- Continuous monitoring:
- Ongoing, largely automated tracking of a live AI system's performance, inputs, outputs and use against defined thresholds.
- Data drift:
- A shift in the distribution of a system's live inputs away from the data it was trained or validated on.
- Concept drift:
- A change in the real-world relationship between inputs and outcomes, so learned patterns stop holding.
- Version pinning:
- Staying on a specific, validated model version until a newer one has been tested and approved.
- Change management:
- Testing, approving, documenting and preparing rollback for every change to a production system.
- Model registry:
- A catalog of model versions recording each one's hash, training-data identifiers, evaluation results, owner and deployment status.
Exam tips: Proactive beats reactive: continuous monitoring plus a scheduled maintenance plan. 'Freeze it' and 'retrain only when it breaks' are the two planted extremes. · A vendor update is a change to YOUR system. Re-validate before it reaches production. · Deployers of vendor models usually maintain through configuration, data, oversight and vendor escalation, not retraining. · Monitoring isn't only model metrics: override rates, usage patterns and complaints catch human and scope problems.
- ✓Four periodic tools: audits, red teaming, threat modeling and security testing. Each finds different problems.
- ✓Deployers assess the system as they run it, not just the model.
- ✓Negotiate testing and audit rights with vendors; some laws put audit duties on deployers directly.
- ✓Set cadence by risk, add change triggers, keep assessors independent, and track findings to closure.
- Audit:
- An independent check of a system and its governance against defined criteria such as policy, law, contract or standards.
- Red teaming:
- Simulating real adversaries who actively try to make an AI system fail, misbehave or leak data.
- Threat modeling:
- Structured, on-paper analysis of how a system could be attacked or misused, ranked by likelihood and impact.
- Security testing:
- Technical testing of security controls, such as penetration tests, vulnerability scans and access checks.
- MITRE ATLAS:
- A public knowledge base of real-world adversary tactics and techniques used against AI systems.
- Threat hunting:
- Proactively searching a live system's logs and telemetry for signs of compromise or abuse that automated alerts have missed.
Exam tips: Read the verb: checks against criteria = audit; attacks = red teaming; analyzes on paper = threat modeling; tests controls = security testing; searches live logs for intruders = threat hunting. · 'No attacks were executed' is the tell for threat modeling. · Cadence answers reward 'risk-based plus change-triggered'. A fixed calendar alone is the near miss. · Deployers need contractual permission and a scope covering the whole system: prompts, RAG, plug-ins and people.
- ✓Know the difference: risk (could happen), issue (has happened, no significant harm), incident (harm).
- ✓Good incident records cover detection, impact, containment, root cause, notifications, fixes and lessons.
- ✓EU high-risk deployers keep logs for at least six months and must inform the provider of risks and serious incidents.
- ✓Providers own post-market monitoring; deployers feed it and should keep their own monitoring plan.
- Serious incident (EU AI Act):
- An incident or malfunction leading to death or serious harm to health, serious and irreversible disruption of critical infrastructure, breach of fundamental-rights obligations, or serious harm to property or the environment.
- Post-market monitoring:
- A provider's system for actively collecting and analyzing data on an AI system's performance throughout its life, fed in part by deployers.
- Near miss:
- An event that could have caused harm but was caught in time; worth recording as an issue.
- Incident record:
- A documented account of what happened, its impact, containment, root cause, notifications, corrective actions and lessons.
- Post-deployment monitoring plan:
- A deployer's documented plan covering metrics and thresholds, user feedback, appeals and overrides, incident response, change management and decommissioning (NIST AI RMF MANAGE 4.1).
Exam tips: Incident order: detect → contain → notify → investigate → correct → learn. Reporting before containing, or reviewing before notifying, are the classic inversions. · Post-market monitoring belongs to the provider (Art. 72), but deployers must monitor and inform the provider (Art. 26(5)). 'Leave it all to the vendor' is wrong. · Record near misses and minor issues: patterns turn into risks. · Guides order incident steps differently, and some put 'communicate' first. Early communication means internal escalation; when harm is ongoing, containment still comes before external notices.
- ✓Uses drift through scope creep, deliberate misuse and data repurposing.
- ✓Forecast with intended and out-of-scope use statements, pre-mortems, misuse brainstorming and stakeholder mapping.
- ✓Reduce with technical, contractual, organizational and documentation controls.
- ✓Treat every new use as a new deployment that needs assessment.
- Secondary use:
- Use of an AI system, or its data, for a purpose beyond the one that was assessed and approved.
- Function creep:
- The gradual expansion of a system into tasks it was never designed or assessed for.
- Downstream harm:
- Harm that ripples beyond the original decision or user, including to people who never used the system.
- Out-of-scope use:
- A use the deployer or provider has identified as inappropriate or unsupported, documented so it can be prevented.
- Purpose limitation:
- The GDPR principle that personal data collected for one purpose may not be further processed in ways incompatible with it.
- Pre-mortem:
- A forecasting exercise that imagines a future failure and works backward to what caused it.
Exam tips: Model card = what this system is for and not for. AI inventory = which systems we have. Secondary-use questions point to the model card and impact assessment. · A new use of an approved system is a new deployment. Assess it before it goes live, even if the technology is unchanged. · Repurposing into a high-risk area (hiring, credit, worker monitoring) can make a deployer the provider under Art. 25(1)(c). · Downstream harms include people who never used the system.
- ✓Plan audiences, messages, timing, channels, incident communications and approvals in advance.
- ✓Tell people AI is in use, what it can and can't do, and how to reach a human or contest an outcome.
- ✓EU deployers have specific duties: informing decision subjects, explaining decisions, labeling deepfakes.
- ✓In incidents: required notifications and affected people first, one voice, honesty over spin.
- ✓Offer a real human or non-AI alternative for significant decisions; GDPR Art. 22, California's ADMT rules and Colorado SB 26-189 require versions of it.
- External communication plan:
- A pre-agreed plan for what an organization tells users, affected people, regulators, partners and the public about its AI, when and through which channels.
- AI disclosure:
- Telling people, at or before first interaction, that they are dealing with an AI system or AI-generated content.
- Right to explanation (EU AI Act Art. 86):
- The right of a person affected by a significant decision based on an Annex III high-risk system to a clear, meaningful explanation from the deployer of the AI's role and the main elements of the decision.
- AI washing:
- Exaggerating or misrepresenting what an AI system can do, which can amount to deceptive marketing.
- Holding statement:
- A pre-drafted initial public statement used in the first hours of an incident while facts are confirmed.
- Non-AI alternative:
- A human or non-automated route offered instead of an AI process; it should be feasible, clearly explained, easy to choose and no worse in service.
Exam tips: The winning answer is the balanced pair: capabilities AND limitations. Hype, hiding and silence are the three standard distractors. · Timing matters: disclose at or before first interaction. A notice after the fact is a deficiency even if the wording is fine. · Technical internals are rarely what affected people need. Look for plain-language, actionable information and a route to a human. · Overstated AI claims are a legal risk (deceptive practices), not just a brand risk.
- ✓Every deployed AI needs a policy and controls to deactivate or localize it.
- ✓Risk-driven triggers are regulatory or performance/safety, never profit or a new release; planned retirement can follow business or vendor reasons.
- ✓Toolkit: kill switch, feature flags, geo-restriction, rollback, graceful degradation, agent stop controls; localize with flags, regional modules, country models or federated learning.
- ✓The policy settles triggers, decision rights, fallback, notifications, evidence, restoration and drills.
- Kill switch:
- A control that stops an AI system globally and quickly, ideally leaving it in a safe state.
- Feature flag:
- A switch that turns a feature on or off for a jurisdiction, customer group or cohort without redeploying software.
- Localization:
- Restricting or adapting how an AI system operates by region, for example disabling it in one jurisdiction or running a country-specific model.
- Rollback:
- Returning a system to its last known-good model version or configuration.
- Graceful degradation:
- Falling back to human handling or a simpler process so service continues when the AI is switched off.
- Deactivation policy:
- A pre-agreed policy setting the triggers, decision rights, controls, fallbacks, notifications and restoration criteria for switching an AI system off or restricting it.
Exam tips: For risk-driven deactivation, valid triggers are regulatory or performance/safety problems; profit, migration hassle and 'a new version exists' are never the answer. Planned retirement (IV.C.8) can legitimately follow business or vendor reasons. · A timely, verified mitigation is a legitimate reason to keep a system running. · One jurisdiction's demand → feature flag or geo-restriction. A severe global incident → kill switch. The kill switch for a local issue is the overbroad trap. · Look for pre-agreed decision rights and tested controls. An untested switch isn't a control.
- ✓Planned retirement and risk-driven deactivation are different processes with different valid triggers.
- ✓A retirement policy sets criteria, decision rights, required steps, evidence and a lessons-learned review.
- ✓Sequence: map dependencies, notify, transition (including a non-AI fallback), snapshot and shut down, retain or dispose, close out.
- ✓Archive what accountability and the law require; destroy the rest, including stray model copies, and get certificates from hosts.
- ✓Mark the system retired in the inventory and registry, exit the contract, and keep the retention clock running.
- Planned retirement:
- Ending an AI system's use on a schedule for reasons such as obsolescence, vendor end of support, a replacement or a changed business need.
- Risk-driven deactivation:
- Switching off or restricting a live AI system because of a regulatory, performance, safety or security problem, under the deactivation policy.
- Decommissioning:
- The controlled process of retiring a system: mapping dependencies, notifying users, transitioning, archiving or destroying data and models, and closing the records.
- Retention schedule:
- A documented set of rules saying how long each type of record is kept and when it must be destroyed.
- Certificate of destruction:
- Written confirmation from a provider or contractor that specified data or model copies have been permanently destroyed.
- Non-AI fallback:
- A manual or rules-based process that takes over an AI system's work when it is switched off or retired.
Exam tips: Read the trigger first. Business or vendor reasons point to planned retirement, which is legitimate; an emergency stop needs a regulatory or performance problem. · Sequence: map, notify, transition, snapshot and shut down, retain or dispose, close out. 'Delete everything first' and 'update the inventory first' are the planted inversions. · Retirement doesn't end retention duties: EU provider documentation runs 10 years from placing on the market, logs at least six months, Colorado records three years. · Deleting the production model isn't disposal. Look for fine-tuned copies, checkpoints, backups and vendor-hosted copies.
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