Perform key activities to assess the AI system.
- ✓Deployers must perform or review an impact assessment of the selected system in their own context.
- ✓Review vendor evidence critically, then add what only you know: workflow, affected people, oversight, redress.
- ✓The FRIA is a deployer duty for public bodies, public-service providers, credit scoring and life/health insurance pricing.
- ✓Test on representative local data and break results down by group.
- ✓Assess before first use, decide, document, and keep it updated.
- Deployer impact assessment:
- An assessment of how a selected AI system will affect people and the organization in the deployer's own context, done before use and kept up to date.
- Fundamental rights impact assessment (FRIA):
- An EU AI Act assessment (Art. 27) that certain deployers of high-risk AI must complete before first use, covering affected groups, risks, oversight and remedies.
- Data protection impact assessment (DPIA):
- A GDPR assessment that a controller must carry out before processing personal data in ways likely to pose a high risk to people's rights.
- ISO/IEC 42005:
- An international standard (2025) giving guidance on assessing the impacts of AI systems on individuals, groups and society.
- Disaggregated evaluation:
- Breaking performance and error rates down by relevant groups to reveal problems that overall averages hide.
Exam tips: Know each assessment's owner: FRIA = deployer (public bodies, private entities providing public services, credit scoring, life and health insurance pricing); conformity assessment = provider; DPIA = controller. · 'The vendor already assessed it' is the classic trap. Vendor documents are inputs, never substitutes. · Timing: before first use, then updated when things change. 'After a pilot on real people' is too late. · Prefer evidence from your own population, broken down by group, over headline benchmark numbers.
- ✓Check data clauses first: training on your data, output ownership, retention, location and subprocessors.
- ✓Read indemnities alongside their exclusions, and liability caps alongside their carve-outs.
- ✓Operational terms matter later: model change notice, SLAs, audit and testing rights, documentation, exit.
- ✓Contracts allocate money and duties between parties, never accountability to the people affected.
- IP indemnity:
- A vendor's promise to defend and compensate the customer if the AI system or its outputs infringe third-party intellectual property.
- Liability cap:
- A contractual ceiling on the damages one party can recover from the other, often with carve-outs for specific harms.
- Model change notification:
- A contract term requiring the vendor to give advance notice of material changes to the model, often paired with version pinning.
- Audit rights:
- The customer's contractual right to obtain evidence of, or directly check, the vendor's controls and compliance.
- Subprocessor:
- A third party the vendor engages to process the customer's data, such as a hosting provider.
- Exit assistance:
- Contract terms covering data return, certified deletion and transition support when the relationship ends.
Exam tips: Contract questions are mapping exercises: restate the risk in one sentence, then pick the clause whose mechanism touches it. · Indemnities and higher caps pay out after harm. Notice, testing and audit rights prevent or detect it. If the stem says 'prevent' or 'detect', choose the latter. · No clause transfers the deployer's accountability to affected people or regulators. · Clauses that forbid testing, benchmarking or auditing are red flags: they block the deployer's own assessment duties.
- ✓Building your own model gives control, data privacy, customization and differentiation.
- ✓It also means increased obligations and higher potential liability, with no vendor to share them.
- ✓Under the EU AI Act, building for your own use can make you both provider and deployer.
- ✓Training-data rights, documentation, security and monitoring all become permanently yours.
- Proprietary model (own):
- An AI model an organization develops or trains itself and controls, rather than licensing from a vendor.
- Provider (EU AI Act):
- Whoever develops an AI system, or has it developed, and places it on the market or puts it into service under its own name, including for its own use.
- Putting into service:
- Supplying an AI system for first use to a deployer, or for the provider's own use, in the EU for its intended purpose.
- Product liability:
- Liability for harm caused by defective products, which under the revised EU Product Liability Directive extends to software, including AI.
- Build vs. buy:
- The choice between developing your own AI model and licensing one, which shifts control, obligations and liability.
Exam tips: Build vs. buy in one line: your own model = more control, more obligations, more liability. Any option saying ownership lightens the legal load is the planted error. · 'Putting into service' includes your own use, so an internal-only model can still make you a provider. · The BoK says Domain IV applies whether you deploy your own model or a third party's. Being the provider adds duties; it never removes deployer duties.
- ✓BoK v2.1 says 'vendor or licensing agreement': open models, code and datasets all come with binding terms.
- ✓Permissive = keep notices; copyleft = share alike on distribution (AGPL: network use too); responsible-AI = obey and pass on use limits; non-commercial = keep out of products.
- ✓Watch output rights, dataset privacy terms, tiered access, changing terms, inherited duties and compatibility.
- ✓Do due diligence before negotiating, ask for ISO/IEC 27001, ISO/IEC 42001 and SOC 2 Type II evidence, and turn every gap into a term, a control or a walk-away.
- Permissive license:
- An open license, such as MIT or Apache 2.0, that allows commercial use and modification as long as notices are kept.
- Copyleft license:
- An open license, such as the GPL, that requires derivative works to be released under the same terms when they are distributed.
- AGPL network clause:
- The GNU Affero GPL term that treats offering modified code as a network service like distributing it, triggering source-sharing duties.
- Responsible AI license (RAIL):
- A license that permits use of a model or code but bans listed harmful uses and requires those restrictions to be passed downstream.
- Vendor due diligence:
- Investigating a vendor's documentation, assurance evidence and track record before negotiating, so the findings shape the contract.
- SOC 2 Type II report:
- An independent auditor's report on whether a service provider's controls operated effectively over a period, typically 6 to 12 months.
Exam tips: 'Open' never means 'no conditions'. Ask three questions: may we use it commercially, what must we pass on, and which uses are banned? · Copyleft bites on distribution; the AGPL also bites when modified code runs as a network service. Permissive licenses mostly ask you to keep the notices. · Due diligence comes before negotiation: the findings decide which clauses you need. · SOC 2 Type II tests controls over a period; Type I only checks their design at a point in time. ISO/IEC 42001 certifies an AI management system, not a model.
- ✓Owning a model brings opportunities: a protectable asset, full explainability and governance on your terms.
- ✓IP strategy: catalog assets, secure ownership with IP assignment and license audits, then choose trade secret, patent or copyright.
- ✓Defend against extraction with API-only access, rate limits, query monitoring, minimal outputs and watermarks.
- ✓Explain with interpretable models, local and global methods (LIME, SHAP) and counterfactuals, in plain language.
- ✓Govern with a review board, a named model owner, development-cycle gates, change control and independent validation.
- Trade secret:
- Confidential business information, such as model weights or curated data, protected for as long as reasonable steps keep it secret.
- IP assignment:
- A contract clause transferring ownership of work created by employees or contractors to the company.
- Model extraction:
- Copying a model's behavior by querying it many times and training a look-alike model on the responses.
- Local vs. global explanation:
- A local explanation shows why one output occurred; a global explanation shows what drives the model's behavior overall.
- Counterfactual explanation:
- An explanation that tells a person what would have needed to be different for the outcome to change.
- Model owner:
- The named person accountable for a model's performance, documentation and risks throughout its life.
Exam tips: v2.1 asks for risks AND opportunities of your own model: control, explainability and a protectable asset are the opportunities. · Theft defenses are layered: API not weights, least-privilege access, rate limits, query monitoring, watermarks, terms of use. 'Too complex to copy' is never the answer. · Local = why this decision; global = what drives the model overall. Affected people need local, plain-language reasons, and counterfactuals are a strong choice. · Building it yourself doesn't skip governance: review board, named owner, development-cycle gates, change control and independent validation.
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.
