The wrong question
Nobody asks whether email is GDPR-compliant. The question is about a specific configuration: whose data, for what purpose, where it sits, and who can reach it.
So we assess the deployment, not the model. The same model can be entirely acceptable in one arrangement and unacceptable in another — the difference is not in the model, but in where the personal data goes and who becomes its recipient.
Two configurations, different obligations
**Data leaves the company.** If the provider acts as a processor, choosing the cloud also brings obligations: a processing agreement, rules for onward transfers outside the European Economic Area, a retention period and a way to delete data on request. All of that is workable, but it is work to be done and documentation to be maintained — not a signature collected once.
**Data stays inside the company.** If the personal data remains solely with you, no external recipient enters the picture. Your own obligations do not disappear — an inventory, access rules, retention and security all remain — but the entire layer of processing agreements and transfers does, because there is nobody to transfer to.
Worth saying plainly: the first configuration is not a mistake. It is a choice you have to be able to describe, and for many companies it is cheaper to maintain than their own environment.
What it changes in practice
Three things recur in every deployment, whatever the industry.
**The agent's context is a copy of the data.** If the agent reads the inbox, its context contains the content of that mail. A deletion request therefore has to reach there too — the conversation history, the memory, the logs. How that is done cannot be assumed; it has to be designed before the first request arrives.
**Logs are personal data.** If you record who asked what and what came back, that is a personal-data set — even if it never contained a single invoice.
**Access limits must be verified, not merely documented.** "The agent sees only what it is entitled to see" has to be a sentence a test can check, not a description of intent in a document.
When the cloud is fine
When the data is not sensitive, the volume is small, and the risk has been assessed honestly — rather than dismissed with "it's only a summarisation tool". Hosted models are often the right choice: cheaper and faster to deploy, with the contracting and billing machinery already on the provider's side.
Maintaining your own environment in order to process publicly available listings is an expensive reflex, not caution.
When the architecture can be the answer
In healthcare, in a law firm, in the public sector, in a company whose internal policy forbids sending data out. Then you are not looking for a provider that "also has GDPR" — you are looking for an arrangement in which personal data has no route out. Not because it looks neater in the documentation, but because the documentation then describes the actual state of affairs.
With your own infrastructure, however, your company takes on model maintenance, updates and the work on accuracy. Cutting the network is an architectural decision with operational consequences, and it has to be costed together with everything else.
This is not legal advice
The above describes architecture and the questions worth asking — not a compliance verdict for a particular deployment. Who is responsible for the data, and on what basis, is settled with a lawyer and your organisation's own documentation, not with an article on a vendor's site.
What this means for your company
Before choosing a tool, answer three questions: what personal data will enter the system at all, who is to receive it outside your company, and how deletion works in every place it lands — including the agent's contexts and logs.
If the third question has no answer, you do not have a deployment. You have a demo.