run.veric.dev
AI vertical · DP preview
For AI Provenance

OpenAI memory + GDPR Art. 17 erasure conflict — open question, 2024 onward

Status: anticipated enforcement / unresolved doctrinal question · Indicative cost ceiling: GDPR Art. 83 max — €20M or 4% worldwide turnover per finding · Time-to-detect: noyb complaint filed Apr 29, 2024; further complaints filed through 2025 · Root cause class: T7 (erasure-completeness — Art. 17 right to erasure against an artifact whose internal structure cannot enumerate per-subject contributions)

What happened

This entry frames an unresolved doctrinal question rather than a closed enforcement action — the "anticipated" register noted in the AI-provenance plan. The public record shows the following:

In 2024 OpenAI introduced the "Memory" feature, which allows ChatGPT to retain user-supplied facts across conversations. Independently, OpenAI's underlying foundation models are periodically fine-tuned on conversation data from users who have not opted out of model improvement (the consumer-surface default since the Italian DPA settlement, with explicit opt-out per Apr 2023).

On April 29, 2024 the privacy advocacy group noyb (None Of Your Business, founded by Max Schrems) filed a complaint with the Austrian DPA against OpenAI on behalf of an unnamed European data subject. The complaint pleaded that ChatGPT generated factually incorrect personal data about the complainant (incorrect birthdate), that OpenAI refused or could not rectify the incorrect data under GDPR Art. 16, and that OpenAI told the complainant rectification or erasure of personal data baked into model weights was not technically possible.

This is the doctrinal collision point: GDPR Art. 17 grants the right to erasure of personal data without undue delay; Art. 16 grants the right to rectification of inaccurate personal data. Both rights presume the controller can identify, locate, and act on the records corresponding to a single data subject. A foundation-model artifact has no such structure — personal data ingested in training is mixed across billions of weight updates and cannot be isolated, surgically removed, or surgically corrected. The technical answer "we cannot do that" collides with the legal answer "you must do that, on request, without undue delay."

EDPB Opinion 28/2024 (Dec 18, 2024) addressed the question. Section 3.3 holds that whether a model is "anonymised" — and therefore outside GDPR's reach — must be assessed case-by-case; mere training-set obfuscation does not by itself anonymise. Where unlawfully processed data contaminated the development phase, the contamination flows to the deployment phase unless the model is genuinely anonymised. As of 2026, multiple DPAs (Austrian DPA on the noyb complaint; French CNIL; Polish UODO) have open files on related rectification/erasure questions. None has issued a final binding decision yet.

The pattern

A foundation-model artifact incorporates personal data from training records. The artifact cannot, by its architecture, enumerate per-subject contributions. EU regulators may compel erasure under Art. 17 on demand. The controller has no compile-time or runtime contract that lets them attest "for data subject X, the model's output is invariant to the inclusion or exclusion of X's training records" — which would be the substantive test of erasure.

The pattern is not specific to OpenAI. Any foundation-model provider that ingests personal data into training has the same exposure. The product surface ("Memory") is incidental — it makes the conflict visible to a single user, but the doctrinal question is about the underlying weights. This is the substrate gap the P7 erasure-completeness primitive is meant to close.

Which tier failed (anticipated)

T7 erasure-completeness — and this is the canonical T7 case at the foundation-model scale. The conflict is precisely that GDPR encodes a property the standard model architecture does not preserve. Either (a) the architecture changes to preserve per-subject erasure (differential privacy bounds, retrieval-augmented generation with externalised personal-data stores, machine-unlearning research moves into production), or (b) the law accepts cryptographic / probabilistic attestations as sufficient, or (c) every Art. 17 request triggers retraining.

What an AG-tower-driven control would have done

This is the case where the "anticipated" framing is honest. AG-tower today does not solve foundation-model unlearning — that is a substrate gap, documented in the P7 erasure-completeness substrate doc. What AG-tower does provide is the contract surface: a Stub refutation in the model-card build that says "Art. 17 erasure pathway: P7 substrate gap — see kernel/silver-l8 audit." That refutation is itself the honest disclosure regulators are asking for. A model card that attests Art. 17 compliance when the underlying substrate cannot demonstrate it is the deceptive surface; a model card that refutes the contract and points to the substrate gap is the auditable one.

When a real P7 implementation lands — whether via DP-trained models, RAG-with-externalised-PII architectures, or a verified machine-unlearning pathway — the same model-card slot flips from Stub to Proof. The contract surface does not change; the substrate underneath it does.

See also

Sources

See the AI-provenance tag glossaryT7 · Range / interval in the canonical glossary

Each refutation in this archive is a SARIF artifact a regulator could replay tomorrow — the same artifact format the SQL-vertical playground emits today, with the AI-provenance tag glossary swapped in.

These write-ups are journalism + product framing; they are not legal advice. Regulatory citations are best-effort references to public documents at time of writing. For anticipated cases, the entry labels the framing explicitly as anticipated rather than closed.