--- title: "PII filter" description: "How meinGPT detects and redacts personal data and company secrets before a prompt reaches a model outside the EU" canonical_url: "https://meingpt.com/en/docs/privacy-security/pii-filter" language: en --- # PII filter 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 **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](/en/docs/platform/models) 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](/en/docs/api)**, the **Outlook add-in** and **workflows** ## How the check works Your message is not sent right away — it is checked first. 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. 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. 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: ```text 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. | Level | What happens | | --- | --- | | **Unrestricted** | No check, no warning. This is how a new workspace ships. | | **EU Models Only - Lenient** | No 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 - Lenient** | Content scan for non-EU models. Detected data is shown; users can anonymize or deliberately override via **Ignore**. | | **Personally Identifiable Information Filter - Enforced** | Same 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. | **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](/en/docs/admin-guide/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 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](/en/docs/platform/models#enabling-or-disabling-models)). Image models are enabled separately, and some of them run outside the EU (see [Image models](/en/docs/admin-guide/image-models#enabling-and-disabling-models)). Model access only covers the models themselves. Tools that call external services — such as [web search](/en/docs/platform/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. ## Related pages ### [Data flow in meinGPT chats](/en/docs/privacy-security/faq-chats-datenfluss) The full path of a message, from input to storage. ### [Model overview](/en/docs/platform/models) Hosting region, provider and context window per model. ### [Compliance Controls](/en/docs/admin-guide/compliance-controls) Privacy mode, audit log and usage policies. ### [Provider selection](/en/docs/privacy-security/provider-selection) Which provider fits which use case.