A support copilot receives a customer message containing an NHS number, a mobile number and a renewal query. The model only needs the renewal context. It does not need the identifiers. DLP redaction rules decide what leaves your application boundary, what is replaced with [REDACTED], and when the request should not continue at all.
For teams operating LLM features in production, redaction is not a cosmetic privacy control. It is a request-level decision with direct consequences for answer quality, incident exposure, provider handling and auditability. Rules that are too broad turn prompts into unusable fragments. Rules that are too narrow create an avoidable path for personal, financial or confidential data to reach a model provider.
What DLP redaction rules should do
DLP redaction rules identify defined categories of sensitive information in prompts and apply a chosen action. In a production AI environment, the useful actions are usually log, warn, redact and block.
Redaction replaces the matched value with [REDACTED] before the request is routed to a provider. This allows work to continue where the surrounding context remains sufficient. For example, a request asking for a summary of a customer complaint may still be answerable after names, phone numbers and account references are removed.
Blocking is the right response when the data itself is essential to the request, when the category carries a high consequence if disclosed, or when policy does not permit the workload to use an external model. A payroll workflow containing bank details is not improved by replacing half the prompt with placeholders. It needs a different process or an approved data boundary.
Logging and warnings serve a separate operational purpose. They reveal patterns: an application field unexpectedly contains personal data, a new feature is sending raw attachments, or one team is repeatedly triggering a policy. They should support remediation, not become a substitute for enforcement.
The aim is not to redact every string that resembles an identifier. The aim is to minimise disclosure while preserving the information needed for a capable model response.
Start with the data path, not pattern matching
The fastest way to create fragile DLP rules is to begin with a long list of regular expressions. Start instead by mapping the request path. Identify which application components construct prompts, which users or systems supply the data, which model tasks are performed and which providers may receive the request.
This distinction matters because sensitivity depends on context. An email address in a fictional test prompt is not the same as an email address copied from a live CRM record. A company registration number may be public in one workflow and commercially sensitive when combined with a deal narrative. Pattern matching can detect a shape; policy determines what that shape means in a particular route.
A practical classification usually separates direct identifiers, financial data, health information, credentials and confidential business material. Direct identifiers include names, addresses, phone numbers and email addresses. Financial data may include payment card details, account numbers and tax identifiers. Credentials deserve their own treatment because an API key or password should generally cause an immediate block, not a redacted request.
Also account for data that is sensitive only in combination. A first name alone may have little operational value. A first name alongside an employer, a disciplinary case and a location creates a materially different disclosure risk. DLP is strongest when it sits alongside clear rules for which applications, teams and routes may handle particular classes of data.
Choose the action by task consequence
Redaction works well when the model needs structure, intent or context rather than the original value. Consider an internal knowledge assistant asked to classify a complaint. The model can identify the issue type and propose a response outline without seeing the customer’s phone number. Replacing it with [REDACTED] changes little about the task.
It works less well where the value drives the answer. An assistant checking whether a supplier identifier appears in a contract cannot complete that task if the identifier is removed. In that case, blocking the external request is more honest and safer than producing a plausible but unreliable answer.
A useful decision test is simple: if a human reviewer saw the redacted prompt, could they still explain why the model had enough information to perform the approved task? If yes, redact. If no, block, redesign the workflow, or use a source that provides only the minimum necessary context.
The same category can justify different actions across routes. A phone number in a customer-support summarisation route may be redacted. The identical phone number in a route designed to draft an SMS is a signal that the task needs careful architectural review. Do not force one global action onto every use case merely because the matching pattern is identical.
Keep redaction in the request pipeline
Policy order determines whether a control can be bypassed or rendered less useful. A governed AI gateway should process the request in a defined sequence: prompt shield, then DLP, then routing, then output moderation.
Prompt shielding comes first because prompt injection and jailbreak attempts can try to alter instructions, extract context or manipulate downstream behaviour. DLP then evaluates the input that will be sent onwards and applies the selected action. Only after these controls should routing choose the capable, cost-effective provider or model. Output moderation evaluates the generated response before it returns to the application.
This arrangement also makes incident analysis clearer. If a request is blocked, teams can determine whether it was rejected for an unsafe instruction, sensitive input or unsafe output, rather than treating all failures as a generic model error.
routeur.ai applies these controls through one governed doorway between applications and model providers. The application can retain an OpenAI-compatible integration while policy enforcement happens on every request, before provider routing. That keeps sensitive-data controls independent of a single model vendor and avoids recreating enforcement logic in each application.
Design for useful prompts after redaction
A redacted prompt must remain interpretable. This is where many policies fail quietly. A model receiving five occurrences of [REDACTED] may still complete a summarisation task. A model receiving a page where every noun has been removed may infer missing facts or produce generic output that looks acceptable in testing but fails in production.
Test representative prompt types, not just isolated matches. Include short chat messages, long support threads, structured forms, copied documents and tool-generated context. Measure whether the intended task still succeeds after redaction, whether output quality changes, and whether users begin entering sensitive details in alternative fields.
Where a workflow repeatedly loses essential context, reduce the data before prompt construction. An application can provide a case category, product tier, issue history and approved policy excerpt rather than serialising a complete customer record. This is often better than attempting to repair an overfilled prompt at the gateway.
Treat placeholders consistently. [REDACTED] should tell engineers, reviewers and the model that content was intentionally removed. It should not be mistaken for a real value, an empty field or a model instruction. The surrounding prompt can make this clear: “Customer contact details have been removed. Do not request or infer them.”
Operate rules as production controls
DLP policies need ownership, test cases and change discipline. Security may define minimum categories and mandatory block conditions, while product and platform teams validate whether redaction preserves each approved use case. Neither group can do this effectively in isolation.
Use metadata-only logging by default where possible. It provides operational evidence without automatically creating another store of sensitive prompt content. When payload retention is explicitly enabled for a justified investigation or evaluation, apply tight access controls and a defined retention decision. The fact that a request was redacted is often more valuable for governance than retaining the original personal data that triggered the rule.
Per-request traces should help teams answer practical questions: which route processed the request, which policy action applied, which provider served it, how long it took and what it cost. This evidence supports incident response and audit preparation without turning tracing into a new disclosure channel.
Review rules when a new provider, feature, prompt template or data source is introduced. A policy that worked for short text classification may behave differently when users upload long documents or when an agent assembles context from several internal systems. Dry-run evaluation is especially useful before enforcement changes: it exposes likely matches and potential disruption without changing the live request outcome.
A minimal deployment pattern
The application integration should remain deliberately ordinary. With an OpenAI-compatible gateway, the connection change can be limited to the API key and base URL while business logic stays byte-for-byte identical.
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 support case."} ], )The governance work is then concentrated where it belongs: defining the approved routes, setting DLP actions, reviewing traces and improving prompt construction. Teams do not need separate provider-specific masking code scattered through every service.
A good redaction policy gives engineers a clear answer at the moment a sensitive value appears: remove it when the task can proceed safely, stop the request when it cannot, and retain enough evidence to improve the system without retaining the secret itself. That is how DLP becomes a production control rather than a rulebook no one can operate.