#Protecting Personal Data from Leaking into AI Models
Status: Available. Describes the platform measures that apply when the AI seller and assistants process customer correspondence. The page is the same for all cells.
Purpose: what exactly the platform does with customers' personal data before the text goes to an AI model, what it does not do, and what remains on your side.
#Contents
- In brief
- Masking before the model
- What is masked
- The last line: the output guard
- Training ban at the provider
- Logs without text
- Knowledge base isolation
- What the platform does not promise
- What remains on your side
#In brief
| Measure | Essence |
|---|---|
| Masking and reverse substitution | before the model, personal data is replaced with tokens; after the response, the tokens are put back |
The pii-guard output guard | a separate check on the transport to the model provider itself: it masks what the detector recognized and what was not masked earlier |
| Training ban | requests to OpenRouter carry provider.data_collection: deny by default |
| Logs without text | the AI usage log stores tokens, cost, and identifiers; the Jev decision log stores identifiers only |
| Knowledge base isolation | knowledge base search is limited to the tenant |
The platform does not claim one hundred percent recognition: the boundaries are described below.
#Masking before the model
Before being sent to the model, the correspondence goes through masking:
- Personal data that is found is replaced with a token such as
[USER_PHONE_1],[USER_EMAIL_1],[CONTACT_…]. The model sees the token, not the value. - The model responds using the tokens.
- Before the response is sent to the customer or operator, the tokens are replaced with the original values.
The "token → value" mapping is not written to the database and not passed to the model provider: it lives only in process memory for the duration of processing and is then deleted.
Masking is enabled on the main paths where the model works with customer text:
- the AI seller on the website, in Telegram, VK, Max, and the channel engine;
- the reply draft and operator hints;
- CRM agents and automations (lead scoring, flows, reminders, mailings, auto-tags);
- the club's AI chemist and audits of its conversations;
- the AI tutor, support, and assessments in the LMS, the mobile app, and the Telegram mini-app.
Coverage of model call sites is checked by an automated test: a new call without masking, or without a recorded reason for the exception, does not pass the automated check.
For lead scoring (Jev) and for the LMS tutor, the model receives internal identifiers or hashed labels instead of names and contacts.
#What is masked
| Data type | Note |
|---|---|
| Phone numbers | Russian and international, as well as local United Kingdom and Indonesian numbers |
| Bank cards and IBAN | IBAN is checked against its checksum |
| SNILS, INN | INN: with a checksum, or next to the word "INN" |
| Passport | by the words "passport", "series", "number" and by format |
| Telegram handles | of the form @name |
| Addresses | by Russian, English, and Indonesian keywords |
| Postcode, UK National Insurance number, NIK (Indonesia) | |
| Date of birth | when context is present |
| Names | with a patronymic, a form of address, a "Name:" label, "Surname Name" in any order; from a name dictionary; the name and contacts of an already known contact |
Medical information is intentionally not masked: in cosmetic chemistry questions it is the substance of the query.
#The last line: the output guard
pii-guard sits on the transport to OpenRouter and to direct model providers. It does not replace the masking above but backs it up: it checks the request body before sending and masks what the detector finds. It works with both regular and streaming provider responses.
For batch processing requests and embedding calculations, the replacement is irreversible: the text goes out with tokens, and substitution back is not needed.
The guard checks the text in the request body. It does not parse binary bodies or audio attachments.
#Training ban at the provider
In all requests to OpenRouter, the platform passes provider.data_collection: deny by default: a provider that stores requests for training is excluded from route selection.
The only exception: AI chemist models marked :free (the free-tier level). The ban does not apply to them, so the chemist's user receives a warning, and the data in such requests goes through masking.
#Logs without text
- The AI usage log stores the number of tokens, the cost, and request identifiers, but not the text.
- The Jev decision log stores identifiers only.
#Knowledge base isolation
Knowledge base search selects data of your tenant only: the agent and the base have an owner, and in the vector index the search runs with a tenant_id filter. A customer's question for one tenant does not find another tenant's materials.
#What the platform does not promise
- Complete recognition. Masking finds what the detector can recognize. A single name without a surname is not treated as personal data and is not masked. Names of third parties without a surname, and information the detector does not know, may pass through.
- No transfer abroad. The page describes the measures taken before the text is sent to the model, not the place it is sent to.
- Compliance with the requirements of a specific law. The measures help reduce the risk of a leak; assessing compliance remains with the personal data operator.
#What remains on your side
- Do not enter personal data into fields where it is not needed: product descriptions, agent instructions, knowledge bases.
- Before enabling the AI seller, tell customers that their messages are processed by AI. The consent bar in the widget: description.
- For exchange over the API, request only the fields you need (Minimization and Field Selection). Information by cell: Data Protection by Cell.