AI and client health data: the UK GDPR questions to settle first

Five, and none of them is about the model. Which lawful basis covers the processing, and which Article 9 condition permits special-category data. Whether the model vendor is your processor and what its terms allow it to do with your inputs, exactly which fields may enter a prompt, and how erasure works once embeddings and logs exist. Settle those in writing first.

Health data is special-category data under Article 9 of the UK GDPR, and processing it is prohibited unless you can name both a lawful basis and a separate Article 9 condition. Most projects we see have the first sitting in a privacy notice somewhere and have never written the second down at all. If your business holds evidence and records but no health data, the questions come out differently and AI for compliance and inspection businesses is the better start.

Two permissions, not one

The common gap is a missing second permission: the Article 9 condition.

Explicit consent is the condition people reach for, and usually the worst fit for an operational system, because consent has to be as easy to withdraw as it was to give. If withdrawal means a client emails the practice and a developer runs a query next week, you do not have withdrawable consent. You have an intention.

Providers have other conditions available, and which one fits depends on what the organisation is. Several of the Data Protection Act 2018 Schedule 1 conditions also require an appropriate policy document to be in place while the processing continues. Short document. It has to exist before the processing starts.

A new AI feature is usually a new purpose, and the condition covering a client record does not stretch to sending that record to another company so a model can summarise it. Write the feature's own two lines, and do the Article 35 assessment the same afternoon. If nobody can write the two lines, that is the finding.

Is the model vendor a processor, and what do its terms say?

Almost always a processor, if the arrangement was set up properly, and that means Article 28 terms. The question is what role the vendor occupies in law, and what its contract permits it to do with what you send.

None of that is on the marketing page. It sits in the data processing addendum, in the sub-processor list and whether you get notice before it changes, and in how long prompts and responses are retained, stated in days. It also sits in whether staff can read that content for abuse monitoring, and whether your inputs may be used to train the vendor's models. That last one has a follow-up: off by contract, or off only if somebody finds the right toggle?

One point worth being blunt about. If a vendor uses your data for its own purposes, it is not acting solely as your processor for that use, whatever the agreement calls the parties. With health data that is the first question a client's solicitor asks, and a clause answers it where a reassurance does not.

What may enter a prompt, written as a list of fields

A deny-list is a promise you cannot keep. "Do not send names, addresses or health detail" survives exactly as long as the first free-text field, because a person describing their week will name their GP and their sister without being asked to.

Invert it. The server assembles the prompt from a named list of fields, and anything not on that list is never read by the code that builds the request, so it is unreachable. The list lives in source, gets reviewed like any other change, and adding to it produces a diff with somebody's name on it.

That is one case of a rule we keep returning to: prompts instruct, code enforces. An instruction telling a model not to repeat an identifier is a request. A server that never had the identifier is a guarantee.

People forget the return trip. A model's summary of a clinical note is health data too, and it inherits everything here, including retention.

The field that is stored but never indexed

On a healthcare platform we build, the sensitive free-text note payload is deliberately excluded from the search index.

Every list and search in that product reads from a search cluster, so the default, the one you get by writing no special code, is that every field becomes full-text queryable. The note body is mapped so that it is stored in the document and not indexed.

The immediate reason was unremarkable. Nothing in the product searches note content, because notes are always fetched for one appointment at a time. Indexing them bought a capability nobody had asked for and widened the surface of the field that needed it least.

The position that came out of it is the part worth keeping: the most private field in the system should be the hardest one to query in bulk. Reading one record is normal and the software should make it easy. Matching a phrase across ten thousand records is a different operation with different consequences, and it should be awkward by construction rather than forbidden by policy.

It is a data architecture decision that happens to be prudent, and calling it a compliance control would be overclaiming. It costs something too: that product cannot ship search across notes without reopening the decision.

One effect nobody designed for: when an AI feature gets proposed, which store it would read from already has an answer. The sensitive payload is not in the store a retrieval feature reaches for first.

Retention and erasure when embeddings and logs exist

Deleting the client record is the easy part. The copies are the work: the vector store if a retrieval feature exists, your own prompt and response logs, the vendor's logs for as long as its retention window runs, backups and the evaluation set. That last one is where real records get pasted into a fixtures file to test a feature and stay for two years.

Treat an embedding as personal data unless you can demonstrate otherwise. The argument that a vector is not personal data because a human cannot read it is not one we would want to make to a regulator. Store the source record identifier alongside every derived artefact, so a deletion can follow the references.

One deletion path, not two. On a coaching platform we build, records created before an account exists are removed through the same deletion event the main application uses, not a path written for that case. The bespoke path is the one that rots, because it has a single caller and nothing exercises it. Then run it against a real record, because an erasure procedure nobody has executed is only a document.

What the DUAA changed for automated decisions

The core data protection reforms of the Data (Use and Access) Act 2025 came into force on 5 February 2026. Section 80 replaced UK GDPR Article 22 with new Articles 22A to 22D.

A significant decision based even partly on special-category data may be taken solely by automated means in only two situations. In the first, every item of personal data behind the decision is processed with the person's explicit consent. In the second, the decision is necessary for a contract or required or authorised by law. The substantial public interest condition must also apply. And no significant decision may be solely automated where the processing rests even partly on the new "recognised legitimate interest" basis. Outside those limits explicit consent is no longer required, but every such decision needs safeguards that inform the person, hear their representations, offer human intervention and let them contest it.

The text of section 80 is the primary reading. The plainest summary is the DUAA explainer the ICO published before the Information Commission replaced it on 30 September 2026, and Clifford Chance covered the commencement in February 2026.

Read that reform as the relaxation it was reported to be and you will get your position backwards. If an automated decision in your product touches health data, you are in the part that did not relax.

Two other dates apply whatever you build. Every controller needed a formal complaints procedure by 19 June 2026, with a 30-day acknowledgement obligation. And the ICO consulted between 31 March and 29 May 2026 on updated automated decision-making guidance, with regulations in force from 12 May 2026 requiring a statutory code of practice, as Burges Salmon set out. Neither was finished when the Information Commission took over. The final guidance is now due in winter 2026 (ICO guidance plans, 2026) and no code had been published, so treat any summary of it, this one included, as second to the Commission's current text.

Selling into the EU adds a separate regime. The EU AI Act reaches UK companies, and it does not care where you filed your accounts.

The five questions, and what a good answer looks like

Most of that is documentation. It is what we write with a client when settling the Article 9 condition before a build, and what a buyer's security questionnaire asks for six months later. Our own copy of the AI documentation pack lives next to the architecture notes, on the theory that anything filed under compliance gets opened once a year by somebody who did not write it.

Common questions

Can we use a general AI assistant on client health records?

Not on a consumer tier, and not before answering the questions above. You need Article 28 processor terms, a stated retention period for prompts and responses, training on your inputs excluded, and an Article 9 condition covering the new purpose. Staff pasting notes into personal accounts is the failure mode to design out first.

Does anonymising the data solve it?

Sometimes, and less often than people hope. Fully anonymised data falls outside the UK GDPR, but clinical narrative resists anonymisation because the identifying details are the content. Pseudonymised data is still personal data, and a regular expression over prose is pseudonymisation.

Do we need a DPIA for an AI feature over health data?

Almost certainly. Article 35 requires one for large-scale processing of special-category data and for new technologies likely to result in high risk, and a model reading client records is both. Write it before the build, because its findings should change the design.

What about training a model on our own client data?

A new purpose, so it needs its own basis, its own Article 9 condition and its own entry in the assessment. It also makes erasure harder, because a trained model has no rows to delete. For most small practices, retrieval over records you can delete is the better shape.