Control what goes to AI: the Plainwater AI gateway
Bram, the controller at a wholesaler of technical parts, wants to know why margin per product group is falling. Noor, the data engineer, wants an AI model to help. The board asks one short question: what does that model see of our data?
Plainwater AI answers with a gateway. Every request to a model passes through it, and every request gets exactly one policy decision. Whatever the rules do not allow never reaches the model provider.
This page explains how the gateway works: pseudonyms for names, modes per data source, exceptions per column and an audit afterwards.
Updated .
What is the AI gateway?
The AI gateway is the single point every request to an AI model passes through, with one policy decision per request. That decision checks the chosen model, the budget and the customer's rules before anything leaves.
So rules live in the gateway, not in a prompt. A model can ignore an instruction like 'do not share personal data'. It cannot get around a gateway that stops the request.
For Noor this means she picks a model the wholesaler has allowed, and the gateway checks again on every request that this still holds. A refused request never arrives at the provider.
How do pseudonyms for table and column names work?
Pseudonymisation replaces table and column names with neutral codes before they go to the model, and translates the answer back for the human. The model sees `t_0056`; Bram reads `Salaries`.
An object name is data too. A table called `Redundancies_2026` tells a model a lot without a single row. That is why names leave as pseudonyms by default.
Translating back also works for names the agent invents. If it builds a view `vw_t_0056_monitor`, Noor sees the real name with `monitor` appended on her screen.
A customer with real customer data only runs with pseudonymisation active. If it is off, the agent does not start, and the gateway checks it again on every step while work is running.
Which data access modes are there?
For each data source you pick one of three modes: metrics only, encrypted values or open. The mode decides whether and how values from the source reach the model.
The stricter of customer rule and source rule always wins. A source can never be more open than the customer. If the wholesaler sets everything to encrypted, a source set to open stays encrypted.
| Mode | What the model gets | When to choose it |
|---|---|---|
| Metrics only | Metadata, counts and statistics; no rows | Default; enough for modelling, quality and performance work |
| Encrypted values | Every cell as a stable token; joins and counts still work | Analysis where the AI must see patterns but not values |
| Open | Literal values | Only on sources the customer explicitly designates |
Can you be stricter per table or column?
Yes. Per table or column you set exceptions that always apply, whatever the mode of the source. Name columns, for example, are hidden by default.
A cohort threshold applies on top: counts below ten become `<10`. Nobody can work out who was off sick from a count of three people in one department.
Bram does not have to remember these rules. They live on the source, and the gateway applies them to every request from every colleague and every agent.
What can you review afterwards?
All prompts and answers are stored encrypted and can be read back by whoever has the right to. Every read is logged as an event itself.
Per customer you set guidelines. The platform checks work afterwards against the rules that applied when it started. Anything that cannot be checked automatically gets the verdict needs a human, never a pass.
A finding names the rule, the verdict and where it happened. The text that triggered the rule is not in it: an audit must not become a leak itself.
Where it stops
The gateway guards what the platform sends. Whatever an employee pastes into another chat service is outside it; you still need a policy in your organisation for that.
Pseudonyms protect names and values the platform knows. Free text a person types in a conversation goes along as text; the gateway does sweep known names out of it.
When a consultant works with their own AI tool over MCP, the model runs outside the platform. The protection then sits on the tools: what the model receives still passes the same rules.
Frequently asked questions
Does Plainwater AI send rows from my database to an AI model?
Not in the default mode. Under metrics only the model gets metadata, counts and statistics. Rows only go along under encrypted (as tokens) or open (literally), and open only on sources you designate yourself.
What happens when a request breaks the rules?
The gateway refuses it before it reaches the model provider. The decision is recorded, so you can see later what was refused and why.
Can a model get around the rules with a clever prompt?
No. The rules are enforcement in the gateway, not an instruction in the prompt. Nothing the model asks or writes changes what the gateway lets through.
Does the model see the real names of my tables?
Not for a customer with real customer data: table and column names go along as pseudonyms. The platform translates the answer back, so you read the real names.
Who can read the stored prompts and answers?
Only people with the right to do so. Storage is encrypted, and every read is recorded as an event in the audit.