Every Prompt Is a Data Transfer

For most of the last decade, data protection inside a well-run company was a mapping exercise. You knew which systems held customer records, which vendors processed them, which contracts governed the flow, and which country the servers sat in. It was tedious work, but it was finite.

Generative AI broke the map. Not because the models are malicious, but because they changed the unit of data movement. Data used to leave the organisation in batches, through integrations that someone had reviewed. Now it leaves one prompt at a time, pasted by whoever happens to be holding the keyboard. A contract clause, a patient summary, a draft board memo, a spreadsheet of salaries: each of these, dropped into a chat window, is a transfer of personal or confidential data to a third-party processor. Most organisations would never approve that transfer if it arrived as a procurement request. They approve it hundreds of times a day without noticing.

The first step to a serious privacy posture is to name the thing correctly. A prompt is not a search query. It is a disclosure.

Where the risk actually lives

It helps to stop thinking of "the AI" as one system and instead trace the lifecycle of a single interaction. There are five distinct places where data can escape your control.

The input. Everything in the prompt, including attached files and whatever an integration retrieves on the user's behalf, is transmitted to the provider. If the prompt contains personal data, the provider is now processing personal data, and the legal relationship needs to reflect that.

The output. Model responses can contain personal data too: summaries of the documents you supplied, inferences about people mentioned, or plausible-sounding fabrications about real individuals. An output is a new record, and under European data protection law, inaccurate personal data in a record is a problem in its own right.

The logs. Providers retain prompts and responses for abuse monitoring, debugging and billing. Retention periods vary from zero to indefinite depending on the product tier and the contract. This is the most underestimated exposure, because logs are exactly what a breach or a legal demand would reach.

Training use. Consumer tiers of many AI services have, at various points, used conversations to improve future models unless the user opted out. Once data is absorbed into model weights it cannot be cleanly deleted, and research on training-data extraction has shown that models can, under some conditions, reproduce fragments of what they were trained on. Enterprise contracts typically exclude training use. Individual employees on personal accounts are not covered by your enterprise contract.

Subprocessors. The provider you contracted with is rarely the only party involved. Hosting, inference capacity, content moderation and support may sit with other companies, each a link in the chain your data protection impact assessment needs to cover.

A useful discipline is to ask, for any AI use case, a single question at each of these five points: who can read this, for how long, and under which law?

Location is not jurisdiction

The most common mistake in AI procurement is to treat data residency as if it settled the sovereignty question. It does not.

In June 2025, Microsoft France's legal director was asked under oath at a French Senate inquiry whether he could guarantee that French citizens' data held in Microsoft's cloud would never be handed to US authorities without French approval. His answer was that he could not. The reason is the US CLOUD Act of 2018, which allows US authorities to compel US-headquartered providers to produce data in their possession or control, regardless of where the servers are. Microsoft has also said it would challenge unfounded requests and that it had not, at that point, handed over European data under the Act. Both statements can be true at once. The point is structural: the protection depends on the provider's willingness to litigate, not on the architecture.

For Swiss and European organisations this produces an uncomfortable conclusion. A European data centre operated by a US-headquartered company reduces some risks, notably latency and certain transfer formalities, but it does not remove foreign legal reach. Contractual transfer frameworks between the EU, Switzerland and the United States help with the legality of transfers. They do not change who can be compelled.

This is why the conversation has moved from "where is the data stored" to "who operates the stack, and which courts can order them to do what". We return to this in our piece on sovereign AI.

What the law already requires

It is tempting to wait for AI-specific regulation before acting. That would be a mistake, because most of what matters is already law.

Under the GDPR, and under Switzerland's revised Federal Act on Data Protection (in force since September 2023), sending personal data to an AI provider is processing. The familiar obligations apply: a lawful basis, purpose limitation, data minimisation, a processing agreement with the provider, an impact assessment where the risk is high, transparency towards the people concerned, and lawful cross-border transfers. None of this is new. It is simply being ignored at a scale that would have been unthinkable for a CRM or an HR system.

The AI-specific layer is arriving on top. In the EU, the AI Act's prohibitions have applied since February 2025 and its obligations for general-purpose model providers since August 2025. The 2026 Digital Omnibus pushed the deadlines for most high-risk systems back to December 2027 and August 2028, but transparency duties and the AI Office's enforcement powers over general-purpose models were not delayed. In Switzerland, the Federal Council chose to ratify the Council of Europe's AI Convention and to adapt existing laws sector by sector rather than write a Swiss AI Act; a consultation draft is now expected in spring 2027.

The practical reading for a compliance function is simple. The data protection obligations are live today. The AI-specific obligations are scheduled. Neither is optional.

A posture that actually works

Banning generative AI does not work. It drives usage onto personal devices and personal accounts, which is the worst possible outcome because it removes every contractual and technical control at once. The organisations getting this right do something more boring and more effective: they classify, and they route.

Classify the data, not the tool. Most companies already have an information classification scheme, typically something like public, internal, confidential and strictly confidential. Extend it with a single column: which AI deployment model is acceptable for this class. Public material can go anywhere. Internal material can go to an enterprise service with a processing agreement, no training use and short retention. Confidential material may need a provider whose operator sits within your own jurisdiction. The most sensitive class, such as client-identifying data in a bank, health records or unreleased financial results, often belongs on infrastructure you control, with models you host yourself.

Make the safe path the easy path. Employees paste data into consumer tools because those tools are fast and the approved alternative is slow or nonexistent. If the sanctioned option is good, people use it. If it is a ticket queue, they do not.

Treat retrieval as disclosure. Assistants increasingly reach into email, documents and drives on the user's behalf. Every connector widens what a single prompt can disclose, and every retrieved document becomes input to the provider. Review connectors the way you would review a new integration, because that is what they are.

Remember that derived data is still data. Systems that index documents for AI search store numerical representations of the text, called embeddings. These are sometimes described as anonymised. They are not: published research has shown that text can be reconstructed from embeddings with surprising accuracy. An embedding index of confidential documents is a confidential asset.

Decide what "deleted" means. Ask every provider three concrete questions: how long are prompts and outputs retained, can retention be set to zero for our tenant, and what survives a deletion request. Get the answers in the contract.

The opportunity hiding in the problem

There is a more optimistic way to read all of this. For most of computing history, the most capable software required sending data to whoever built it. That is no longer strictly true for AI. Open-weight models have closed much of the capability gap with closed frontier systems, and many everyday tasks such as summarising, drafting, extracting and searching across documents can now run on a single workstation or a modest server under your own control.

That changes the privacy conversation from "how much risk will we accept to use AI" to "which tasks genuinely need a frontier model in someone else's cloud, and which do not". For many organisations the honest answer is that the second list is longer than they assumed.

Privacy in the age of AI is not a matter of saying no. It is a matter of knowing, prompt by prompt, where the data goes and why that destination was chosen. Companies that can answer that question will adopt AI faster, not slower, because they will be the ones their clients, regulators and employees trust to do it.