EU / European Union / revised 6 Nov 2026

GDPR Article 9 and LLMs: Special Category Data in Prompts and Outputs

Article 9 GDPR prohibits processing health, religious, political, trade union, genetic, biometric and sex life data unless one of its listed conditions applies, and LLM prompts reach those categories far more often than product teams expect. The Court of Justice has held that data which indirectly reveals a sensitive trait is covered, so a prompt, and whatever a model infers from it, can bring an ordinary feature under Article 9 and the DPIA duty in Article 35(3)(b).

Test a sovereign route Talk to a sovereign architect

Citation: Regulation (EU) 2016/679, Articles 9, 22(4), 35(3)(b) and 83(5)(a); Regulation (EU) 2024/1689, Article 10(5)
Regulator: National supervisory authorities, coordinated by the European Data Protection Board
In force: 25 May 2018
Maximum penalty: Up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher (Art. 83(5)(a), which covers infringements of Article 9)

Statutory text

Article 9(1): the categories and the prohibition

Article 9(1) prohibits processing personal data that reveals racial or ethnic origin, political opinions, religious or philosophical beliefs or trade union membership, and processing genetic data, biometric data used to uniquely identify a natural person, data concerning health, and data concerning a person's sex life or sexual orientation. The prohibition sits on top of Article 6: a controller needs both a lawful basis and an Article 9(2) condition. Data about criminal convictions and offences is handled separately under Article 10.

Racial or ethnic origin
Political opinions
Religious or philosophical beliefs
Trade union membership
Genetic data, as defined in Article 4(13)
Biometric data processed to uniquely identify a natural person, as defined in Article 4(14)
Data concerning health, including the provision of health care services, as defined in Article 4(15)
Data concerning a natural person's sex life or sexual orientation

Article 9(2): the conditions AI use cases actually rely on

Article 9(2) sets out ten conditions, labelled (a) to (j). Only a handful fit commercial AI features, and several depend on Union or Member State law. Article 9(4) also lets Member States keep or add conditions for genetic, biometric and health data, which is why the same assistant can be lawful in one Member State and need a different design in another.

(a) explicit consent for one or more specified purposes, which is hard to rely on where there is an imbalance of power, such as between employer and employee
(b) obligations and rights in employment, social security and social protection law, as authorised by law with appropriate safeguards
(c) vital interests, where the data subject is physically or legally unable to give consent
(e) data the data subject has manifestly made public
(f) the establishment, exercise or defence of legal claims
(g) substantial public interest on the basis of Union or Member State law
(h) preventive or occupational medicine, medical diagnosis and health or social care, under the professional secrecy safeguard in Article 9(3)
(i) public health, and (j) archiving, scientific or historical research and statistics under Article 89(1)

Inference: when a prompt reveals more than it says

In Case C-184/20 (1 August 2022) the Court of Justice held that publishing the name of a person's spouse or partner was processing of special category data, because it could indirectly reveal sexual orientation. In Case C-252/21 Meta Platforms v Bundeskartellamt (4 July 2023) it applied Article 9 to data about visits to apps and websites that reveal sensitive information. In Case C-21/23 Lindenapotheke (4 October 2024) it held that details entered when ordering pharmacy-only, non-prescription medicines online are health data, even though it is only probable, not certain, that the medicine is for the buyer.

For language models the consequence is direct. A prompt asking for help wording a leave request after a miscarriage, a support transcript that mentions a hearing aid, or an HR assistant summarising a grievance raised through the union all carry special category data, whether or not any structured field says so. Outputs can create it too: a model that tags a customer message as showing signs of depression has generated health data about that customer, and the controller is processing it from that moment.

Article 35(3)(b), Article 22(4) and the AI Act

Article 35(3)(b) makes a DPIA mandatory for processing on a large scale of special categories under Article 9(1) or of criminal offence data under Article 10. The DPIA guidelines endorsed by the EDPB (WP248 rev.01) add that processing meeting two or more of their criteria, such as sensitive data and innovative use of new technology, will usually need one, and many national lists adopted under Article 35(4) name AI-based processing. Article 22(4) bars solely automated decisions with legal or similarly significant effects based on special categories unless Article 9(2)(a) or (g) applies and suitable safeguards are in place.

The EU AI Act adds one narrow permission. Article 10(5) of Regulation (EU) 2024/1689 allows providers of high-risk AI systems to process special categories exceptionally, to the extent strictly necessary for bias detection and correction, subject to safeguards that include pseudonymisation, strict access controls and deletion once the bias has been corrected. It is not a general licence to put special category data into prompts.

Technical requirements for the inference path

01
Detect categories, not only identifiers
Identifier detectors catch names, IBANs and national ID numbers. Article 9 also needs topic detection: diagnoses, medication names, religious observance, union activity, sexual orientation and political affiliation. Run both in-path in the origin data plane, so classification happens before any routing decision is made.
02
Pseudonymise the person, keep the condition
A drafting or triage task often needs the clinical or religious context to be useful. Replace the identity with a token from a local vault instead of stripping the context. The result is pseudonymised, not anonymous, so it remains personal data under Recital 26, but the downstream model never learns who it concerns.
03
Classify completions as well as prompts
Run the same classifier on the model's output. When a completion introduces a special category that the prompt did not carry, mark the receipt and the downstream record, because the controller now holds inferred special category data and its retention and access rules apply.
04
Bind each use case to its Article 9(2) condition
Store the condition, such as 9(2)(h) for a clinical documentation assistant or 9(2)(b) for an occupational health workflow, against the use case identifier the application sends. A request carrying special category data under a use case with no recorded condition is refused rather than quietly processed.
05
No residue at the provider
Abuse-monitoring logs at hosted providers can hold prompt content for a period. For special category traffic, require a zero-retention configuration or a self-hosted runtime, so the only copies of the data are the ones your own systems keep.

Prescribed YTT Secunet routing rules

#	Rule	Legal rationale
01	When any Article 9(1) category is detected, resolve only to endpoints approved for special category data: self-hosted runtimes in the tenant's jurisdiction, or in-jurisdiction endpoints with zero data retention.	Special category data carries the highest risk of harm and the strictest conditions, so it should reach as few parties as possible.
02	Refuse special category requests whose use case has no recorded Article 9(2) condition.	Article 9(1) is a prohibition; processing without a condition is unlawful however the data arrived.
03	Pseudonymise direct identifiers before forwarding any special category prompt.	Data minimisation under Article 5(1)(c) and data protection by design under Article 25; the task rarely needs the name to be useful.
04	Never use a cross-border fallback for special category traffic; fail closed when no approved in-jurisdiction endpoint is healthy.	An unplanned transfer of health or biometric data during an incident is exactly the outcome a DPIA is meant to prevent.
05	Tag receipts with the detected categories and whether they arose in the prompt or the completion.	The DPIA and the Article 30 record need to show where special category data arose, including by inference.

Policy pack excerpt

eu-gdpr-art9

The rules above, written as Open Policy Agent Rego (v1 syntax). The gateway evaluates the pack in-process in every regional data plane before forwarding a request; YTT Secunet measures median evaluation under 3 ms in production.

Packs are versioned and signed. The version that decided each request is named in the residency receipt, so an auditor can match the decision to this exact text.

How the policy engine works

regoeu-gdpr-art9.rego

package yttsecunet.policies.eu_gdpr_art9

import rego.v1

art9_categories := {"racial_ethnic_origin", "political_opinion", "religious_belief", "trade_union", "genetic", "biometric_id", "health", "sex_life_orientation"}

detected contains c if {
	some c in input.request.detected_categories
	c in art9_categories
}

special if count(detected) > 0

deny contains "no Article 9(2) condition recorded for this use case" if {
	special
	not data.tenants[input.tenant.id].art9_conditions[input.request.use_case]
}

deny contains "endpoint not approved for special category data" if {
	special
	not input.endpoint.special_category_approved
}

deny contains "direct identifiers must be pseudonymised first" if {
	special
	input.request.unmasked_identifiers > 0
}

deny contains "special category data cannot fail over across jurisdictions" if {
	special
	input.endpoint.jurisdiction != input.tenant.jurisdiction
}

default allow := false

allow if count(deny) == 0

Audit checklist

Each item is verifiable against configuration, signed receipts or contract records. Tick through it with your DPO.

01Every AI use case has been assessed for Article 9(1) categories in prompts, retrieved context and outputs, with the result recorded.
02Each use case that can carry special category data has a documented Article 9(2) condition and, where relevant, the Member State law it relies on.
03A DPIA exists for every use case processing special category data on a large scale (Art. 35(3)(b)) or meeting two or more WP248 criteria.
04The category classifier has been tested on representative prompts in each working language, with detection rates recorded.
05Direct identifiers are pseudonymised before special category prompts leave the data plane, with the vault held in the origin jurisdiction.
06Endpoints approved for special category data are self-hosted or run with zero data retention, confirmed in configuration and contract.
07Inferred special category data in outputs is flagged and subject to the same retention and access rules as collected data.
08No solely automated decision with significant effects relies on special category data without Article 9(2)(a) or (g) and the Article 22(4) safeguards.

GDPR Article 9 special category data: frequently asked questions

Is a symptom typed into a support chatbot health data?

Usually, yes. Data concerning health covers information that reveals a person's physical or mental health status, and Lindenapotheke confirms that probability rather than certainty is enough. If the chat can be linked to the user, it is special category data.

Does pseudonymisation take data out of Article 9?

No. Pseudonymised data remains personal data for anyone able to re-identify it, and the sensitive nature of the content does not change. Pseudonymisation lowers the risk and supports the DPIA; it does not remove the need for an Article 9(2) condition.

Can employees consent to an HR assistant processing their health data?

Rarely in a way that holds. The EDPB's consent guidelines point out that the imbalance of power in employment makes freely given consent difficult. Employment-related processing usually relies on Article 9(2)(b) and the national law that gives effect to it.

Does YTT Secunet decide which Article 9(2) condition applies?

No. YTT Secunet does not give legal advice and does not replace your DPIA. Your DPO records the condition for each use case; the policy engine enforces that one exists, detects the categories, and records what happened on every request.

Sovereign route ready

Stop risking 4% global turnover GDPR fines on AI inference.

Deploy sovereign, cryptographically proven AI routing in 15 minutes.

Schedule an architecture demo Start 14-day trial