How it works
Tokenize, process, detokenize, clean up.
Four steps between the employee and the AI model. Processing happens entirely server-side; the browser never receives a key or a token mapping.
The flow
What happens per message
employee
│ "Call Jan de Vries on 06-12345678 about the boiler fault"
▼
┌──────────────┐ POST /filter ┌──────────────────┐
│ AVGFILTER │ ──────────────────────▶ │ filter service │
│ (server) │ ◀────────────────────── │ (EU, Azure) │
└──────────────┘ tokens + session_id └──────────────────┘
│ "Call [NAAM_a41] on [TEL_7c2] about the boiler fault"
▼
┌──────────────┐
│ AI model │ sees tokens only
└──────────────┘
│ "Schedule an engineer for [NAAM_a41]; call [TEL_7c2] first."
▼
┌──────────────┐ POST /detokenize
│ AVGFILTER │ ──────────────────────▶ filter service
└──────────────┘
│ "Schedule an engineer for Jan de Vries; call 06-12345678 first."
▼
employeePer step
The details
1. Tokenize (fail-closed)
Every user input goes server-side to the /filter endpoint. The service returns the tokenized text, the number of detected personal data items and a session_id. If the call fails or takes longer than five seconds, the request is aborted with a 502 and no AI call follows. There is no fallback to the original text.
2. Tokens only to the model
The system prompt requires placeholders such as [NAAM_xxx], [BSN_xxx], [TEL_xxx], [EMAIL_xxx] and [IBAN_xxx] to be reproduced verbatim. The conversation history that is sent along also consists exclusively of tokenized text.
3. Detokenize (fail-open)
The complete answer is buffered and then mapped back in a single operation using the same session_id. If the session has expired or is unknown, the answer is shown with the tokens intact. Sessions remain valid for thirty days so a conversation can be reloaded.
4. Storage
Where conversations are retained, we store the tokenized version and the session_id alongside the readable text. For AI context, the tokenized version is always used. Nothing is stored in the demo on this site.
5. Cleanup on deletion
When a conversation is deleted, all unique session_ids are collected and submitted per session to /cleanup. Only then are the records removed, so no token mapping is left behind.