GDPR Accuracy and LLM Hallucination: What Regulators Said

The short answer

When a large language model (LLM) produces a false statement about an identifiable person, European regulators treat that output as personal data that must satisfy the accuracy principle in Article 5(1)(d) of the General Data Protection Regulation (GDPR). The European Data Protection Board's (EDPB) ChatGPT Taskforce said so plainly in May 2024: the probabilistic nature of the system does not suspend the principle, and transparency notices that warn users about errors are "not sufficient to comply with the data accuracy principle" ^[1]. For an organization deploying LLMs, the practical consequence is that accuracy has to be designed and documented, and a person must be able to get a wrong statement about them corrected.

This article reads the legal text, the regulator statements and the two best-known complaints, then sets out controls that make the duty workable. It covers EU and UK law separately, and it is educational, not legal advice.

What Article 5(1)(d) says

Article 5(1)(d) GDPR requires personal data to be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay ('accuracy')" ^[2].

Four connected provisions turn the principle into obligations:

Sources for the table: Articles 5, 16, 18, 19 and 25. Infringements of the basic principles in Article 5 fall in the higher tier of administrative fines, up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher ^[2].

Three phrases in Article 5(1)(d) matter most for language models.

• "Having regard to the purposes." Accuracy is judged relative to why the data is processed. A dataset of historical news articles is not inaccurate because a person has since changed jobs. An assistant that answers "who is the CFO of X" is processing for a purpose that depends on currency.
• "Every reasonable step." The standard is reasonableness, not perfection. That leaves room for statistical systems, provided the steps taken are proportionate and documented.
• "Erased or rectified without delay." The remedy assumes the controller can locate and change the inaccurate data. For a fact stored in a database that is trivial. For a statement a model generates from its parameters, it is the hard part.

Accuracy and purpose: when "up to date" matters

The purpose test cuts both ways. If an LLM is used to draft fiction, its outputs are not presented as facts about real people, and the accuracy question is framed differently. If it is used in customer service, recruitment, credit, compliance screening or search, its statements about people are offered as facts and will be acted on.

The EDPB Taskforce made exactly this point about ChatGPT. It observed that "the purpose of the data processing is to train ChatGPT and not necessarily to provide factually accurate information", that the training approach "leads to a model which may also produce biased or made up outputs", and that outputs "are likely to be taken as factually accurate by end users, including information relating to individuals, regardless of their actual accuracy". Its conclusion: "In any case, the principle of data accuracy must be complied with" ^[1].

Input data and output data

The Taskforce distinguished two places where accuracy applies. Input data covers data collected, for instance, through web scraping, and the content users provide as prompts. Output data covers what the system returns ^[1]. The distinction is useful for any LLM deployment:

• Input accuracy is a data-quality question about what was collected and retrieved. It can be managed with ordinary data governance: source selection, deduplication, correction.
• Output accuracy is about what the model asserts. A model can produce a false statement about a person even when no false statement about that person existed anywhere in its inputs, by combining true fragments wrongly.

The Taskforce also recorded that, at the time, OpenAI suggested users shift "from rectification to erasure when rectification is not feasible due to the technical complexity of ChatGPT" ^[1], and it reminded the controller of its Article 25(1) duty to build in safeguards (para 35). The report describes its contents as preliminary views of an ongoing coordination between supervisory authorities, not a decision.

The EDPB's later Opinion 28/2024 (adopted 18 December 2024) addressed AI models more generally. It stated that AI models trained with personal data "cannot, in all cases, be considered anonymous", and that the assessment depends on whether personal data, which it describes as possibly "accurate or inaccurate (because statistically inferred)", can be extracted from the model directly or by querying it ^[3]. That matters for accuracy because it means personal data in a model's outputs, including wrong data, is not automatically outside the GDPR.

The noyb complaints: rectification requests a model cannot satisfy

Two complaints filed by the privacy organization noyb show how the principle meets practice.

Austria, April 2024. noyb filed a complaint with the Austrian data protection authority on behalf of a public figure whose date of birth ChatGPT repeatedly gave incorrectly "instead of telling users that it doesn't have the necessary data". According to noyb, OpenAI refused to rectify or erase the data, arguing that correction was not possible, said it could filter or block data on certain prompts only in a way that would filter all information about the complainant, and did not adequately answer the access request about the data, its sources and recipients. The complaint invoked Articles 5, 15 and 16 and asked the authority to investigate, order compliance with the access request and impose a fine ^[4].

Norway, March 2025. noyb filed a complaint with the Norwegian Datatilsynet after ChatGPT told a user that a Norwegian man had murdered two of his children and been sentenced to 21 years in prison. The fabricated story mixed in true details: the number and gender of his children and his home town. noyb reported that ChatGPT now searched the internet when asked about specific people, which stopped this output, but argued that the incorrect data "may still remain part of the LLM's dataset". It invoked Article 5(1)(d) and asked the authority to order deletion of the defamatory output, fine-tuning to eliminate inaccurate results, and a fine. noyb's position on disclaimers: "you can't bypass the legal obligation to ensure the accuracy of the personal data you process via a disclaimer" ^[5].

Neither complaint had a published decision when this article was checked on 28 October 2026: noyb's pages for both cases report no outcome, and no decision by the Austrian or Norwegian authority was found.

As of 28 October 2026 we found no published final decision in either case. They are complaints, which state one party's view; they show the questions authorities are being asked, not the answers.

The Norwegian case illustrates the most damaging pattern of hallucination about people: a fluent statement that is mostly true, with one false and serious element. A reader cannot tell which part is wrong, and the true details make the false one more credible.

The UK position: opinions, inferences and mistakes

The UK GDPR keeps the same accuracy principle. The Information Commissioner's Office (ICO) explains that the Data Protection Act 2018 defines "inaccurate" as "incorrect or misleading as to any matter of fact" ^[6]. Its guidance adds distinctions that are useful for model output:

• Opinions. "A record of an opinion is not necessarily inaccurate personal data just because the individual disagrees with it", but the record must make clear that it is an opinion and, where appropriate, whose.
• Mistakes. "It is acceptable to keep records of mistakes, provided those records are not misleading about the facts."
• Currency. Data used for a purpose that relies on it remaining current should be kept up to date.
• Challenges. Controllers must carefully consider challenges to accuracy.

The ICO's AI guidance separates two meanings of the word. Data protection accuracy is the legal duty above. Statistical accuracy "refers to how often an AI system guesses the correct answer, measured against correctly labelled test data". The ICO states that the principle "does not mean that an AI system needs to be 100% statistically accurate", but that controllers must account for incorrect inferences and their impact, and that records should indicate outputs "are statistically informed guesses rather than facts", note the provenance of the data and the system used, and be updated if an inference rests on inaccurate data ^[7]. The ICO recommends measuring precision and recall rather than overall accuracy, and documenting retraining thresholds for concept drift.

Both ICO pages state that the guidance is under review following the Data (Use and Access) Act. UK readers should check current wording.

A worked example: one false statement, two architectures

The following case is fictional. Halden Therapeutics AG is a fictional company, and Dr Lena Brandt is a fictional person.

A compliance assistant at a fictional supplier is asked: "Who leads clinical operations at Halden Therapeutics AG, and has she been subject to any regulatory action?" It answers: "Dr Lena Brandt, Head of Clinical Operations since 2023. In 2021 she was named in an FDA warning letter for data integrity failures at a previous employer." The first sentence is true. The second is false: the 2021 warning letter named a different site, and Dr Brandt was not mentioned.

Dr Brandt submits a rectification request under Article 16. Compare how two architectures can respond.

The point is not that one architecture is lawful and the other unlawful. It is that rectification "without delay" presupposes that the controller can find the inaccurate data and change it. Where a statement about a person is drawn from an identifiable record and cited, that presupposition holds. Where it is produced from the model's parameters, the controller has to rely on filters and retraining and must be able to explain why those steps are reasonable.

Controls that help

None of the following is a statutory list. They are measures that map to the provisions above.

1. Classify person-related use cases by purpose. Identify where outputs about identifiable people are presented as fact (screening, due diligence, HR, customer service) and treat those as accuracy-critical.
2. Ground factual statements about people in retrievable records. Retrieve from a governed source and cite it at the level of the claim; see the site's note on testing LLM citations claim by claim.
3. Prefer abstention to invention. Where no source supports a statement about a person, the answer should say so. The Austrian complaint turned on a system giving a wrong date "instead of telling users that it doesn't have the necessary data". The site's method on declaring unknowns treats "not found" as an explicit value rather than a blank.
4. Label inferences. Where an output is an inference or estimate, say so in the record and the interface, as the ICO recommends.
5. Log outputs about people. Without a record of what was said to whom, Article 19 notification and Article 15 access requests cannot be answered.
6. Build a correction path. Define how a rectification request reaches the record, the retrieval index and any cached answers, and how long each takes.
7. Measure. Track error rates on person-related questions with precision and recall, and set thresholds for intervention.
8. Document. Keep the purpose analysis, the evaluation results, the correction log and the reasons for the measures chosen, to meet Article 5(2).

Documentation to keep

An accountability file for an LLM system that produces statements about people would typically contain: the purpose and the reasons accuracy matters for it; the sources the system is allowed to draw on; evaluation results on person-related questions, with dates and versions; the rectification and restriction procedure and its log; output logs or a justification for not keeping them; and the record of each challenge and how it was resolved. The hallucination glossary entry gives the terminology.

Limits

This article summarizes EU and UK texts and regulator statements as of 28 October 2026. The EDPB Taskforce report records preliminary views; the noyb documents are complaints; the ICO guidance is under review. National supervisory authorities decide cases individually. Nothing here is legal advice.

A record that keeps a cited, verbatim, dated source behind every value, and declares unknowns instead of leaving blanks, is one way to make statements about people correctable; that is the design Reliable Context describes in its published guarantees.