Govern the release, monitoring and maintenance of the AI system.
- ✓Readiness = the go/no-go gate between building and deploying.
- ✓Check criteria, documentation, conformity, operational readiness and sign-offs.
- ✓Monitoring, human oversight, incident response and rollback must exist on day one, not 'next sprint'.
- ✓Release in stages (canary, shadow mode) with a tested rollback plan.
- ✓Testing continues after launch, on real production data.
- Readiness assessment:
- The formal check after development and before deployment that decides whether a system is ready to release (go/no-go).
- Go/no-go criteria:
- Acceptance thresholds agreed in advance (performance, fairness, robustness, security, documentation) that a system must meet before release.
- Sign-off:
- A named, accountable person's recorded approval that release criteria are met and the residual risk is accepted.
- Shadow deployment:
- Running a new model on live traffic without acting on its outputs, to compare it safely against the current system.
- Canary (phased) release:
- Releasing to a small share of users first and expanding only if monitoring stays healthy.
- Rollback plan:
- A tested way to return quickly to the previous version if the new one misbehaves.
Exam tips: Sequence anchor: the readiness assessment comes AFTER development and BEFORE deployment. Post-deployment (inference) testing on production data comes AFTER deployment. · Any option that lowers or redefines a threshold to hit a launch date is a trap. Criteria are set in advance and misses are escalated. · 'It passed validation, so no more testing is needed' is always wrong. Lab results never guarantee production performance. · Watch for self-approval: the team that built the model shouldn't be the only one signing it off.
- ✓Model card = concise summary: purpose, performance by subgroup, limits, intended and out-of-scope uses.
- ✓Inventory = org-wide register; technical documentation = proof for regulators; datasheet = about a dataset.
- ✓EU high-risk providers: QMS, technical documentation, conformity assessment, declaration, CE marking, registration, then market.
- ✓Substantial modifications trigger a new assessment, so plan your update envelope up front.
- Model card:
- A short, structured summary of one model's purpose, performance (including by subgroup), limitations, and intended and out-of-scope uses.
- Datasheet for datasets:
- A document recording a dataset's motivation, composition, collection process and recommended uses.
- AI system inventory:
- An organization-wide register of AI systems with their owners, documentation, incident plans, data dictionaries and links to code.
- Conformity assessment:
- The pre-market process showing a high-risk AI system meets the EU AI Act's requirements, by internal control or with a notified body.
- CE marking:
- The mark a provider affixes to show a product conforms to applicable EU requirements, after the conformity assessment and declaration.
- Substantial modification:
- A change not foreseen in the initial conformity assessment that affects compliance or the intended purpose; it triggers a new assessment.
Exam tips: Model card vs. AI system inventory is a favorite swap: short summary of one model vs. the full internal repository (incident plans, data dictionaries, source links, contacts). · When a question asks how to forecast or limit secondary or unintended uses at release, the model card (intended and out-of-scope uses) is the classic answer. · Conformity happens BEFORE placing on the market. Any option that ships first and assesses later is wrong. · Unplanned substantial modification = new conformity assessment. Pre-determined, documented changes are the exception.
- ✓Monitor performance, inputs, outputs, fairness, security, human signals and operations.
- ✓Every metric needs a threshold and an owner.
- ✓Monitoring is a loop: collect, measure, alert, diagnose, act, validate.
- ✓Providers monitor the whole fleet (Art. 72); deployers monitor their own use (Art. 26).
- Continuous monitoring:
- Ongoing tracking of a deployed AI system's performance, inputs, outputs, fairness, security and human feedback.
- Post-market monitoring (EU AI Act Art. 72):
- The provider's duty to systematically collect and analyze real-world performance data over a high-risk system's lifetime, based on a documented plan.
- Ground truth:
- The verified correct outcome that predictions are compared against to measure real accuracy.
- Alert threshold:
- A pre-set value that, when crossed, signals a problem and triggers action by a named owner.
- Override rate:
- How often human reviewers reject or change the system's output; a rising rate is an early warning sign.
Exam tips: Monitoring never 'completes.' Options that scale it back after a stable year, a clean audit or 'perfect accuracy' are traps. · Provider monitoring is fleet-wide and feeds corrective action; deployer monitoring covers its own use in context. Check whose perspective the question takes. · Input monitoring alone misses concept drift. Prefer answers that also track outcomes against ground truth. · Third-party and pre-trained components you build on are monitored too, including for bad actors (NIST MANAGE 3.1 and 3.2).
- ✓A model is a snapshot; drift is the world moving away from it.
- ✓Data drift = inputs change; concept drift = input-outcome relationship changes; model drift = performance decays.
- ✓Maintain on a schedule AND on triggers.
- ✓Every update follows change management: diagnose, retrain, re-validate, check conformity, document, stage, monitor.
- Data drift:
- A change in the distribution of the inputs a model receives compared with its training data.
- Concept drift:
- A change in the relationship between inputs and the correct output, so the same inputs now call for a different answer.
- Model drift (model decay):
- The decline in a deployed model's performance over time, usually caused by data or concept drift.
- Retraining trigger:
- An automated threshold or alarm that starts the retraining process when monitored performance crosses a defined line.
- Change management:
- The controlled process for updating a system: test, version, document, approve and release with rollback ready.
- Champion–challenger:
- Testing a candidate model against the production model on live cases and promoting it only if it clearly performs better.
Exam tips: Inputs changed = data drift. Inputs look the same but outcomes behave differently = concept drift. Model drift (decay) is the performance symptom. · An alert justifies investigation, not automatic emergency retraining. Diagnose, then retrain through change management. · Don't confuse overfitting (a training problem) with drift (a post-deployment problem). · Retraining on a narrow, recent window can create temporal bias; the exam rewards representative data.
- ✓Four assessments, four questions: do we comply? can it be broken? what could go wrong? do the controls hold?
- ✓Threat model first; it scopes red teaming and security testing. Audits check the whole program against criteria.
- ✓High-stakes markers call for an independent or third-party audit.
- ✓Run them on a calendar and on triggers, scaled to risk.
- ✓Threat hunting, bug bashes and bug bounties supplement, never replace, internal testing and monitoring.
- Audit:
- An independent or internal check of a system or program against defined criteria such as laws, standards, policies or the provider's own claims.
- Red teaming:
- An active, creative simulation of adversarial attacks to find ways a system can be made to fail or misbehave.
- Threat modeling:
- Structured analysis, on paper, of a system's assets, entry points, likely attackers and techniques, used to prioritize defenses and scope testing.
- Security (penetration) testing:
- Structured testing of technical controls, such as APIs, infrastructure and access, to find exploitable vulnerabilities.
- Threat hunting:
- Proactively searching a live system for signs that someone is already abusing or compromising it, rather than waiting for alerts.
- Bug bash vs. bug bounty:
- A bug bash is a focused internal session where builders, testers and sometimes users hunt functional bugs together; a bug bounty pays outside researchers to report flaws responsibly.
Exam tips: Match the verb: audit CHECKS against criteria, red team ATTACKS, threat model MAPS on paper, security testing PROBES technical controls, threat hunting HUNTS for live abuse. · Threat modeling comes before red teaming and scopes it. Thinking about attackers is not yet attacking. · No assessment replaces another, or replaces continuous monitoring. 'X lets us retire Y' is a trap. · Independence is a hallmark of a credible audit. Consequential decisions, sensitive data, high-risk domains, scale, bias potential, critical infrastructure and public discourse are markers for an independent or third-party audit.
- ✓Main attacks: prompt injection, jailbreaking, data poisoning, evasion, model extraction, membership inference.
- ✓The OWASP Top 10 for LLMs ranks prompt injection first; MITRE ATLAS catalogs real attacker techniques.
- ✓Red teaming: scope, diverse team, attack, record, fix and retest, feed back.
- ✓Findings must flow into fixes, documentation and monitoring.
- Prompt injection:
- Crafted input that overrides a model's instructions, either typed directly or hidden in content the model reads (indirect).
- Jailbreak:
- A technique that coaxes a model into bypassing its safety rules or usage restrictions.
- Data poisoning:
- Corrupting training or fine-tuning data so the model learns harmful or attacker-chosen behavior.
- Model extraction:
- Reconstructing a working copy of a model by systematically querying it and learning from its outputs.
- Membership inference:
- Probing a model's outputs to determine whether a specific person's data was in its training set.
- Excessive agency:
- Giving an AI agent more permissions, tools or autonomy than its task needs, so a manipulation can do more damage.
Exam tips: Check the attacker's access: evasion, extraction and membership inference need only query access; poisoning needs a route into the training data. · Indirect prompt injection (instructions hidden in content the model reads) is a favorite GenAI scenario. · OWASP, MITRE ATLAS and NIST AI 600-1 are voluntary resources. Don't pick an option calling them legally binding. · A confirmed, unfixed high-severity finding means fix and retest before launch. Publishing exploit details is never the 'transparency' answer.
- ✓Risk = might happen; issue = a problem now; incident = harm or near harm. Log all three.
- ✓Prepare, identify, contain, eradicate, recover, learn, and notify as soon as a duty triggers.
- ✓EU high-risk providers report serious incidents fast, then investigate and take corrective action.
- ✓Preserve evidence and keep records accurate and complete.
- ✓Mine AI incident databases to learn from other people's failures.
- AI incident:
- An event in which an AI system caused, or nearly caused, harm to people, property, rights or the environment.
- Near miss:
- An incident where harm was narrowly avoided; it is still documented and investigated.
- Risk register:
- The living record of identified risks with their likelihood, severity, owner and mitigations.
- 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.
- Containment:
- The response step that stops harm spreading, for example by disabling a feature or rolling back, while preserving evidence.
- AI incident database:
- A public collection of real-world AI harms and near misses (e.g., the AI Incident Database, OECD AIM) used for learning, not regulatory reporting.
Exam tips: Sequence: identify → contain → eradicate → recover → learn. Right after identification, the answer is containment, not root-cause surgery. · Speed must not destroy evidence: preserve logs and the model version, and under Art. 73 don't alter the system before informing authorities. · Art. 73 deadlines are outer limits (15 days; 10 for a death; 2 for widespread infringement or critical infrastructure). 'Immediately' is the rule. · Public incident databases are for learning. They are never the regulatory reporting channel.
- ✓Usual suspects: brittleness, lack of robustness, poor-quality data, insufficient testing, drift, adversarial attacks, hallucination, misaligned objectives.
- ✓Older outlines add catastrophic forgetting, uncertainty and false positives.
- ✓A label ('it hallucinated') is not a root cause; keep asking why.
- ✓Root-cause analysis is cross-functional because each team sees different causes.
- ✓Use structured tools (5 Whys, fishbone) in a blameless culture.
- Brittleness:
- A system's tendency to fail, often abruptly, when conditions differ from those it was trained on.
- Robustness:
- A system's ability to maintain performance across varied, noisy, unexpected or manipulated conditions.
- Hallucination (confabulation):
- A generative model producing fluent, confident output that is false or unsupported.
- Root cause analysis:
- A structured investigation that traces an incident past its symptoms to the underlying cause that must be fixed.
- Fishbone (Ishikawa) diagram:
- A root-cause tool that groups candidate causes into categories such as data, model, process, people and environment.
- Catastrophic forgetting:
- When retraining or fine-tuning on new data makes a model abruptly lose capabilities it had before.
Exam tips: 'Patch and close' and 'blame the vendor first' are traps. The IAPP answer documents the incident and runs cross-functional root-cause analysis before choosing a corrective action. · A known, foreseeable condition that was never tested points to insufficient testing, even if the failure looks like brittleness. · A suspiciously fast single-team diagnosis that matches that team's specialty is a cue for cross-functional review. · Hallucination applies to generative models; don't pick it for a classifier or scoring model. Old skills vanishing after a fine-tune or retrain is catastrophic forgetting, not drift.
- ✓Technical documentation proves compliance (regulators); instructions for use enable safe operation (deployers).
- ✓The post-market monitoring plan sits inside the technical documentation.
- ✓Transparency reports and model or system cards tell the public, and some laws now require them.
- ✓Disclosures are living documents with a boundary: enable safe use, don't arm attackers.
- Technical documentation (EU AI Act Art. 11):
- The detailed, up-to-date file showing how a high-risk system meets the Act's requirements, kept for authorities and set out in Annex IV.
- Instructions for use:
- Provider-written guidance that lets deployers operate a high-risk system correctly, including its purpose, accuracy, limits, risks and oversight needs (Art. 13).
- Post-market monitoring plan:
- The documented plan for how a provider will collect and analyze real-world performance data; part of the technical documentation (Art. 72).
- Transparency report:
- A public summary of a system's capabilities, limitations, testing and risk management, voluntary or required by some laws.
- EU database for high-risk AI:
- The public EU register where providers record high-risk systems, including electronic instructions for use for most of them (Arts. 49 and 71).
Exam tips: Match the document to the audience: technical documentation for regulators, instructions for use for deployers, transparency reports for the public. · If a deployer misuses a system because the instructions hid its limits, the provider's disclosure failed. Instructions for use are how providers enable correct deployment. · Transparency isn't 'publish everything.' Options that release exploit details, personal data or source code are traps. · The FRIA is a deployer duty. Don't pick it when the question asks what the provider owes.
- ✓Separate development, test or staging, and production; promote only through the pipeline.
- ✓Segregate duties so no one person can build, approve and deploy alone.
- ✓A model registry ties each version to its data, results, owner and status: traceable, repeatable, reversible.
- ✓Secure the pipeline: signed artifacts, restricted triggers, dependency scans, rogue-deployment alerts, tamper-evident logs.
- Environment separation:
- Keeping development, test or staging, and production apart, with models promoted only through an approved pipeline.
- Segregation of duties:
- A control ensuring no single person can build, approve and deploy a change alone.
- Model registry:
- The single record of every model version, with its hash, dataset versions, evaluation results, owner, approvals and status.
- Rogue deployment:
- A model running in production that didn't come through the approved pipeline or isn't in the registry.
- Artifact signing:
- Cryptographically signing model files so the pipeline can verify they haven't been altered before deployment.
Exam tips: Development, test or staging, and production stay separate; models move only through an approved pipeline. 'Copy it from the laptop' and 'give developers production admin' are traps. · Segregation of duties: nobody builds, approves and deploys alone. · Traceability question (which model and data made this decision?) → a model registry linking versions to datasets, kept after retirement. · An unregistered model in production is an incident: contain (roll back), preserve evidence, investigate. Never 'register it so the records match'.
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.
