When you ask an AI assistant a question inside your organisation, the answer depends on what your tool actually sends outside your network. GDPR makes the destination and processing method material facts that you need to know and be able to document.
What travels when you use an AI assistant
A typical AI workspace flow involves three kinds of data: the question itself, document passages that the system retrieved as context, and metadata about the query (timestamps, user identity, which documents were searched). Exactly what leaves your infrastructure depends on where inference happens.
If you run inference locally — on your own GPU, with model weights on your own disk — nothing leaves the network. The question arrives, stays inside your environment, the answer is generated there, and only the resulting conversation and any audit records touch your database. This is why local inference is a different conversation from hosted APIs entirely.
If you use a hosted model API, only the question and the retrieved passages leave your server. Your document store, search indexes, chat history, and audit trail remain on your infrastructure. But those passages — snippets of text from your documents — do cross the boundary. That crossing is where GDPR compliance becomes concrete.
The data processing agreement is not optional
Using an external API to process your data makes the API provider a data processor under GDPR. That relationship has legal consequences: you need a Data Processing Agreement (DPA) that specifies what data goes where, how long it stays, what the provider does with it, and whether they use sub-processors.
Most providers of commercial LLM APIs offer DPAs as standard. This is not a courtesy — it is a legal requirement that both parties need in place before processing starts. If a vendor tells you they will sign a DPA "later," or that privacy documentation is not necessary because the data is already encrypted, those are red flags.
The agreement tells you: where the provider processes the data (which region, which servers), whether they use the data for model improvement, how long they retain it, and what sub-processors they employ. Sub-processors matter because the provider might route your data through other services — compliance vendors, logging platforms, analytics — that you do not directly contract with. The DPA must list them and give you a way to object to changes.
Regional processing and transfer restrictions
Many providers operate global infrastructure. A request sent to an API might be processed in a data center in California, Europe, or elsewhere. For organisations in the EU, the transfer of personal data outside the EU is restricted under GDPR — it is not forbidden, but it requires a legal mechanism like a Standard Contractual Clause (SCC) or an adequacy decision. Your DPA should address how transfers are protected.
Some providers offer European or regional endpoints specifically to keep processing within the EU. If that matters for your organisation — if your documents contain personal data of EU residents and you want processing to stay in Europe — you need to verify that the endpoint you are using actually processes data there. Marketing copy claiming European processing is not the same as a contractual guarantee. Ask.
This is not legal advice and the specifics depend on your jurisdiction and the nature of the data you send. An organisation processing personal data of EU residents faces different obligations than one processing purely commercial information. Consult your legal and privacy teams before deciding whether hosted APIs work for your use case.
Self-hosted models as a simpler case
When you run a model locally — through platforms like Ollama on your own hardware — you become the sole processor. The data never leaves your control. There is no external DPA to negotiate because there is no external processor. This simplicity is one reason self-hosted inference appeals to organisations with strict data residency requirements.
The trade-off is capability: local models are smaller and less capable than hosted ones, and running them requires your infrastructure to provide the compute. But if GDPR compliance requires you to keep text data inside your jurisdiction and under your control, local inference makes that straightforward to verify and defend.
The practical checklist
If your organisation uses AI assistants and processes any personal or regulated data, verify: whether the tool uses local inference only, or can send data to external APIs; if external APIs are used, where processing happens and whether a DPA exists; whether you can see and audit which sub-processors are involved; whether the tool offers regional endpoints if processing within a specific region matters to you.
Self-hosted platforms like Nodus Veritatis where you control whether hosted models are enabled and which documents are sent to them make this chain visible and controllable. But any AI workspace — hosted or self-hosted — that uses external APIs for some capabilities needs the data processing agreement in place. It is the foundation of knowing what leaves the building and who is allowed to do what with it.