Risk vocabulary borrowed from the wrong domain is itself a risk. When a CAIO asks about "AI security," they might mean prompt injection, training data exposure, model supply chain integrity, or all three — and each requires a different control. When legal raises "AI liability," they might mean copyright infringement from training data, defamation from confident fabrication, or contractual exposure buried in model provider terms. Same words, different problems.
That collision is what this chapter addresses. Not by cataloguing every possible AI risk — threat inventories don't help you triage. The goal is calibrated vocabulary: a working map of the four distinct risk surfaces, what makes each one structurally different from the others, and why the failure modes inside them don't respond to controls your buyers already have in place.
Four Surfaces, Not One
Generative AI risk sits across four disciplines that security teams, privacy officers, legal counsel, and compliance functions normally own separately. In practice, they're landing on the same desk at the same time, which is why conversations get muddled.
Security is the familiar surface — threat actors, exploitable vulnerabilities, attack vectors. The vocabulary translates. The attack surface doesn't. Prompt injection, model inversion, and supply chain compromise don't respond to the same controls as network intrusion or credential theft. A WAF doesn't know what a prompt is.
Privacy is about data subjects, consent, retention, and re-identification. The framework is familiar. What's new is that the model itself is now a potential exfiltration path. If a model was fine-tuned on customer records, a carefully crafted query might surface them — not through a breach, but through inference. The data never moved. The model just learned it.
Legal is where the ground is genuinely unsettled. Copyright liability for training data, defamation exposure from confident fabrication, professional negligence when an AI-generated output is wrong in a high-stakes context — these are active litigation areas, not established doctrine. The Andersen v. Stability AI case, the New York Times suit against OpenAI, the ongoing EU AI Act liability provisions: none of these have produced stable precedent yet. Telling a buyer this is "solved" is a credibility-ending move.
Regulatory is the most dynamic surface. Sector-specific obligations — HIPAA, FedRAMP, FINRA, FERPA — were written before generative AI existed, and agencies are still issuing guidance on how they apply. The EU AI Act is in force but implementation timelines are staggered. The US has executive orders and NIST frameworks but no comprehensive federal AI law. The compliance posture a buyer builds today may need to be rebuilt in 18 months.
These four surfaces overlap, but they don't collapse into each other. A privacy failure isn't automatically a security failure. A legal exposure isn't automatically a compliance gap. Treating them as a single "AI risk" problem produces controls aimed at the wrong surface.
The Failure Modes That Break the Playbook
Four specific failure modes explain why existing controls fall short. Buyers will use imprecise language for them, and imprecise language leads to imprecise solutions.
Training data leakage is exposure that happened before deployment. If a model was trained on data it shouldn't have seen — PII, proprietary documents, copyrighted text — that exposure is baked in. There's nothing to intercept at runtime. DLP policies, data classification schemes, and access controls all operate on data in motion or at rest. Training data leakage is data at inference: the model simply knows things, and the right query surfaces them. The control lives upstream, in training data governance, not in the runtime stack.
Prompt hijacking via retrieved content is the attack vector most buyers haven't thought through yet. In retrieval-augmented generation (RAG) architectures, the model pulls documents from a knowledge base and uses them as context. If an attacker can influence what those documents contain — through a poisoned knowledge base, a malicious document in scope, or content on a public webpage the system indexes — they can embed instructions that redirect the model's behavior. The attack surface is any text the model reads. That includes documents your users upload, web pages your agent browses, and emails your system processes.
Confident fabrication is an epistemic failure, not a security failure, and that distinction matters for controls. When a model generates a false statement with high confidence and no uncertainty signal, no existing security tool catches it. The output looks correct. The model has no mechanism to flag what it doesn't know. The exposure is legal (defamation, professional negligence) and operational (decisions made on false information). The control is architectural — output validation, human review gates, domain-specific grounding — not a security patch.
Internet-scale supply chain is the hardest to operationalize. A model's training corpus is effectively the entire public internet plus whatever proprietary data the deploying organization contributed. There is no software bill of materials for it. Supply chain security as practiced for software — dependency scanning, provenance tracking, vulnerability disclosure — doesn't translate to a corpus that may contain billions of documents from millions of sources. The relevant governance question is what oversight exists over the model provider's training and fine-tuning practices, not what's in the supply chain.
IDAM Bridge — In identity, SQL injection is the canonical example of user input contaminating a trusted execution context — solved by parameterized queries that structurally separate code from data. The closest AI equivalent is prompt injection via retrieved content: attacker-controlled text in a document the model reads can redirect its behavior, just as malicious SQL in a form field can redirect a query. It diverges here: parameterization works because SQL has a grammar that separates instructions from data. Natural language doesn't. An LLM processing a retrieved document has no structural mechanism to distinguish "these are instructions from the system" from "instructions embedded in a PDF by someone who wanted to override the system." The defense isn't a parsing fix — it's architectural.
What This Section Covers
The ten lessons that follow move from failure mode to control. OWASP's LLM Top 10 provides the security taxonomy. Data leakage and jailbreak resistance cover the runtime attack surface. Copyright and fabrication liability address the legal exposure. The EU AI Act and emerging US frameworks map the regulatory terrain. Sector compliance — HIPAA, FedRAMP, FINRA — translates the frameworks into the verticals where your buyers operate. Audit obligations close the loop on what governance actually requires at deployment.
None of these lessons assume the reader needs to become a risk specialist. The goal is fluency: enough precision to ask the right question in a discovery call, recognize when a buyer's concern is landing on the wrong surface, and know when to bring in someone who goes deeper.