€15 million.
In December 2024, the Italian Garante fined OpenAI €15M for ChatGPT processing of personal data — and ordered a six-month public awareness campaign. If you're a controller using an LLM as a processor, here is what the decision actually obligates you to do.
The decision is provvedimento n. 9978020 of 19 December 2024.
Read it as more than a vendor punishment. It is a controller playbook disguised as an enforcement action. The Garante focused on failures tied to GDPR Article 5(1)(a) on lawfulness and transparency, Article 6 on lawful basis, Articles 12, 13 and 14 on information duties, and Article 25 on data protection by design.
Italy's temporary ChatGPT ban in March 2023 set the procedural precedent. The December 2024 ruling is the substantive version: this is what the regulator thinks AI data governance should look like in practice.
Why this decision matters beyond OpenAI
Most DPOs read this kind of case and file it under vendor risk. That is too neat. OpenAI's failures do not cancel your own.
If your staff paste personal data into ChatGPT, Claude, Gemini, or Copilot, you are still the controller for that disclosure and subsequent processing in your business context.
That means Article 28 still lands on your desk. You need processor terms, documented instructions, due diligence on technical and organisational measures, and evidence that the tool is being used inside the boundaries you set.
"The model provider got fined" is not a defence. It is an admission that you sent personal data into a processor you did not govern tightly enough.
The same logic runs through UK ICO guidance. The ICO's 2024 guidance on generative AI and data protection also treats transparency as a live issue, not paperwork theatre. If personal data is used in generative AI systems, your Article 13 and Article 14 notices need to say so in plain language.
Different regulator, same direction of travel.
A controller's last useful control point is usually the browser, before the prompt leaves the device.
!Prytive popup intercepting a prompt and surfacing the controller-side GDPR exposure
The operational failures the Garante identified
Start with lawful basis. The Garante found no valid Article 6 basis for parts of the personal data processing used for training. That is a vendor-side finding, but the controller-side lesson is simple: you do not get to treat prompting an LLM as regulation-free because the interface feels casual.
If an employee types this:
Summarise these 200 customer emails and identify the ones expressing frustration with our pricing.you have an Article 6 question before you have a productivity gain. Are you relying on Article 6(1)(f) legitimate interests? Fine. Show the assessment. Show necessity.
Show why your balancing test covers sending those emails to that specific processor for that specific purpose. If the original collection notice did not reasonably cover this use, your Articles 13 and 14 position also starts to wobble.
Transparency was the second major theme. The Garante pointed to gaps under Articles 12 to 14. Many privacy notices still say variants of "we use service providers to help operate our business."
That will not carry much weight if staff are using LLMs to analyse complaints, HR files, or customer support threads. Both the Garante and ICO are telling you the same thing: name the AI processing clearly enough that a data subject could understand it without a law degree.
Then there is Article 25. Data protection by design is where a lot of AI governance decks go to die. Lovely flowcharts. Zero actual interception.
If your control starts after the prompt has already reached the model, that is not design. That is incident response wearing a blazer.
Three prompts that create immediate GDPR exposure
This is where compliance stops being abstract.
Translate this internal HR investigation file for the German team.That can involve Article 9 special category data, allegations, witness statements, health references, union membership details, or disciplinary content. Your analysis needs both an Article 6 basis and, where special category data is present, an Article 9 condition. It also needs a clean purpose chain.
"Translation" is not a magic word that dissolves sensitivity.
Cluster these 1,200 patient feedback responses by sentiment and topic.That is likely health data. Article 9 risk is obvious. Article 32 is next. What security measures are in place before transmission? Is the data minimised? Are direct identifiers removed?
Can your team prove what was sent, by whom, and to which tool? If you cannot answer those questions in under an hour, your control environment is built on optimism.
Summarise these 200 customer emails and identify the ones expressing frustration with our pricing.Routine commercial task. Still personal data. Still a controller decision. Still subject to Article 5(1)(a), Article 6, and Articles 13 and 14.
Shared responsibility is not a slogan
Vendors love the phrase because it spreads blame politely. Regulators mean something narrower and harsher. Shared responsibility means each party keeps its own legal burden.
OpenAI can fail on transparency, lawful basis, design, or security. You still owe Article 28 diligence. You still choose whether your employees can send names, complaint histories, HR records, patient comments, financial details, and confidential deal material into that processor.
You still need records showing what categories of data were involved, what instructions applied, what technical restrictions existed, and how misuse was prevented.
That is why blanket AI policies age badly. "Do not paste sensitive data into ChatGPT" is not control. It is wishful thinking with a logo on top.
If you need a starting point for the policy layer, the one-page AI usage policy template is useful. But policy without browser-layer enforcement leaves you explaining to the DPA why the warning lived in SharePoint while the data lived in a prompt box.
Six controller-side actions this ruling implies
- Map LLM uses to Article 6 before rollout. Separate summarisation, translation, drafting, classification, and search. They do not all share the same lawful basis analysis.
- Review Article 9 triggers. HR, health, legal claims, insurance files, and support tickets often contain special category data even when the business owner insists they do not.
- Rewrite your Articles 13 and 14 notices. Say when generative AI is used, for which categories of personal data, for which purposes, with which providers, and what safeguards apply. Plain English. Not legal mist.
- Tighten Article 28 evidence. Keep processor terms, transfer assessments where relevant, subprocessor visibility, and records of the instructions you gave users and admins.
- Implement Article 25 controls before transmission. Block or redact high-risk prompts in the browser. Post-submission monitoring is useful, but it is not enough.
- Test Article 32 with real prompts. Run controlled exercises using live-like data patterns. Measure whether names, account numbers, health details, and investigation material are intercepted before leaving the device. If you need the response clock for a bad day, the 72-hour AI incident response playbook is the practical version.
The real lesson from the €15M fine
The Garante's December 2024 ruling is the most operationally useful GDPR decision on AI so far because it turns vague AI governance talk into concrete controller duties. Lawfulness under Article 5(1)(a) and Article 6. Transparency under Articles 12 to 14. Design under Article 25. Vendor governance under Article 28.
None of that disappears because the model provider has its own regulatory problems.
Your staff will keep using LLMs. That part is settled. The only serious question is whether you can prove the data was governed before it crossed the browser boundary.
Make the implicit controller obligations explicit. Prytive intercepts high-risk prompts before they reach ChatGPT, Copilot, Gemini, or Claude, and logs the redacted Article 28 evidence base you would otherwise lack.