If you have a legacy DLP deployment and you are now asking what it covers for AI prompt traffic, the answer is almost certainly: very little. This is not because legacy DLP is poorly built. It is because the inspection surfaces it was designed for do not intersect with how AI prompt traffic moves. Understanding why requires going through the inspection surfaces one by one and being precise about what each one captures and what it misses entirely.
How Legacy DLP Works: The Five Inspection Surfaces
Legacy DLP products built over the past decade and a half generally inspect five surfaces: outbound email (SMTP traffic, Exchange transport rules, or email gateway inline inspection), file system and endpoint transfers (files written to USB storage, external drives, or sync folders for cloud storage like Dropbox or Google Drive), network-level DLP (content inspection on non-HTTPS traffic, or HTTPS with TLS decryption configured), web proxy or CASB (categorize web destinations, restrict access to consumer file sharing, inspect uploaded files), and clipboard monitoring (endpoint agent detects large copy operations, flags content copied across defined data classifications).
Each of these surfaces was designed to answer a specific question: is a sensitive file or a block of text being moved through this channel? The detection logic looks for patterns (regex for SSN, credit card numbers, IBAN formats), fingerprints (hash-based matching against classified documents), or keyword dictionaries. The assumption is that data leaves the organization in a recognizable form through a channel the DLP layer monitors.
Why the Prompt Surface Does Not Match Any of These
When an employee types a prompt into ChatGPT's text input field and clicks the submit button, the following happens at the network level: the browser sends an HTTPS POST request to chat.openai.com. The request body contains JSON with the prompt text and conversation metadata. The connection is TLS-encrypted.
Email DLP does not fire. Nothing was sent to an email address.
File DLP does not fire. No file was created, no file was written to a sync folder, and no USB transfer occurred.
Network DLP does not fire unless the organization has deployed TLS interception, which most have not for major SaaS domains. Even with TLS interception, the DLP policy would need to be specifically configured to inspect POST body content to AI tool endpoints, which is not a default inspection rule in any legacy DLP product.
CASB or proxy does not block the request, because chatgpt.com is a known SaaS domain categorized as "AI assistant" or "productivity" and is typically on an allow list. The proxy sees that the employee made a request to an allowed SaaS service. It does not see what was in the request body.
Clipboard monitoring might fire if the employee copy-pasted from a classified document and the clipboard agent was monitoring that specific paste operation. But the clipboard monitor has a narrow window. It sees the clipboard copy event. It does not see where the content ultimately went. If the employee typed the sensitive content directly into the prompt box, or if the clipboard monitoring did not classify the original document, nothing fires.
The result: a complete transfer of sensitive content to a public AI inference endpoint produces no DLP alerts in a standard legacy DLP deployment.
The Freeform Natural Language Problem
Even if a legacy DLP tool were positioned to inspect AI prompt content, there is a second structural problem: the pattern-matching detection model was built for structured data in file formats.
A credit card number in an email attachment triggers the Luhn-check regex. A Social Security Number in a Word document triggers the SSN pattern. These are relatively easy detection targets because the data has a known format and appears in a context (a file, an email body) where the DLP tool expects to find it.
An AI prompt containing sensitive information often does not look like a file or an email. It looks like a natural language sentence: "Can you help me draft a response to this customer? Their name is [name], they have an account with ID [ID], and they are asking about a charge from [date]." None of that individually matches an SSN regex or a credit card format. But it is clearly customer record data that regulators under CCPA or GDPR would consider personal information the organization is responsible for protecting.
Or consider a developer's prompt: "Here is the function that handles our payment processing. It calls [internal service name] at [internal endpoint] with the API key [key string]. Can you help me refactor this?" The API key is in there, and a well-tuned regex might catch the key format. But the internal service names, the architecture details, and the code logic are all proprietary information with no regex pattern to match against.
Legacy DLP's detection model was calibrated for structured data in known formats. AI prompts are freeform natural language with sensitive information embedded in prose, code, and mixed-context text. The detection surface and the detection model are mismatched from first principles.
What CASB Coverage Actually Provides
Security teams often ask about CASB tools as an AI tool governance layer, given that CASBs were marketed as covering SaaS usage. It is worth being specific about what CASB coverage actually delivers for AI tools.
A CASB can see that an employee accessed chatgpt.com and roughly how much network traffic they generated. It can block access to specific AI tool domains if the policy is set that way. It can log which AI tools are accessed by which employees, giving the security team an inventory of AI tool usage patterns.
What CASB cannot do: inspect the content of HTTPS POST bodies to AI tool endpoints without TLS interception. Categorize the data types present in prompt content. Alert on a specific prompt that contained API keys. Provide the incident response team with a log entry that says "employee X sent a prompt containing PII to ChatGPT at 14:32 UTC." The CASB log entry for that same moment says "employee X accessed chatgpt.com."
CASB visibility is access visibility. It tells you who is using AI tools, how often, and from where. That is useful information for understanding AI tool adoption and scoping. It is not the same as knowing what data is going into those tools.
A Gap Analysis Framing for Your Security Review
When presenting this gap to a CISO or compliance team, the framing that tends to land is not "legacy DLP is broken" but "legacy DLP was not designed for this surface, and we should be precise about what it covers and does not cover."
Draw the threat model: employee sends sensitive data to a public AI tool. Trace that threat through each DLP control layer. At each layer, ask: does this control see the prompt content? In most standard configurations, the answer is no at every layer. That is not a DLP configuration failure. It is a coverage gap inherent to the architecture.
The gap analysis produces a clear statement of what is needed: a control layer that is positioned to inspect prompt content before it leaves the employee's browser, capable of applying your organization's classification policy to freeform natural language text, and able to take action (block or redact) at the time of submission rather than detecting the event retroactively. That is the architectural requirement, and it maps directly to what inline prompt inspection tools provide and what legacy DLP tools structurally cannot.
For teams that have invested significantly in legacy DLP and are evaluating whether to supplement or replace, the answer for most organizations is supplement, not replace. Email DLP, endpoint file monitoring, and CASB access logging remain useful for the surfaces they were built for. The AI prompt surface requires an additional layer that those tools were not designed to cover. The legacy DLP investment is not wasted. It is just incomplete for the current threat landscape.