What breaks when organisations try to govern GenAI with classic DLP alone?

Why This Matters for Security Teams

Classic DLP was designed to spot sensitive data moving through files, email, and sanctioned endpoints. GenAI changes the path of exposure: users can paste regulated content into chat interfaces, browsers, copilots, and internal assistants without ever creating a traditional file event. That means the control objective is no longer only data exfiltration prevention, but also prompt governance, response safety, and policy enforcement at the point of interaction. The NIST Cybersecurity Framework 2.0 is useful here because it frames governance, protection, and detection as connected functions rather than a single control layer.

Security teams often assume existing DLP rules will catch risky AI usage because the same data classifications still apply. In practice, the failure is structural: the control is watching the wrong channel. A prompt can leak source code, customer records, incident details, or credentials into an external model, and the model response can reintroduce sensitive material into a new workflow. That creates a governance problem, not just a data loss problem. In practice, many security teams encounter this only after employees have already normalized AI copy-paste workflows rather than through intentional control design.

How It Works in Practice

Effective GenAI protection uses DLP as one layer inside a broader inspection and policy stack. Instead of waiting for a document to leave the endpoint, controls should evaluate content before it enters an AI system, while it is being transformed by the model, and again as output is returned to the user. Current guidance suggests this should include prompt scanning, policy-based redaction, context-aware blocking, and response inspection. The NIST AI 600-1 GenAI Profile is helpful because it treats AI risk as a lifecycle issue, not a point control.

• Scan prompts for secrets, regulated data, and high-risk instructions before transmission.
• Redact or tokenize sensitive values where business use is legitimate but full disclosure is not.
• Inspect model responses for data leakage, unsafe recommendations, and policy violations.
• Log user, model, prompt, and response metadata for investigation and governance.
• Apply allowlist or brokered access to approved AI services where possible.

Operationally, this is usually implemented with secure web gateways, API proxies, endpoint controls, browser interception, and application-layer policy engines. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a strong mapping point for access control, audit logging, and information flow enforcement, but the implementation must be adapted for AI traffic rather than legacy document transfer. These controls tend to break down in unmanaged browser access and shadow AI use because the organisation never sees a file boundary to inspect.

Common Variations and Edge Cases

Tighter prompt inspection often increases user friction and privacy concerns, requiring organisations to balance leakage prevention against workflow speed and legitimate data use. That tradeoff becomes more visible in engineering, legal, finance, and support teams where the most valuable prompts also carry the most sensitive material.

There is no universal standard for this yet, especially for response filtering and model-side enforcement. Some organisations focus on denylisting secrets and regulated identifiers, while others prioritise sensitive context detection and semantic policy checks. The right answer depends on whether the AI system is internal, externally hosted, or embedded in a business application. For regulated environments, DLP should be paired with broader control mapping from NIST Cybersecurity Framework 2.0 and control baselines such as NIST 800-53, because AI exposure often spans identity, device, network, and application layers at once. The hardest cases are unmanaged devices, browser extensions, and consumer AI tools, where interception is incomplete and policy enforcement becomes mostly advisory.

Related resources from NHI Mgmt Group

• What breaks when organisations try to govern AI with existing privacy or records processes alone?
• What breaks when organisations try to govern cloud access with proxies or bastions alone?
• What breaks when organisations try to govern non-human identities without lifecycle ownership?
• What breaks when organisations try to govern AI agents without continuous discovery and inventory?