Rectifying AI-Hallucinated Personal Data Under GDPR

A model says a named person was convicted of a crime they did not commit, or gives the wrong date of birth, or attributes a quotation to somebody who never said it. The data subject asks for it to be corrected. Article 16 is short and clear; applying it to a system with no record to edit is neither.

What Article 16 actually gives

Article 16 of Regulation (EU) 2016/679 gives the data subject the right to obtain from the controller, without undue delay, the rectification of inaccurate personal data concerning them, and — taking account of the purposes of the processing — the right to have incomplete personal data completed, including by means of a supplementary statement.

Two details in that sentence are usually skipped and both matter here. First, the remedy is not limited to editing a value: a supplementary statement is expressly contemplated, which is the doctrinal hook for everything controllers currently do in this area. Second, Article 19 requires the controller to communicate any rectification to each recipient to whom the data was disclosed, unless that proves impossible or involves disproportionate effort — a duty that is straightforward for a customer database and strange for an output delivered once to one user.

Accuracy is judged against the purpose

Article 5(1)(d) requires personal data to be accurate and, where necessary, kept up to date, with every reasonable step taken to ensure that inaccurate data is erased or rectified without delay having regard to the purposes for which it is processed. That qualifier is doing real work, and it is the strongest argument available to a model provider.

The Court of Justice made the point in a different setting in Case C-434/16, Nowak, decided 20 December 2017 and available from the Court’s case register: a candidate’s exam script and the examiner’s comments are personal data, but accuracy is assessed against the purpose — the record accurately records what the candidate wrote, and the right to rectification does not entitle a candidate to change their answers after the fact.

Applied here, the argument runs: the purpose of a generative output is to produce a plausible continuation, not to assert a fact about a person, and the log accurately records what the model produced. The counter-argument is that the purpose of a general-purpose assistant that users treat as an information source is, in substance, to inform, and that a controller cannot define its way out of the accuracy principle by characterising its own output as fiction while marketing it as useful. Neither argument has been resolved by a court.

What has actually been filed and decided

Italy — Garante

The Italian data protection authority ordered a temporary limitation on OpenAI’s processing of Italian users’ data on 30 March 2023, citing among other things the absence of a suitable legal basis for training and the inaccuracy of information the service produced about individuals. The service resumed at the end of April 2023 after changes. In December 2024 the Garante concluded the underlying proceeding with a fine of EUR 15 million and an order to run an information campaign, again including findings on legal basis and transparency; OpenAI stated publicly that it would appeal. Provisions are published by the Garante per la protezione dei dati personali. An appealed administrative decision is not a final determination of the law, and the Garante’s findings were broader than the accuracy point.

Austria and Norway — noyb complaints

On 29 April 2024 the Austrian NGO noyb filed a complaint with the Austrian data protection authority on behalf of a complainant whose date of birth ChatGPT stated incorrectly, arguing breaches of the accuracy principle in Article 5(1)(d) and of Article 16, and noting that OpenAI had said it could not correct the output but only block the name. In March 2025 noyb filed a further complaint with the Norwegian Datatilsynet concerning output that falsely described a complainant as having been convicted of killing his children. The complaints themselves are published by noyb — cited here as the primary record of what was filed, not as authority for what the law means.

The important thing about this list is what is missing from it: a decision, from any authority or court, holding what Article 16 requires a model provider to do. That is why this page is dated and why it does not predict an outcome. Enforcement outcomes across the area are collected on notable GDPR AI fines.

The two positions on what rectification means

The narrow position. The obligation attaches to personal data the controller processes in a retrievable form. The controller must correct the record — the stored conversation, the cached answer, the retrieval index entry — and must take reasonable steps to stop the false statement recurring, for example by filtering the output or grounding the answer. It cannot be required to alter the weights, because there is no operation that identifies the contribution of one fact to a parameter, and Article 16 does not oblige the impossible.

The wide position. If the system reliably reproduces a false statement about a person on request, the system is processing inaccurate personal data about them each time, and “we cannot edit it” is a description of the controller’s design choice rather than a defence. On this view a controller that cannot rectify must either prevent the output or stop the processing, and the impossibility argument reduces to an admission that the processing cannot be brought into compliance.

Both positions have serious support and neither has been adopted authoritatively. What tilts the argument is likely to be how the prior question in whether the weights themselves hold personal data resolves: if they do not, the wide position has to be reframed as being about the output rather than the model, which narrows the remedy considerably.

What a controller can do today

• Correct everything retrievable, immediately. Stored conversations, caches, retrieval corpora, evaluation sets. This part is not controversial and failing it is the easiest finding to make against you.
• Use the supplementary statement route. Article 16 expressly contemplates it, and it is the only remedy in the text that fits a system which cannot delete a belief.
• Suppress at the output layer, and be candid that it is suppression. Refusing to answer about a named individual is a real mitigation and it is not rectification; describing it as rectification is the kind of overstatement that turns a defensible response into a misleading one.
• Ground answers about people in a retrievable source where the product makes factual claims about individuals, so that correcting the source corrects the system.
• Say what the system is, in the interface. A clear statement that outputs may be inaccurate about people goes to the purpose against which accuracy is judged under Article 5(1)(d), and it is worth having in place before an authority asks what users were told.
• Record the request and your reasoning. Article 12(4) requires you to tell the data subject, without delay and within one month, if you are not acting on the request, and why, and to inform them of their right to complain and to a judicial remedy. A refusal without that notice is a separate breach from the refusal itself.

What would settle it

A reasoned decision by a supervisory authority on the Article 16 point specifically — rather than on legal basis or transparency, where the decisions so far have concentrated — followed by an appeal to a national court and, in all likelihood, a reference to the Court of Justice. The questions a reference would need to answer are whether model parameters constitute personal data relating to an identifiable person, whether a generative output is subject to the accuracy principle having regard to the purpose of the processing, and whether output filtering satisfies Article 16 or only mitigates a continuing breach. Until then, a controller has to act on the retrievable data, mitigate the output, and document the position it takes on the rest.