Four risk disciplines converge on every generative AI deployment: security, privacy, legal, and regulatory. They are not the same problem, they don't share the same control vocabulary, and they don't respond to the same mitigations. Treating them as a single "AI risk" category is how organizations end up with policies that are simultaneously over-engineered in one dimension and completely blind in another.
This chapter is about triage. Not alarm.
The goal is a vocabulary precise enough to tell the difference between a buyer who has identified a real risk for their specific deployment and a buyer who is performing risk concern because their legal team sent a questionnaire. Both conversations happen, and they require different responses.
Why This Is Appearing in Procurement Now
Generative AI risk didn't become real in 2025 — it became visible. The combination of agency-level AI deployment mandates, CAIO roles with actual sign-off authority, and a litigation landscape that's still forming around copyright and data provenance has pushed these questions from the research community into the procurement conversation. Chief AI Officers at civilian agencies are now required to assess AI systems before deployment, and they're asking questions that their existing risk frameworks weren't built to answer.
The questions aren't wrong. The frameworks are just incomplete.
Buyers have FISMA compliance programs, data classification policies, and vendor risk management processes that have worked reasonably well for traditional software. Those programs assume certain things about how software behaves: that it executes deterministic logic, that its outputs are bounded by its inputs, that its behavior can be tested and certified. Generative AI breaks all three assumptions. Understanding what the existing controls actually cover — and what they don't — is the work. The deployment doesn't stop; the risk model expands.
Four Surfaces, Briefly
Security is about what an attacker can do to or through the system. The threat model for generative AI includes failure modes that don't have clean analogs in traditional application security — particularly the ability for attacker-controlled content to redirect model behavior, and the model's role as an intermediary that can be manipulated into acting against the interests of the organization deploying it.
Privacy is about what the system does with personal information — both in training and in operation. The questions here are about data minimization, retention, and whether information shared with a model in one context can surface in another. These are familiar categories; the unfamiliar part is that the mechanisms of leakage are different from anything in a traditional data handling policy.
Legal is about liability — intellectual property, contractual obligations, professional responsibility in regulated domains. The litigation landscape around training data and generated output is actively forming. Confident answers are premature. What's not premature is knowing which questions to ask.
Regulatory is about compliance obligations that apply to specific deployment contexts — HIPAA for health information, FedRAMP for federal systems, sector-specific rules for financial services. These frameworks weren't written with generative AI in mind, and the guidance on how they apply is still being issued.
These four surfaces overlap. A prompt injection attack that causes a model to exfiltrate conversation history is simultaneously a security failure and a privacy failure. A model that generates legally incorrect advice in a regulated domain is simultaneously a legal risk and a regulatory risk. The overlap is real. The disciplines are still distinct, because the controls that address each one come from different parts of the organization and operate on different timelines.
The Failure Modes That Don't Map
Four failure modes define the specific risk character of generative AI. They appear in every serious risk assessment, and they're worth naming plainly before the lessons unpack them.
Training data leakage is the possibility that a model reproduces content from its training set — including content that was private, proprietary, or personal at the time of training. This is not a misconfigured access control. Tightening permissions on the model's output doesn't address it. The leakage, if it occurs, is a property of the model's weights, not of its deployment configuration.
Prompt injection is the redirection of model behavior through attacker-controlled content in the model's context. This content can arrive through retrieved documents, tool outputs, emails the model is asked to summarize, or any other channel where external content enters the context window. The model processes it as instruction. There is no reliable input sanitization that prevents this at the protocol level, which is why it's a different problem from SQL injection despite the superficial resemblance.
Hallucination — the model's generation of confident, plausible, false outputs — is not a software bug in the conventional sense. It is an emergent property of how large language models work. It cannot be patched. It can be mitigated through deployment architecture choices, but the mitigation is probabilistic, not deterministic. This matters enormously for any deployment where the model's output is treated as authoritative.
The supply chain for a generative AI system includes the training data, which for most foundation models includes a substantial portion of the public internet at a point in time. This is not analogous to a third-party library dependency. Auditing it the way you audit a software bill of materials isn't possible. The model's behavior is shaped by content that no one in the procurement chain has reviewed.
None of these failure modes fit cleanly into existing security or compliance playbooks. Precision, not alarm, is the appropriate response. Organizations struggling with AI risk governance are mostly struggling because they're applying controls designed for one threat model to a system with a fundamentally different one.
IDAM Bridge — In identity, complete mediation means every access request passes through a policy enforcement point that can evaluate who is asking, what they're asking for, and whether policy permits it. The closest AI equivalent is input validation — checking what enters the model's context before it's processed. It diverges here: a policy enforcement point operates on a closed, enumerable set of principals. A generative AI model processes natural language from sources that cannot be enumerated in advance, including attacker-controlled content embedded in retrieved documents or tool outputs. The model has no native mechanism to distinguish instruction from data. Complete mediation assumes you can define the principal set. Prompt injection works precisely because that assumption doesn't hold.
What This Chapter Covers
The lessons that follow address each risk surface in enough depth to support a real buyer conversation. Not implementation guidance — the controls belong to the security architects and compliance teams. What you need is the vocabulary to triage: to recognize which risk is actually in play, to know which part of the buyer's organization owns it, and to ask the question that moves the conversation forward rather than the one that stalls it.
The chapter covers prompt injection and input trust, training data provenance and leakage, hallucination and output reliability, and the regulatory frameworks that are actively being applied to AI deployments in the federal context. Each lesson follows the same structure: what the risk actually is, what the common misconception is, and what a calibrated response looks like.
Fluency, not expertise, is the goal. In a buying process where the CISO, the privacy officer, the general counsel, and the compliance team are all at the table with different concerns, being the person who has clearly done the reading is a distinct kind of credibility. It's the kind that closes deals.