Generative AI creates four distinct risk surfaces: security, privacy, legal, and regulatory. They share a name — "AI risk" — and a common trigger, an AI deployment. That's approximately where the commonality ends.
Each surface has a different owner inside the enterprise. Each demands a different control discipline. Each produces a different kind of conversation when it surfaces in a buyer meeting. Treating "we have AI risk concerns" as a single question produces a single answer. Hearing four structurally different questions, and identifying which one is actually live, changes the conversation.
That's the purpose of this chapter. Not a comprehensive threat catalog. Calibrated vocabulary for triage.
The Four Surfaces
Security risk is what happens when an AI system becomes an attack surface or an attack vector. Adversaries can manipulate model inputs, extract information from model outputs, compromise the infrastructure the model runs on, or abuse the model's access to downstream systems. The owner is the security engineering team, the people who hold threat modeling, vulnerability management, and incident response. The control disciplines are familiar: access control, segmentation, logging, detection. What's unfamiliar is the attack surface itself. AI systems introduce failure modes that don't map cleanly onto the threat models security teams built for human-driven workflows, and that gap is where the real exposure lives.
Privacy risk sits at the intersection of data governance and legal compliance. An AI system can process personal information in ways that violate reasonable expectations or legal requirements: training on data that shouldn't have been used, surfacing information that should have stayed siloed, retaining inputs longer than policy allows. The owner is typically the privacy officer or data protection officer, not the security team. The control disciplines are different: data classification, retention policy, consent management, data subject rights. Security controls can reduce privacy risk but cannot eliminate it. A system can be perfectly secure and still constitute a privacy violation. The failure mode is authorized use that exceeds what was permitted, not unauthorized access.
Legal risk is what happens when an AI system's outputs, or the process of building it, creates liability. Questions about the provenance of training data. Questions about accuracy and reliance when AI outputs inform decisions that affect people. Contractual obligations that a deployment may create or violate. Legal risk is owned by general counsel, and the control discipline is not technical — it's governance. Who approved this use case? What representations were made? What's the paper trail? The tools here are policies, contracts, and review processes. A security architecture doesn't answer these questions, and a privacy framework doesn't either.
Regulatory risk arises when an AI deployment runs into a compliance requirement the organization didn't know applied, or knew applied and didn't satisfy. This is distinct from legal risk because regulatory requirements exist independent of whether anyone is harmed or any contract is breached. A regulator can find a violation without a plaintiff, without a breach, without any adverse outcome. Regulatory risk is owned by the compliance function, and its control discipline is documentation, audit readiness, and policy alignment. The landscape here is genuinely unsettled: multiple regulatory frameworks across jurisdictions are in various stages of development and finalization, and the mapping between specific AI deployment patterns and specific compliance obligations is still being worked out. Anyone who tells you this is settled is selling certainty they don't have.
Why the Owner Question Is the First Question
These four surfaces overlap at the edges. A security incident can create privacy exposure. A privacy violation can trigger regulatory action. A legal liability can emerge from a security failure. The overlaps are real, and the lessons in this chapter address them.
But the overlaps don't collapse the distinctions. A CISO raising concerns about model manipulation is not asking the same question as a general counsel raising concerns about training data provenance, even if both conversations are nominally about "AI risk." Conflating them produces answers that satisfy no one. The person asking about attack surface doesn't need a copyright briefing. The person asking about regulatory exposure doesn't need a threat model.
When a buyer raises AI risk, the first move is triage. Which surface? Who owns it inside their organization? What control discipline are they working from? Those three questions determine which conversation you're actually in and who else needs to be in the room.
This matters more in public sector than in most enterprise contexts. Federal agencies don't have a single AI risk owner. The CISO, the privacy officer, the general counsel, and the compliance function are distinct organizations with distinct reporting lines, distinct budget authorities, and distinct definitions of what "managing AI risk" means. A conversation that lands well with one of them may land wrong with another, because they're asking different questions.
What This Chapter Covers
The lessons that follow go deep on each surface. They cover specific threat categories, specific regulatory frameworks, specific legal questions, and specific audit requirements. This piece is not the place for that depth.
What this piece gives you is the map you read before you enter the territory: four surfaces, four owners, four control disciplines, and the triage instinct to tell them apart before you answer.
IDAM Bridge — In identity, access governance separates four distinct disciplines: authentication, authorization, governance, and audit. Each has a different owner and a different toolset, but all four operate against the same object — the user identity. The closest AI equivalent is the four risk surfaces: security, privacy, legal, and regulatory. It diverges here: in IAM, a single principal model threads all four disciplines together. In AI risk, there's no equivalent shared object. A security incident, a privacy violation, a legal liability, and a regulatory finding can all arise from the same deployment without any of them being reducible to the others — and there's no "AI identity record" that connects them. That's why no single owner and no unified control framework can govern all four, and why triage is the skill, not taxonomy.
The buyer who says "we need to manage AI risk" is not necessarily asking for a product. They may be asking for a framework, a policy, a legal review, or a compliance posture. Knowing which one they're asking for is the difference between a conversation that goes somewhere and one that doesn't.
The chapters that follow give you the depth on each surface. This one gives you the orientation: four surfaces, four owners, four control disciplines.