SignalFeed

Your Pricing Page Is Your Highest-Intent AEO Asset. Most Hide It.

Italy's Garante fined OpenAI EUR 15 million, Hamburg's DPA said model weights are not personal data, and the French CNIL is publishing per-stage guidance for AI providers. The right to erasure has collided with a technology that cannot meaningfully forget. This is what EU data protection authorities are actually demanding from AI search providers and the operators who depend on them.


When the Italian Garante per la Protezione dei Dati Personali published its EUR 15 million enforcement decision against OpenAI on December 20, 2024, it became the largest GDPR fine ever levied against a generative AI provider and the first to test Article 17 of the regulation, the right to erasure, against the architectural reality of large language models. The decision concluded that OpenAI processed personal data to train ChatGPT without an adequate Article 6 legal basis, failed to notify the Garante of a March 2023 data breach involving Italian users, and ran a product that under-13s could freely access without age verification. Buried in the same decision was a six-month order requiring OpenAI to run a public information campaign across Italian media explaining how ChatGPT handles personal data and how Italian residents can exercise their GDPR rights, including the right to be forgotten. The campaign launched in February 2025; the doctrinal questions it surfaced are unresolved and increasingly load-bearing for any operator running an AEO program in or adjacent to the EU.

This article is a working framework for that intersection. It covers how Article 17 applies to LLM training corpora and to retrieval-augmented AI search, what the Italian Garante, the French CNIL, the Hamburg Commissioner for Data Protection, the UK Information Commissioner's Office, and the European Data Protection Board have each said about scope and remedy, how OpenAI, Anthropic, and Google currently handle data subject requests, and what an operator-side AEO program needs to change to absorb the compliance load without losing citation visibility. The frame is practitioner-first: this is what a privacy counsel, head of growth, and head of platform need to agree on before the next quarterly board review.

Article 17 in the LLM Era: What the Regulation Actually Says

The right to erasure was drafted before transformer models existed. Article 17(1) of the General Data Protection Regulation as published in the Official Journal of the EU gives a data subject the right to obtain from the controller, without undue delay, the erasure of personal data concerning them when one of six grounds applies: the data is no longer necessary, consent is withdrawn, the subject objects under Article 21 and there are no overriding legitimate grounds, the processing was unlawful, an EU or member-state legal obligation requires erasure, or the data was collected from a child. Article 17(2) extends the obligation to controllers that have made the data public: they must take reasonable technical and organizational measures to inform other controllers processing the data that erasure has been requested.

The regulation imagines a controller with a structured record of where personal data sits — a database row, a CRM field, a document. The controller deletes the row, the data is gone, the obligation is satisfied. None of the underlying mechanics of an LLM look like that. Personal data enters a training corpus as raw text scraped from the open web; the corpus is tokenized, the tokens are statistically compressed into billions of floating-point weights; the model that emerges can sometimes regurgitate memorized passages but more often blends statistical patterns derived from many sources. There is no row to delete. There is no field. The closest analog to a structured record is the original training-data file, which most labs retain in some form for audit and reproducibility purposes — and which is the easiest target for an Article 17 request.

The European Data Protection Board attempted to close some of the doctrinal ambiguity with its Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models, adopted on December 17, 2024. The opinion sets out a three-question test for whether an AI model itself contains personal data: (1) whether identification of a data subject from the model is reasonably likely given the means available to the controller or another person, (2) whether the model has been designed to preserve identifying information from training data, and (3) whether identifying information can be extracted through normal interaction with the model. If any of the three is yes, the model is processing personal data and the controller is bound by the full GDPR. If all three are no, the EDPB suggests the model itself may not be processing personal data, although the training that produced it almost certainly was.

The practical effect of Opinion 28/2024 is that frontier LLMs — GPT-4o, Claude Opus 4, Gemini 2.5, Llama 3.1 405B — almost certainly fail the third prong because they can be prompted to extract identifying information about named individuals from training data. They are therefore in scope. The operational question that follows is what an Article 17 remedy actually looks like when weight-level deletion is technically infeasible.

The Four DPAs Setting the Standard

European data protection authorities are not a monolithic block. Each national DPA has issued guidance, opinions, or enforcement decisions that diverge on key questions, and the four that matter most for AI search are the Italian Garante, the French CNIL, the Hamburg Commissioner for Data Protection, and the UK Information Commissioner's Office.

Italian Garante: Enforcement-Forward, Ban-Willing

The Garante is the regulator that put ChatGPT briefly offline. The March 31, 2023 temporary ban order followed a data breach disclosed by OpenAI on March 20, 2023 and cited the absence of an Article 6 legal basis for training, the absence of an age-verification mechanism, and the absence of an information notice for Italian users. OpenAI restored service in Italy on April 28, 2023 after committing to add an information notice, an age-gate, an opt-out for training, and an Article 17 intake form. The December 2024 EUR 15 million fine adjudicated the same underlying complaint as a final-stage enforcement and added the public information campaign order. The Garante's posture in 2026 remains the most aggressive in the bloc and the one operators should treat as the binding floor: assume any AI search provider that wants to operate in Italy has to offer a working Article 17 process and assume the Garante will audit it.

French CNIL: Guidance-Forward, Per-Stage

The Commission Nationale de l'Informatique et des Libertes has taken a more documentation-focused approach. CNIL's AI How-To Sheets, the series of guidance documents published since April 2024, break the AI lifecycle into phases (purpose definition, lawful basis, dataset constitution, model training, deployment, and exercise of rights) and offer specific compliance pathways for each. The most operationally consequential of these is the May 2024 sheet on the legal basis of legitimate interest for training-data scraping, which CNIL accepts as a viable Article 6(1)(f) basis subject to a structured balancing test, and the February 2025 sheet on individual rights, which sets a 30-day expected window for AI providers to respond to Article 17 requests and identifies output-filtering as an acceptable interim remedy when weight modification is infeasible. CNIL has been quieter than the Garante on enforcement but has opened formal investigations into several frontier-model providers; the working assumption among EU privacy counsel is that the next major enforcement decision against an LLM controller will come from Paris.

Hamburg DPA: Doctrinal Counterweight

The Hamburgischer Beauftragte fur Datenschutz und Informationsfreiheit released a July 15, 2024 discussion paper titled Large Language Models and Personal Data that argued the trained weights of an LLM do not themselves contain personal data within the meaning of the GDPR, on the grounds that personal data requires a relationship between identifying information and a specific natural person, and that the lossy statistical compression of training data into model weights breaks that relationship for all but a small fraction of memorized examples. The paper was explicit that it was a discussion contribution rather than a binding interpretation, and the EDPB's Opinion 28/2024 partially rejected the Hamburg position five months later. The Hamburg view nonetheless remains influential because it offers a defensible doctrinal home for AI providers arguing that Article 17 erasure obligations apply to training corpora and outputs but not to weights themselves. Operators with EU exposure should treat the Hamburg paper as the most coherent argument an AI provider is likely to make in litigation, and plan accordingly.

UK ICO: Consultation-Forward

The UK Information Commissioner's Office sits outside the GDPR but inside the UK GDPR, which is functionally identical on Article 17. The ICO ran a generative AI consultation series across 2024 and 2025, publishing five chapters on lawful basis, purpose limitation, accuracy, individual rights, and controller-processor allocation. The fourth chapter, on individual rights, takes a position close to the CNIL's: output filtering is an acceptable interim measure, weight-level deletion is not currently required, and providers must document the technical and organizational measures they take to honor Article 17 requests. The ICO has not yet issued a major enforcement decision against an LLM provider, but the consultation outputs have become a de facto checklist for UK-resident AI providers and for international providers serving UK users.

How the Top AI Search Providers Actually Handle DSRs

The published enforcement standards are one thing; the actual intake and response flows operators encounter in 2026 are another. The table below summarizes the working Article 17 process at each major AI search provider, based on documented intake forms, published transparency reporting, and reported outcomes from EU privacy counsel.

ProviderIntake ChannelIdentity VerificationDefault RemedyWeight ModificationResponse Window
OpenAI (ChatGPT, ChatGPT search)Personal data removal form linked from EU privacy noticeGovernment-issued ID plus prompt examplesOutput filter + future-training exclusionNo30 days
Anthropic (Claude, Claude search)privacy@anthropic.comGovernment-issued ID plus prompt examplesOutput filter + future-training exclusionNo30 days
Google (Gemini, AI Overviews)Existing Right to be Forgotten web form, AI extensionExisting Google identity verificationRetrieval-time suppression + AI-output filterNo30 days
Microsoft (Copilot)Privacy DashboardMicrosoft account verificationRetrieval-time suppression + AI-output filterNo30 days
Perplexityprivacy@perplexity.aiEmail-based verificationSource removal + output filterNo (Perplexity does not train base models)30 days
Meta (Meta AI)Existing Meta privacy formExisting Meta account verificationOutput filter + training opt-out (EU users)No30 days
Mistral (Le Chat, La Plateforme)privacy@mistral.aiGovernment-issued IDOutput filter + future-training exclusionNo30 days
xAI (Grok)privacy@x.aiGovernment-issued ID plus prompt examplesOutput filterNo30 days

The consistency across providers is not accidental. The current consensus interpretation, blessed implicitly by the EDPB and explicitly by CNIL and the ICO, is that output filtering plus future-training exclusion satisfies the controller's Article 17 obligation when weight-level deletion is technically infeasible and disproportionately costly. The Italian Garante has not endorsed this consensus in writing but has not yet challenged it in enforcement; the Hamburg DPA's discussion paper provides doctrinal cover for the lack of weight modification. The fragile point in the consensus is what happens when a data subject demonstrates that the output filter is leaky — that the model still returns identifying information about them in adversarial or paraphrased prompts. CNIL's February 2025 individual-rights sheet suggests that recurring filter failures escalate the obligation, but stops short of mandating retraining.

The Three Remedies That Are Actually on the Table

Across the published guidance and the working provider intakes, three remedy types appear repeatedly. Operators need to understand all three because each carries a different AEO implication.

Output Filtering

The dominant remedy in 2026. The controller adds a classifier or retrieval-time filter that suppresses generation of identifying information about a named data subject. OpenAI implements this as a moderation-layer rule applied to both ChatGPT outputs and ChatGPT search citations; Anthropic implements it as a constitutional-AI prompt rule plus a runtime filter; Google implements it as a retrieval-side blocklist plus an output classifier. The AEO consequence for operators is asymmetric: a successful Article 17 request from a named individual associated with your brand (a founder, an executive, a customer) can suppress AI citations of pages that prominently feature that individual. The mitigation is to diversify citation-magnet content away from any single named subject so that a single Article 17 request cannot collapse an entire AEO surface.

Future-Training Exclusion

The second remedy. The controller commits not to use the requester's personal data in future training runs, typically through a documented exclusion list maintained by the data team. OpenAI and Anthropic both maintain such lists; Google has confirmed equivalent infrastructure for Gemini training. The remedy has no immediate effect on the current production model — the data already memorized stays memorized — but it removes the data from the next generation. For operators, the AEO impact is that any future LLM trained after a successful Article 17 request will have less training-data exposure to the named individual, which gradually reduces the model's ability to cite them as an authority. The decay curve is roughly aligned with model-generation cadence: 12-18 months for OpenAI and Anthropic, 18-24 months for Google.

Retrieval-Time Suppression

The third remedy. The controller adds the named data subject to a suppression list applied at the retrieval layer of any RAG-style AI search product. ChatGPT search, Perplexity, AI Overviews, and Copilot all operate retrieval suppression separately from the underlying model; a data subject whose name is on the suppression list will not appear as a citation in the retrieval output, even if the source content remains crawlable and indexed. The AEO consequence is the most immediate of the three: a successful retrieval-suppression order against a named individual can remove your brand from AI search citations within hours, regardless of how much content you have published. The mitigation is the same as for output filtering — diversification of citation-magnet content across multiple named subjects and entity references.

Data Poisoning and Machine Unlearning: The Technical Side

When weight modification is the goal but full retraining is impossible, two technical approaches are emerging.

The first is targeted unlearning. A growing research literature, surveyed in the NIST AI 100-2 E2025 report on adversarial machine learning, documents methods for selectively unlearning specific training examples without full retraining. Techniques include gradient ascent on the unlearned examples, influence-function-based weight updates, and knowledge-distillation approaches that preserve general capability while ablating specific facts. None of these is production-grade at frontier-model scale as of 2026; the field is roughly where adversarial robustness was in 2017. EU regulators have indicated they will revisit the Article 17 standard once unlearning matures, but providers are not currently expected to deploy techniques whose efficacy and side effects are not yet established.

The second is data poisoning as a defensive remedy. A data subject (or a controller acting on their behalf) introduces adversarial training data into the public web that statistically biases future models away from accurate memorization of the protected information. The technique exists, has been demonstrated in academic settings, and has been productized by tools like the University of Chicago's Glaze and Nightshade projects for protecting artist work. Data poisoning is not an Article 17 remedy in the legal sense — no DPA has endorsed it — but it is increasingly part of the practical toolkit when other remedies prove leaky. Several EU privacy counsel have advised clients to pair Article 17 requests with selective poisoning campaigns targeting the public-web sources most likely to be picked up by next-generation training corpora.

The combined approach is starting to be called layered erasure. The layers, from least to most aggressive: (1) source delisting from the public web, (2) retrieval-time suppression at the AI search provider, (3) output filtering at the AI search provider, (4) future-training exclusion, (5) targeted unlearning when available, (6) adversarial poisoning of remaining public-web sources, (7) full retraining as a last resort. Operators advising on Article 17 in 2026 should walk through the layers in order, document each step, and reserve the most aggressive layers for cases where the data subject has demonstrated material ongoing harm.

The 8-Step Operator Playbook for Article 17 Readiness

Most operators sit on both sides of the Article 17 question — as data subjects through their named founders and executives, and as data controllers through the content they publish. The playbook below is the working sequence used by EU privacy counsel advising mid-market SaaS, ecommerce, and B2B services companies as of May 2026.

1. Map your named-individual exposure. Inventory every page on your owned web properties that names a specific natural person — founders, executives, customers, employees, third parties named in case studies, journalists quoted in press releases. Tag each with the named individual, the legal basis for processing (consent, contract, legitimate interest), the publication date, and the AEO importance of the page. The output is a row-per-page register that becomes the working surface for every subsequent step.

2. Establish a written-consent layer for AEO-targeted content. Any page intended as an AEO citation magnet that features a named individual should be backed by written consent that covers training-data inclusion and AI search citation. The consent form should be specific to AEO, not buried in general marketing terms, and should be renewable. Several EU privacy counsel have suggested a five-year renewal cadence aligned with the typical employment-tenure horizon.

3. Build a 30-day takedown workflow. When a data subject submits an Article 17 request to you as controller, the GDPR gives you one month to respond. Your workflow needs to cover identity verification (typically government-issued ID plus a notarized statement for high-risk requests), an internal review against Article 17 exceptions (freedom of expression, public-interest archiving, legal claims), a takedown step that removes the page or redacts the named individual, a noindex directive applied to the page during transition, and a notice to relevant AI crawlers requesting recrawl. The workflow should be documented and stress-tested against a fake request annually.

4. Issue robots.txt and llms.txt updates on takedown. When a page is removed or substantially redacted as part of an Article 17 response, the most reliable signal to AI crawlers is an updated robots.txt or llms.txt directive paired with a sitemap update. Cloudflare, Akamai, and Fastly all support cache invalidation that propagates the takedown to edge caches within minutes. Document the cache invalidation step explicitly because it is the most frequently missed compliance failure in audited workflows. For deeper background on the crawler control layer, see our crawler permission economy and training-data monetization analysis.

5. Submit downstream Article 17(2) notifications. Article 17(2) requires the original controller to inform other controllers processing the data that erasure has been requested. In the AI search context, this means submitting parallel requests to OpenAI, Anthropic, Google, Microsoft, Perplexity, Mistral, and any other LLM provider that has likely scraped the relevant page. The submissions should reference the original page URL, the date of the takedown, and the identity of the data subject (with appropriate privacy protections in the inter-controller communication). Most providers respond within their stated 30-day window.

6. Audit AI search outputs for residual exposure. After 30 days, run a structured audit across ChatGPT, ChatGPT search, Claude, Perplexity, AI Overviews, Gemini, Copilot, Meta AI, and Le Chat using a battery of test prompts designed to elicit information about the named data subject. Document the residual citations and feed them back into the relevant provider intake as a follow-up complaint. The audit is also a useful internal AEO instrument independent of the compliance use case.

7. Layer in adversarial measures if needed. For data subjects who continue to suffer harm despite layered remedies, the next escalation is adversarial: a public-web counter-campaign that floods crawl-eligible surfaces with content correcting the LLM's misstatements, supplemented if necessary by selective use of data-poisoning techniques on sources unlikely to respond to Article 17 requests directly. This is not a routine step; it is for cases where the LLM is producing materially harmful misstatements about the data subject.

8. Pre-register your AEO content against future Article 17 risk. Before publishing any future named-individual content, run it through a pre-publication checklist: is the named individual a public figure or a private one (which affects the freedom-of-expression exception under Article 17(3)(a)), is the content time-bound or evergreen (evergreen content carries higher Article 17 exposure), can the named individual be replaced by a role title or an anonymized composite without losing AEO value. Many citation-magnet patterns work equally well with role titles ("Head of Growth at a 200-person SaaS company") as with named individuals, and the substitution materially reduces compliance exposure.

The playbook is iterative. The first round through the eight steps typically takes a mid-market operator 90 to 120 days; the steady-state cadence after that is one full audit per quarter plus a real-time intake workflow for new Article 17 requests.

Where AEO Strategy Splits Under Article 17 Pressure

The compliance load is not evenly distributed across AEO strategies. Some content patterns absorb Article 17 risk easily; others are structurally exposed.

The high-risk patterns are founder-led thought leadership where the founder's name is the AEO entity, customer case studies that name specific individuals, deal-announcement content that names buyers and sellers, biographical content about executives, and any "experts cited" content built around named third parties. Each of these depends on the named individual remaining a stable, citable entity in LLM training data and retrieval outputs; an Article 17 request from any of the named individuals collapses the AEO value of the underlying page.

The low-risk patterns are role-based content ("how a Head of Growth at a 200-person SaaS company runs a launch"), original-research content where the entity is the brand or the dataset rather than a named individual, schema-marked product and pricing content, comparison content that names competing products rather than individuals, and changelog and documentation content. Each of these maintains AEO value even if every named individual exercises Article 17 simultaneously.

The strategic reorientation that many EU-exposed operators are running in 2026 is to migrate AEO investment from high-risk to low-risk patterns at the margin, without abandoning founder-led content entirely. The migration is consistent with the broader regulatory trajectory: the EU AI Act first fines and enforcement decisions of 2026 are also pushing brands toward provable, auditable content; the AI search EU DSA compliance regime adds transparency requirements that mesh with GDPR documentation; and the broader privacy regulatory direction across the bloc reinforces low-risk pattern investment.

What Comes Next: The Cases to Watch

Three pending or imminent decisions will shape the Article 17 standard through 2027.

The first is the EDPB's promised follow-up to Opinion 28/2024, expected in late 2026, which is widely reported to address the specific question of whether retrieval-augmented AI search systems sit inside or outside the scope of the GDPR's training-data analysis. The current EDPB position treats retrieval and training as separate processing activities; the follow-up is expected to consolidate them or to issue distinct guidance for each.

The second is the French CNIL's expected ruling on the legal-basis question for AI training, which has been in formal investigation against at least two unnamed frontier-model providers since mid-2025. Politico EU has reported that the CNIL is preparing a finding that legitimate interest is an inadequate basis for training-data scraping when the data subject is not a public figure, which if upheld would force AI providers to obtain affirmative consent for training data that includes identifiable private individuals.

The third is the German Federal Administrative Court's pending review of the Hamburg DPA's discussion paper, which is expected to determine whether the Hamburg position can be invoked as a defense against Article 17 requests directed at model weights. A ruling in either direction will recalibrate the bargaining position between data subjects and AI providers across the EU.

For operators, the practical implication is that the Article 17 standard is unsettled and will remain unsettled through at least 2027. The right posture is to over-document, run the eight-step playbook quarterly, and design AEO content with replaceability built in. The cost of doing this is a modest reduction in the persuasive specificity of named-individual content; the cost of not doing it is a brittle citation surface that any motivated data subject can collapse.

Takeaway: Article 17 has collided with a technology that cannot meaningfully forget, and the EU's data protection authorities are settling — for now — on a layered remedy that combines output filtering, retrieval suppression, and future-training exclusion rather than the weight-level deletion the regulation literally requires. The Italian Garante is the enforcement floor, the French CNIL the documentation standard, the Hamburg DPA the doctrinal counterweight, and the EDPB the consolidating voice. For operators, the practical work is on the controller side: map your named-individual exposure, build a 30-day takedown workflow, refresh consent annually, and migrate citation-magnet content toward role-based and research-based patterns that survive single-subject Article 17 requests. The compliance load is real, but the AEO programs that absorb it will outlast the ones that do not.

Frequently Asked Questions

Does the GDPR right to be forgotten apply to ChatGPT and other LLMs?

Yes, but with a contested scope that European data protection authorities are still defining. Article 17 of the GDPR gives any EU data subject the right to demand erasure of personal data a controller holds, and the European Data Protection Board has confirmed in its December 2024 Opinion 28/2024 that LLM providers are controllers when they process personal data through training and inference. What is contested is whether memorized personal data inside model weights counts as personal data the controller still 'holds,' or whether it has been transformed into a statistical artifact outside the GDPR's reach. The Hamburg Commissioner for Data Protection took the second view in a July 2024 discussion paper. The Italian Garante, the French CNIL, and the EDPB itself have taken the first view. OpenAI, Anthropic, and Google all currently accept Article 17 requests through formal intake forms, regardless of the doctrinal debate.

How do I submit a right-to-be-forgotten request to OpenAI, Anthropic, or Google for AI search?

Each provider operates a distinct intake. OpenAI uses a personal data removal request form linked from its EU privacy notice that asks for identity verification, a description of the personal data, and the exact prompts that elicit the data. The default response is a 'we will not use your data for training' commitment plus an output filter that blocks the model from returning the named individual; full weight modification is not offered. Anthropic accepts requests through privacy@anthropic.com with a similar identity-verification step and a documented commitment to filter Claude outputs about the requester, again without weight modification. Google handles AI Overviews and Gemini erasure requests through its existing 'Right to be forgotten' web form, then applies retrieval-time suppression. None of the three currently retrain models on demand, and EU regulators have so far accepted output suppression as a partial remedy.

What did the Italian Garante actually fine OpenAI for in 2024?

Italy's Garante per la Protezione dei Dati Personali fined OpenAI EUR 15 million on December 20, 2024, after concluding that the company processed personal data to train ChatGPT without an adequate legal basis, failed to notify the authority of a March 2023 data breach affecting Italian users, and lacked an age-verification mechanism to keep users under 13 out of the product. The Garante also ordered OpenAI to run a six-month public information campaign across Italian media explaining how ChatGPT processes data and how users can exercise their GDPR rights. The fine was the second major intervention by the Garante against OpenAI, following the temporary March 2023 ban that briefly took ChatGPT offline in Italy. The 2024 ruling is the highest-profile GDPR enforcement against a generative AI provider to date and has become the template other DPAs are referencing.

Can a data subject force OpenAI or Anthropic to retrain a model to remove their personal data?

Not in current practice, and probably not in current law. No EU data protection authority has yet ordered a full retraining as a remedy under Article 17, partly because the cost would be disproportionate (typically USD 50-150 million per frontier-model run) and partly because the EDPB has accepted output-layer suppression as a reasonable measure when weight-level deletion is technically infeasible. The closer question is whether a controller can be ordered to perform machine-unlearning techniques that target specific training examples; the field is real, but no production-scale technique reliably erases memorized data without degrading the model. The current de facto standard is a layered remedy: removal from future training corpora, retrieval-time filters that suppress live citations, output classifiers that refuse to generate the named individual, and a documented log of compliance steps. EU regulators have indicated they will revisit the standard once unlearning techniques mature.

How does the right to be forgotten affect operators who want to be cited by AI search?

Operators sit on both sides of the Article 17 question. As data subjects, your founders, executives, and named employees can demand erasure of personal data from LLM training corpora and AI search outputs; as data controllers publishing content about customers, employees, and third parties, you can receive erasure requests yourself and become liable for re-publishing data after the original source has been delisted. The AEO consequence is that any content strategy that depends on persistent biographical detail (founder profiles, customer-story names, deal-announcement quotes) carries a latent compliance risk if the named individual later exercises Article 17. The operator response is to design citation-magnet content with replaceable name slots, written consent for AEO-targeted bios, and a documented takedown workflow that can suppress a page from AI crawlers within 30 days of a verified request.