At a glance
Domain IV is the deployer’s domain. Where Domain III is about building a system, Domain IV is about choosing, assessing, deploying and running one — whether you built it or bought it. Competency IV.A covers the decision to deploy: before any system goes live you must (1) understand the use-case context, (2) understand the differences between AI model types so you pick the right one, and (3) understand the deployment options — both where it runs and how it is adapted.
A useful framing: the deploy decision is a series of fit-and-risk trade-offs. Each choice (model type, hosting location, adaptation technique) buys you capability or control at the cost of effort, money, privacy exposure or governance burden. The job is to match the choice to the use case and its risk level — not to default to the most powerful option.
IV.A.1 — Understand the context of the AI use case
Before evaluating which AI, evaluate whether and where AI fits. The BOK lists five context factors — learn them:
- Business objectives — what problem is being solved and what does success look like? AI should map to a real objective, not be adopted for its own sake. A weak objective makes every downstream choice arbitrary.
- Performance requirements — required accuracy, latency, throughput, availability and the cost of error. A medical triage tool and a marketing-copy assistant tolerate wildly different error rates; this drives both model choice and how much oversight is needed.
- Data availability — do you have enough relevant, high-quality, lawfully usable data (for training, fine-tuning, RAG or evaluation)? Data dependency is the most common reason an AI project stalls.
- Ethical considerations — fairness, potential for harm, affected groups, dignity and rights. Some use cases (e.g., social scoring, manipulative or subliminal systems) are off-limits regardless of performance, and the EU AI Act prohibits several outright.
- Workforce readiness — do staff have the AI literacy, training and processes to operate and oversee the system responsibly? The EU AI Act makes AI literacy an explicit obligation (Art. 4). Deploying into an unprepared workforce is itself a risk.
IV.A.2 — Differences in AI model types
Choosing a model is choosing a set of trade-offs along several axes. The BOK names four; know what each buys and costs.
| Axis | Option A | Option B | Deployer trade-off |
|---|---|---|---|
| Output type | Classic / discriminative (predicts, classifies, scores) | Generative (creates new content) | Classic is narrower, often cheaper, more interpretable, easier to validate; generative is flexible but hallucinates, is harder to evaluate, and raises IP/data-use questions. |
| Openness | Proprietary / closed (API to vendor’s hosted model) | Open-source / open-weight (self-hosted, modifiable) | Closed = fast start, managed safety/updates, but lock-in, less control, data leaves your boundary. Open = full control, on-prem privacy, customization — but you own safety, security, patching and compute. |
| Size | Small (fewer parameters) | Large (foundation-scale) | Small = cheaper, faster, lower latency, deployable at the edge, easier to govern; large = more capable and general, but costly, slower, harder to explain and run locally. |
| Modality | Language / unimodal (text only) | Multimodal (text + image + audio + video) | Multimodal unlocks richer use cases but widens the attack and risk surface and complicates evaluation, consent and data governance. |
The right answer is rarely “the biggest, most general model.” A well-scoped small, classic model may beat a large generative one on cost, latency, explainability and governability for a narrow task — while a generative or multimodal model is justified only when the use case actually needs open-ended content or multiple modalities.
IV.A.3 — Differences in AI deployment options
Two distinct questions live here: where does it run and how is it adapted. The exam tests both.
Where it runs: cloud vs. on-premise vs. edge
| Location | Strengths | Weaknesses / risks |
|---|---|---|
| Cloud | Elastic scale, low upfront cost, managed updates and security, easy access to large models | Data leaves your boundary (privacy, residency, sovereignty), vendor lock-in, ongoing cost, dependency on connectivity |
| On-premise | Maximum control, data stays in-house (privacy/IP/residency), no third-party dependency | High capital and operating cost, you own all maintenance, scaling and security, slower to adopt new models |
| Edge (on-device) | Lowest latency, works offline, best data locality (data never leaves the device) | Constrained compute/memory (small models only), harder to update and monitor a fleet of devices, physical-access security risk |
The driving factors are latency, privacy/data residency, control, cost and scale. Highly regulated or sensitive data pushes toward on-prem or edge; scale and speed-to-market push toward cloud.
How it is adapted: as-is, prompting, RAG, fine-tuning, agentic
These are not interchangeable — each suits a different goal and carries different governance implications. Order them by cost and intrusiveness:
| Technique | What it changes | Best for | Governance implications |
|---|---|---|---|
| Use as-is / prompt engineering | Nothing in the model; only the instructions/examples in the prompt | Quick wins, general tasks, prototyping | Cheapest and fastest; lowest burden, but behaviour is least controllable and can drift if the vendor updates the model |
| Retrieval-augmented generation (RAG) | Adds external documents at inference time; weights unchanged | Grounding answers in current, proprietary or citable data; reducing hallucination without retraining | Requires data governance over the knowledge base (access control, freshness, provenance); answers only as good/secure as the retrieved corpus |
| Fine-tuning | The model’s weights, via further training on your data | Consistent domain style, format or vocabulary the base model can’t reliably follow | Needs quality labelled data, compute and re-validation; risk of memorizing/leaking training data, embedding bias, and re-testing obligations on every retrain |
| Agentic architecture | Lets the model plan and act over multiple steps, calling tools/systems | Complex multi-step workflows requiring autonomy and tool use | Highest capability and highest risk: tool misuse, cascading errors, reduced human oversight — demands guardrails, action limits and strong monitoring |
A common rule of thumb: reach for the lightest technique that meets the requirement. Try prompting first; add RAG when you need grounding/freshness; fine-tune when you need durable behavioural change; adopt agentic designs only when the workflow genuinely requires autonomous multi-step action — and govern them most tightly.
How this shows up later
- The model and deployment choices here determine the obligations you assess in IV.B (impact assessment, vendor terms, proprietary-model liability).
- Agentic and generative choices raise the autonomy and harm characteristics from I.A, demanding the tighter monitoring and oversight controls in IV.C.
- The deployer perspective ties directly to EU AI Act deployer obligations and the NIST AI RMF Manage function, both revisited in IV.C.