Generative AI introduces four distinct risk surfaces — security, privacy, legal, and regulatory — and the most important thing to understand about them is that they don't reduce to each other. An organization can have strong security controls and still carry significant legal exposure. It can be FISMA-compliant and still have a privacy liability it hasn't named. Most buyer conversations fail here: four different problems get treated as one, and the controls don't hold because they weren't built for the right problem.
This chapter is about triage. Not alarm, not exhaustive coverage — triage. By the end of it, you should be able to hear a buyer's concern and place it in the right domain, because the domain determines the control discipline, the owner, and the conversation that actually needs to happen.
Four Surfaces, Four Disciplines
Security is the adversarial surface. It covers what an attacker can do to a system that includes a generative AI component: injecting malicious instructions through content the model processes, manipulating model behavior through crafted inputs, extracting sensitive information through carefully constructed queries. Supply chain risk takes a form here that traditional threat models weren't designed to handle — the model itself, the data it was trained on, the plugins and tools it can invoke. The control discipline is threat modeling and technical controls, owned by the security team. The failure mode is assuming that because the application layer is secured, the model layer is secured too.
Privacy is a different problem. It lives in the data the model has seen and what the model can reproduce. Language models trained on large datasets can memorize and, under the right conditions, regurgitate fragments of that training data — including content that was never meant to be retrievable. Beyond memorization, there's inference: a model's outputs can sometimes reveal information about its training distribution in ways that create privacy exposure even when no individual record is directly reproduced. The control discipline is data governance and privacy engineering. The owner is not the security team. Organizations that route privacy questions to their security function will get technically competent answers to the wrong questions.
Legal risk is about liability and ownership in territory where the law is still forming. Who owns the output of a generative AI system? What is the organization's exposure when a model produces a confident, plausible, and factually wrong statement that a user acts on? What does the vendor contract actually say about data use, model training, and indemnification? These are not security questions or compliance questions. They require legal review, and they require it before deployment, not after an incident. The control discipline is contractual and legal review. The owner is counsel.
Regulatory risk is about compliance frameworks that were written before generative AI existed and are now being applied to it, often awkwardly. FISMA was designed for traditional IT systems with defined boundaries and auditable states. FedRAMP extended that logic to cloud services. Neither framework was written for a system whose outputs are probabilistic, whose behavior can be altered through natural language inputs, and whose audit trail captures what was sent and received but not why the model produced what it produced. Emerging frameworks — NIST's AI Risk Management Framework, the EU AI Act, agency-specific guidance from OMB — are attempting to close that gap, but the mapping is still incomplete. The control discipline is framework alignment and compliance monitoring. The owner is the compliance function.
IDAM Bridge — In identity, authorization scope defines what a token can do, and that scope is enforced by the authorization server — not the client, not the resource. The closest AI equivalent is the system prompt, which constrains what the model will and won't do. It diverges here: unlike OAuth scope, the system prompt is enforced by the model itself. An attacker who can inject instructions into the model's context — through a document the model reads, a tool output it processes, or user input it incorporates — can potentially override those constraints from the inside. The enforcement mechanism and the attack surface are the same thing. Prompt injection has no clean IDAM analog for exactly that reason.
Why the Existing Playbook Doesn't Cover This
Traditional security frameworks assume a defined attack surface. You know what you're protecting. You know what the threats look like. You build controls at the boundary. Generative AI's attack surface includes the entire corpus the model was trained on, every piece of content the model processes at inference time, and outputs that can't be fully predicted from inputs. The threat model is open-ended in a way that perimeter-based and even zero trust frameworks weren't designed to address — they were built around systems whose behavior is deterministic given known inputs, and that assumption doesn't hold here.
Compliance frameworks have a different problem. They assume the framework was written for the technology being assessed. When an auditor asks whether a system meets FISMA's audit and accountability controls, the expected answer involves log files, access records, and a chain of custody for who did what and when. A generative AI system produces logs of inputs and outputs. It does not produce an auditable record of its reasoning. That gap is structural — a mismatch between what the framework expects and what the technology produces, not something a configuration change resolves.
Neither of these failures means the existing frameworks are useless. Zero trust principles apply to AI systems — the question of which identities can invoke which models with which tools is an access control question, and it has access control answers. FISMA's control families provide a starting point for AI system assessment. But "starting point" is the operative phrase. The frameworks require extension, not just application.
What This Chapter Covers
The ten lessons that follow this opener address each risk surface in depth. Security lessons cover the specific failure modes — prompt injection, training data exposure, agentic system risks — and the controls that address them. Privacy lessons address data governance for AI systems, including what "training data" means in practice for organizations using third-party models versus fine-tuning their own. Legal lessons cover the liability questions that counsel needs to answer before deployment. Regulatory lessons map the current framework landscape, including where NIST AI RMF, OMB guidance, and agency-specific requirements converge and where they conflict.
The chapter closes with a recap built around the triage frame: given a specific deployment shape and a specific buyer concern, which surface does it belong to, who owns the response, and what does a credible answer look like?
One honest note before you proceed: this field is moving. Some of what the regulatory lessons cover reflects guidance issued in the last eighteen months and may have been updated by the time you're reading this. Where the framework is settled, the lessons say so. Where it isn't, they say that too — and name specifically what's unsettled, rather than gesturing at uncertainty. That distinction is the difference between content you can use in a buyer conversation and content that will get you in trouble when the buyer's counsel asks a follow-up.
Start with the security surface. Buyers raise it first, and it's where the gap between what they think they understand and what's actually happening is widest.