PII filter

How meinGPT detects and redacts personal data and company secrets before a prompt reaches a model outside the EU

The PII filter is a protective layer at exactly one point: before a prompt goes to a model outside the EU. It checks your input for personal data and confidential company data and offers you a redacted version before the request is sent.

When the filter applies — and when it does not

Note

The filter only checks for models outside the EU. If you pick an EU-hosted model, no check takes place: the model itself runs in European hosting, and the filter costs neither time nor credits there.

The decision is made from the hosting region of the selected model. Which model runs where is listed in the model overview and is also visible in the model picker in chat at any time. Best model counts as an EU model and is not checked — not even when the automatic selection falls back to an enabled model outside the EU, for example because GPT-5 is disabled in the workspace.

The meinGPT web app checks in two places: in chat when you send a new message, and in image generation when you submit a prompt. This includes chats with assistants and in projects.

What the filter does not check

The filter runs in the web app's input field, not on the server. So the following are not checked:

  • Editing and regenerating a message — not even when you switch to a model outside the EU while doing so
  • The existing chat history when you switch an ongoing chat to a model outside the EU — only the new message is checked, the history goes along unchecked
  • Requests through the API, the Outlook add-in and workflows

How the check works

Intercepted before sending

Your message is not sent right away — it is checked first.

Checked by a checking model

The prompt goes to a checking model — GPT-5 via the Azure OpenAI Service in an EU data centre. Only when an input exceeds GPT-5's context window (around 400,000 tokens) does another model with a larger context window check it, and that model does not necessarily run in the EU. The checking model is explicitly instructed as a detection step, not as an assistant: it does not answer your request, it only marks it up. Every check is billed in credits like any other model usage.

Structured result

What comes back is not free text but a fixed schema with four fields: a short explanation, the redacted text, a mapping table from placeholder to original value, and the number of redactions.

Your decision

If the check finds at least one item, the dialog Personal Information detected appears with the redacted text. Anonymize message applies the redacted version, and only that version is sent. If the check finds nothing, your message goes out without a dialog.

A redacted prompt looks like this, for example:

Input:    @Jane Doe: Please use the current API key: sk-meingpt-asjdjkasnd...
Redacted: @[NAME]: Please use the current API key: [SECRET]

The checking model picks the placeholders itself; they are not always named the same (for example [NAME], [NAME1] or [APIKEY]).

The four levels

The level applies to the entire workspace. As a workspace admin you set it under Settings → Advanced Settings in the PII filter field.

LevelWhat happens
UnrestrictedNo check, no warning. This is how a new workspace ships.
EU Models Only - LenientNo content scan. For non-EU models the notice Non-EU Model detected appears; users can confirm it and hide it via Don't show this again — this is stored in the browser, not in the user account.
Personally Identifiable Information Filter - LenientContent scan for non-EU models. Detected data is shown; users can anonymize or deliberately override via Ignore.
Personally Identifiable Information Filter - EnforcedSame as lenient, but without Ignore. If a user closes the dialog, the message stays in the input field: they can edit it by hand and send it again — it is then checked again — or pick an EU model.

Attention

The shipping default is "Unrestricted". A new workspace starts with no check and no warning. Set the level deliberately before your rollout — it does not move to a stricter value on its own.

Every change to this setting is recorded in the audit log — see Compliance Controls.

What the filter detects

The checking model is instructed to redact personal data and potentially confidential company data, for example:

  • full names — a first name on its own stays
  • identifiers such as a device's IMEI
  • API keys and other secrets

Detection is deliberately conservative: anything that could be confidential gets redacted. A plain company name with no need for secrecy stays as it is. There is no fixed list of data types — the checking model decides case by case what gets redacted.

Limits of the filter

Attention

The filter is an additional protective layer, not proof that data is free of personal information. Account for it accordingly in a data protection impact assessment.

  • Detection is done by a language model and is therefore probabilistic. It is not a rule-based guarantee that every piece of personal data will be found.
  • What gets checked is the text you type — not the contents of attached files, not passages from data pools, and not web search results.
  • If the check fails technically, the message is let through — whether the error occurs in the browser or at the checking model. The filter does not block as a side effect of an outage, but it is also not effective during one.
  • The mapping table is not automatically reinserted. The placeholder stays in the conversation, so the answer comes back with [NAME] instead of the real name.
  • Extremely long inputs are skipped. If the text exceeds every available context window (around one million tokens), the check is omitted.

The reliable boundary: model access

If you want to make sure prompts only reach models in European hosting, the filter is not the right tool — model access is. As a workspace admin you decide which language models are available at all (see Enabling or disabling models). Image models are enabled separately, and some of them run outside the EU (see Image models).

Model access only covers the models themselves. Tools that call external services — such as web search or connectors to third-party systems — send their requests to the respective provider, regardless of where the model runs.

The PII filter is then the second line, for the case that a model outside the EU is enabled later. This combination — enable only EU language and image models, set the level to Enforced — is the usual setup for organizations with elevated requirements.

Was this page helpful?