Privacy Guard: Mask personal data.
This page describes what happens technically when you send a message in Coveniq. It is written for data protection officers, IT leads and anyone who would rather check the protection than believe it. It also states what the guard cannot do.
What the Guard makes of it
The demonstration
Your text, through the real Guard.
The placeholder carries the category. The model knows that a person stands in this place, not an amount.
The examples are in German. The Guard is calibrated for German, and its detection is strongest there: on English text it currently finds street addresses and organisation names less reliably. We would rather show the demonstration at its real strength than translate the examples and let the result mislead you. Your own text is checked in any language, English included.
Use fictional sample data only. Your text is sent to the Privacy Guard for analysis, not to a language model. Up to 2,000 characters and twenty checks per hour.
What the model reads
The Guard numbers the findings in order of appearance. If the same name occurs twice, it gets two numbers.
The pipeline
Seven stations when Privacy Guard is enabled
The Privacy Guard is a standalone service in its own repository. The application calls it over HTTP and authenticates with a token that exists on the server only and never reaches the browser. It knows neither the detection models nor the mapping between real value and placeholder.
1
Input
Prompt with real names, addresses and file numbers. Nothing has to be redacted first.
2
Length check
Length is checked before any service sees the message. Limit: 60,000 characters.
3
Pseudonymization
Detected personal data is replaced with structured placeholders. Detection can miss information.
Border of your organization
4
Knowledge space search
Semantic search runs on the mitigated text. The embedding provider sees no raw data either.
5
Model call
Only the pseudonymized prompt goes to OpenAI or Anthropic.
Border of your organization
6
De-anonymization
The placeholders are reversed. The guard then checks for leaked values.
7
Storage and output
Three separate layers are stored. After successful de-anonymization, the user sees the answer with the original values.
Input
Your text, exactly as you wrote it.
This example shows the difference between the original text and the version sent to the model.
The reference linking placeholder and original value lives for exactly one chat turn. It is not stored in the application database. After the turn there is no key there that connects the two.
What is detected
Fifteen categories. Plus whatever you add.
Extensible through fine-tuning, specific to your tenant.
Identity
- Person
- Email address
- Phone number
- IP address
- URLdetected, not replaced
Place and affiliation
- Street
- House number
- Postal code
- Place
- Organisation
Context
- Date and timedetected, not replaced
- Nationality / religion / politics
Never releasable
- IBAN
- Credit card number
- Internal ID
The three categories with a lock are excluded from any release, and the block is enforced on the server. Even a manipulated client cannot get around it.
The Guard detects two categories but does not replace them: a date on its own allows no conclusion about a person, and whatever a web address contains is caught by the recogniser responsible for it. They therefore never light up.
The limits
What the guard detects is configurable.
Detecting personal data works with trained models and rules. Language depends on context, and every organization has its own abbreviations and formats. So detection deviates in two directions: it protects too much or too little. We name both, because being open about the limits is the most credible argument we have.
A vendor who promises you perfection here has either not measured or is not telling the truth.
First run
Please check the route via Google Maps and get back to us by Friday.
Second run
Please check the route via Google Maps and get back to us by Friday.
First run
The case is filed under staff number EMP-1234, please note it in the record.
Second run
The case is filed under staff number [DE_INTERNAL_ID_1], please note it in the record.
What the guard gets wrong, you correct permanently.
Your users report both in one click. Your administrators correct both permanently.
Two kinds of correction, one guided dialogue. What users submit through the reporting function collects in a queue. When the administrator confirms a report, a permanent correction is created automatically, and it is recorded who confirmed it.
Right there in the dialogue the administrator enters a sample text and sees immediately which parts the pattern catches, before saving. No trial and error in live operation.
Control and evidence
You set how much your people see and may decide.
Nobody sets the innermost ring. These three views answer the questions IT leads and data protection officers actually ask during evaluation.
Which failures block the model call?
Normal case
- Input
- Privacy Guard
- Model
- Answer
Guard does not respond
- Input
- Privacy Guard
- Model
- Answer
Both runs show an enabled Guard. If the pre-send check fails, the request is blocked. Later checks have their own failure behavior.
The main failure cases at a glance:
| Situation | Behaviour of the application |
|---|---|
| Guard unreachable or error during pseudonymization | The model call does not happen. The user gets an error message, not an answer. |
| Error during de-anonymization | The error is logged; the answer is delivered with placeholders instead of original values. |
| Error during the leak check | Logged, the chat continues. The check is a warning, not a gate. |
| Leak detected | Logged. The answer is delivered, since the user entered the values in question themselves. |
| Message over 60,000 characters | Rejected before any service sees it. This applies even when the guard is switched off for the tenant. |
Situation
Guard unreachable or error during pseudonymization
Behaviour of the application
The model call does not happen. The user gets an error message, not an answer.
Situation
Error during de-anonymization
Behaviour of the application
The error is logged; the answer is delivered with placeholders instead of original values.
Situation
Error during the leak check
Behaviour of the application
Logged, the chat continues. The check is a warning, not a gate.
Situation
Leak detected
Behaviour of the application
Logged. The answer is delivered, since the user entered the values in question themselves.
Situation
Message over 60,000 characters
Behaviour of the application
Rejected before any service sees it. This applies even when the guard is switched off for the tenant.
Every guard call is designed to take under two seconds at normal load. The application aborts after five seconds.
Three levels of control
Outer: tenant default
Tenant admin
Privacy Guard on, transparency on, pre-send review off. Applies to all users of the tenant.
Middle: per-user override
Tenant admin under Members
Enable the pre-send review for the legal department without imposing it on the whole workforce.
Inner: server-side boundary
built in, cannot be switched off
IBAN, credit card and internal identifier can never be released. Enforced on the server, not in the browser.
An individual user cannot switch protection off. That is an organizational decision, not a personal one.
Three content layers per message
Raw content
What the user typed. Reference, audit, display in the chat.
Mitigated content
What the AI model read. The evidence of what actually left the platform.
Final content
What the user received. Output and archive.
Stored separately and bound to the tenant in the platform for evidence and error analysis. Row level security separates access between organizations.
FAQ
The questions people actually ask
No. The Privacy Guard is controlled at organization level only. There is no switch for it in a user interface.
When the Privacy Guard is enabled and pseudonymization fails, the model call does not happen. Later checks have separate failure behavior, described below.
For every message, what the user wrote and what the model read are stored separately. In addition, the statistics show how many items were protected in a given period, and the release audit records every deliberate exception.
Calibration
Test it against your own data.
The guard does not yet know your organization’s abbreviations. During onboarding you teach them to it, and the corrections belong to you alone.