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.
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:
- 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?"
- The model gets the structure:
t_0056with columnsc_0112,c_0113,c_0118. - It writes a query using those pseudonyms.
- The result comes back with counts per department. Departments with fewer than ten employees show "<10", so no individual can be identified.
- The analyst sees the table with the real department names.