The Question
Your security team has deployed a best-in-class DLP stack. Symantec, Forcepoint, or Microsoft Purview is scanning outbound email, monitoring USB transfers, and inspecting web uploads. It catches SSNs, credit card numbers, and healthcare record identifiers before they leave the perimeter. Then your organization deploys an LLM-based assistant and the CISO asks the question nobody has a clean answer to: Is our DLP protecting data in AI systems?
The honest answer is: mostly no. Traditional DLP was architected for a world of structured data moving through defined, enumerable channels. AI systems process unstructured text, generate novel output that may or may not contain sensitive information, and incorporate data into model weights in ways that have no analogue in the DLP threat model. The pattern-matching engine that catches a nine-digit SSN in an email body cannot determine whether a board memo uploaded to an LLM contains material non-public information about a pending acquisition. It cannot tell whether a model's response to a user query reveals something that was embedded in the training data. The channel does not exist in the DLP taxonomy.
This is not a minor gap. It is a categorical mismatch between the security control and the threat surface it is being asked to cover.
Traditional DLP protects data in transit through known channels — AI data security must protect data that is incorporated into model weights, retrieved as context, and transformed into model output, which are channels that DLP was never designed to see.
Why This Matters Now
In September 2024, Samsung's internal semiconductor design data appeared in outputs from ChatGPT after engineers uploaded proprietary code and circuit diagrams to the tool for debugging assistance. Samsung subsequently banned employee use of external generative AI tools — but the disclosure had already occurred, and no DLP control had fired. The data left the organization not as a file attachment or email, but as a prompt submitted to a third-party inference endpoint.
This incident was not an isolated edge case. It was the first publicly documented instance of a recurring data exposure pattern: enterprise employees submitting sensitive business context to external LLM APIs in the course of normal work, with no data loss prevention control capable of understanding the semantic content of what was being transmitted.
The regulatory environment has accelerated the pressure. The EU AI Act (effective August 2024 for prohibited practices, August 2026 for high-risk systems) explicitly requires that high-risk AI systems maintain documentation of training data governance and that personal data used in AI training be processed in compliance with GDPR. The US NIST AI Risk Management Framework, updated in 2025, includes data security as a core pillar of the Govern function. The UK ICO published guidance in 2024 stating that organizations using third-party generative AI tools are controllers of personal data submitted in prompts and must conduct data protection impact assessments before deployment.
The compliance posture of most enterprises at this moment is: DLP controls that cannot see LLM data flows, data governance documentation that predates AI programs, and AI deployments that have outpaced security review. The gap between regulatory expectation and operational practice is widening rapidly.
What the CURVE™ Data Shows
The 2026 Stackcurve Data Security for AI CURVE™ Report evaluated seventeen vendors across four capability domains: semantic data classification, AI pipeline visibility, training data governance, and inference output monitoring. The findings reveal a market that is still early — most vendors have strong capability in one or two domains and significant gaps in the others.
Nightfall AI leads in semantic DLP for LLM applications, with production-grade integrations for OpenAI, Google Gemini, and Anthropic API endpoints. Their classifier suite covers PII, PHI, PCI, and custom sensitive categories using transformer-based models rather than pattern matching. Securiti.ai delivers the broadest platform scope with their AI Data Command Center — covering data discovery, consent management, and AI governance in a single platform, though depth in inference-time controls lags their discovery capabilities. BigID has extended its data discovery platform to cover AI training datasets, with lineage tracking and classification at scale. Knostic is the emerging specialist in access governance for LLM output — controlling what information different users are permitted to receive in model responses based on their authorization level. Immuta provides data access control for ML pipelines, with policy enforcement at the data access layer rather than the application layer.
Buyers evaluating this space need to assess whether they need point capability (semantic DLP for a specific LLM deployment) or platform coverage (end-to-end data governance across the AI lifecycle). Most organizations will need both, and most current budgets are sized for one.
The full vendor rankings are in the 2026 Stackcurve Data Security for AI CURVE™ Report — free to download.
The Gap Most Buyers Miss
Most organizations framing their AI data security problem are asking the wrong question. They ask: which DLP vendor supports LLM integrations? The correct question is: which phases of the AI data lifecycle are we not currently monitoring?
The semantic classification gap. Traditional DLP operates on structural patterns: a regular expression for SSNs, a checksum for credit card numbers, a file hash for known sensitive documents. LLM inputs and outputs are natural language. "The Q4 guidance is $4.2 billion, which we have not disclosed" contains material non-public information — but there is no structural pattern to detect it. Semantic DLP, using transformer-based classifiers trained on sensitive content categories, is the only technical approach that works. Few organizations have deployed it.
The inference endpoint gap. When an employee submits a query to ChatGPT, Copilot, or Claude via a browser tab, that traffic traverses the corporate network as HTTPS to a known domain. A CASB or proxy can block the domain. But blocking ChatGPT.com does not stop the same employee from accessing the same API via a mobile hotspot, a personal device, or a browser extension. The enforcement perimeter does not align with the data flow perimeter. Organizations need to address the governance problem (policy, training, acceptable use) in parallel with the technical control problem.
The training data governance gap. The data used to fine-tune enterprise AI models receives essentially no security governance in most organizations. It is assembled by ML engineers who understand the modeling requirements, stored in cloud object storage, and accessed by training jobs running with service account credentials. There is no data classification, no access logging, no lineage documentation. This is simultaneously the most sensitive data asset in the AI program and the least governed.
The output monitoring gap. An LLM response that contains sensitive information — a customer's account details surfaced through RAG retrieval, a proprietary process description from the training set — is not flagged by any control in most organizations' security stacks. Output DLP for LLM responses requires monitoring at the application layer, not the network layer, because the output is generated dynamically rather than transmitted as a known file.
The organizations that close these gaps first are not necessarily those with the largest security budgets — they are those that have mapped the data flows in their AI systems before deploying security controls, rather than after.
Questions Your Buying Team Should Be Asking
1. Can your semantic classifier identify sensitive categories — MNPI, trade secrets, attorney-client privilege, strategic plans — in unstructured natural language, not just in structured data patterns?
The core capability question for AI-native DLP. Vendors should be able to demonstrate classification accuracy on real enterprise document samples, not just on benchmark datasets. Ask for precision and recall metrics on the specific sensitive categories relevant to your industry. Pattern-matching vendors will struggle to answer this question coherently.
2. Which inference endpoints and LLM APIs does your solution monitor, and how does coverage extend to shadow AI usage on personal devices or unmanaged networks?
No technical control covers shadow AI use comprehensively. Vendors who claim otherwise are overselling. What matters is the coverage model — which endpoints are monitored, how policy is enforced on managed devices, and what the visibility gap is for unmanaged access. Honest answers to this question distinguish mature vendors from immature ones.
3. How does your solution handle training data governance — classification, lineage, access control, and audit logging for data used in fine-tuning and model training?
Most DLP vendors do not have a coherent answer to this question because their products were not designed for this use case. It is an important filter. Vendors with genuine training data governance capability — BigID, Securiti.ai, Immuta — can describe specific workflows. Vendors without it will pivot to adjacent features.
4. What does inference-time retrieval access control look like in your product for RAG systems — specifically, how do you ensure that retrieved context respects the query user's authorization level?
This is the Knostic question. In a RAG deployment where the vector database contains documents of varying sensitivity levels, the retrieval system must enforce access controls at query time, not just at ingestion time. Ask vendors to walk through the technical mechanism. Authorization-aware retrieval is still an emerging capability and most platforms do not have it.
5. How does your solution integrate with our existing SIEM and data governance platforms, and what does the audit log look like for AI data access events?
AI data security controls that do not feed into the SIEM and data governance platforms are monitoring theater — observations that cannot be acted on. The integration architecture matters as much as the detection capability. Ask specifically about SIEM connectors, event schemas, and whether AI data access events are normalized against the same taxonomy as traditional data access events.
The Stackcurve Take
The market framing of "DLP for AI" undersells the scope of the problem and misleads buyers into thinking that extending existing DLP to cover LLM endpoints is sufficient. It is not. AI systems introduce three data security problems that have no analogue in traditional DLP: model weights as a data class, semantic context as a sensitivity indicator, and inference-time generation as a data transformation. Addressing these problems requires a new security architecture, not a feature addition to an existing DLP product.
The vendors closest to a complete solution — Nightfall AI for semantic DLP, Securiti.ai for platform breadth, Knostic for output access governance, Immuta and BigID for data pipeline governance — are each strong in specific domains. No single vendor has closed the full perimeter. Buyers should map their specific AI deployment architecture against the five phases of the AI data lifecycle and prioritize controls for the phases with the highest data sensitivity and the lowest current coverage.
The organization that deploys an LLM-based assistant without semantic DLP, inference monitoring, and training data governance is not operating with acceptable risk — it is operating with undocumented risk, which is a different and more serious problem.
The 2026 Stackcurve Data Security for AI CURVE™ Report covers semantic DLP, training data governance, inference output monitoring, and AI pipeline visibility — with vendor-by-vendor capability assessments across all four domains. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.