Overview
Understanding how to govern AI deployment and use is written from the deployer's viewpoint: an organization adopting an AI system, often from a vendor, or deploying its own model. It has three competencies and 13 performance indicators. IV.A covers the decision to deploy: the context of the use case, differences among model types such as classic versus generative, proprietary versus open source and small versus large models, and deployment options such as cloud, on-premise or edge, using a model as is or with enhancements like fine-tuning and retrieval-augmented generation. IV.B covers assessment: an impact assessment on the selected system, key terms and risks in vendor or licensing agreements, and the risks and opportunities of deploying a proprietary model of one's own. IV.C covers governing use: applying policy, monitoring and retraining, periodic assessment, documenting incidents and post-market monitoring plans, limiting secondary uses and downstream harms, external communication, and policies and controls to deactivate or localize a system.
IAPP allocates 21 to 25 scored items here, about 27% of the exam.
How it's tested
Domain IV questions usually describe an organization choosing, contracting for or operating an AI system. You decide which option fits the context, which contract term matters, what to monitor or how to respond when use drifts beyond the original purpose. Favor answers that keep the deployer in control of data, oversight and exit.
-
Choose the option
A use case with constraints on data, cost, latency or control is described, and you choose the model type, deployment location or enhancement method that fits.
-
Read the contract
A vendor agreement is summarized, and you identify the missing or risky term, such as training on customer data, audit rights, liability caps or incident notice.
-
Govern live use
A deployed system is being used for new purposes, producing complaints or facing a new law, and you choose the monitoring, communication or deactivation response.
A law firm wants a generative AI assistant that answers questions from its own precedents, which change weekly. Fine-tuning a model on the documents seems thorough but bakes in stale content and is hard to update or delete. Retrieval-augmented generation keeps documents in a controlled store, reflects updates immediately and supports citations. Given the changing content and confidentiality needs, retrieval is the better governance choice.
Performance indicators 13
Official performance indicators from the IAPP outline, in outline order.
IV.A.1 Understand the context of the AI use caseObjectives, performance needs, data, ethics and workforce.
- What it means
- This indicator covers the questions a deployer answers before choosing a system. IAPP's examples include business objectives, performance requirements, data availability and ethical considerations. Context also covers who is affected, the legal setting, the workforce impact and how much autonomy the system will have.
- What to understand
- The same tool can be low risk in one context and high risk in another: a summarization model is minor for meeting notes but significant for medical records. Context sets the needed accuracy, explainability, oversight and testing. If data is unavailable or unsuitable, the use case may not be viable. Workforce impact and stakeholder acceptance affect whether deployment succeeds.
- How it shows up
- A proposed deployment is described and you identify the context factor that changes the risk.
- Common confusion
- Judging a tool's risk by its technology rather than the setting in which it is used.
IV.A.2 Understand the differences in AI model typesClassic vs. generative, proprietary vs. open, small vs. large.
- What it means
- This indicator compares model types along several axes. Classic or traditional models predict, classify or score; generative models create text, images, code or audio. Proprietary models are accessed under vendor terms with limited visibility; open-source or open-weight models can be inspected, modified and self-hosted. Small models are cheaper and easier to run locally; large models are more capable but costlier and harder to evaluate.
- What to understand
- Each type carries different risks. Generative models bring hallucination, IP and content safety risk; classic models bring scoring bias and explainability issues. Open models give control and transparency but shift security and maintenance duties to the deployer and carry license conditions. Proprietary models limit inspection but come with vendor support and contractual commitments. Larger is not automatically better for a narrow task.
- How it shows up
- Requirements for control, cost, transparency or capability are given, and you choose the model type.
- Common confusion
- Assuming open-source models are free of license obligations or are automatically more transparent in practice.
IV.A.3 Understand the differences in AI deployment optionsCloud, on-premise, edge; as is or enhanced.
- What it means
- This indicator covers where and how a model runs. Location options are cloud, on-premise and edge devices. Usage options range from using a model as is, through prompt engineering and retrieval-augmented generation, to fine-tuning or further training on the organization's data.
- What to understand
- Cloud offers scale and speed but raises data transfer, residency and vendor dependence questions. On-premise gives control at higher cost. Edge suits low latency and privacy-sensitive local processing. RAG grounds outputs in controlled, updatable documents without changing model weights; fine-tuning changes the model and makes removing data harder. Each enhancement may change the deployer's legal role and risk profile.
- How it shows up
- A deployment need such as data residency or frequently changing content is described, and you choose the option.
- Common confusion
- Choosing fine-tuning to add frequently changing knowledge, where retrieval is easier to update and govern.
IV.B.1 Perform or review an impact assessment on the selected AI systemDeployer-side impact assessment of the chosen system.
- What it means
- This indicator covers assessing the specific system chosen for deployment, in the deployer's context. It uses vendor documentation, testing in the deployer's environment and stakeholder input. Where applicable, it includes a DPIA and, for certain AI Act deployers of high-risk systems, a fundamental rights impact assessment.
- What to understand
- The vendor's own assessment is an input, not a substitute, because the vendor does not know the deployer's population, workflow or data. Test the system on representative local data before relying on it. Record residual risk and who accepted it. Repeat the assessment when the use, user group or system version changes.
- How it shows up
- A deployer relies on a vendor's assessment alone, and you choose what is missing.
- Common confusion
- Accepting the vendor's bias audit as proof the system is fair in the deployer's setting.
IV.B.2 Identify and evaluate key terms and risks in the vendor or licensing agreementData use, IP, liability, audit and exit terms.
- What it means
- This indicator covers contract review for AI. Key terms include whether customer data or prompts train the vendor's models, data retention and location, confidentiality, ownership of outputs, IP indemnity, liability caps, warranties on performance, audit and transparency rights, incident and change notification, subcontractors, compliance responsibilities and termination and data return.
- What to understand
- Standard terms often favor the vendor, so negotiate what matters for the risk. Open-source and model licenses can restrict uses, require attribution or impose responsible-use conditions. Make sure the contract gives the information the deployer needs to meet its own obligations, such as instructions for use and logs. Watch for unilateral rights to change the model.
- How it shows up
- A vendor agreement is summarized and you pick the term that creates the greatest risk.
- Common confusion
- Focusing only on price and uptime while missing data use and model change terms.
IV.B.3 Identify and understand the risks and opportunities that are unique to a company deploying its own proprietary AI modelSelf-built model: control, cost and full accountability.
- What it means
- This indicator covers deploying a model the company built or trained itself. Opportunities include full control over design, data, updates and security, competitive differentiation, and no dependence on a vendor's roadmap or terms. Risks include high cost, scarce skills, full accountability for performance and compliance, and possibly taking on provider obligations.
- What to understand
- With no vendor to share responsibility, the organization must provide its own testing, documentation, monitoring and incident handling. If it places the system on the market or uses it for a high-risk purpose, it carries provider duties under the AI Act. Weigh the build-versus-buy decision against internal capability and the risk tier.
- How it shows up
- A company debates building its own model versus licensing one, and you identify the trade-off.
- Common confusion
- Assuming in-house models are lower risk because no third party is involved.
IV.C.1 Apply the policies, procedures, best practices and ethical considerations to the deployment of an AI systemUse policy, oversight, training and data handling.
- What it means
- This indicator covers applying organizational rules at deployment. It includes acceptable use policies, data handling rules for prompts and outputs, human oversight assignments, user training, access controls, notices to affected people and following the provider's instructions for use.
- What to understand
- Deployers must use high-risk systems according to instructions, assign trained human overseers, keep logs under their control and ensure input data is relevant. Users need to know the system's limits to avoid automation bias. Policies should state which data may be entered into which tools. Ethical review continues at deployment because real use can differ from design assumptions.
- How it shows up
- A system is about to go live and you identify the deployment control that is missing.
- Common confusion
- Assuming the vendor's design-time controls make deployer policies unnecessary.
IV.C.2 Conduct continuous monitoring of the AI model and system, and establish a regular schedule for maintenance, updates and retrainingDeployer monitoring and update management.
- What it means
- This indicator covers monitoring by the deployer in live use. It tracks output quality, user complaints, drift in the deployer's own data, fairness across the people served and changes the vendor makes. It also sets a schedule for updates, reviews and, where the deployer controls it, retraining or re-indexing data.
- What to understand
- Vendor model updates can change behavior without notice, so monitor after each version change and require notification in the contract. Generative systems need output sampling for hallucinations and harmful content. Deployers of high-risk AI Act systems must monitor operation and inform the provider of risks. Feedback channels from users and affected people are part of monitoring.
- How it shows up
- A vendor updates its model or complaints rise, and you choose the monitoring action.
- Common confusion
- Leaving all monitoring to the vendor because it operates the model.
IV.C.3 Conduct periodic activities to assess the AI system's performance, reliability and safetyDeployer audits, red teaming and threat modeling.
- What it means
- This indicator repeats the periodic assessment theme for systems in use. Deployers run audits, red teaming, threat modeling and bias reviews on the system as configured in their environment, including prompts, retrieval sources, integrations and user workflows.
- What to understand
- A model that passed the vendor's tests can fail in the deployer's configuration, for example when retrieval exposes confidential documents or integrations allow prompt injection. Some laws require periodic independent bias audits for certain uses, such as New York City's rule for automated employment decision tools. Results should update the impact assessment.
- How it shows up
- A deployed system needs scheduled assurance, and you choose the assessment that fits its configuration.
- Common confusion
- Relying on the vendor's annual audit without testing the deployer's own configuration.
IV.C.4 Document incidents, issues, risks and post-market monitoring plansDeployer records and post-market monitoring.
- What it means
- This indicator covers record keeping during use: incident logs, issue trackers, risk register updates and post-market monitoring plans. Under the AI Act, providers create the post-market monitoring plan, and deployers support it by monitoring use, keeping logs and reporting serious incidents and risks to the provider.
- What to understand
- Documentation shows that the deployer used the system responsibly if harm occurs. Keep records of who overrode outputs, complaints received and actions taken. Clarify in the contract how incidents are shared between deployer and vendor. Post-market monitoring plans should state what data is collected, how often it is reviewed and who acts on it.
- How it shows up
- An incident occurs in a vendor system, and you identify what the deployer must document and share.
- Common confusion
- Assuming only providers need incident records.
IV.C.5 Forecast and reduce risks of secondary or unintended uses and downstream harmsFunction creep, misuse and downstream effects.
- What it means
- This indicator covers uses beyond the approved purpose. Secondary uses include applying a tool approved for one task to another, such as using a customer sentiment model to evaluate staff. Downstream harms include outputs reused by other systems or people in ways that cause damage, and misuse by bad actors.
- What to understand
- Forecast foreseeable misuse during assessment and add controls: purpose limits in policy and contract, access restrictions, technical guardrails, output labeling and monitoring for new uses. A new purpose requires a new assessment and may change the risk tier. Privacy purpose limitation reinforces this control.
- How it shows up
- A team wants to reuse an approved tool for a different purpose, and you choose the governance response.
- Common confusion
- Treating a new use of an already-approved tool as automatically approved.
IV.C.6 Establish external communication plansNotices, regulators, media and affected people.
- What it means
- This indicator covers communicating with people outside the organization: customers and affected individuals, regulators, business partners, investors and the media. Plans cover routine transparency, such as notices that AI is used and how to contest decisions, and crisis communication after incidents.
- What to understand
- Prepare messages and owners before an incident, not during it. Communication must be accurate and consistent with legal duties, including AI Act transparency notices and breach notification rules. Overstated claims about AI create consumer protection exposure. Provide channels for feedback and appeal, which also feed monitoring.
- How it shows up
- An AI incident becomes public or a new AI feature launches, and you choose the communication step.
- Common confusion
- Treating external communication as a public relations task without legal and governance input.
IV.C.7 Create and implement a policy and controls to deactivate or localize an AI system as necessaryKill switches, rollback and regional restriction.
- What it means
- This indicator covers stopping or restricting a system. Deactivation turns it off or reverts to a fallback process; localization limits it to certain regions, users or functions, for example when a new law applies in one jurisdiction. IAPP's examples of triggers include regulatory requirements, among others such as serious incidents, performance failure and vendor termination.
- What to understand
- Plan deactivation before launch: define triggers, decision rights, technical means and the manual fallback that keeps the business running. Test the switch. Localization can keep a system available where lawful while restricting it elsewhere. Contracts should support data return and transition if a vendor system is shut down.
- How it shows up
- A serious harm or a new legal restriction appears, and you choose deactivation or localization controls.
- Common confusion
- Assuming a system can be switched off quickly without a planned fallback process.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Deployer
Organization using an AI system under its authority.
- Remember
- Keeps oversight, monitoring and log duties.
- Tested as
- Role questions.
- Trap
- Shifting all duties to the vendor.
-
Classic vs. generative models
Predict or classify versus create content.
- Remember
- Different risk profiles.
- Tested as
- Model type questions.
- Trap
- Applying hallucination controls to a scoring model only.
-
Open vs. proprietary models
Inspectable and self-hostable versus vendor-controlled.
- Remember
- Open shifts security and maintenance to the deployer.
- Tested as
- Model type questions.
- Trap
- Assuming open means no license terms.
-
Retrieval-augmented generation
Grounding outputs in documents retrieved at query time.
- Remember
- Easy to update; supports citations.
- Tested as
- Enhancement questions.
- Trap
- Using fine-tuning for changing knowledge.
-
Fine-tuning
Further training of a model on new data.
- Remember
- Changes weights; data hard to remove.
- Tested as
- Enhancement questions.
- Trap
- Thinking it is easily reversible.
-
Cloud vs. on-premise vs. edge
Hosted, in-house or on-device processing.
- Remember
- Trade control, cost, latency and residency.
- Tested as
- Deployment questions.
- Trap
- Ignoring data residency.
-
Vendor data use clause
Whether the vendor may train on customer data.
- Remember
- Often the highest-risk term.
- Tested as
- Contract questions.
- Trap
- Missing it in standard terms.
-
Model change notification
Vendor duty to notify of model updates.
- Remember
- Triggers re-testing.
- Tested as
- Contract and monitoring questions.
- Trap
- Assuming the model is static.
-
Automation bias
Over-trusting AI outputs.
- Remember
- Training and interface design reduce it.
- Tested as
- Oversight questions.
- Trap
- Assuming a human reviewer removes risk.
-
Function creep
Use drifting beyond the approved purpose.
- Remember
- New purpose means new assessment.
- Tested as
- Secondary use questions.
- Trap
- Treating reuse as pre-approved.
-
Deactivation and localization
Shutting down or limiting a system by region, user or function.
- Remember
- Plan triggers and fallback before launch.
- Tested as
- Control questions.
- Trap
- No manual fallback.
-
External communication plan
Prepared messages and owners for notices and incidents.
- Remember
- Accuracy avoids deception claims.
- Tested as
- Communication questions.
- Trap
- Leaving it to PR alone.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
RAG vs. fine-tuning vs. using as is
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Use as is | Vendor model with prompts only | Fastest, least control | Expecting domain accuracy without grounding |
| RAG | Retrieves approved documents at query time | Updatable, citable, weights unchanged | Forgetting access control on the document store |
| Fine-tuning | Further trains the model on new data | Changes behavior; hard to unlearn | Using it for fast-changing facts |
Model type trade-offs
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Proprietary | Accessed under vendor terms | Support and commitments, limited visibility | Assuming full transparency |
| Open source or open weight | Inspectable and self-hostable | Control with deployer-owned security | Ignoring license conditions |
| Small model | Fewer parameters, lower cost | Local and efficient for narrow tasks | Expecting broad reasoning |
| Large model | Broad capability | Higher cost and harder evaluation | Choosing it by default |
Deployment location
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Cloud | Vendor-hosted infrastructure | Scale with transfer and residency questions | Ignoring cross-border transfer rules |
| On-premise | Organization's own infrastructure | Control at higher cost | Assuming it is automatically secure |
| Edge | On devices near the user | Low latency, local data | Forgetting update and monitoring challenges |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Vendor audit is enough
- What candidates pick
- Rely on the vendor's published bias audit before deploying a hiring tool.
- Why it looks right
- The audit is independent and recent.
- Why it's wrong
- It reflects the vendor's test data, not the deployer's candidates or workflow, so local testing is still needed.
Clue to watch for The deployer's population differs from the vendor's test set.
-
Fine-tune for fresh facts
- What candidates pick
- Fine-tune a model on policy documents that change monthly.
- Why it looks right
- Fine-tuning sounds more thorough.
- Why it's wrong
- Retrieval keeps content current and removable; fine-tuning bakes in stale information and complicates deletion.
Clue to watch for Content changes often or must be cited.
-
Open means unrestricted
- What candidates pick
- Deploy an open-weight model commercially without reviewing its license.
- Why it looks right
- Open models are freely downloadable.
- Why it's wrong
- Model licenses can restrict uses, require attribution or impose acceptable use terms the deployer must follow.
Clue to watch for The model is described as open weight under a custom license.
-
Price and uptime first
- What candidates pick
- Prioritize service levels when reviewing an AI vendor contract.
- Why it looks right
- They are standard procurement concerns.
- Why it's wrong
- The higher AI risks are data use for training, model changes, liability and audit rights.
Clue to watch for The contract is silent on customer data use.
-
Reuse is pre-approved
- What candidates pick
- Let HR use a customer sentiment tool to score employee messages.
- Why it looks right
- The tool already passed review.
- Why it's wrong
- A new purpose affecting different people needs a new assessment and may raise the risk tier.
Clue to watch for The users or affected group change.
-
Switch off later
- What candidates pick
- Plan deactivation only if a serious incident happens.
- Why it looks right
- Incidents seem unlikely at launch.
- Why it's wrong
- Without pre-set triggers, owners and a fallback, shutting down causes disruption and delays harm reduction.
Clue to watch for The question asks what to prepare before go-live.
Answer framework
Apply these steps to Domain IV scenarios about choosing, contracting for or operating an AI system.
- Define the use case context: objectives, performance needs, data availability, affected people, legal setting and ethical concerns.
- Choose the model type and deployment option that fit those constraints, comparing generative versus classic, open versus proprietary, and cloud, on-premise or edge.
- Assess the selected system in the deployer's own context and review the vendor or license terms for data use, IP, liability, audit, change notice and exit.
- At go-live, apply use policies, assign trained overseers, set monitoring and periodic assessments, and document incidents and post-market monitoring duties.
- Control the system over time by blocking unapproved secondary uses, preparing external communication and keeping tested deactivation and localization controls ready.
Practice question
Want more like this? The AIGP practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Treat this domain as a procurement and operations playbook. Start with IV.A by building a comparison sheet: model types on one side (classic, generative, open, proprietary, small, large) and deployment options on the other (cloud, on-premise, edge, as is, RAG, fine-tuning). For each, note one benefit and one governance risk.
For IV.B, obtain a sample SaaS AI contract or a vendor's published AI terms and mark the clauses on data use, retention, output ownership, IP indemnity, liability, audit rights, model change notice and exit. Practice writing three questions you would ask the vendor. Then compare the build option: what does an organization gain and take on when it deploys its own model?
For IV.C, write a one-page operating plan for a deployed assistant covering acceptable use, oversight roles, monitoring metrics, audit cadence, incident logging, secondary use rules, external messaging and a deactivation procedure. Cross-reference AI Act deployer duties from Domain II. Finish with case-study practice, focusing on questions where several answers sound reasonable and the best one keeps the deployer in control.
FAQ
How much of the AIGP exam is Understanding how to govern AI deployment and use?
Domain IV accounts for 21 to 25 of the 85 scored items, about 27%, the same range as Domain III.
How is Domain IV different from Domain III?
Domain III governs building AI. Domain IV governs choosing and using AI, usually from the deployer's side, including vendor contracts and live operation.
Does the exam expect technical knowledge of RAG and fine-tuning?
Only at a conceptual level. You should know what each does, how they differ in updatability and data removal, and what governance risks each creates.
What vendor contract terms matter most for AI?
Use of customer data for training, retention and location, output ownership, IP indemnity, liability limits, audit rights, model change notice, incident notification and exit terms.
What does deactivate or localize mean?
Deactivation stops a system or reverts to a fallback. Localization restricts it to certain regions, users or functions, for example where a new law applies.
Do deployers have obligations under the EU AI Act?
Yes. Deployers of high-risk systems must follow instructions for use, assign human oversight, monitor operation, keep logs and in some cases complete a fundamental rights impact assessment.
Other Artificial Intelligence & Machine Learning certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 4 knowledge
You have covered deployment decisions, vendor terms, monitoring, secondary uses and deactivation. Check whether you can keep the deployer in control across exam scenarios.