EXIN AI Security Professional

The five G.U.A.R.D. steps (Bloom 3 — know the order and what belongs where):

1. Govern — general AI governance: AI inventory, policies, assigned responsibilities (increasingly a Chief AI Officer alongside the CISO), impact assessments, compliance checking, education. Home of the AI management system (AIMS) per ISO/IEC 42001.
2. Understand — decide which threats actually apply per system; educate engineers and security staff; draw the responsibility line with suppliers.
3. Adapt — reshape existing processes: extend the ISMS with AI assets and threats, add AI-specific threat modeling, AI security testing, and supply-chain management for data, models and hosting.
4. Reduce — limit the impact of things going wrong (the model can always be wrong or manipulated): minimize and obfuscate sensitive data; cap model privileges, add guardrails and oversight.
5. Demonstrate — evidence that safeguards work: transparency, test results, documentation — for management, regulators and clients.

• Responsible AI = the ethics/society/governance lens — fairness to people, accountability, oversight structures (boards, ethics committees). Trustworthy AI = the technical/operational lens — robustness, reliability, transparency, explainability (engineering). Tell: “ethics, societal impact, accountability” → responsible; “robustness, reliability, explainability” → trustworthy — even if the story contains the word “trust.”
• Shadow AI: staff use unsanctioned public tools regardless of bans. The effective fix is a secure, high-quality sanctioned alternative plus explicit risk communication — never a ban alone.
• Equation: AI security = threats to AI-specific assets + threats to all other assets. It extends the existing program; conventional tooling is necessary but not sufficient.
• Three novelties: (1) new assets — training data, augmentation data, the model, its input, its output; (2) new attack surface through legitimate use — just querying the model enables evasion, prompt injection, extraction, resource exhaustion; (3) new suppliers — data, ready-made models, model hosting.
• Why conventional tools miss AI attacks: they match structure and known-bad byte patterns, while adversarial inputs and poisoned records travel through fully legitimate channels — the harm is statistical, not signature-shaped. Zero model trust: assume the model can be misled, wrong, and leaky.
• Threat rhythm across the five assets: both data and the model face leaks (confidentiality) and poisoning (integrity) — the model in both lifecycle phases, development-time and runtime; input only leaks; output's danger is carrying injection onward. System prompts count as augmentation data.

Go deeper: full textbook section.

Four risk management steps (in order, repeated regularly and on change):

1. Identify — threat modeling turns the threat catalogue into concrete, prioritized risks for your system (does it apply? how could it happen here? what impact?).
2. Evaluate — estimate likelihood × severity; plot on a heatmap to prioritize.
3. Risk treatment — per risk: mitigate (implement controls — most common), transfer (outsource/insure), avoid (change plans, maybe drop AI there), accept (knowingly bear it).
4. Risk communication & monitoring — risk register with owner, severity, status; inform stakeholders; verify treatments work.

• Threat modeling is the bridge between the generic threat catalogue and concrete prioritized risks. Controls only enter at step 3 — picking controls from a raw threat list skips two steps.
• Agentic AI takes action: it invokes tools, triggers other agents, operates across systems. Four amplifiers: agents act, are autonomous (agent triggers agent; working memory becomes an attack vector), behave complexly, and are multi-system.
• Excessive agency = more capability than the task needs; blast radius = how much one compromise can damage — the central design question.
• Data-theft triangle: agent processes attacker-controlled data + can access sensitive data + can send data out. Remove any one leg and that attack collapses.
• Agentic AI amplifies existing threats rather than creating new ones: an injection that once produced an embarrassing answer now moves money.
• Six agentic AI controls: traceability · memory-integrity protection · prompt-injection defenses · rule-based guardrails · least model privilege · human oversight.

Go deeper: full textbook section.

The heaviest subtopic on the exam. Input threats (threats through use) need nothing but access to the input channel of a deployed model.

• Six generic runtime controls (know which control starves which attack): monitor use · rate limiting · model access control · anomalous input handling · unwanted input series handling · obscure confidence (rich confidence scores are the feedback many attacks feed on).
• Evasion — crafting input (adversarial examples) that misleads the model into doing its task incorrectly; integrity of model behavior. Evasion manipulates the data the model works on; prompt injection manipulates instructions. Variants: targeted/untargeted, digital/physical, diffuse perturbation vs localized patch.

Five evasion types, ordered by attacker knowledge:

1. Zero-knowledge evasion (black/closed-box) — no internals at all; query the live target and read responses (decision-based; score-based if confidence is returned).
2. Partial-knowledge evasion (gray-box) — some internals (architecture, data type) sharpen the search; the most realistic case.
3. Perfect-knowledge evasion (white/open-box) — full architecture + parameters + weights; compute the minimal perturbation directly via gradients.
4. Transfer attack — craft adversarial examples on a surrogate model (similar model, own-trained copy, stolen or exfiltrated replica), then apply to the target. Zero queries against the target during the search — rate limits and detection never see it coming.
5. Evasion after poisoning — the trigger of a backdoor planted earlier via poisoning; no search needed, the weakness was manufactured, not natural.

• Search-frustrating controls (rate limiting, series detection, obscure confidence) are useless against transfer attacks and evasion after poisoning; per-input controls (evasion input handling, input distortion, adversarial training) still work.
• Direct prompt injection — the user is the attacker, socially engineering the model (role-play, “ignore previous instructions,” encodings, multi-turn steering, coaxing out the system prompt). A jailbreak specifically defeats the supplier's alignment. Harm usually flows back to the attacker only — unless there is shared context or the model can act.
• Indirect prompt injection — a third party hides instructions in content the application inserts into the prompt (compromised webpage, white-on-white CV text, pixels in an image); the typing user is an innocent victim. OWASP's analogy: remote code execution. Most dangerous in agentic systems.
• Controls: prompt injection I/O handling (both kinds); input segregation is dedicated to the indirect kind (delimit untrusted data + instruct the model to ignore instructions inside it — a partial mitigation only).

The seven layers of prompt injection protection (in order — weak alone, strong together):

1. Model Alignment — train and instruct the model to behave (flaw: models stay easy to mislead).
2. Prompt Injection Defense — sanitize, filter, detect (flaw: arms race, false negatives → assume some injections succeed).
3. Human Oversight — a human approves selected critical actions (flaw: cost, delay, approval fatigue).
4. Automated Oversight — logic detects suspicious activity in context and intervenes on its own (flaw: reactive).
5. User-Based Privilege — the agent gets exactly the served user's rights, in advance (flaw: users hold more than the task needs).
6. Intent-Based Privilege — task-scoped rights, in advance (a summarizer reads mail, cannot send).
7. Just-In-Time Authorization — rights granted at the moment, per subtask; the sub-agent touching untrusted content holds nothing to abuse.

• Layers 1–2 prevent and detect; layers 3–7 control blast radius. Cues: self-operating detector = 4; a person approving = 3; pre-assigned by user identity = 5, by task = 6; granted at the moment = 7.
• Sensitive data disclosure through use — three mechanisms: disclosure in output (the model emits memorized training/input data — once inside a model, source access rights can no longer be enforced; last-line control: sensitive output handling); model inversion (attacker reconstructs training data they never had by optimizing inputs to maximize confidence signals); membership inference (attacker already holds a record and reads tell-tale extra confidence to learn one bit: was it in the training set?).
• Root enabler: overfitting — dedicated development-time control is a small model (plus regularization); runtime: obscure confidence, rate limiting.
• Model exfiltration — harvest input–output pairs through the legitimate interface (or logs/traffic) and train a functional replica. Synonyms: model stealing, model extraction, model theft through use. Three consequences: IP theft at API prices; the replica is a perfect-knowledge surrogate for developing evasion attacks offline; safety protections can be stripped from a copy. Countermeasures: the generic input-threat controls plus model watermarking — which proves ownership after theft, never prevents it.
• AI resource exhaustion — input causes depletion of funds or availability via frequency, volume, or content. The sponge attack (energy-latency attack) crafts single inputs that maximize computation: a denial-of-wallet (DoW) attack on the budget that can simultaneously become denial of service (DoS). Two dedicated controls: DoS input validation · limit resources (per-input cap).

Go deeper: full textbook section.

Attacks strike while the system is built: the engineering environment and its supply chain. Poisoning breaks integrity of behavior; leaks break confidentiality. Always ask first: which lifecycle stage?

• Data poisoning — manipulating data the model learns from, to change its behavior. Five entry points: supplier · transit · storage · preparation · operation (live-collected training data — fake reviews fed to the next retraining: the attacker touches the running system, but the threat is development-time because the harm happens when the data is learned from).
• Two flavors: sabotage (regular inputs misbehave — surfaces quickly) vs targeted/backdoor (a hidden trigger + attacker-chosen label; normal behavior otherwise, so it sails through every test set). Runtime exploitation of the planted trigger = evasion after poisoning. Backdoors are hard to find: no code to review, parameters unreadable, testing uses normal cases.
• Anti-poisoning controls: development security, data segregation, supply-chain management; more train data, data quality control, train data distortion, poison robust model, adversarial training, model ensemble (a deviating member flags poisoning).
• Direct development-time model poisoning — the attacker's hands on the model or its build machinery inside the development environment: edited weights, swapped model files, serialized files executing code on load (deserialization), altered pipeline code or configuration, compromised libraries.
• Supply-chain model poisoning — a supplied trained model manipulated before you integrated it (poisoned supplier data or tampered parameters — invisible from your side). Covers ready-made models used as-is and models you fine-tune: fine-tuning on clean data does not reliably erase a backdoor (a transfer learning attack). Your controls: supply-chain management (provenance, checksums/signatures, supplier vetting, artifact scanning), plus poison robust model, model ensemble, continuous validation.
• Broad model poisoning has exactly three types: data poisoning · direct development-time model poisoning · supply-chain model poisoning. A supplied poisoned dataset = data poisoning; a supplied poisoned model = supply-chain model poisoning.
• Three development-time leaks — named by the stolen asset: development-time data leak (training/test data — the development environment holds real data, unlike conventional dev); direct development-time model leak (parameters, weights, architecture — upgrades a zero-knowledge attacker to perfect-knowledge); source code/configuration leak (the pipeline recipe — IP even with no data or weights exposed).
• Leak controls: development security, data segregation, confidential compute, data limitation. Federated learning nuance: decreases the risk of all data leaking, increases the risk of some data leaking (more environments).

Go deeper: full textbook section.

A live AI system is an ordinary IT system: every conventional attack applies (SQL injection, stolen credentials, man-in-the-middle, ransomware) against the confidentiality, integrity, and availability of all assets. Defenses are the existing Secure Development Program and Security Program. The exam probes the AI-specific consequences:

• Breach of production storage → steal the model, then run inversion and membership inference offline against the copy.
• Tamper with the model undetected — parameters are opaque binary; no code review will show it.
• Change behavior without touching the model — hack the augmentation-data store.
• Direct runtime model poisoning — altering the parameters of the live model (or compromising its input/output logic, e.g. man-in-the-middle rewriting responses). Integrity breach: still runs, no longer behaves as validated. Controls: runtime model integrity (access control, checksums, encryption, Trusted Execution Environment) · runtime model input/output integrity.
• Direct runtime model leak — stealing parameters from production (executables, memory, storage, transfer — including side channels: timing, power, electromagnetic emissions). Double harm: IP theft + a private rehearsal copy. Controls: runtime model confidentiality · model obfuscation.
• Lifecycle discipline: same attack, different crime scene — “training environment / before deployment” → development-time; “production server / live system” → runtime. Reconstructed purely via API queries → neither: model exfiltration.
• Output containing conventional injection — model output carries a classic payload (XSS, commands) that a downstream component trusts and executes; the exfiltration variant packs data into a URL or markdown image the client fetches. Rule: treat model output as untrusted input. Control: encode model output.
• Input data leak — the user's input (often deeply sensitive: strategy, code, health) exposed at rest or in transit by conventional attack — debug logs, breached buckets. Aggravators: metadata identifies users; cloud inference processes input in clear text; provider logging and subpoenas; RAG context rides inside prompts. Control: model input confidentiality (encryption, access control, minimal retention) + send less in the first place.
• Augmentation data (RAG fragments, system prompts) — double identity: like training data for integrity, like any sensitive store for confidentiality. Usually lives in a vector database — a copy of sensitive content outside its regular protection, and embeddings themselves can be mined to recover text. Retrieval must respect the asking user's access rights; anything retrievable can end up in output.
• Direct augmentation data leak — attacker reads the store (confidentiality; behavior unchanged). Augmentation data manipulation — attacker writes to the store (integrity; behavior steered without touching model or user input). Controls: augmentation data confidentiality · augmentation data integrity.

Go deeper: full textbook section.

• Good AI security governance = clear policies, defined roles, and risk management spanning secure development, deployment, and monitoring. Never a single tool, a one-off audit, or one lifecycle stage.
• Bare minimum for AI security oversight: (1) inventory current AI use and AI ideas; (2) risk analysis on that inventory (genuine threat modeling → applicable threats, needed controls, owners). Inventory first, then analysis.

Six general governance controls (learn as a set):

1. AI Program — govern AI as an organization: inventory of initiatives, impact analysis, responsibilities, AI literacy.
2. Security Program — the ISMS covers the whole AI lifecycle and AI-specific assets and threats.
3. Secure Development Program — build security in during construction.
4. Development Program — engineering best practice (versioning, testing, documentation) applied to AI; its objective is broader than security: maintainable, portable, reliable, future-ready systems. The odd one out.
5. Check Compliance — AI-relevant and privacy laws inside compliance management; compliance as a driver — but laws protect people, not your company secrets, so compliance is a floor, never a risk analysis.
6. Security Education — teach engineers, dev teams, and security staff the threats and controls — including which controls are yours vs the supplier's.

• Coverage: governance controls are overarching — all AI threats, all lifecycle stages (they set the conditions under which every other control is selected and run).
• Eight organizational implementation steps (in order): organize control of AI → teach data obfuscation & minimization → extend supply-chain management (data, models, cloud) → add AI assets & risks to the ISMS repository → teach DevSecOps → teach AI security controls for model engineering & runtime → extend monitoring to AI-attack behavior → implement model guardrails, oversight and least privilege.
• Ready-made models: the provider owns model-level, development-time controls (training-data hygiene, poisoning defenses, its own environment and supply chain, base alignment). Your assurance over that side is supply-chain management (vetting, authenticity, published testing).
• The deployer (you) owns application-level controls always: what data you send, output validation and encoding, prompt injection handling, user and model privileges, oversight in your context.
• Self-hosted ready-made model: you also own everything at runtime (infrastructure, monitoring, rate limiting, access control). Hosted (API): the provider takes the hosting platform's runtime controls — but application-level duties never transfer.
• Hosted extra: your input is processed in clear text inside the provider's environment. Due-diligence questions: the model's actual run location, retention rules, logging practices, and whether your input feeds training. Contracts: the supplier is responsible for training-data content, not automatically accountable — check licenses and warranties.

Go deeper: full textbook section.

Reduce the data attack surface in three dimensions: amount, variety, duration — development-time and runtime, across training data, augmentation data, inputs, outputs, and logs.

1. Data minimization — remove fields and records the application does not need (verify by experiment; models tolerate reduced features surprisingly well; propagate upstream deletions; keep identifiers only to honor deletion, outside training).
2. Allowed data — remove data prohibited for the purpose (e.g., personal data without consent for reuse). Minimization is a necessity test; allowed data is a permission test.
3. Short retention — delete or anonymize once no longer needed or when law requires; minimization along the time axis (every extra month is extra exposure).
4. Obfuscate training data — when data must stay, make it less recognizable: masking/tokenization, pseudonymization (reversible — the mapping table needs separate protection; weaker than anonymization), differential-privacy noise, distributed learning (PATE), encryption where possible. Caveats: costs model performance; reduces, never eliminates, re-identification risk.
5. Discretion — minimize access to technical details (papers, blogs, verbose output, error messages) that would help attackers pick and tune attacks; balance against AI transparency: open about properties, quiet about internals.

• Why it works: “what is not there cannot be leaked — or manipulated.” Absent data cannot be disclosed, reconstructed (inversion), inferred (membership inference), or corrupted (poisoning) — the benefit lands on confidentiality and integrity, and a stolen minimized dataset simply contains less to lose. One of the two blast-radius levers.

Go deeper: full textbook section.

Unwanted behavior needs no attacker: bad or insufficient training data, drift and staleness, engineering mistakes, and feedback loops (model output contaminating future training — model collapse). This family limits the effects, whatever the cause.

1. Oversight — watch behavior (human or automated) and respond: output detection rules, grounding checks by a second model, rollback, escalation. Human weaknesses: cost, slowness, missing context, approval fatigue.
2. Least model privilege — minimize what the model can do and reach: act with the served user's rights, scope permissions to the task, and never place authorization inside GenAI instructions. The heart of agentic safety.
3. Model alignment — constrain behavior inside the model (training choices, fine-tuning, RLHF, system prompts). Probabilistic and manipulable — one layer only.
4. AI transparency — inform users about system properties (how it roughly works, training data, expected accuracy, residual risks) so they calibrate reliance; simplest form: disclosing that an AI is involved (the EU AI Act requires it for chatbots).
5. Continuous validation — frequently test behavior against a test set to catch permanent change (poisoning) or drift; respond by investigating, rolling back, restricting use, adding oversight, disabling. Limit: backdoors are designed to pass it.
6. Explainability — explain individual decisions; counters overreliance and helps assessors.
7. Unwanted bias testing — measure unwanted bias; doubles as a security sensor — a sudden bias shift can be the first symptom of poisoning.

• Canonical answers: best agent safeguard = task-scoped least privilege + human approval for high-risk actions. Transparency = system properties; explainability = a specific decision.
• Blast radius has two levers — minimize/obfuscate data (3.2) and limit behavior (3.3). Risk payoff: a reduced attack surface, a bounded blast radius, lower legal/reputational exposure. Performance payoff: outputs stay on-scope, calibration and consistency improve, hallucinations drop, compute waste and incident counts fall — reliability and resource efficiency.
• Two mitigation failure modes: overreliance (users trust too much → transparency/explainability) and excessive agency (engineers grant too much → least model privilege).

Go deeper: full textbook section.

• Primary purpose of AI security testing: assess the resilience of an AI system by reproducing realistic attacks in a controlled environment. Not accuracy measurement, not compliance demonstration, not functional verification — an answer option without an adversary in it cannot be AI security testing.

Three testing strategies:

1. Conventional security testing — pentesting the surrounding stack: servers, APIs, authentication, network, supply chain. Mandatory, but blind to model-specific attacks.
2. Model performance validation — a benign test set against acceptance criteria; security use: detecting permanently altered behavior (data or model poisoning); also correctness and drift. Maps to continuous validation.
3. AI security testing — the security part of AI red teaming: simulate attacks, stress safeguards, attempt bypasses.

• Threats to test for beyond conventional testing (3 vs 3, no overlap) — predictive AI: evasion · model exfiltration (the replica becomes an attack oracle) · model poisoning (data, pipeline, model, or training supply chain). Generative AI: prompt injection (direct + indirect) · sensitive data disclosure in output · insecure output handling (output carries a conventional payload processed downstream).
• These trios are the key threats, not the whole landscape — full scope comes from risk analysis during scoping.

Go deeper: full textbook section.

The eight-step general AI security testing approach (in order):

1. Define objectives & scope — goals aligned with organizational, compliance, and risk requirements.
2. Understand the AI system — model, use cases, deployment scenarios.
3. Identify potential threats — threat modeling, attack surface, threat actors (start from the 4.1 trios).
4. Develop attack scenarios — concrete scenarios and edge cases for this system.
5. Test execution — run the attacks, manual or automated.
6. Risk assessment — document vulnerabilities; weigh severity against likelihood.
7. Prioritization & risk mitigation — remediation plan, implement mitigations, compute residual risk.
8. Validation of fixes — retest post-remediation; a fix that fails sends you back through the cycle.

• The process is iterative twice over: findings feed back within a cycle, and the whole cycle reruns regularly (at minimum before each deployment).
• Execution discipline: build a base attack set, tailor it to the system's own sensitive data and unacceptable outputs, pair each attack with an automated detection, test through the production route with production-equivalent configuration, run multiple times (non-deterministic output), and keep positive testing (benign inputs still work).
• After a clean first round, add variation algorithms — synonyms, encodings, formatting changes. A blocked attack proves the phrasing was recognized, not that the threat is handled; varying inputs is, in essence, an evasion attack on your own detection mechanisms.

Go deeper: full textbook section.

• Privacy = personal data protection + respect for further individual rights (know, correct, erase, object). Perfect encryption can still violate privacy — the second half is about purpose and rights, not secrecy.
• AI privacy splits in two: (1) security threats and controls protecting personal data everywhere it lives (training/test data, input, output) plus integrity of model behavior where wrong outputs hurt people; (2) non-security obligations — use limitation, consent, fairness, transparency, accuracy, and the rights to correct, object, erase.
• Why AI makes privacy harder: data intensity · long retention of training data (retraining) · exposure in the engineering environment (real data, unlike conventional dev) · model attacks that extract training data (inversion, membership inference, disclosure through use) · discriminating decisions · privacy-invading actions triggered by output. AI-native mitigation: federated learning — train in iterations across sites so raw data never leaves its source.
• PIA/DPIA: structured up-front assessment; a DPIA is mandatory under GDPR for likely-high-risk processing — training on personal data is a textbook trigger. A safeguard failure is a privacy incident with breach-notification duties.

Nine privacy principles (alphabetical, with scenario cues):

1. Accuracy — an incorrect record leads to a damaging automated decision about a person.
2. Consent — no valid permission: never asked, bundled, unwithdrawable, or coerced (employer–employee).
3. Data minimization & storage limitation — more data, finer grain, or longer retention than the purpose needs.
4. Fairness & lawfulness — handling people's data in unexpected ways, without legal basis, or with unjustified adverse effects.
5. Privacy rights — no way to access, correct, erase, or object.
6. Privacy by design — privacy bolted on after launch instead of engineered in (companion: privacy by default — most protective settings out of the box).
7. Security & safeguards — personal data unprotected in training sets, the engineering environment, or I/O.
8. Transparency & explainability — people affected by an algorithmic decision have no way to see its logic or inputs.
9. Use limitation & purpose specification — data collected for one purpose reused for another. The top exam pattern: whenever data crosses from its collection purpose to a new one (KYC data → marketing model, MFA phone numbers → advertising), this is the answer.

Go deeper: full textbook section.

The four ISO/IEC standards (a matching exercise):

1. ISO/IEC 23894 — AI risk management guidance across the AI lifecycle, aligned with ISO 31000.
2. ISO/IEC 27005 — information security risk management supporting ISO/IEC 27001 — not AI-specific; extend it to AI attack surfaces.
3. ISO/IEC 42001 — the AI management system (AIMS): governance, policies, roles, controls, continual improvement. 42001 is to AI what 27001 is to information security.
4. ISO/IEC 5338 — AI system lifecycle processes: AI engineering / MLOps for data and model development, deployment, operation.

• Matching cues: “AI risk management” → 23894; “information security risk management” → 27005; “management system / governance / continual improvement” → 42001; “lifecycle / engineering / MLOps” → 5338.

EU AI Act — four risk tiers (perspective: harm to people — safety, health, fundamental rights):

1. Unacceptable risk — prohibited outright: social scoring, manipulation, real-time remote biometric identification in public spaces. No compliance path exists.
2. High risk — permitted with compliance obligations + ex-ante conformity assessment (before market): products under safety legislation (medical devices), recruitment/employment, critical infrastructure, law enforcement.
3. Limited risk (specific transparency risk) — permitted with transparency obligations: a chatbot must disclose it is a bot.
4. Minimal / no risk — permitted without restrictions.

• Tiers are not mutually exclusive — a high-risk conversational system also owes limited-tier disclosures. Blind spot: the Act protects people, not company secrets — compliant is not the same as secure. GenAI addition: providers must disclose copyrighted training material.

Ten GDPR friction points (challenges AI creates under the GDPR):

1. Lawful basis — genuinely difficult to identify one that squarely covers model training on personal data.
2. Purpose limitation — service data keeps getting pulled toward training, a new purpose.
3. Data minimization vs model performance — the law wants less, accuracy wants more.
4. Transparency and explainability — “meaningful information about the logic” vs black-box models.
5. Automated decision-making and profiling — rights to human intervention, contest, information.
6. Operationalizing data-subject rights — erasure baked into a model may mean retraining without the person's data.
7. Accuracy and fairness — incorrect or biased data → unjustified adverse decisions.
8. Security and leakage — inversion, membership inference, and disclosure make the model itself a breach channel.
9. International transfers — data, GPUs, and providers cross borders casually.
10. Accountability and roles — controller vs processor across supplier/deployer chains is rarely obvious.

Ten copyright risk-mitigation strategies:

1. Mitigate disclosure of sensitive training data in output — stop the model emitting absorbed protected material.
2. Comprehensive IP audits — inventory all IP touching the system: datasets, code, systems, interfaces.
3. Clear legal framework and policies — written, enforced AI-use policies aligned with IP law.
4. Ethical data sourcing — in-house, permissioned, or properly licensed public-domain data. Ranking: in-house creation is the most ethical and safest (full provenance); licensed second; “publicly available” is not a license.
5. Define ownership of AI-generated content — decide up front who owns output and how it may be used.
6. Confidentiality and trade-secret protocols — handling rules that preserve trade-secret status.
7. Employee training — staff know the AI IP policies and the cost of infringement.
8. Compliance monitoring systems — ongoing checks for potential infringement by the system.
9. Response planning for IP infringement — a prepared plan for claims.
10. Licenses and/or warranties from AI suppliers — contractual cover for intended (and future) use, with supplier obligations for infringement claims.

Go deeper: full textbook section.