AI DLP is data loss prevention applied to the prompt layer: detecting sensitive data in text submitted to AI tools, before submission, rather than in files, email or network traffic. Also called LLM DLP or prompt-layer DLP.
Why a separate category
Traditional DLP is organised around files and channels.
Its model is that data lives in documents and leaves through enumerable exits: email attachment, USB, print, cloud sync, upload.
Text typed into a browser composer is none of those. It never becomes a file, never traverses a monitored channel, and never matches a rule, so a fully functioning endpoint DLP deployment reports nothing while thousands of records flow to a third party every week.
What the system does
What separates products is when the inspection happens.
The distinguishing property is timing. Inspection happens before the message is sent, which is the only point at which prevention rather than after-the-fact alerting is possible.
- 01
Capture
The outbound text block and its destination, at the composer.
- 02
Detect
Sensitive data in it: patterns, contextual models, custom rules.
- 03
Classify
Against compliance frameworks, scored by whether the destination is sanctioned.
- 04
Enforce
Log, warn inline, or block the submit.
- 05
Report
A record to the console and the SIEM.
The two architectures
Where step two executes is the whole evaluation.
Which one a vendor uses is the single most consequential question in an AI DLP evaluation, and it is not always in the datasheet.
Cloud classification
The prompt is sent to a service for inspection. Heavier models, no endpoint footprint, and the content now exists in another vendor’s systems.
On-device classification
Detection runs locally and only a derived, redacted record is transmitted. Harder to build, and the content never leaves the machine.
What it is not
It is not a firewall rule with a longer list.
Two things get sold as AI DLP that are not. The first is a blocklist of AI hostnames. That stops traffic to the names on the list and tells you nothing about what was in the message, which means it cannot distinguish a developer pasting a stack trace from someone pasting a patient record. It also moves the behaviour to a phone, where there is no record at all.
The second is a proxy that terminates the connection and inspects the body server-side. That does see content, and it sees it by making a copy of every prompt your staff write. For a covered entity or anyone handling cardholder data, that copy is a disclosure of its own, which is the argument for redacting before anything leaves the device rather than after.
The honest limit is that content inspection at the composer sees what is typed or pasted into a browser or desktop client. A file attached to a chat, or data reaching a model through an API your developers wrote, is a different control and needs a different answer.
Questions
Is AI DLP different from the DLP we already own?
Yes, in what it inspects. Endpoint DLP is organised around files and the channels they leave through. A prompt never becomes a file and never traverses one of those channels, so a fully working endpoint DLP deployment can report nothing while thousands of records go out every week.
Does AI DLP have to read what employees type?
It has to inspect the text about to be sent, which is not the same as retaining it. The inspection can run on the device and emit only a finding: the kind of data, a count, the destination and the action taken. Whether a product keeps the text is a design choice, not a requirement.
Can a web gateway or proxy do this instead?
Not for the thing that matters. A gateway sees an encrypted connection to a hostname. It can allow or deny the whole tool, but it cannot see the sentence inside the session, so it cannot distinguish a harmless question from one carrying a patient record.
What happens if detection is wrong?
False positives are the real failure mode, not missed identifiers. A rate high enough that people learn to click through the warning destroys the control, which is why precision matters more than recall once a tool is actually deployed.
Does it work for AI desktop apps, or only the browser?
Both, by different means. Browser coverage comes from an extension reading the composer; desktop apps are read through the operating system's accessibility layer, because those apps pin their certificates and intercepting their connection breaks them.
Is this the same as blocking ChatGPT?
No, and blocking is usually counterproductive. Denying the tool moves the behaviour to a personal phone, where there is no visibility at all. AI DLP exists so the tool stays usable and the record does not go with it.
Keep reading
- The comparison AI DLP vs CASB vs endpoint DLP What a CASB, endpoint DLP and a web gateway each inspect, and the surface that falls between all three. 6 min read
- Product Detection engine Itzal's detection runs locally in layers, patterns, contextual inference, framework mapping. Product page
- Product Surface coverage An honest coverage matrix for AI DLP: which surfaces Itzal inspects, which it doesn't. Product page
- Evaluation How to evaluate an AI DLP tool The questions that separate these products, starting with the one most datasheets avoid: where does classification actually execute. 6 min read