← Insights

·AI governance, GDPR, data sovereignty

Every prompt is a data-export decision

For a regulated firm, sending a prompt to an external AI model is not merely a productivity choice. It is a decision to export data, and it should be treated like one.


When your firm sends a prompt to an AI model that runs on someone else’s servers, you have moved data outside your walls. That is true whether the prompt holds a client name, a position, a draft memo, or just the shape of a question you would not want a competitor to see. The provider’s terms may promise not to train on it. That promise matters, but it does not change what happened: the data left.

For most companies this is a manageable risk. For a regulated one it is the centre of the problem.

A firm under the GDPR, DORA, MiFID II or the AI Act cannot treat confidentiality as a matter of trust alone. It needs evidence of where data was processed, who could reach it, which provider and jurisdiction were involved, and what happened when the provider received a lawful demand. “We do not train on your data” addresses only one part of that question. Once data enters a third-party service, control also depends on that provider’s architecture, contract, operations and legal obligations.

So the objective way to think about each prompt is as an export decision. Before the data leaves, you would want to know three things. Does it contain anything that should not cross the boundary? If it does, can that part be stripped, tokenised, or kept local before anything is sent? And is there a record afterwards of what left and what did not?

Most firms have none of this today. The prompt box is open to everyone, it sends everything, and nobody can reconstruct what was disclosed. That is not a posture you can take to a regulator.

The answer is not simply to ban AI. A blanket prohibition can push use into personal accounts with no institutional record. A more defensible pattern is to put the export decision inside the firm: classify the request, apply configured controls, retain evidence and route only what the firm has decided may leave. Protected-value substitution can keep supported fields out of an external payload, but detectors and configurations must be validated and residual context may still be identifying.

GAIA-CORE is being developed around that control point. Its protected-egress mechanism exists in source but remains default-off pending hardware-key binding, witnessed activation and customer validation. GAIA-CORE is just short of MVP; it is not an official customer deployment or a guarantee that no sensitive context can leave.

That is the principle GAIA25 is built around, and it is the idea behind GAIA Brain, the customer-hosted control and evidence layer we have in development. The technology matters less than the habit it enforces: treat every prompt as an export, and decide it on purpose.