AI agents in healthcare: handling sensitive health data under GDPR and the EHDS

What is a healthcare AI agent, and what data does it touch?

An AI agent in healthcare or the life sciences runs into sensitive health data sooner or later: a patient record attached to an email, a clinical report inside a complaint, a scanned prescription in a quality file. It has to be settled before production.

A healthcare AI agent is a system built on a large language model that carries out tasks for a pharmaceutical company, a medical device maker or a care provider: it reads documents, queries tools and drafts answers. Its legal framework depends on the data it sees and the purpose it is given.

As of 28 October 2026, several regimes overlap for such an agent in the EU: Article 9 of the GDPR, national hosting rules such as France’s HDS certification, data protection authority guidance on pseudonymisation and AI, the AI Act as amended by the Digital Omnibus, and the European Health Data Space (EHDS). At Koneetiv, the 100% Claude consultancy and official Anthropic partner, this is the grid we use at scoping to decide where an agent may touch health data and where it has to stop. Sector use cases are on our page on AI agents for healthcare and life sciences.

What does the GDPR say about health data?

A broad definition, assessed case by case

The GDPR defines data concerning health as personal data on a person’s past, present or future physical or mental health that reveal information about their health status (Article 4(15) and Recital 35). France’s supervisory authority, the CNIL, sorts it into three families: health data by nature (medical history, test results, treatments), data that become health data once combined with other data, and data that become health data through their medical use.

For an agent, the combination family is the trap. An order history for orthopaedic products, matched with a name and an address, can be enough to reveal a health condition. An agent that assembles context from several sources creates exactly this kind of combination, without anyone having decided it at design time.

Prohibited by default, with narrow exceptions

Article 9 lists health data among the special categories: processing is prohibited unless one of the exceptions in Article 9(2) applies. They include the person’s explicit consent, preventive medicine, medical diagnosis and the provision of health care (point h), public interest in the area of public health (point i) and scientific research (point j). A lawful basis under Article 6 is required on top.

A data protection impact assessment (DPIA) is the norm for health data. Article 35 requires one for large-scale processing of special categories, and the CNIL states that most health data processing needs one. For an agent, the DPIA has to describe what it actually does: the sources it queries, the data sent to the model, what it keeps in its logs, who reviews its outputs before they go out.

Does an AI agent need certified health data hosting?

France’s HDS certification rule

The GDPR does not require a hosting certification. France does: under Article L1111-8 of its Public Health Code, anyone hosting personal health data collected during prevention, diagnosis, care or social and medico-social follow-up, on behalf of those who produced or collected it or on behalf of the patient, must be certified as a health data host (HDS). France’s digital health agency (ANS) notes that a healthcare facility running its own information system does not need the certification.

There are two certificates, physical infrastructure host and managed services host (virtual infrastructure, application platform, operations, offsite backup), issued for three years by a Cofrac-accredited body. The same article prohibits any transfer of identifying health data for payment, directly or indirectly, even with the person’s consent. If you serve French patients or care providers, this is the rule your architecture has to meet.

The current framework: version 2.0, with 2.1 announced

The certification framework in force is version 2.0, approved by a French ministerial order of 26 April 2024. Hosts that were already certified had until 16 May 2026 to comply. It tightens the requirements on data transfers outside the European Union.

The ANS has announced a version 2.1, planned for October 2026 and not published as of 28 October 2026, applicable three months after publication. Contracts will have to state whether the host is subject to a non-EU law that could force a transfer, and describe any transfers that take place. The ANS specifies that remote access counts as a transfer, which matters for any support team reaching the data from outside the European Economic Area.

Decree no. 2026-209 of 24 March 2026, published in the Official Journal on 26 March 2026, has already tightened the hosting rules: health data must be stored in the European Union or the European Economic Area, and remote access from a third country is treated as a transfer, allowed only under the GDPR conditions (an adequacy decision or appropriate safeguards). The host must also tell its clients what it does about the risk of transfer or unauthorised access by third-country authorities. For an agent, this means checking where the data is stored and from which countries the provider’s teams reach it.

What this means for an agent’s architecture

An agent is a chain: the orchestration app, the model called through an API, the document store it queries, the logs, the conversation history, sometimes a cache. Every link that stores health data on your behalf raises the hosting question. The answer is settled link by link, with your DPO and legal counsel.

On the model side, we assume nothing about any provider’s commitments. The questions to put to it in writing, Anthropic included, stay the same:

• which region processes requests, depending on the access channel (direct API or a third-party cloud);
• whether requests and outputs are retained, for how long, and whether your contract offers a no-retention option;
• which components of the chain hold a health data hosting certification, and for which activities;
• who at the provider and its subprocessors can access the data, and from which countries;
• whether the provider is subject to a non-EU law that could require a transfer.

Where may the agent touch health data, and where must it stop?

The boundary is drawn at scoping, in writing, before the first line of code. We split it into zones, on the model of the trust zones we use to classify AI agents in LOOP™.

No health data: where to start

Regulatory documentation, quality management, technical support on a product, scientific monitoring: much of the work in a pharmaceutical or medical device company needs no personal health data at all. A first agent in this scope sets up architecture and governance without opening the hosting question. That still has to be guaranteed technically, with an input filter that strips attachments and sensitive fields before they reach the model.

Pseudonymised data: lower risk, same rules

Pseudonymisation replaces direct identifiers with a code, with the mapping kept separately and protected (GDPR Article 4(5)). Recital 26 is explicit: pseudonymised data that additional information can link back to a person remain personal data. For the controller holding the mapping table, pseudonymised health data remain health data. The Court of Justice of the EU qualified this on 4 September 2025 (case C-413/23 P): for a recipient with no reasonable means of re-identifying people, pseudonymised data may not be personal data. The ruling concerns Regulation 2018/1725, which applies to EU institutions, and leaves the obligations of the company holding the key intact.

Pseudonymisation is still worth building in. The agent works on the coded record, the mapping table lives in another system the agent cannot reach, and re-identification, when needed, happens on the human side in the business application. The agent’s logs then hold only codes, which shrinks the exposure if an incident occurs.

Off limits: medical purpose and decisions about people

Software that its manufacturer intends for diagnosis, prevention, monitoring or treatment can be a medical device under Regulation (EU) 2017/745. An agent that suggests a diagnosis, recommends a treatment or triages patients therefore enters another regulatory world, with CE marking and often a notified body.

Our position is to keep these uses out of a general-purpose agent, unless the project is run as a medical device with the regulatory team that requires. The same caution applies to decisions that affect a person based on their health: insurance pricing, access to a benefit, priority of care. In the LOOP™ grid, these actions sit in the red or black zone: the agent prepares, an authorised person decides and signs.

How does the AI Act fit with healthcare rules?

The AI Act (Regulation (EU) 2024/1689) applies alongside the GDPR and health law. Its timeline has moved: the Digital Omnibus on AI, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July, pushed back the high-risk obligations. The full set of deadlines is on our AI Act compliance page.

An agent that is a medical device: high-risk from 2 August 2028

An AI system that is a medical device, or a safety component of one, and that goes through a notified body is classified as high-risk by Article 6(1) and Annex I. That annex covers, among others, the regulations on medical devices (2017/745) and in vitro diagnostic medical devices (2017/746). Since the Omnibus, high-risk requirements apply to these systems from 2 August 2028. Both regulations stay in Section A of Annex I, and the Omnibus adds an equivalence mechanism (new Article 2(13)): some AI Act requirements may be limited where the sectoral legislation provides an equivalent or higher level of protection, under delegated acts the Commission must adopt by 2 August 2027.

Annex III use cases that touch health: 2 December 2027

Annex III lists high-risk uses independent of any product, and several concern health: public authorities assessing eligibility for public assistance benefits and services, including healthcare (point 5(a)), risk assessment and pricing in life and health insurance (point 5(c)), and the classification of emergency calls and emergency healthcare patient triage (point 5(d)). For these systems the deadline is now 2 December 2027.

The Article 50 transparency obligations have applied since 2 August 2026: an agent designed to interact directly with people must let them know they are dealing with an AI, unless that is obvious. For an internal documentation or support agent, the AI Act weighs little, and the GDPR does most of the work.

What does the European Health Data Space (EHDS) change?

Adopted, with obligations phased in until 2031

Regulation (EU) 2025/327 on the European Health Data Space was adopted on 11 February 2025 and published in the Official Journal on 5 March 2025. It applies from 26 March 2027, and its heaviest parts arrive later.

For primary use, meaning data exchanged to treat patients, the priority categories come in two waves: patient summaries, ePrescriptions and eDispensations from 26 March 2029, then medical imaging, test results and discharge reports from 26 March 2031.

Secondary use opens up AI training, under a permit

Chapter IV, applicable from 26 March 2029, governs the secondary use of health data. Among the permitted purposes, Article 53 names the training, testing and evaluation of algorithms, including AI systems and medical devices, as part of health-related scientific research. Access requires a data permit from a health data access body, and Article 54 prohibits using the data to take decisions detrimental to a person or to exclude them from an insurance or credit contract.

For a company deploying an agent in 2026, the EHDS changes little before 2029. It does set a direction: more structured health data, more widely exchanged, with tightly controlled secondary use. An architecture that already records who sees which data, and for what purpose, will not need rebuilding.

What role do data protection authorities play?

Each Member State’s data protection authority enforces the GDPR, and in health its role goes beyond enforcement. France’s CNIL is a good example: it publishes reference methodologies (MR-001 and following) that simplify formalities for health research, handles authorisation requests where no simplified framework applies, and gave a favourable opinion on the revised HDS framework on 13 July 2023.

On AI, its recommendations finalised on 22 July 2025 guide the analysis of whether a model falls under the GDPR, and list filters at the level of the system wrapping the model among the ways to avoid processing personal data. On 5 March 2026 it published a guidance sheet, “AI and health: developing and evaluating AI systems in compliance with the regulations”, covering the creation of a health data warehouse for future research, the creation of a health dataset to develop an AI system and the evaluation of the impact of its deployment, with the prior formalities.

The same day, together with France’s health authority (HAS), which co-leads the project, it opened a consultation on an “AI in care settings” guide, which closed on 16 April 2026. The sheet leaves deployment itself aside. For healthcare facilities and professionals, the draft HAS-CNIL guide, in the version put out for consultation, covers deployment in care settings; other companies deploying an agent stay with the general rules of DPIA, records and data minimisation. For an agent project, prepare the dialogue with your authority upfront: the DPIA, the record of processing and the agent’s documentation are what let you answer an inspection.

What does a well-scoped healthcare agent look like?

A regulatory affairs and quality team at a healthcare manufacturer gives an agent the job of monitoring scientific and regulatory literature: it scans publications, guidance from health authorities and changes to standards, flags what affects the company’s products and drafts a sourced summary that the team reviews before circulating it. That is the kind of use described on our page on the AI agent for regulatory monitoring.

On public sources, the agent should see no personal health data. It appears when the scope widens: a publication describing a clinical case in detail, or a request to cross-check the monitoring with internal complaints and incident reports, which may describe an event involving a patient. Scoping sets the rule before that happens. An upstream filter admits only public sources, internal extracts arrive pseudonymised, and any summary that links a signal to an identifiable patient leaves the automated path for the LOOP™ red zone, where a person decides. Other summaries go through the orange zone, one step more cautious than in standard regulatory monitoring because a clinical publication can always carry an identifying detail: the agent proposes, the team approves before circulation.

How do you scope an AI agent that touches health data?

The order we follow at scoping, before the first production release:

1. Write down the agent’s purpose and rule out any medical purpose that is not intended.
2. Map the data the agent will see, field by field, flagging those that become health data once combined.
3. Choose the lawful basis and the Article 9 exception, then run the DPIA on how the agent actually works.
4. Check, link by link, who stores what and where, and whether the hosting needs certification.
5. Filter and pseudonymise upstream of the model, and keep the mapping table out of the agent’s reach.
6. Keep a human signature on anything that commits the company and log the approvals, as LOOP™ governance provides.
7. Classify the agent under the AI Act (Annex I, Annex III, Article 50) and date the deadlines that apply to it.

The method applies to companies of every size: a business of a few dozen people and a pharmaceutical group face the same questions at different volumes. For the security of the agent itself, access rights and logs included, our guide to securing Claude agents in production complements this grid, and our MCP audit for production covers access to business systems.

To see where your organisation stands on agent governance before opening a health project, the AI maturity assessment measures the six axes of the Koneetiv framework (2026 edition).