The Risk Surface of Generative AI

Generative AI creates risk across four distinct surfaces: security, privacy, legal, and regulatory. Each surface requires different controls, different expertise, and a different person in the room with decision authority.

Most organizations are treating AI risk as one problem with one owner. That's the first and most consequential mistake. Assigning "AI risk" to the CISO, or to legal, or to a newly appointed Chief AI Officer whose authority boundaries haven't been drawn yet, guarantees that at least two of the four surfaces go unmanaged. Nobody is being negligent. The organizational chart just hasn't caught up to the threat model.

This matters in a specific way when you're in the room. When a buyer can't articulate who owns which piece of their AI risk posture, the conversation stalls on a governance gap that presents as a technical objection. Recognizing the difference changes what you do next.

You already understand trust chains, access control, audit logging, and governance frameworks. That knowledge is genuinely useful in AI risk conversations. But each risk surface has a point where the familiar model stops mapping, and misplaced confidence in the analogy is more dangerous than having no analogy at all. The lessons in this section mark those break points precisely, so you know when your instincts are helping and when they're about to mislead you.

Four surfaces, four owners

Security is the attack surface of the AI system itself. Models can be manipulated through their inputs. Training data can be corrupted before deployment. The supply chain for a large language model runs through pre-trained weights, third-party datasets, fine-tuning pipelines, and inference infrastructure, with no strong provenance assurances at multiple layers. NIST AI 600-1 (the companion profile to the AI Risk Management Framework, focused specifically on generative AI; the closest thing to a consensus risk taxonomy the federal ecosystem has produced) catalogs twelve risk categories it considers unique to or worsened by generative AI, and several of them live here. The OWASP Top 10 for LLMs (an open community standard maintained by the same foundation behind the web application Top 10; strong on practical exploitation patterns) maintains a parallel taxonomy. Both sources identify the LLM supply chain as a distinct risk category, extending through training data, pre-trained models, adapters, and deployment infrastructure (NIST AI 600-1, "Value Chain and Component Integration"; OWASP LLM03:2025). Security owns this surface. The controls are technical.

Privacy sits adjacent to security but answers to different authority. A model trained on personal data may memorize and reproduce that data in outputs. A model deployed inside an agency may ingest sensitive information through user prompts and retain it in ways nobody authorized. The controls here are data governance frameworks, consent mechanisms, and retention policies — a different toolkit entirely. The owner is the Chief Privacy Officer. Conflating privacy with security is how organizations end up passing a security audit while the privacy exposure sits untouched.

Legal risk is a different discipline entirely. When a model generates content derived from copyrighted training data, that's a question for counsel, not the SOC. When a model produces output that a human relies on for a consequential decision, liability attaches somewhere, and "somewhere" is doing a lot of work in that sentence because the case law is still forming. The controls are contractual and procedural: licensing terms, indemnification clauses, human review requirements. General counsel needs to be in the room before procurement, not after incident response.

Regulatory risk is the compliance layer, and it has its own calendar. Federal agencies operate under executive directives mandating AI governance structures, use case inventories, and minimum risk management practices. The EU AI Act assigns different obligations depending on whether you're a provider or a deployer of an AI system. Those are legally distinct roles with different compliance burdens (EU AI Act, Article 3 definitions; corroborated by Pitch.law's legal analysis, March 2026). Treating regulatory compliance as a subset of security is like treating contract law as a subset of accounting. Same building, different discipline entirely.

The NIST AI RMF Govern function (NIST's official implementation playbook; the Govern function is the cross-cutting organizational layer of the AI RMF) makes this organizational reality explicit. It calls for cross-functional teams spanning legal, compliance, data science, and operations, and states plainly that unclear responsibility chains limit the effectiveness of everything downstream. This is the structural premise of the framework, stated up front.

Why this is in your meetings now

The federal AI conversation has shifted from "should we worry about this" to "who owns which piece." That's a different kind of meeting, and it's happening now because agencies have been told to stand up governance structures and report what they're running.

The OMB 2025 AI Use Case Inventory (the official public repository where agencies report AI deployments under OMB directive) shows 56 agency submissions with over 3,600 individual use cases, more than 400 classified as high-impact (OMB GitHub repository, April 2026; corroborated by agency-level inventory disclosures). Agencies are operationalizing multi-domain governance in response. DHS stood up a governance board with membership spanning IT, cybersecurity, privacy, civil rights, procurement, and legal counsel. GSA's AI strategy requires joint review of production AI systems by the CAIO, CISO, Chief Privacy Officer, and data governance leads (GSA official strategy, November 2025; confirmed by Ogletree Deakins' compliance analysis, December 2025).

Your buyer isn't wondering whether AI risk is real. They're trying to figure out which risks apply to their specific deployment, who owns each one, and which controls they're missing. You can work with that.

Where the familiar models stop working

NIST AI 600-1 is careful about this. The risks it catalogs are described as "novel to or exacerbated by" generative AI. That qualifier matters. Some AI risks are familiar problems in unfamiliar packaging. Others have no clean precedent.

Three failure modes fall into the second category:

• Confident factual fabrication. The industry calls this "hallucination," though that term implies the model is trying to be truthful and failing. NIST uses "confabulation." What's actually happening is that the model generates statistically plausible text with no mechanism for verifying its own claims. A structural property of how the architecture works. It ships with the model.
• Prompt injection. The model cannot reliably distinguish between instructions and data, a separation that traditional application architectures enforce at a foundational level.
• Training data leakage. The model memorizes and can reproduce data it was trained on, including data never intended to be retrievable.

Each gets detailed treatment in the lessons ahead. The important structural point: these emerge from how generative AI works. They're properties of the architecture, and the controls that address them don't resemble anything in a traditional security playbook.

What's ahead

The lessons ahead walk each risk surface in detail. You'll get the security taxonomy, the privacy framework where data governance meets model behavior, the legal landscape with honest markers for what's settled and what's genuinely unknown, and the regulatory map with specific obligations, owners, and deadlines.

The goal throughout is vocabulary and judgment. Some of the risks circulating in the AI discourse are real and immediate. Some are theoretical. Some are vendor FUD wearing a compliance hat. This section helps you tell the difference, so you can follow the conversation without bluffing and know when your existing instincts apply and when they'll steer you wrong.