📌 Note: This is an independently prepared study aid based on the publicly available AIGP BoK domain outline. It is not an official IAPP publication. Domain IV covers deployment practice and governance; where it touches specific legal obligations (for example, provider versus deployer reporting duties), verify the current statutory text before relying on it professionally, as those rules evolve.
1. Introduction and How to Use This Material
Domain IV is one of the two heaviest domains on the AIGP exam, carrying 21–25 questions. Where Domain III governs how an AI system is built, Domain IV governs how it is chosen, deployed, operated, and eventually retired, from the point of view of the organization putting the system into use.
It is split across three competencies:
- IV.A, Evaluate key factors and risks relevant to the decision to deploy (6–8 questions)
- IV.B, Perform key activities to assess the AI system (5–7 questions)
- IV.C, Govern the deployment and use of the AI system (9–11 questions)
IV.C is the single heaviest competency on the entire exam, tied with Domain III's III.C.
The relationship between Domain III and Domain IV
These two domains overlap deliberately, and the exam expects you to keep them apart:
- Domain III is the development and release side, the perspective of whoever builds, trains, tests, and releases the system. The actor is a developer or provider.
- Domain IV is the deployment and use side, the perspective of whoever selects a system (often built by someone else), decides whether to deploy it, and operates it responsibly over its lifetime. The actor is a deployer.
The same organization can occupy both roles. But a Domain IV question is written from the seat of the deployer: should we deploy this, on what terms, and how do we run it safely?
How to use this guide
- Domain IV applies whether an organization deploys a third-party system or its own proprietary model. The BoK is explicit that deploying your own model brings additional obligations and higher potential liability (IV.B).
- Sections 5–10 (lifecycle diagram, comparison tables, exam traps, knowledge check, mnemonics, 25-fact page) are for revision. Work through Sections 2–4 first.
- Watch for the recurring exam theme: accountability is non-delegable. A deployer cannot contract away, outsource, or "instructions-defence" its way out of responsibility for how a system behaves in its context.
2. Competency IV.A: Evaluating the Decision to Deploy
Before any system is deployed, the governance professional helps the organization decide whether and how to deploy it. That decision rests on understanding the use-case context, the type of model, and the deployment options.
2.1 Understanding the Context of the Use Case
A deployment decision cannot be made in the abstract. The BoK identifies the factors that define the context:
| Factor | Questions to ask |
|---|---|
| Business objectives | What problem does this solve? What does success look like, and how will it be measured? |
| Performance requirements | What accuracy, latency, reliability, and availability does the use case actually require? A triage tool and a marketing recommender have very different thresholds. |
| Data availability | Is the data the system needs available, sufficient, lawful to use, and representative of the deployment population? |
| Ethical considerations | Does the use case involve consequential decisions, vulnerable populations, or significant potential for harm? |
| Workforce readiness | Do the people who will operate, oversee, and rely on the system have the skills and training to do so? Is the organization ready to absorb the change? |
Workforce readiness is easy to overlook and frequently tested: a technically sound system deployed to a workforce that cannot oversee it, or does not trust it, or is not trained on it, will fail in practice.
2.2 Differences in AI Model Types
The type of model shapes the risks, the obligations, and the governance approach. The BoK names several axes of difference:
| Axis | Distinction | Governance implication |
|---|---|---|
| Classic vs. generative | Classic/predictive models output scores, classes, or forecasts; generative models produce new content. | Generative models add risks of fabricated ("hallucinated") output, content-safety issues, and IP/attribution questions. |
| Proprietary vs. open source | A closed vendor model vs. an openly available one. | Proprietary: less transparency, vendor dependency. Open source: more control and inspectability, but the deployer owns more of the assurance burden. |
| Small vs. large | Smaller task-specific models vs. large foundation models. | Large models are more capable but costlier, harder to explain, and more resource-intensive; small models can run on constrained hardware and are easier to validate. |
| Language vs. multimodal | Text-only vs. models handling images, audio, video, or combinations. | Multimodal systems expand the attack surface and the range of possible harms (for example, biometric inference, synthetic media). |
📘 Study tip The exam may give a set of constraints (offline, low-cost hardware, narrow task) and ask which model type fits. Match the model to the constraints: constrained environment and narrow task point to a small, efficient model; broad content generation points to a large or generative model.
2.3 Differences in Deployment Options
How a model is hosted and adapted matters as much as which model it is.
Where the model runs:
| Option | Characteristics | Governance considerations |
|---|---|---|
| Cloud | Hosted by a provider, accessed over the network. | Scalability and low upfront cost, but cross-border data transfer, vendor dependency, and data-in-transit exposure. |
| On-premise | Runs on the organization's own infrastructure. | More control and data residency, but higher cost and maintenance burden. |
| Edge | Runs on local or embedded devices. | Works offline and reduces data transmission, but constrained compute and harder to update and monitor centrally. |
How the model is adapted:
| Technique | What it does | Governance implication |
|---|---|---|
| As-is (off-the-shelf) | Use the base model without modification. | Fastest, but the deployer inherits the base model's limitations and biases. |
| Fine-tuning | Further-train the model on domain-specific data. | Improves fit, but the deployer takes on data-governance and may take on provider-like obligations. |
| Retrieval-augmented generation (RAG) | Ground responses in an external knowledge source at query time. | Reduces fabrication and keeps knowledge current without retraining, but the retrieval source must itself be governed. |
| Agentic architectures | The model plans and takes multi-step actions, often invoking tools. | Autonomy raises the stakes: actions in the world require stronger oversight, guardrails, and the ability to stop the system. |
📘 Study tip Fine-tuning or substantially modifying a third-party model can turn a deployer into a provider for regulatory purposes, inheriting provider obligations. This crossover is a favourite exam theme, see Section 3.3 and the exam traps.
3. Competency IV.B: Assessing the AI System
Once a candidate system is identified, the deployer must assess it before committing. The BoK names three activities: an impact assessment, evaluation of the vendor agreement, and understanding the special risks of deploying one's own proprietary model.
3.1 Impact Assessment on the Selected System
The deployer performs or reviews an impact assessment on the specific system it intends to deploy, in its intended context. This is distinct from any assessment the developer performed, because the deployment context introduces new factors: a different population, a different purpose, different data, and different downstream consequences.
A deployment-stage impact assessment addresses:
- The intended use and the populations affected in this deployment.
- Potential harms and affected rights in this context.
- Whether the system's validated performance holds for the deployer's actual population.
- Residual risks and the controls the deployer will apply.
- Whether to proceed, proceed with conditions, or decline.
Where the system is high-risk and the deployer falls within scope, this may take the form of a fundamental rights impact assessment (FRIA) under the EU AI Act, and may sit alongside a DPIA where personal data is involved. All three can be required for the same deployment.
3.2 Vendor and Licensing Agreement Terms
When a system is licensed from a third party, the contract is a primary governance instrument. The deployer must identify and evaluate key terms and risks, because the contract allocates responsibility, and default vendor terms usually allocate it away from the vendor.
Terms that demand scrutiny:
| Contract term | Why it matters |
|---|---|
| Liability allocation | Vendors often disclaim liability for outcomes produced using the model. A disclaimer allocates cost between the parties but does not transfer the deployer's accountability to those affected. |
| Data use and reuse rights | Vendors may reserve the right to use data submitted for scoring to train their own products, a confidentiality and privacy exposure. |
| Model change / update rights | Vendors may update the model at any time, sometimes silently. Without notice and version tracking, the deployer's system can change behaviour unexpectedly. |
| Audit and transparency rights | Whether the deployer can obtain documentation, performance data, and bias testing, and whether it can audit. |
| Security commitments | The vendor's security obligations, breach-notification duties, and sub-processor controls. |
| Exit and termination | Whether the deployer can disengage, migrate, or deactivate the system, and on what terms. |
📘 Study tip A liability disclaimer in a vendor contract is a classic trap. It reallocates financial risk between the two companies; it does not discharge the deployer's governance and legal accountability to regulators or affected individuals. Accountability is non-delegable.
3.3 Risks and Opportunities of Deploying Your Own Proprietary Model
An organization that deploys its own proprietary model, rather than a third party's, occupies more of the value chain and inherits more of the obligation. The BoK is explicit that this brings increased obligations and higher potential liability.
| Dimension | Third-party model | Own proprietary model |
|---|---|---|
| Control | Lower, bounded by vendor | Higher, full control of design and data |
| Transparency | Often limited | Full internal visibility |
| Obligations | Shared with provider | Concentrated on the organization |
| Liability exposure | Partly allocable by contract | Higher and less transferable |
| Assurance burden | Partly carried by vendor | Carried in full by the organization |
The opportunity is greater control, differentiation, and the ability to tailor the system. The cost is that the organization becomes solely responsible for compliance across the lifecycle, with no vendor to share the burden.
4. Competency IV.C: Governing Deployment and Use
IV.C is the operational heart of Domain IV and the heaviest competency on the exam. It covers everything that happens once a system is live.
4.1 Applying Policies and Controls to Deployment
The BoK groups the deployment-stage governance activities as data governance, risk management, issue management, and user training.
| Activity | What it means in deployment |
|---|---|
| Data governance | Governing the data the system consumes in operation, quality, lawful basis, and protection of inputs (including confidential data fed to generative tools). |
| Risk management | Maintaining a live view of the system's risks, updating the risk register as conditions change. |
| Issue management | A defined process for logging, triaging, and resolving issues that arise in operation, distinct from full incidents. |
| User training | Ensuring the people who use and oversee the system understand its purpose, limitations, correct use, and how to escalate concerns. |
4.2 Continuous Monitoring, Maintenance, and Retraining
Deployment is the start of a new governance phase, not the end of one. AI systems are dynamic: their environment shifts, inputs drift, and performance changes.
What to monitor continuously:
| Dimension | What to watch |
|---|---|
| Performance | Accuracy and task-appropriate metrics staying within bounds. |
| Fairness | Subgroup disparities stable and within agreed limits. |
| Data drift | Input distribution shifting away from the training distribution. |
| Model / concept drift | The real-world relationship the model was trained on changing. |
| Error patterns | Errors clustering in particular groups, contexts, or times. |
| Usage patterns | Signs of misuse, out-of-scope use, or use by unintended populations. |
Maintenance and retraining must run on a defined schedule, with triggered retraining when monitoring thresholds are breached before the scheduled cycle.
📘 Study tip Distinguish data drift (the inputs have changed distribution) from model/concept drift (the real-world relationship has changed). Both degrade performance but require different diagnoses. A behaviour change with unchanged inputs and no input drift points to something else entirely, often a silent vendor model update (see the exam traps).
4.3 Periodic Assessment: Audits, Red Teaming, Threat Modeling
On top of continuous monitoring, the BoK requires periodic, deeper assessments.
| Assessment | Purpose |
|---|---|
| Audit | Independent review that the system operates within its documented controls and that governance is actually working. |
| Red teaming | Adversarial testing to find failure modes, bias, unsafe outputs, and ways to manipulate or bypass the system, especially for generative and agentic systems. |
| Threat modeling | Structured analysis of attack vectors and failure scenarios before they occur. |
| Security testing | Ongoing penetration and adversarial-robustness testing post-deployment, not only at release. |
4.4 Incident, Issue, and Post-Market Documentation
The BoK requires documenting incidents, issues, risks, and post-market monitoring plans.
Post-market monitoring is a documented, forward-looking process, not merely a set of live dashboards. It defines what will be systematically collected and analysed over the system's lifetime, measured against intended purpose, with defined triggers for corrective action and escalation. Operational dashboards are an input to it, not a substitute for it.
Incident response follows a structured sequence:
DETECT → CONTAIN → ASSESS → REMEDIATE → REPORT → LEARN
A note on serious-incident reporting: obligations vary by legal regime. As a general rule, where a system is supplied by a provider, the primary reporting duty commonly rests with that provider, but the deployer is not passive, it must promptly notify the provider and comply with any reporting obligations the governing regime places on it. A deployer cannot assume the provider's responsibilities remove its own governance duties, and cannot simply do nothing externally. (Verify the specific duties under the applicable law before relying on them.)
4.5 Secondary and Unintended Uses and Downstream Harms
A distinctive Domain IV obligation: the deployer must forecast and reduce risks of secondary or unintended uses and downstream harms.
A model validated for one purpose carries no assurance for another. When its outputs are repurposed, for instance, resume-screening scores quietly reused to inform promotions or layoffs, the new use has never been assessed, and harm can result. Governance means anticipating these drift-into-new-use scenarios and controlling them, so that outputs are not repurposed beyond the validated intended use without a fresh assessment.
4.6 External Communication Plans
The deployer must establish external communication plans, knowing, in advance, who will be told what, and how, when something goes wrong or when disclosure is required. This includes:
- Transparency notices to users (for example, that they are interacting with AI, or that a decision was automated).
- Communication to affected individuals where an incident or adverse decision requires it.
- Coordinated messaging to regulators, partners, and the public during an incident.
- Clear internal ownership of external communication, so messaging is not improvised under pressure.
4.7 Deactivation and Localization Controls
The BoK requires the deployer to create and implement a policy and controls to deactivate or localize an AI system as necessary, for example, due to regulatory requirements or performance issues.
This is the ability to stop or contain the system, and it is a control in its own right. Validation and monitoring do not remove the need for it, because some situations require an immediate stop that neither can provide:
- A regulator orders suspension.
- A safety-critical malfunction emerges.
- A vulnerability is being actively exploited.
- Performance degrades beyond acceptable limits.
"Localize" means restricting the system, for example, to a narrower scope, region, or function, rather than shutting it down entirely. Both the full stop and the localized restriction must be designed in advance, not improvised.
📘 Study tip A common wrong answer holds that a system which "passed all validation" needs no deactivation capability. Validation reduces expected failures; it cannot cover regulatory suspension, novel malfunctions, or active exploitation. The ability to stop is a required control regardless of how well the system tested.
5. The Deployment Governance Lifecycle: End-to-End View
Domain IV covers the deployment side of the lifecycle. Here it is end to end, from the deploy decision through retirement.
┌────────────────────────────────────────────────────────────────┐
│ AI DEPLOYMENT GOVERNANCE LIFECYCLE │
└────────────────────────────────────────────────────────────────┘
┌─────────────────┐
│ 1. USE-CASE & │ Business objectives, performance needs,
│ CONTEXT EVAL │ data availability, ethics, workforce
│ (IV.A) │ readiness; model type; deployment option.
└────────┬────────┘
│ Gate: is deployment appropriate at all?
┌────────▼────────┐
│ 2. SYSTEM │ Impact assessment in context; vendor and
│ ASSESSMENT │ licensing terms; own-model risk/liability.
│ (IV.B) │
└────────┬────────┘
│ Gate: acceptable on terms and in this context?
┌────────▼────────┐
│ 3. DEPLOYMENT │ Data governance, risk & issue management,
│ CONTROLS │ user training, human oversight, guardrails.
│ (IV.C) │
└────────┬────────┘
│ Gate: controls in place before go-live?
┌────────▼────────┐
│ 4. CONTINUOUS │ Performance, fairness, drift, error and
│ MONITORING │ usage patterns; maintenance & retraining
│ (IV.C) │ on schedule and on trigger.
└────────┬────────┘
│
┌────────▼────────┐
│ 5. PERIODIC │ Audits, red teaming, threat modeling,
│ ASSESSMENT │ security testing.
│ (IV.C) │
└────────┬────────┘
│
┌────────▼────────┐
│ 6. INCIDENT & │ Detect, Contain, Assess, Remediate,
│ COMMS │ Report, Learn; external communication
│ (IV.C) │ plans; post-market monitoring records.
└────────┬────────┘
│
┌────────▼────────┐
│ 7. SECONDARY- │ Forecast and control unintended uses and
│ USE CONTROL │ downstream harms; reassess on repurposing.
│ (IV.C) │
└────────┬────────┘
│
┌────────▼────────┐
│ 8. DEACTIVATE │ Policy and controls to stop or localize
│ / LOCALIZE │ the system when required.
│ (IV.C) │
└─────────────────┘
📘 Study tip Each stage has a governance gate. "We deployed it and it works" is not governance. "We evaluated context and terms, applied controls before go-live, monitored continuously, assessed periodically, and retained the ability to stop it" is governance.
6. Comparison Tables
6.1 Provider vs. Deployer (Domain IV lens)
| Aspect | Provider (Domain III seat) | Deployer (Domain IV seat) |
|---|---|---|
| Core question | How do we build and release this safely? | Should we deploy this, on what terms, and how do we run it? |
| Owns | Design, training, testing, release documentation | Deployment context, operation, oversight in use |
| Impact assessment | Pre-market / design-stage | In-context deployment assessment (and FRIA where applicable) |
| Primary incident-reporting duty | Commonly the provider | Notify provider, comply with own applicable obligations |
| Role can flip? | No | Yes: substantial modification, rebranding, or re-purposing can make a deployer a provider |
6.2 Deployment Location Options
| Cloud | On-premise | Edge | |
|---|---|---|---|
| Upfront cost | Low | High | Varies |
| Data residency / control | Lower | Higher | Highest (local) |
| Scalability | High | Limited | Limited |
| Works offline | No | Yes (internal) | Yes |
| Update / monitor centrally | Easy | Moderate | Hard |
| Key risk | Cross-border transfer, vendor dependency | Cost, maintenance | Constrained compute, update lag |
6.3 Model Adaptation Techniques
| Technique | Retrains the model? | Main benefit | Main governance cost |
|---|---|---|---|
| As-is | No | Fastest to deploy | Inherits base-model limitations |
| Fine-tuning | Yes | Domain fit | Data governance; may trigger provider obligations |
| RAG | No | Current, grounded answers | The retrieval source must be governed |
| Agentic | No (adds autonomy) | Multi-step task completion | Actions in the world need stronger oversight and a stop control |
6.4 Continuous Monitoring vs. Periodic Assessment
| Aspect | Continuous monitoring | Periodic assessment |
|---|---|---|
| Frequency | Real-time / near-real-time | Scheduled or event-triggered |
| Method | Automated metrics, dashboards, alerting | Human-led audit, red team, threat modeling |
| Detects | Early degradation and incidents | Deeper governance, robustness, and security gaps |
| Output | Alerts, incident triggers, logs | Audit reports, red-team findings, updated risk register |
6.5 Data Drift vs. Model Drift vs. Vendor Update
| Symptom source | What changed | Signature | Control |
|---|---|---|---|
| Data drift | Input distribution | Inputs statistically shifted from training | Retrain on recent data |
| Model / concept drift | Real-world relationship | Accuracy falls against ground truth over time | Reassess and possibly redesign |
| Silent vendor update | The vendor's model version | Behaviour shifts with unchanged inputs and no input drift | Change management: notification, version logging, re-validation |
7. Exam Traps
⚠ Exam Trap 1, A liability disclaimer does not transfer accountability. A vendor clause disclaiming liability allocates financial risk between the two companies. It does not discharge the deployer's governance and legal accountability to regulators or affected individuals.
⚠ Exam Trap 2, "We followed the provider's instructions" is a floor, not a ceiling. Following instructions for use is necessary but not sufficient. The deployer still owes human oversight and monitoring in its own context, including acting on a known divergence between its real population and the validated one.
⚠ Exam Trap 3, Passing validation does not remove the need for a deactivation control. The ability to stop or localize a system is a control in its own right. Validation cannot cover regulatory suspension, novel malfunctions, or active exploitation.
⚠ Exam Trap 4, A behaviour change with unchanged inputs is probably not drift. If inputs are unchanged and no input drift is detected, suspect a silent vendor model update. The fix is change management and version tracking, not retraining your own data.
⚠ Exam Trap 5, Post-market monitoring is a documented process, not a dashboard. Live operational dashboards are an input to post-market monitoring, not the whole of it. The plan is a forward-looking documented process with defined analysis and escalation triggers.
⚠ Exam Trap 6, Containment is not the same as reporting. Switching to a manual process and containing harm reduces ongoing damage, but it does not by itself discharge notification and reporting duties for harm already caused.
⚠ Exam Trap 7, Validation for one purpose does not license reuse for another. Repurposing a model's outputs for a use it was never validated for is a governance failure. Secondary and unintended uses must be forecast and controlled, with fresh assessment before repurposing.
⚠ Exam Trap 8, Chasing the optimization metric can defeat the objective. When a deployed system optimizes a narrow proxy (for example, watch time) and produces harmful downstream effects, the fix is to broaden the objective and add guardrail metrics, not to push the proxy harder, and not to shut the system down entirely.
⚠ Exam Trap 9, Match oversight strength to stakes and volume. An irreversible, rights-critical, low-volume decision warrants human-in-the-loop (approve each case). Aggregate-only or after-the-fact oversight is too weak, and merely naming an accountable human is not oversight.
⚠ Exam Trap 10, A blanket ban is rarely the governed response to shadow AI. When an unsanctioned deployment is discovered, the proportionate first step is to bring it under governance, assess, contain, evaluate data exposure, and route it through controls or restrict it, not to ban an entire technology or to do nothing.
8. Knowledge Check Questions
1. An organization is deciding whether to deploy an AI system to a workforce that has had no training on it and does not trust its outputs. Which deployment-context factor is MOST directly at issue?
- A. Performance requirements.
- B. Data availability.
- C. Workforce readiness.
- D. Model type selection.
Answer: C. Workforce readiness, whether the people who will operate, oversee, and rely on the system are equipped to do so, is a named IV.A context factor and is exactly what is missing here.
2. A deployer fine-tunes a third-party foundation model on its own data and markets the result under its own brand. From a governance standpoint, the MOST important consequence is:
- A. The deployer has reduced its obligations because the base model was pre-validated.
- B. The deployer may now be treated as a provider and inherit provider obligations.
- C. The vendor becomes solely responsible for the fine-tuned model.
- D. No governance consequence follows from fine-tuning.
Answer: B. Substantial modification, fine-tuning, or rebranding can turn a deployer into a provider for regulatory purposes, bringing provider obligations. It increases rather than reduces obligations.
3. A vendor's standard contract disclaims all liability for outcomes produced using its model. A deployer relies on this clause to conclude it bears no responsibility for a harmful automated decision. The flaw is:
- A. There is no flaw; the disclaimer transfers all responsibility to the vendor.
- B. A liability disclaimer allocates cost between the parties but does not transfer the deployer's accountability to regulators or affected individuals.
- C. Disclaimers are always unenforceable, so it has no effect.
- D. The deployer should have demanded the model's source code instead.
Answer: B. Accountability is non-delegable. A disclaimer reallocates financial risk between the companies; it does not discharge the deployer's governance and legal accountability to third parties.
4. Nine weeks after launch, a licensed AI system's decision patterns shift. Inputs are unchanged, configuration is unchanged, and no input drift is detected. The MOST likely explanation is:
- A. Concept drift; retrain the deployer's own model.
- B. Data drift; apply stricter input schema checks.
- C. A silent vendor model update; the missing control is change management and version tracking.
- D. Overfitting; collect more training data.
Answer: C. A behaviour change with unchanged inputs and no input drift points to a version change on the vendor's side. The control is change-management (notification, version logging, re-validation), not retraining or schema checks.
5. A deployed recommender is optimized purely for watch time. Watch time rises, but sensational content, complaints, and cancellations rise with it. The MOST appropriate response is:
- A. Do nothing; the chosen metric is improving.
- B. Increase the weight on watch time.
- C. Recognize the metric as too narrow a proxy and govern the objective, broaden it and add guardrail metrics and downstream-harm monitoring.
- D. Permanently shut down the recommender.
Answer: C. This is metric-objective divergence (specification gaming). The fix is to correct and broaden the objective with guardrails, not to chase the proxy or to abandon the system.
6. A high-risk clinical AI causes a serious incident in a hospital that deployed it. A manager says only the provider that built it must act externally. The MOST accurate position is:
- A. The manager is correct; the deployer does nothing externally.
- B. The deployer must promptly notify the provider and comply with any applicable reporting obligations under the governing regime; it cannot assume the provider's duties remove its own.
- C. The deployer must always file the primary report itself in every case.
- D. No external action is needed because manual triage contained the harm.
Answer: B. The provider commonly holds the primary reporting duty, but the deployer must at minimum notify the provider and meet its own applicable obligations. Doing nothing is wrong; so is assuming the deployer is always the primary reporter.
7. Resume-screening scores are quietly reused by another team to inform layoffs, a use the model was never validated for. The neglected deployment-governance obligation is:
- A. To expand the model to as many internal uses as possible.
- B. To forecast and control secondary or unintended uses and downstream harms.
- C. To publish the model's source code internally.
- D. None; validation for one purpose covers all internal reuse.
Answer: B. Validation is purpose-specific. Outputs must not be repurposed beyond the validated use without fresh assessment; forecasting and controlling secondary use is a named IV.C obligation.
8. An autonomous industrial control AI has passed all validation. Operations argues no stop-or-rollback capability is needed. The strongest governance response is:
- A. Operations is right; validated systems need no deactivation control.
- B. Monitoring will always catch problems in time to fix in place.
- C. Implement a policy and controls to deactivate or localize the system, since validation cannot cover suspension orders, novel malfunctions, or active exploitation.
- D. Run the system fully manually, abandoning autonomy.
Answer: C. The ability to stop or localize is a required control regardless of validation. Monitoring detects but does not stop, and abandoning autonomy entirely is disproportionate.
9. Mnemonics and Memory Aids
9.1 IV.A context factors: "BPD-EW"
- B, Business objectives
- P, Performance requirements
- D, Data availability
- E, Ethical considerations
- W, Workforce readiness
9.2 Deployment locations: "COE"
- C, Cloud
- O, On-premise
- E, Edge
9.3 Model adaptation techniques: "AFRA"
- A, As-is
- F, Fine-tuning
- R, RAG (retrieval-augmented generation)
- A, Agentic architectures
9.4 Vendor contract terms to scrutinise: "LDCASE"
- L, Liability allocation
- D, Data use / reuse rights
- C, Change / update rights
- A, Audit and transparency rights
- S, Security commitments
- E, Exit and termination
9.5 Incident response sequence: "DC-AR-RL"
- D, Detect
- C, Contain
- A, Assess
- R, Remediate
- R, Report
- L, Learn
9.6 IV.C governance duties: "MAP-SED"
- M, Monitor continuously (and maintain / retrain)
- A, Assess periodically (audit, red team, threat model)
- P, Policies and controls at deployment (data, risk, issue, training)
- S, Secondary-use and downstream-harm control
- E, External communication plans
- D, Deactivate / localize controls
10. If You Remember Only These 25 Facts
For final-day revision.
- Domain IV governs deployment and use from the deployer's seat; Domain III governs building and release from the provider's seat.
- Domain IV carries 21–25 questions; IV.C is the heaviest competency on the exam.
- The IV.A context factors are business objectives, performance requirements, data availability, ethical considerations, and workforce readiness.
- Workforce readiness is a real deployment factor, a system a workforce cannot oversee or trust will fail in practice.
- Model type axes: classic vs generative, proprietary vs open source, small vs large, language vs multimodal.
- Match the model to the constraints, constrained/offline/narrow points to a small efficient model.
- Deployment locations: cloud (scalable, transfer risk), on-premise (control, cost), edge (offline, constrained).
- Adaptation techniques: as-is, fine-tuning, RAG, agentic, each with distinct governance costs.
- Fine-tuning or substantially modifying a third-party model can make a deployer a provider, inheriting provider obligations.
- RAG reduces fabrication and keeps knowledge current without retraining, but the retrieval source must be governed.
- Agentic systems act in the world, they need stronger oversight, guardrails, and a stop control.
- The deployer performs an in-context impact assessment (and a FRIA where applicable), distinct from the developer's.
- Vendor contract terms to scrutinise: liability, data reuse, silent updates, audit rights, security, exit.
- A liability disclaimer reallocates cost between companies; it does not transfer accountability to regulators or affected people.
- Deploying your own proprietary model brings increased obligations and higher, less-transferable liability.
- Deployment controls: data governance, risk management, issue management, user training.
- Continuous monitoring covers performance, fairness, data drift, model/concept drift, error and usage patterns.
- Data drift = inputs shifted; model/concept drift = the real-world relationship changed; a behaviour change with unchanged inputs suggests a silent vendor update.
- Maintenance and retraining run on a schedule and on trigger.
- Periodic assessment: audits, red teaming, threat modeling, security testing, deeper than continuous monitoring.
- Post-market monitoring is a documented, forward-looking process, not just live dashboards.
- On serious incidents, the provider commonly holds the primary reporting duty, but the deployer must notify the provider and comply with its own applicable obligations, never "do nothing."
- Secondary and unintended uses must be forecast and controlled; validation for one purpose does not license reuse for another.
- External communication plans are prepared in advance, who is told what, and how.
- A deactivation / localization control is required regardless of validation, for suspension orders, malfunctions, exploitation, or performance failure.
11. Glossary
Agentic architecture: A deployment approach in which the AI plans and executes multi-step actions, often invoking tools, requiring stronger oversight and containment controls.
As-is deployment: Using a base model without modification, inheriting its limitations and biases.
Change management (for third-party models): The controls, notification, version logging, and re-validation, that track and govern changes a vendor makes to a deployed model.
Continuous monitoring: Real-time or near-real-time tracking of a deployed system's performance, fairness, drift, and usage.
Data drift: A shift in the statistical distribution of inputs a deployed model receives relative to its training distribution.
Deactivation / localization control: A pre-designed policy and mechanism to stop a system entirely or restrict it to a narrower scope, region, or function when required.
Deployer: The organization that uses an AI system in its activities, whether built in-house or by a third party.
Edge deployment: Running a model on local or embedded devices, enabling offline operation but constraining compute and central monitoring.
External communication plan: A prepared plan defining who is informed of what, and how, including user transparency notices and incident communications.
Fine-tuning: Further training a model on domain-specific data to improve fit; may bring provider obligations.
FRIA (Fundamental Rights Impact Assessment): An assessment required of certain deployers of high-risk AI under the EU AI Act, evaluating impacts on fundamental rights.
Human-in-the-loop / on-the-loop / over-the-loop: Oversight models of decreasing intervention strength: approving each decision, monitoring and able to intervene, and setting policy while reviewing aggregate performance, respectively.
Localize: To restrict a system's scope, region, or function rather than shutting it down entirely.
Model / concept drift: A change in the real-world relationship between inputs and the outcome a model was trained to predict, degrading performance over time.
Post-market monitoring: A documented, forward-looking process for collecting and analysing a deployed system's performance and risks over its lifetime, with defined triggers for action, distinct from live operational dashboards.
Proprietary model (own): A model an organization develops and deploys itself, bringing greater control but concentrated obligations and higher liability.
Provider: The entity that develops an AI system or places it on the market under its own name; a deployer can become a provider through substantial modification, rebranding, or repurposing.
Red teaming: Adversarial testing that attempts to elicit failures, bias, unsafe outputs, or ways to manipulate or bypass a deployed system.
Retrieval-augmented generation (RAG): Grounding a model's outputs in an external knowledge source at query time to reduce fabrication and keep answers current.
Secondary / unintended use: Use of a system or its outputs beyond the validated intended purpose, which must be forecast and controlled.
Serious-incident reporting: The obligation to report serious incidents to authorities; the primary duty commonly rests with the provider, while the deployer must notify the provider and meet its own applicable obligations.
Threat modeling: Structured analysis of potential attack vectors and failure scenarios for a deployed system.
Vendor / licensing agreement: The contract governing use of a third-party model, allocating liability, data rights, update rights, audit rights, security, and exit terms.