At a glance
Competency IV.B is the due-diligence layer of deployment. Having chosen a system in IV.A, the deployer now does three assessment activities before committing: (1) perform or review an impact assessment on the selected system, (2) scrutinize the vendor/licensing agreement for the terms and risks that matter, and (3) understand the extra obligations and liability that come from deploying your own proprietary model rather than buying one.
The throughline: buying an AI system does not buy you out of accountability. Whether you build or buy, you must assess impacts, secure the right contractual protections, and understand where liability lands.
IV.B.1 — Perform or review an impact assessment on the selected system
An AI impact assessment (AIA) systematically identifies and documents how the system could affect people and society, so risks can be mitigated before and during deployment. ISO/IEC 42005 provides guidance on conducting and documenting one; the EU AI Act requires certain high-risk deployers to perform a Fundamental Rights Impact Assessment (FRIA, Art. 27).
A deployer typically covers:
- System and context — purpose, intended use, deployment environment, and where it sits in the workflow.
- Affected stakeholders — who is subject to or affected by the system’s outputs (including vulnerable groups).
- Risks and harms — to individuals, groups, organizations and society (drawing on the I.A harm taxonomy): bias/discrimination, privacy, safety, opacity, security.
- Benefits — the value that justifies accepting residual risk.
- Mitigations and controls — human oversight, testing, data governance, fallback procedures.
- Residual risk and a decision — whether to deploy, deploy-with-conditions, or not.
Crucially, a deployer often reviews an assessment supplied by the provider rather than starting from scratch — but must validate it against its own use context. The provider assessed the system in general; only the deployer knows the specific population, data and stakes.
IV.B.2 — Key terms and risks in the vendor or licensing agreement
A deployer’s protections live (or die) in the contract. These are the terms to find, evaluate and negotiate — and the red flags to spot.
| Term | What to secure | Red flag |
|---|---|---|
| Indemnification | Vendor covers third-party claims (esp. IP infringement from training data/outputs) | No IP indemnity, or indemnity riddled with carve-outs |
| Liability cap | A cap proportionate to the deployment’s risk; carve-outs for data breach, IP, willful misconduct | Cap limited to fees paid, with no carve-outs, on a high-risk use |
| Data-use / training rights | Vendor will not train on your inputs/prompts without consent; clear data-handling and deletion terms | Broad licence for the vendor to use your data to “improve services” |
| IP ownership | Clarity on who owns inputs, fine-tuned weights and outputs | Silence on output ownership; vendor claims rights to your fine-tune |
| Audit / transparency rights | Right to documentation, evaluation results, security info, and to audit | No visibility into the model, data lineage or security posture |
| SLAs | Uptime, latency, support response — ideally also accuracy/quality | No SLA, or SLAs that ignore output quality |
| Model-change / deprecation notice | Advance notice before the model is changed, retired or materially updated | Vendor may swap or sunset the model with no notice |
| Security, privacy & compliance | Breach notification, sub-processor controls, regulatory-cooperation and certifications | No breach-notice duty; uncontrolled sub-processors |
Two risks deserve emphasis because they recur on the exam:
- Data-use rights — if the vendor can train on your prompts/inputs, confidential and personal data can leak into a shared model. This is both an IP and a privacy (GDPR) problem.
- IP indemnification — given unsettled copyright questions around AI output (see the U.S. Copyright Office guidance), a deployer wants the vendor to stand behind infringement claims arising from the model.
IV.B.3 — Risks and opportunities unique to deploying your OWN proprietary model
Building and deploying your own model changes the risk picture. Under the EU AI Act, doing so can make you both provider and deployer, collapsing two sets of obligations onto one organization.
Increased obligations and risks:
- Full provider obligations — risk management, data governance, technical documentation, conformity assessment, post-market monitoring, transparency — none of which a vendor absorbs for you.
- Higher and more direct liability — there is no vendor to indemnify you; harms from the model land on you, and you can’t point to a third party.
- End-to-end responsibility — for training-data quality and provenance, security (poisoning, extraction), bias, safety testing, maintenance, retraining and incident response across the whole life cycle.
- Resource burden — talent, compute, MLOps and ongoing governance cost.
Opportunities and advantages:
- Control and customization — tailor the model precisely to your domain, data and risk appetite.
- Data sovereignty and privacy — keep sensitive data and IP in-house; nothing trains a third party’s model.
- No vendor lock-in or external model-change risk — you control updates and deprecation.
- Competitive differentiation — a proprietary capability and the IP that comes with it.
How this shows up later
- The impact assessment, contract controls and liability picture feed directly into the governance, monitoring and incident-documentation activities in IV.C.
- The provider vs. deployer distinction and EU AI Act obligations connect back to the roles and risk tiers studied in Domain II.
- Vendor data-use and IP terms tie to the privacy (GDPR) and copyright issues from Domain I/II.