Personal data in a prompt

The assistant goes live next month, and legal wants the list of personal data that leaves the company and where it goes. The list does not exist, and the reason is not carelessness.

Where the data actually is

An engineer can show legal the code. The code contains a template, a system prompt, and a call. It does not contain the data, because a prompt is assembled at the moment of the request out of whatever the conversation has accumulated, whatever a record lookup returned, whatever a tool answered with, and whatever the user pasted in.

So “what personal data leaves” is not a property of the application. It is a property of each request, and it differs in every one of them. A review can establish what the code intends to send. What was actually sent is visible only to something watching the traffic.

That is awkward for a programme built on documents, and it is the job the enforcement plane exists to do. Data protection law has never described an artifact you can inspect. It attaches to a disclosure at the moment the disclosure is made, and a prompt to a hosted model is a disclosure to a processor, usually across a border.

What the path can do

It can see the data, in the body as assembled, including inside the arguments of a tool call, which is where personal data most often travels without anybody meaning it to.

It can change the request before it leaves, which is the one intervention that changes what was transferred. A control that runs earlier constrains what the code was likely to send. A control that runs later describes what already went.

It can say what it did. The same pass that finds a span and replaces it writes down which rule fired, on which span, under which revision of the configuration. Evidence assembled by a different system afterwards is a claim about the enforcement. This is a record of it.

Redaction that survives contact with the business

PII controls get switched off after a month because one-way redaction breaks the work. A support ticket that reads “the payment from card [REDACTED] was declined twice” gives the model nothing to reason about, and a tool that looks the value up finds no customer.

So the replacement matters as much as the detection. A stand-in can be a placeholder, or a pseudonym that is stable for the same input, and both of those are one-way by design. It can also be format-preserving: a card number replaced by a different card number that still passes its checksum, so the model handles it as a card and a recognizer downstream still finds it. Those are different promises, so they are keyed separately. The pseudonym key can be rotated whenever you like, because nothing has to reverse it, and the format-preserving key is an AES key with the obligations that implies.

Then there is the way back. An MCP server can name the entity types whose format-preserved values are turned back into the originals in that server’s tool arguments, after the guardrails have run. The default is to restore nothing, which is the right answer for every server nobody has deliberately decided about. Naming a type there declares that this server is inside the boundary: a system of record that may see the real values and needs them, because a lookup against a stand-in finds the wrong customer or none.

That declaration is about the counterparty, not the rule, so it lives beside the server’s URL. And it applies only at a hop the gateway itself dials, since a promise about a destination holds only where you make the connection.

What pistra does not know

There is no PDPL mode and no GDPR mode. Neither word appears anywhere in the code, deliberately.

The gateway has entity types, rules that act on them, and controls identifiers on a rule that ride onto every record that rule decides. Your data protection officer decides which entity types count as personal data in your context, which rule discharges which control, and what the identifier is called. The gateway makes the rule happen at the moment of the call and signs what it did.

A compliance mode would be a vendor’s reading of a law, on a date, applied to your data. When the reading is wrong you inherit it without being told, and when the regulation moves you wait for a release. That is the argument post 5 made about unified APIs, in a different regime.

When you do not need this

If personal data lives in a database and your application never puts any of it in a prompt, an inspection hop buys you nothing. A code assistant on a repository with no customer data in it, a classifier over documents that were already yours, an internal search over an internal wiki: those are governed by who has an account, not by what is in the body.

And if what you want is the mapping, a pack that labels entity types against a named regime’s categories so you can hand it to an auditor, a detector vendor who sells that will get you there faster than we will. You will still need something holding the connection to act on the verdict. Buy the labelling from whoever labels for a living.

The dates

The AI Act’s obligations for high-risk systems arrive in December 2027. The transfer obligation arrived the first time one of your applications called a model, and in Saudi Arabia the transition period for the PDPL ended on 14 September 2024. One of those needs a plane that runs today.

All posts