GDPR and AI: Handling Health Data Under UK and EU Law

Under GDPR, health data is special category data and processing it is prohibited by default. You may only process it if a condition in Article 9 applies, on top of a lawful basis in Article 6. That means AI on health data needs two legal building blocks, not one.

The rules apply to any organisation in the UK or EU, and to organisations elsewhere that handle the health data of UK or EU people. AI raises the stakes because it often means new technology, large-scale data, and offshore vendors.

This guide explains the Article 9 conditions, the paperwork you need, and the AI-specific duties around impact assessments, vendor contracts, international transfers, and automated decisions. It ends with a practical deployment checklist.

Health Data Is Special Category Data

Health data is special category data under Article 9 of the GDPR, and processing it is prohibited unless a specific condition applies. Article 9(1) sets the default ban, and Article 9(2) lists the exceptions that lift it.

Special category data covers data about physical or mental health, plus related categories like genetic and biometric data. The ICO treats it as needing a greater level of protection because misuse can cause serious harm.

Article 9(2) gives ten conditions that can lift the ban. The common ones for health work are explicit consent, and the health or social care condition in Article 9(2)(h). Others include vital interests, substantial public interest, and scientific research.

In healthcare, consent is often not the right route. The ICO notes that consent to medical treatment is separate from your data protection basis, and the health or social care condition usually fits better than asking each patient to consent to the processing.

• Explicit consent (Article 9(2)(a)) must be a clear, specific, opt-in statement that can be withdrawn.
• Health or social care (Article 9(2)(h)) covers treatment, diagnosis, and care management.
• Substantial public interest and scientific research each need extra UK or member-state safeguards.
• Some conditions in UK law also require an appropriate policy document.

You Need Both an Article 6 Basis and an Article 9 Condition

Health data needs two legal building blocks: a lawful basis under Article 6 and a separate condition under Article 9. One does not replace the other, and you must identify both before processing starts.

Article 6 gives six lawful bases, such as consent, contract, legal obligation, vital interests, public task, and legitimate interests. You pick the one that fits your purpose for using the AI.

Article 9 sits on top of that. So a hospital might rely on public task under Article 6 and the health or social care condition under Article 9 for the same processing.

Document both choices before you deploy. If you cannot name a valid Article 6 basis and a valid Article 9 condition, the AI use is unlawful even if the tool works well.

• Article 6: your general reason for processing (contract, public task, legitimate interests, and so on).
• Article 9: the extra permission that lifts the ban on health data.
• Both must be identified and recorded before the first live record is processed.

Controllers, Processors, and the Data Processing Agreement

When an AI vendor processes health data on your behalf, GDPR requires a written contract under Article 28. This Data Processing Agreement is the GDPR analogue of the HIPAA BAA, and you cannot rely on the vendor without it.

A controller decides why and how data is processed. A processor acts on the controller's documented instructions. Most AI vendors that handle your data are processors, and you stay the controller and carry the accountability.

The ICO confirms that every time a controller uses a processor there must be a written contract. Article 28(3) sets out mandatory terms, including processing only on your instructions, confidentiality, security, sub-processor controls, and deletion at the end.

In our AI-compliance work with healthcare-adjacent and nonprofit clients, the failure mode we see most is staff pasting patient data into consumer AI tools with no Article 28 contract in place. A free chatbot account is not a compliant processor.

Check the vendor's data terms before you send any health data. Confirm whether they train models on your inputs, where they process, and who their sub-processors are. Tools like ChatGPT and Claude publish enterprise terms that differ from their consumer versions.

• Get a signed Article 28 DPA before any health data reaches the vendor.
• Confirm the vendor will not use your data to train models unless you agree.
• Map every sub-processor, since each also needs an equivalent contract.
• Require documented security measures and end-of-contract deletion.

The DPIA Is Practically Mandatory for AI on Health Data

A Data Protection Impact Assessment is required under Article 35 when processing is likely to result in a high risk to people, especially with new technology. AI on large-scale health data ticks these boxes, so a DPIA is practically mandatory.

The ICO states that DPIAs are likely to be an obligation when you use AI to process personal data, and that they must be done before processing begins. Large-scale special category data and new technologies each trigger the requirement on their own.

A DPIA describes the processing, tests whether it is necessary and proportionate, identifies risks to people, and sets out measures to reduce them. Do it early, while you can still change the design.

If the DPIA shows a high residual risk you cannot reduce, you must consult the ICO before you start. Skipping the DPIA is one of the fastest ways to turn a routine AI project into a reportable failure.

• Triggers include new technology, large-scale special category data, and profiling with significant effects.
• Complete the DPIA before the AI goes live, not after.
• Consult the ICO where a high residual risk remains.
• Keep it as a living document and update it when the tool changes.

International Transfers and Offshore AI Processing

Sending health data to an AI vendor outside the UK or EEA is a restricted transfer under Chapter V of the GDPR, and it needs its own safeguard. Many AI tools process in the United States, so this rule bites often.

The simplest route is an adequacy decision, where the UK or EU has ruled that a country protects data to a high enough standard. If no adequacy decision covers the transfer, you need an appropriate safeguard instead.

For EU exporters the main safeguard is the European Commission's Standard Contractual Clauses. For UK exporters the ICO provides the International Data Transfer Agreement, or an Addendum that attaches to the EU SCCs.

You usually also need a transfer risk assessment to check the safeguard holds in the destination country. Confirm exactly where your AI vendor processes and stores data, because the marketing region and the processing region are not always the same.

• Check for an adequacy decision covering the destination first.
• EU exporters: use the EU Standard Contractual Clauses.
• UK exporters: use the UK IDTA or the UK Addendum to the EU SCCs.
• Run a transfer risk assessment when you rely on SCCs or the IDTA.

Automated Decisions, Profiling, and Transparency

Article 22 restricts solely automated decisions that have a legal or similarly significant effect on someone. In health settings that could include an AI triage tool or an eligibility decision with no meaningful human review.

Where Article 22 applies, you can only make such decisions under one of three routes: it is necessary for a contract, it is authorised by law, or the person gave explicit consent. You must also give people a way to get human review and to contest the outcome.

Meaningful human involvement can take the processing outside the Article 22 restriction. A clinician who genuinely reviews and can override the AI, rather than rubber-stamping it, changes the analysis.

You also owe transparency duties under Articles 13 and 14. Tell people you are using automated decision-making, give meaningful information about the logic, and explain the likely consequences. AI does not remove the duty to be clear about how you use health data.

• Article 22 covers solely automated decisions with significant effects.
• Allowed only via contract necessity, legal authorisation, or explicit consent.
• Add genuine human review, not a token sign-off.
• Articles 13 and 14 require you to explain the logic and the consequences.

How the EU AI Act Fits Alongside GDPR

The EU AI Act adds a second rulebook, and AI used in health contexts can be classed as high-risk. It complements GDPR rather than replacing it, so both can apply to the same system at once.

GDPR is a fundamental rights law about personal data. The AI Act is a product safety law about how AI systems are built and used. AI in medical devices or in certain health decision-making tends to fall into the high-risk tier.

High-risk systems carry duties such as risk management, data governance, technical documentation, record-keeping, human oversight, and accuracy and robustness. These sit on top of your GDPR obligations, not instead of them.

For a UK organisation the AI Act may still matter if you serve EU users or use EU-facing AI systems. Track it as a separate workstream, and get specialist advice on whether your specific tool is in scope.

UK GDPR Versus EU GDPR After Brexit

UK GDPR and EU GDPR are separate laws that remain largely aligned. After Brexit the UK kept the GDPR as UK GDPR, sitting alongside the Data Protection Act 2018, so the core rules on health data are broadly the same.

The main practical difference is the regulator and the paperwork. The ICO is the UK authority, while EU organisations answer to national supervisory authorities and the EDPB. Transfer tools also differ, with the UK using the IDTA and the EU using the SCCs.

UK data protection law continues to evolve, so recent reforms may create small divergences over time. Do not assume the two regimes are identical on every detail.

If you serve both markets, follow the stricter reading and confirm the current position on the ICO site for the UK and the EDPB site for the EU. Verify specifics on the official pages rather than relying on general summaries.

• Same core structure: Article 6 basis plus Article 9 condition for health data.
• Different regulators: ICO in the UK, national authorities and the EDPB in the EU.
• Different transfer tools: UK IDTA and Addendum versus EU SCCs.
• Expect gradual divergence, so check current guidance for each market.

How to Deploy AI on Health Data Under GDPR: A Checklist

You can deploy AI on health data compliantly by working through a fixed set of steps before go-live. The list below turns the GDPR duties above into a practical order of work.

Start with the legal foundations, then the vendor and transfer paperwork, then the risk and transparency controls. Complete each step and record the outcome, because accountability means being able to show your working.

• 1. Confirm the health data is special category data and map every data flow.
• 2. Identify and document an Article 6 lawful basis and an Article 9 condition.
• 3. Complete a DPIA before processing, and consult the ICO if high residual risk remains.
• 4. Sign an Article 28 Data Processing Agreement with every AI vendor.
• 5. Confirm the vendor will not train on your data without agreement, and map sub-processors.
• 6. Cover any transfer outside the UK or EEA with adequacy, SCCs, or the UK IDTA, plus a transfer risk assessment.
• 7. Check whether Article 22 applies, and add meaningful human review where it does.
• 8. Update privacy notices under Articles 13 and 14 to explain the AI and its logic.
• 9. Assess whether the EU AI Act applies and treat any high-risk duties as a separate track.
• 10. Set retention, security, and staff-training controls, and review after launch.