Ask most boards how much sensitive data left the building through an AI model last quarter, and you will get a shrug. Not because the risk is small, but because nobody is measuring it. Security spend gets justified with numbers: mean time to detect, patch coverage, phishing click rates. AI data exposure has no such number in most organizations, which is exactly why it keeps growing unchecked.

That gap is now expensive. IBM’s 2025 Cost of a Data Breach Report found that ungoverned “shadow AI” was involved in one in five breaches and added $670,000 to the average breach cost . These are not abstract governance failures. They are line items.

Why the exposure is invisible

The reason AI data leakage is hard to measure is the same reason it is hard to stop: most of it happens outside the systems you already monitor. Verizon’s 2025 DBIR found that 15% of employees routinely access GenAI on corporate devices, and 72% of them do so through non-corporate email accounts , outside corporate authentication and policy entirely. Your DLP tooling was built for email, endpoints, and file shares. It was not built to inspect what a developer pastes into a chat window or what an autonomous agent sends to a model provider’s API.

The result is a blind spot that leadership can already feel. Gartner reports that 69% of cybersecurity leaders suspect or can prove employees use prohibited AI tools , and predicts more than 40% of enterprises will hit a security or compliance incident tied to unauthorized shadow AI by 2030. Suspicion is not a metric. It is the absence of one.

The exposure runs both ways

Data-leak risk at the AI boundary is not only about what employees send out. It is also about what models send back. OWASP moved Sensitive Information Disclosure up to #2 in its 2025 Top 10 for LLM Applications , from #6 in 2023, precisely because models can surface sensitive data through their output: training data, retrieved context, or content pulled in by a manipulated prompt.

So the threat model has two directions:

  • Egress: proprietary code, customer PII, contracts, and internal strategy leaving in prompts, often to accounts and jurisdictions you do not control.
  • Ingress: sensitive data returning in model output, whether by accident or through deliberate extraction attempts against your own AI applications.

Both are data-loss events, and shadow-AI breaches skew heavily toward exactly that. The same IBM data shows these incidents were disproportionately likely to compromise personally identifiable information (65%) and intellectual property (40%) . This is not a productivity story with a security footnote. It is your crown-jewel data walking out through a channel you cannot see.

What “good” looks like

The organizations getting burned are not the ones using AI aggressively. They are the ones using it without controls. IBM found that among companies that suffered an AI-related security incident, 97% lacked proper AI access controls and 63% had no governance policy for AI at all . The problem is rarely that a policy was wrong. It is that there was no enforcement point where policy could be applied.

A defensible AI data-exposure program needs to answer four questions with numbers, not adjectives:

  • Volume: how much AI traffic crosses our boundary, and to which providers?
  • Sensitivity: how much of it carries regulated or proprietary data?
  • Disposition: what was allowed, redacted, or blocked, and under what rule?
  • Trend: is the exposure rising or falling quarter over quarter?

Those four turn a vague fear into a chart a board can read. And a board should want to read it: Stanford’s AI Index recorded a 56.4% year-over-year rise in documented AI incidents, to 233 in 2024 , while noting that organizations acknowledge the risks but their mitigation lags. The direction of travel is clear. What is missing is the instrumentation.

Put a control layer at the boundary

You cannot measure or govern traffic you never see, and you cannot see it from the endpoint or the SaaS console. The one place every prompt and every response necessarily passes through is the network path between your applications, agents, and their model providers. That boundary is where exposure becomes observable, and where policy can actually be enforced before data leaves rather than discovered after.

Treating that path as a first-class control point is what converts a diffuse worry into a governed, measured flow. It is also where cross-border risk gets caught: Gartner expects more than 40% of AI-related data breaches to stem from improper cross-border GenAI use by 2027 , and jurisdiction is only enforceable where traffic is inspected in transit.

This is the role a transparent firewall at the AI traffic layer plays: vendor-neutral, sitting inline between your AI systems and every provider, turning ungoverned prompt traffic into something you can see, enforce against, and report on. The metric your board wants already exists in that traffic. It just needs somewhere to be measured.

If AI data exposure is currently a shrug in your organization, the fix starts with putting a number on it. That is the problem Milgram was built to solve.