A support copilot receives a customer message containing an NHS number. A finance workflow sends a bank detail to a model while summarising an invoice. A developer pastes a production credential into an internal assistant. These are not unusual edge cases. They are routine consequences of putting language models close to business processes.
To deploy AI DLP actions effectively, teams need controls that operate on every request before it reaches a model provider, rather than guidance documents that rely on users getting every prompt right. The practical question is not whether sensitive data may appear in prompts. It will. The question is what the platform should do when it does.
DLP needs an action, not just a detection result
Detection alone creates a queue of security findings. That may be useful for investigation, but it does not prevent an exposed value from leaving the organisation. Production AI systems need a defined response that matches the data type, workflow and acceptable operational risk.
The four useful AI DLP actions are log, warn, redact and block. Each creates a different balance between continuity, evidence and protection.
Log records that a detection occurred while allowing the request to continue. It is a sensible starting point when a team is mapping exposure, validating detector quality or assessing a new workflow. Logging is not a long-term answer for high-risk identifiers or secrets, because the sensitive content can still be sent onwards. It is an observation mode.
Warn allows the request to continue but makes the policy event visible to the relevant team or user flow. This can be appropriate where context matters and an immediate block would disrupt a legitimate process. For example, a restricted internal workflow may handle personal data under a controlled procedure, while the team still needs evidence that the policy was triggered. Warnings require ownership: if nobody reviews them, they become logging with extra noise.
Redact replaces the detected value with [REDACTED] before the request is routed to a provider. This is often the most practical control for workflows that still benefit from the surrounding context. A support agent can ask for a summary of a customer issue without transmitting the customer's email address, account number or other detected value. Redaction does change the context received by the model, so quality testing matters. There is no value restoration step: the model receives [REDACTED], not a reversible placeholder.
Block stops the request before it is sent to the model. Use it where sending the data is unacceptable, such as credentials, payment details, restricted personal data or content that violates a hard internal policy. Blocking introduces user friction, but that is the correct trade-off when the alternative is an unauthorised disclosure. A clear application-side message and an approved alternative workflow reduce unnecessary support tickets.
The key is to avoid treating these actions as a single global setting. A payroll assistant, a public-facing chatbot and a developer productivity tool do not have the same data boundary or failure tolerance.
Put enforcement at the governed doorway
DLP is difficult to maintain when every application implements its own model wrapper, regular expressions and exception handling. Rules diverge, model providers are added without the same safeguards, and evidence is scattered across application logs.
A governed API gateway changes the enforcement point. Every model request passes through one doorway between applications and providers. The request pipeline is consistent: prompt shield first, then DLP, then routing, then output moderation.
That order matters. Prompt-injection and jailbreak shielding examines the request before sensitive-data controls. DLP then applies its action before routing decides which capable, cost-effective provider should handle the request. Output moderation assesses the model response after generation. These are separate controls with separate purposes; output moderation cannot recover data already sent in an input prompt.
This central placement also avoids a common governance gap: treating a model change as purely an engineering optimisation. If an application can switch providers or models, its DLP enforcement must remain unchanged. Request-level policy controls should travel with the request, not depend on a particular provider integration.
Start with an exposure map, then choose actions by consequence
Before enforcing blocks, identify where prompts and outputs originate. Focus on the systems already connected to LLMs: customer conversations, document processing, internal search, sales operations, code assistants and automated decisions. For each flow, establish what may enter the prompt, who initiates it, which model capability is required and what happens if a request cannot proceed.
A useful policy design separates three questions. First, what categories of data must be detected? Second, which workflows have a legitimate reason to handle them? Third, should the result be observed, redacted or stopped?
Consider an internal knowledge assistant. Employee names in retrieved text may be expected, and redacting every name could make answers unusable. A policy team might begin with logging and trace review, then apply redaction to higher-risk identifiers. In contrast, a developer assistant receiving a likely secret should normally block the request. The objective is not maximum blocking. It is an enforceable boundary that preserves useful work.
Policy scope also needs to reflect routes and teams. A named route for a low-risk summarisation workload can have different expectations from a route used by a regulated business process. Scoped API keys and named routes help teams apply accountability without embedding policy logic throughout their applications.
Deploy AI DLP actions with a minimal integration change
The fastest deployment pattern is to leave application behaviour intact and move the model endpoint to the control plane. With an OpenAI-compatible client, business logic and request shape stay byte-for-byte identical. The operational change is the API key and base URL.
import os from openai import OpenAI
client = OpenAI( api_key=os.environ["ROUTEUR_KEY"], base_url="https://api.routeur.ai/v1" )
response = client.chat.completions.create( model="auto", messages=[ {"role": "user", "content": "Summarise this customer case for the support team."} ] )The application can continue to request auto, allowing routing rules and priorities to select an appropriate model. Where a team needs a defined operational path, it can use a plain logical route name instead. Neither approach requires a new SDK or application rewrite.
This is more than a convenience. A central deployment model prevents one product squad from adding DLP while another bypasses it through a direct provider key. It also makes provider failover and model changes compatible with the same security posture.
Test policy effects before making them disruptive
DLP decisions should be tested against representative prompts, not only synthetic examples. Real inputs reveal whether detection patterns catch the formats employees and customers actually use, and whether redaction removes information that a model needs to complete a legitimate task.
Use controlled test traffic across the workflows that matter. Include clean prompts, clearly sensitive prompts, ambiguous content and prompts with several detected values. Review the resulting per-request traces alongside application outcomes. Metadata-only logging by default reduces unnecessary payload retention, while explicit opt-in payload retention can support a tightly controlled investigation or evaluation process where appropriate.
A staged rollout usually produces better results than turning every detection into a block on day one. Run a proposed rule in log mode, measure frequency and false positives, then move to warn, redact or block according to the observed consequence. High-confidence secret detection may justify a direct block; less certain personal-data detection may need a period of validation.
The Routeur-Dry-Run header is useful when teams want to assess a policy path without making it the live enforcement outcome. Routeur-Trace can support request-level investigation during testing. These controls should be used deliberately and with clear trace access practices, especially in regulated environments.
Operate DLP as part of production governance
A policy is only credible if teams can show that it is active, review how it performs and change it safely. Per-request traces provide an operational record of the path a request took, including policy decisions and routing context. That evidence is valuable for incident response, internal assurance and EU AI Act record-keeping activities.
DLP also belongs alongside cost and reliability controls. A hard spend cap can alert or block requests with a 429 when a limit is reached, but it should not be mistaken for a data-protection control or an automatic rerouting mechanism. Similarly, routing to a lower-cost model may reduce spend, but it does not alter the need to inspect requests before provider selection.
Set review ownership across engineering, security and the business function that owns the workflow. Security teams should define non-negotiable data boundaries. Platform teams should monitor enforcement and route behaviour. Product teams should evaluate whether redaction or blocking creates unacceptable user impact. This shared model keeps DLP from becoming either a security-only rulebook or an engineering-only configuration exercise.
The useful endpoint is not a dashboard showing thousands of detections. It is a production environment where each application can use the model capability it needs, while sensitive data is handled according to a deliberate action at one governed doorway. routeur.ai is designed to make that control deployable without asking every team to rebuild its AI integration first.