# Pseudonymisation An object name is data too. A table called `Salaries_Board`, or a column `TerminationDate`, already tells a model a lot about an organisation before a single row has been read. That is why, in Plainwater AI, names go to the model as pseudonyms. ## How it works Per task the platform keeps a register of real names and their pseudonyms: | Real name | Pseudonym | | --- | --- | | `Salaries` | `t_0056` | | `Employee_ID` | `c_0112` | | `Department` | `c_0113` | The model only sees the pseudonyms. It can work with them as usual: write a query, suggest a join, recommend an index. The structure stays intact. Only the meaning carried by the name stays on the platform. The pseudonym is stable within the task. `t_0056` is the same table throughout the conversation, so the model can reason without getting confused. ## Translated back for the human What the model answers, the platform translates back before you see it. If the model writes "Add an index on `c_0112` in `t_0056`", you read "Add an index on `Employee_ID` in `Salaries`". That also works for names the model invents itself. If the model proposes a view called `vw_t_0056_monitor`, you read `vw_Salaries_monitor`. And it works the other way round. If you type a real name in the conversation, it is replaced before the message goes to the model. What you see on screen, you can simply type back without it leaking. :::accent One copy, not two The platform stores conversations with the pseudonyms in them. There is no second copy with the real names. Translation back only happens at the moment someone with the right permissions reads along. ::: ## When is it mandatory? A customer with a source that contains real customer data only runs with active pseudonymisation. That is not a setting you can forget: without pseudonymisation a task does not start. And because a source can also be added while a task is running, it is checked again on every tool call. ## And the values? Names are one thing, values another. For values there are the modes of [data access](/concepten/datatoegang): - In **metrics only**, no values reach the model. Only counts and statistics. - In **encrypted values**, every cell is a stable token. The same customer name always gives the same token, so the model can count, group and join without knowing the name. - In **open**, literal values go along, only on sources the customer designates for it. With encrypted values too, the platform translates back for the human looking at the result. ## Free text Some text from a database is trickier: the source code of a procedure, a query text, a description. Values can hide in it. For a source with real customer data, such free text does not go to the model in readable form, only in replaced form. ## What it is not Pseudonymisation is not anonymisation in the legal sense. The register makes translation back possible, and whoever holds the register can do that too. The difference is where the register lives: on the platform, in your environment, and not at the model vendor. The model sees the structure and never the key. And what the register does not know, it cannot replace. A name that only occurs in free text and does not exist as an object anywhere is not recognised by the register. That is why the platform combines pseudonymisation with the data access modes and with exceptions per column: you do not have to rely on a single mechanism. ## Example An analyst asks: "How many employees per department got a salary increase this year?" 1. The model gets the structure: `t_0056` with columns `c_0112`, `c_0113`, `c_0118`. 2. It writes a query using those pseudonyms. 3. The result comes back with counts per department. Departments with fewer than ten employees show "<10", so no individual can be identified. 4. The analyst sees the table with the real department names. ## See also - [The AI gateway](/concepten/ai-poort) - [Data access per source](/concepten/datatoegang) - [Glossary](/begrippen)