Is ChatGPT GDPR-compliant?
The question is not well formed. GDPR regulates processing, not products, so no assistant is compliant or non-compliant in the abstract. A public assistant can be used lawfully for some purposes and unlawfully for others. What determines the answer is the data you put in, the legal basis you rely on, and where the processing happens.
For public-information tasks — drafting, summarising text you supply, general research — the analysis is usually straightforward. The difficulty appears when the assistant is connected to internal company data: customer records, HR files, case files, contracts, incident reports. At that point you are processing personal data at scale through a third party, and the full weight of the Regulation applies.
What does GDPR actually require of an AI assistant?
Four things carry most of the weight: a lawful basis for the processing, a defensible position on international transfers under Chapter V, security measures appropriate to the risk under Article 32, and the ability to demonstrate all of it under the accountability principle in Article 5(2). Each of these is a deployment property, not a model property.
| Requirement | GDPR basis | What it means for an AI assistant |
|---|---|---|
| Lawful basis | Article 6 (and Article 9 for special categories) | You need a basis for the processing the assistant performs, including any secondary use such as service improvement or model training. |
| International transfers | Chapter V, Articles 44–49 | If personal data reaches a third country, you need an adequacy decision, appropriate safeguards, or a derogation — and a transfer impact assessment where relevant. |
| Security of processing | Article 32 | Access control, encryption, resilience, and testing. In practice this is where permission-aware retrieval sits. |
| Accountability | Article 5(2), Article 30 | You must be able to demonstrate compliance — records of processing, and evidence of what the system actually did. |
Why are international transfers the hardest part?
Because the legal ground has moved twice. The Court of Justice invalidated the Privacy Shield framework in its Schrems II judgment of 16 July 2020, primarily over US surveillance access and the absence of effective redress. The EU-US Data Privacy Framework restored a transfer route in July 2023, but it rests on an adequacy decision of the same type.
Adequacy decisions are reviewable and challengeable. Organisations that built their transfer position entirely on Privacy Shield had to rebuild it after 2020. That history is why many risk functions in regulated sectors now prefer architectures where the transfer question does not arise at all, rather than architectures that depend on a decision remaining in force.
Separately, US law can reach data held by US-controlled providers regardless of where the servers sit. The Clarifying Lawful Overseas Use of Data Act of 2018 allows US authorities to compel providers subject to US jurisdiction to produce data in their possession, custody, or control, including data stored abroad. GDPR Article 48 addresses the resulting conflict by providing that third-country judgments and decisions are only recognisable on the basis of an international agreement. That tension is unresolved, which is precisely why it appears in so many security questionnaires.
What are the realistic alternatives?
There are four deployment patterns, and they trade convenience against control in a predictable order. Most European organisations end up choosing between the enterprise tier of a public provider and a dedicated European deployment, with on-premise reserved for the highest-sensitivity workloads.
| Pattern | Transfer position | Trade-off |
|---|---|---|
| Consumer AI assistant | Weakest. Often outside any enterprise agreement, with unclear data use. | Highest convenience, lowest control. This is what shadow AI usually means in practice. |
| Enterprise tier of a public provider | Contractual protections and EU data-residency commitments, but the provider remains subject to its home jurisdiction. | Good capability and support; the ownership and lawful-access questions remain open. |
| Dedicated European deployment | Processing stays in a defined EU environment, with no external model API calls. | Removes the transfer argument for most workloads; requires a vendor that supports it properly. |
| On-premise or air-gapped | Data does not leave your infrastructure at all. | Strongest position, highest operational burden. Usually reserved for the most sensitive workloads. |
Why does access control decide most of these projects?
Because an assistant that retrieves documents a user was never entitled to see has not created a productivity problem — it has created a personal data breach under Article 4(12), with the notification obligations that follow. This is the most common reason internal AI pilots fail security review, and it is an architectural property that cannot be retrofitted with policy.
The failure mode is specific and predictable. A system indexes everything it can reach using a service account with broad rights, then attempts to filter results by user afterwards. Filtering after retrieval is fragile: summaries, embeddings, cached answers, and suggested follow-ups can all leak content the filter was supposed to withhold.
The alternative is to carry each source system's access control into the retrieval step itself, so a user's query only ever reaches material they were already authorised to open. It is harder to build and much easier to defend in a review.
What should we ask a vendor before deploying?
Ask questions that have documentary answers rather than reassuring ones. The following list maps directly onto the four GDPR requirements above and can be pasted into a vendor assessment as-is.
- Where does inference physically happen, and does any company content leave that boundary — including for embeddings, re-ranking, safety classification, or telemetry?
- Which entity controls the operator of the processing environment, and in which jurisdiction is it incorporated?
- Is customer content used to train or improve any model, under any circumstances, and how is that enforced technically rather than contractually?
- How are source-system permissions carried into retrieval, per user, per query? Ask for a demonstration, not a description.
- What record exists of what was retrieved and generated, how long is it kept, and can we export it?
- Which subprocessors are involved, and what is the notification process when that list changes?
- What is documented in the Article 30 record, and will you supply the material we need for a DPIA?