Almost every product eventually touches personally identifiable information: a name in a support ticket, an IBAN in a complaint, a date of birth on an intake form. Much of it is regulated, and sending it to a model provider means handing it to a third party.
Today, whoever wrote the feature decides whether to redact, and the decision is made once. One team strips names before building the prompt. Another forwards the support ticket verbatim, because the raw text is what makes the answer useful. A third means to come back to it after launch. None of those are unreasonable on their own. They are just made separately, by people with different information, at different times.
Then the applications change. A prompt grows a customer-context field. A retrieval step starts pulling whole documents instead of snippets. The decision made at launch stops being the decision running in production, and nothing triggers a re-review. Ask what personal data your organization sent to a model provider last quarter and usually nobody can answer. Not because anyone was careless, but because the answer is spread across a dozen codebases and was never written down.
A gateway is the one place all of that traffic already passes through. Redact there and the guarantee stops depending on per-team discipline. It covers applications written before anyone thought about PII, and the ones shipped next quarter by someone who never saw the checklist.
So that is where we put it. PII redaction is available in the Orq.ai AI Gateway today, in open beta, as the PII Redaction plugin. It finds the personal data in a request, swaps each value for its own placeholder before the request leaves for the provider, and puts the real values back into the response on the way home. The provider works on placeholders. Your user sees the real answer.
Detection quality
Recall measures how much personal data the system catches. Anything it misses remains a risk.
We trained our own model because existing options worked reasonably well in English but were noticeably weaker in Dutch, which appears in much of our customers' sensitive text.
Across two Dutch evaluation datasets, mostly made up of names and structured identifiers, aggregate recall was about 0.90. The datasets included both general text and noisy financial text.
Names and locations are the hard cases, which is why we report them separately.
Both numbers are pooled across the two sets rather than averaged, so the larger set carries its real weight. They also span very different text. General Dutch prose scores well above these figures; dense financial text, where names compete with account numbers and organization names, scores below them. If your traffic looks like the latter, treat these as the optimistic end.
The detector is also tuned to over-flag rather than miss, so it will sometimes mask something that was not personal data. The confidence threshold is the lever if you want the opposite trade.
What it costs in latency
Redaction adds a scan on the way out and a restore on the way back. The restore is free. It runs no model and stays flat at about 30 ms whatever the size. The scan is the cost, and it grows with the length of the request.
A chat turn of a thousand characters adds about a tenth of a second, most of which is network rather than detection. Beyond that the cost tracks the length of the text. A 200-page document, 400,000 characters, adds about eleven seconds.
These are end-to-end numbers measured through the gateway on the same GPU we run in production, so they include network and gateway overhead rather than detection time alone. They are also measured one request at a time. Large documents are processed serially, so concurrent long requests queue behind each other rather than running in parallel — size the deployment for that if long documents are your normal traffic.
Two ways to turn it on
Add a pii_redaction entry to the plugins array on a request and that call is redacted. This is the per-application path, and it is the one to start with. A single team can protect a single workload without waiting on anyone.
Or switch the plugin on in workspace settings. It then applies to every call that does not already carry its own pii_redaction entry, including applications written before you enabled it.
The two combine in one direction only. A request can make redaction stricter than the workspace setting, by lowering the confidence threshold or blocking where the workspace would pass through. It cannot weaken or disable it. That is what turns the workspace setting from a default into a control. A team can opt into more protection, never out of it.
In either place you choose which categories to mask, the minimum detection confidence, and what happens when detection cannot run. Blocking prevents an unscanned request from reaching the provider, and is the default. Passing it through keeps the application available, while accepting the additional exposure. A customer support assistant and an internal code tool may need different answers.
Redaction is reversible. The gateway turns:
Email Sanne de Vries at s.devries@meridiaanzorg.nl
into:
<PERSON_1>at<EMAIL_ADDRESS_1>
The provider sees placeholders. When the response returns, the gateway restores the real values before the user sees the answer.
It runs where you do
The PII detection model runs inside the service you deploy. It does not send text to a third-party classifier.
The detection service has no database and does not store the mapping used to reverse a redaction.
You can still follow a redacted request end to end. Redaction appears as its own pii.redact span next to the model call, with the settings that were applied and a breakdown of what it masked.
This request carried 31 values worth masking, 25 of them person names, each swapped for the numbered placeholder the provider sees.
The same plugin works on Orq.ai's managed service, in your own cluster or in a fully air-gapped environment. The data path stays consistent across those deployment options.
Coverage beyond names and numbers
The system covers more than forty categories. These include names, contact details, financial identifiers, credentials, government numbers and device identifiers.
It can also detect race and ethnic origin, biometric identifiers, medical record and health plan numbers, and blood type. Depending on the context, this data may require additional safeguards under the GDPR.
Removing a name is not always enough to hide someone's identity. The detector also recognizes attributes that can identify a person when combined, such as age, job title and location.
These details appear in healthcare transcripts, HR files and customer complaints about medical leave.
The national identifier catalogs cover the Netherlands, Belgium, the United Kingdom, Germany, France and the United States.
The detector treats jurisdiction separately from the language of the text. Someone in Amsterdam may write in English and still include a Dutch BSN, which a language-only rule could miss.
Where it fits, and where it does not
Enable the plugin when a team routes sensitive text through the gateway and you would rather have one baseline than a per-application review. It fits customer support assistants, internal copilots over HR or healthcare text, and any workload where a model provider should not see the raw values. Widening it to the whole workspace is the natural second step, once you have watched it on real traffic.
Where it does not fit:
The model needs the real values. An assistant that verifies a customer's identity cannot work on placeholders. Redaction removes exactly what the task depends on.
Your text is not primarily Dutch or English. The base model is multilingual and still runs, so you will get detections. We fine-tuned on Dutch and English only, so the quality numbers above do not carry over, and we cannot tell you what to expect.
Your traffic is dominated by very large documents. Budget for the latency above, and note that we have only measured up to 400,000 characters, roughly 200 pages. The scaling will roughly be linear, but starts to really increase latency to noticeable levels after this point.
RAG with personal information. Most retrieval survives this with only a few points of recall lost, but queries that search for a specific person degrade badly, because the name you are searching for is the thing that was removed. How much it matters depends on what your users ask for; we measured it in a separate post.
Self-hosted models: when your models run on your own infra, enabling PII redaction serves less of a purpose, as the data would not leave your systems regardless. For example, Azure OpenAI Private Cloud deployments or self-hosted vLLM or Ollama instances don't necessarily need a redaction layer.
For Agents, you apply the plugin on the response call that invokes the agent. There is currently no per-agent setting.
Detection is a filter, not a guarantee. Recall around 0.90 means roughly one in ten entities is missed on the datasets we measured. It substantially reduces exposure, but does not remove the need for a data processing agreement with your provider.
Getting started
Nothing changes until you turn it on. Existing gateway traffic is unaffected; nothing is redacted unless a request asks for it or the workspace setting is on, request and response shapes are unchanged for anyone who leaves it off, and switching it back off takes effect immediately.
Start by looking rather than changing. detect reports what personal data a sample of your traffic actually contains, and returns the text untouched:
That is a better guide to which categories you need than reading the catalog. Then redact one request. Add a pii_redaction entry to the plugins array and nothing else has to change:
The same thing from the CLI, this time narrowed to names and email addresses and set to fail closed:
The API field is entities; the settings UI calls the same things types. Omit the field to redact every category supported for the language.
Once you know it behaves the way you want, widen it. In my.orq.ai, go to Settings, Plugins, PII Redaction and enable it. The sliders icon next to the toggle opens the configuration panel, where you set the categories, the confidence threshold and the failure behavior that apply to every request that does not bring its own.
The panel is where the configuration actually lives, and it has two modes:
All, on the left, detects every category the selected regions cover. There is nothing else to decide, which is why the panel stops.
Custom, on the right, is the one worth understanding. You pick the categories, and the threshold stops being a single number: the global slider applies to every category that has no setting of its own, and any category can be pinned higher or lower. BIC/SWIFT sits at 95% there, because a bank identifier code either matches its format or it does not, while the rest stay at the default 50%.
Start on All. Move to Custom when a specific category is too noisy or too quiet for your traffic.
Try it
PII redaction is free during the beta. Add the plugin to one request, run detect over a representative sample, then set the categories, threshold and failure behavior for the workspace from what you find.
Extending support for multi-turn conversations is next on the list, along with more measured languages. If a category or jurisdiction matters to you and is not here yet, tell us and it moves up the list.
Questions, gaps and bad detections are all welcome at support@orq.ai. Full reference is in the PII Redaction documentation.
