Evaluate key factors and risks relevant to the decision to deploy the AI system.
- ✓Domain IV takes the deployer's view: the organization putting AI to work, bought or built.
- ✓Five context checks: business objectives, performance requirements, data availability, ethics and workforce readiness.
- ✓Set performance requirements for your own context; vendor benchmarks aren't your requirements.
- ✓Data availability includes the legal right to use the data, not just having it.
- ✓Workforce readiness means training, role design and calibrated trust for everyone affected, not just IT; organizational readiness adds budget, data and security maturity, and risk tolerance.
- Deployer:
- The organization that uses an AI system under its own authority, whether it bought the system or built it.
- Use-case context:
- The business objectives, performance requirements, data availability, ethical considerations and workforce readiness that decide whether an AI deployment makes sense.
- Performance requirements:
- The accuracy, speed, explainability, availability and error tolerance a specific use demands, set by the deployer for its own context.
- Data availability:
- Whether suitable, good-quality data exists and the organization has the right to use it for the intended purpose.
- Workforce readiness:
- Whether the people who will use, oversee or be affected by an AI system have the skills, training, roles and trust to work with it well.
- Organizational readiness:
- Whether the organization has the leadership, budget, data governance, security and privacy maturity, risk tolerance and operating capacity to support an AI deployment.
Exam tips: When a stem lists facts a confident sponsor is ignoring (unlabeled data, untrained staff, no success metric), those ignored facts usually point to the answer. · FIRST questions about a new deployment usually reward defining the use case and its context before pilots, vendors or models. · Benchmarks answer only the performance question, and only on the vendor's data. They never settle a deploy decision on their own. · 'Don't use AI here' can be the right answer. Take options seriously when they question whether AI fits at all.
- ✓Four axes: classic vs. generative, proprietary vs. open, small vs. large, language vs. multimodal.
- ✓Generative models add confabulation, IP and harmful-content risks.
- ✓Open weights give control and transparency but put hosting, security and safety on you, under the license's terms.
- ✓Small models are easier to test, explain and host privately; large ones are broader but harder to evaluate.
- ✓Multimodal capability adds new attack channels and sensitive-data risks.
- Classic (predictive) AI:
- Models that classify, score or forecast from inputs rather than create new content.
- Generative AI:
- Models that create new content such as text, images, code or audio.
- Proprietary (closed) model:
- A model whose code and weights are not published; you use it under license or through an API.
- Open-weights model:
- A model whose trained parameters are published for download, usually under a license that may still carry conditions.
- Multimodal model:
- A model that processes more than one type of data, such as text together with images, audio or video.
Exam tips: Model-type questions often describe a model in one sentence and flip one axis in each wrong option. Check all four axes. · 'Open' never means 'no conditions'. Look for license limits on commercial use, attribution and acceptable use. · Bigger is rarely the governance answer. Labeled history plus fixed categories points to a classic model. · Closed models shift evidence-gathering to vendor diligence; they never shift accountability off the deployer.
- ✓Cloud = scale and convenience, with data leaving your walls and shared responsibility.
- ✓On-premise = maximum control and inspectability, and all the security work is yours.
- ✓Edge = low latency, offline operation and local data, but hard fleet updates and monitoring.
- ✓Hybrid mixes environments (for example, edge inference with cloud training): more fit, more integration work.
- ✓Choose by data sensitivity, control needs and connectivity, not by hype or headline cost.
- Cloud deployment:
- Running an AI system on a provider's remote infrastructure, typically as a managed service.
- On-premise deployment:
- Running an AI system on servers the organization owns and operates itself.
- Edge deployment:
- Running an AI model directly on an end device such as a phone, camera, vehicle or sensor.
- Shared responsibility model:
- The split of security and compliance duties between a cloud provider (infrastructure) and its customer (data, access and use).
- Data residency:
- A requirement that data be stored or processed within a particular country or region.
- Hybrid deployment:
- Combining environments, such as edge or on-premise inference with cloud training and updates, so each workload runs where it fits.
Exam tips: When several options satisfy the loud constraint (such as residency), the answer turns on the quiet one: offline operation, physical control or auditability. · Residency is not control. An in-country cloud region keeps data local, but the provider still operates the hardware. · Moving to the cloud moves the work, never the accountability. · Edge is the answer when latency, offline operation or on-device privacy is a hard requirement. Expect follow-ups about updating and rolling back a fleet, and about slimming models (quantization, distillation) at some cost in accuracy.
- ✓As is → prompting → RAG → fine-tuning → agents: each adds fit and power, and shifts responsibility to you.
- ✓RAG keeps knowledge fresh and citable, but the document store needs access control, quality checks and injection defenses.
- ✓Fine-tuning changes the model: govern the training data, re-test safety, and check whether you've become a provider.
- ✓Agents need least privilege, human approval for high-impact actions, action logs and a way to stop and roll back.
- Prompt engineering:
- Shaping a model's behavior through the instructions and examples sent with each request, without changing the model.
- Retrieval-augmented generation (RAG):
- A technique where the system retrieves relevant documents at query time and adds them to the prompt, leaving the model's weights unchanged.
- Fine-tuning:
- Further training a pre-trained model on your own examples, which permanently changes its weights.
- Agentic architecture:
- A design in which a model plans steps and calls tools to take actions toward a goal with limited human input.
- Excessive agency:
- OWASP's term for an AI system with more functionality, permissions or autonomy than its task needs.
- Indirect prompt injection:
- Malicious instructions hidden in content the model reads, such as a retrieved document or web page, that hijack its behavior.
Exam tips: Changing content + citations + no training budget = RAG. Stable format + huge volume + cost pressure = fine-tuning. · Upgrading from answers to actions raises permissions, logging, human approval and rollback. Training-data risks are unchanged by that upgrade. · Fine-tuning or repurposing can make a deployer the provider under EU AI Act Art. 25. Watch for 'substantial modification' and 'changes the intended purpose'. · A system prompt is guidance, not a security control.
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.
Govern the deployment and use of the AI system.
- ✓Deployment is where policies must operate: data governance, risk management, issue management and user training.
- ✓Production data governance = input rules, minimization, retention limits, input quality, access control, and the transfer and notice duties that go-live triggers.
- ✓Keep the risk register alive with scheduled and change-triggered reviews.
- ✓Issue management needs easy reporting, triage, escalation and closure.
- ✓Role-based, ongoing training is the main defense against automation bias.
- Automation bias:
- The tendency to over-trust an automated system's output instead of exercising independent judgment.
- Risk register:
- A living record of identified risks, each with an owner, rating, treatment and review date.
- Issue management:
- The process for capturing, triaging, escalating and resolving problems with a live system, and learning from them.
- Data minimization:
- Collecting and keeping only the data a defined purpose actually needs.
- Role-based training:
- Training tailored to what each group (end users, overseers, leaders) needs to do with an AI system.
Exam tips: When the stem says the model meets spec but outcomes are bad, the lever is human: training, usage policy, verification duties. · 'Keep everything in case it's useful' is never a purpose. Minimization and retention limits win. · Training is a standing control with refreshers. One-off launch briefings are the distractor. · Banners and disclaimers alone don't change behavior. Prefer options that assign duties and build skills.
- ✓Deployers monitor in their own context: performance, drift, fairness, output quality, oversight signals, usage and vendor changes.
- ✓Every metric needs a threshold, an owner and a planned response.
- ✓Maintenance runs on a calendar plus triggers, under change management.
- ✓Vendor upgrades need re-validation; version pinning buys the time.
- ✓Separate development, staging and production, keep builders out of production, and track every version in a model registry.
- Continuous monitoring:
- Ongoing, largely automated tracking of a live AI system's performance, inputs, outputs and use against defined thresholds.
- Data drift:
- A shift in the distribution of a system's live inputs away from the data it was trained or validated on.
- Concept drift:
- A change in the real-world relationship between inputs and outcomes, so learned patterns stop holding.
- Version pinning:
- Staying on a specific, validated model version until a newer one has been tested and approved.
- Change management:
- Testing, approving, documenting and preparing rollback for every change to a production system.
- Model registry:
- A catalog of model versions recording each one's hash, training-data identifiers, evaluation results, owner and deployment status.
Exam tips: Proactive beats reactive: continuous monitoring plus a scheduled maintenance plan. 'Freeze it' and 'retrain only when it breaks' are the two planted extremes. · A vendor update is a change to YOUR system. Re-validate before it reaches production. · Deployers of vendor models usually maintain through configuration, data, oversight and vendor escalation, not retraining. · Monitoring isn't only model metrics: override rates, usage patterns and complaints catch human and scope problems.
- ✓Four periodic tools: audits, red teaming, threat modeling and security testing. Each finds different problems.
- ✓Deployers assess the system as they run it, not just the model.
- ✓Negotiate testing and audit rights with vendors; some laws put audit duties on deployers directly.
- ✓Set cadence by risk, add change triggers, keep assessors independent, and track findings to closure.
- Audit:
- An independent check of a system and its governance against defined criteria such as policy, law, contract or standards.
- Red teaming:
- Simulating real adversaries who actively try to make an AI system fail, misbehave or leak data.
- Threat modeling:
- Structured, on-paper analysis of how a system could be attacked or misused, ranked by likelihood and impact.
- Security testing:
- Technical testing of security controls, such as penetration tests, vulnerability scans and access checks.
- MITRE ATLAS:
- A public knowledge base of real-world adversary tactics and techniques used against AI systems.
- Threat hunting:
- Proactively searching a live system's logs and telemetry for signs of compromise or abuse that automated alerts have missed.
Exam tips: Read the verb: checks against criteria = audit; attacks = red teaming; analyzes on paper = threat modeling; tests controls = security testing; searches live logs for intruders = threat hunting. · 'No attacks were executed' is the tell for threat modeling. · Cadence answers reward 'risk-based plus change-triggered'. A fixed calendar alone is the near miss. · Deployers need contractual permission and a scope covering the whole system: prompts, RAG, plug-ins and people.
- ✓Know the difference: risk (could happen), issue (has happened, no significant harm), incident (harm).
- ✓Good incident records cover detection, impact, containment, root cause, notifications, fixes and lessons.
- ✓EU high-risk deployers keep logs for at least six months and must inform the provider of risks and serious incidents.
- ✓Providers own post-market monitoring; deployers feed it and should keep their own monitoring plan.
- Serious incident (EU AI Act):
- An incident or malfunction leading to death or serious harm to health, serious and irreversible disruption of critical infrastructure, breach of fundamental-rights obligations, or serious harm to property or the environment.
- Post-market monitoring:
- A provider's system for actively collecting and analyzing data on an AI system's performance throughout its life, fed in part by deployers.
- Near miss:
- An event that could have caused harm but was caught in time; worth recording as an issue.
- Incident record:
- A documented account of what happened, its impact, containment, root cause, notifications, corrective actions and lessons.
- Post-deployment monitoring plan:
- A deployer's documented plan covering metrics and thresholds, user feedback, appeals and overrides, incident response, change management and decommissioning (NIST AI RMF MANAGE 4.1).
Exam tips: Incident order: detect → contain → notify → investigate → correct → learn. Reporting before containing, or reviewing before notifying, are the classic inversions. · Post-market monitoring belongs to the provider (Art. 72), but deployers must monitor and inform the provider (Art. 26(5)). 'Leave it all to the vendor' is wrong. · Record near misses and minor issues: patterns turn into risks. · Guides order incident steps differently, and some put 'communicate' first. Early communication means internal escalation; when harm is ongoing, containment still comes before external notices.
- ✓Uses drift through scope creep, deliberate misuse and data repurposing.
- ✓Forecast with intended and out-of-scope use statements, pre-mortems, misuse brainstorming and stakeholder mapping.
- ✓Reduce with technical, contractual, organizational and documentation controls.
- ✓Treat every new use as a new deployment that needs assessment.
- Secondary use:
- Use of an AI system, or its data, for a purpose beyond the one that was assessed and approved.
- Function creep:
- The gradual expansion of a system into tasks it was never designed or assessed for.
- Downstream harm:
- Harm that ripples beyond the original decision or user, including to people who never used the system.
- Out-of-scope use:
- A use the deployer or provider has identified as inappropriate or unsupported, documented so it can be prevented.
- Purpose limitation:
- The GDPR principle that personal data collected for one purpose may not be further processed in ways incompatible with it.
- Pre-mortem:
- A forecasting exercise that imagines a future failure and works backward to what caused it.
Exam tips: Model card = what this system is for and not for. AI inventory = which systems we have. Secondary-use questions point to the model card and impact assessment. · A new use of an approved system is a new deployment. Assess it before it goes live, even if the technology is unchanged. · Repurposing into a high-risk area (hiring, credit, worker monitoring) can make a deployer the provider under Art. 25(1)(c). · Downstream harms include people who never used the system.
- ✓Plan audiences, messages, timing, channels, incident communications and approvals in advance.
- ✓Tell people AI is in use, what it can and can't do, and how to reach a human or contest an outcome.
- ✓EU deployers have specific duties: informing decision subjects, explaining decisions, labeling deepfakes.
- ✓In incidents: required notifications and affected people first, one voice, honesty over spin.
- ✓Offer a real human or non-AI alternative for significant decisions; GDPR Art. 22, California's ADMT rules and Colorado SB 26-189 require versions of it.
- External communication plan:
- A pre-agreed plan for what an organization tells users, affected people, regulators, partners and the public about its AI, when and through which channels.
- AI disclosure:
- Telling people, at or before first interaction, that they are dealing with an AI system or AI-generated content.
- Right to explanation (EU AI Act Art. 86):
- The right of a person affected by a significant decision based on an Annex III high-risk system to a clear, meaningful explanation from the deployer of the AI's role and the main elements of the decision.
- AI washing:
- Exaggerating or misrepresenting what an AI system can do, which can amount to deceptive marketing.
- Holding statement:
- A pre-drafted initial public statement used in the first hours of an incident while facts are confirmed.
- Non-AI alternative:
- A human or non-automated route offered instead of an AI process; it should be feasible, clearly explained, easy to choose and no worse in service.
Exam tips: The winning answer is the balanced pair: capabilities AND limitations. Hype, hiding and silence are the three standard distractors. · Timing matters: disclose at or before first interaction. A notice after the fact is a deficiency even if the wording is fine. · Technical internals are rarely what affected people need. Look for plain-language, actionable information and a route to a human. · Overstated AI claims are a legal risk (deceptive practices), not just a brand risk.
- ✓Every deployed AI needs a policy and controls to deactivate or localize it.
- ✓Risk-driven triggers are regulatory or performance/safety, never profit or a new release; planned retirement can follow business or vendor reasons.
- ✓Toolkit: kill switch, feature flags, geo-restriction, rollback, graceful degradation, agent stop controls; localize with flags, regional modules, country models or federated learning.
- ✓The policy settles triggers, decision rights, fallback, notifications, evidence, restoration and drills.
- Kill switch:
- A control that stops an AI system globally and quickly, ideally leaving it in a safe state.
- Feature flag:
- A switch that turns a feature on or off for a jurisdiction, customer group or cohort without redeploying software.
- Localization:
- Restricting or adapting how an AI system operates by region, for example disabling it in one jurisdiction or running a country-specific model.
- Rollback:
- Returning a system to its last known-good model version or configuration.
- Graceful degradation:
- Falling back to human handling or a simpler process so service continues when the AI is switched off.
- Deactivation policy:
- A pre-agreed policy setting the triggers, decision rights, controls, fallbacks, notifications and restoration criteria for switching an AI system off or restricting it.
Exam tips: For risk-driven deactivation, valid triggers are regulatory or performance/safety problems; profit, migration hassle and 'a new version exists' are never the answer. Planned retirement (IV.C.8) can legitimately follow business or vendor reasons. · A timely, verified mitigation is a legitimate reason to keep a system running. · One jurisdiction's demand → feature flag or geo-restriction. A severe global incident → kill switch. The kill switch for a local issue is the overbroad trap. · Look for pre-agreed decision rights and tested controls. An untested switch isn't a control.
- ✓Planned retirement and risk-driven deactivation are different processes with different valid triggers.
- ✓A retirement policy sets criteria, decision rights, required steps, evidence and a lessons-learned review.
- ✓Sequence: map dependencies, notify, transition (including a non-AI fallback), snapshot and shut down, retain or dispose, close out.
- ✓Archive what accountability and the law require; destroy the rest, including stray model copies, and get certificates from hosts.
- ✓Mark the system retired in the inventory and registry, exit the contract, and keep the retention clock running.
- Planned retirement:
- Ending an AI system's use on a schedule for reasons such as obsolescence, vendor end of support, a replacement or a changed business need.
- Risk-driven deactivation:
- Switching off or restricting a live AI system because of a regulatory, performance, safety or security problem, under the deactivation policy.
- Decommissioning:
- The controlled process of retiring a system: mapping dependencies, notifying users, transitioning, archiving or destroying data and models, and closing the records.
- Retention schedule:
- A documented set of rules saying how long each type of record is kept and when it must be destroyed.
- Certificate of destruction:
- Written confirmation from a provider or contractor that specified data or model copies have been permanently destroyed.
- Non-AI fallback:
- A manual or rules-based process that takes over an AI system's work when it is switched off or retired.
Exam tips: Read the trigger first. Business or vendor reasons point to planned retirement, which is legitimate; an emergency stop needs a regulatory or performance problem. · Sequence: map, notify, transition, snapshot and shut down, retain or dispose, close out. 'Delete everything first' and 'update the inventory first' are the planted inversions. · Retirement doesn't end retention duties: EU provider documentation runs 10 years from placing on the market, logs at least six months, Colorado records three years. · Deleting the production model isn't disposal. Look for fine-tuned copies, checkpoints, backups and vendor-hosted copies.
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.
