Can a broker use AI on a protection fact-find?

Yes. No rule bans it, and the FCA does not approve or ban tools. But a protection fact-find captures health and medical detail, which is special category data under UK GDPR, the most protected class in law. The bar for processing it is the highest in data protection, so the care required is greater than for an ordinary case, not the same.

Is client health data special category data under GDPR?

Yes. Article 9 of UK GDPR lists data concerning health among the special categories and begins from a prohibition on processing it. To process it lawfully a firm needs a condition of its own under Article 9(2), the client's explicit consent or one of the conditions in the Data Protection Act 2018, including those for insurance, on top of the ordinary Article 6 lawful basis. Two locks, not one.

Is it a breach to put a client's medical history into an AI tool?

It can be, and it is the clearest data-protection line in broking. Medical history is special category data, so processing it requires an Article 9 condition and security appropriate to the harm a loss would cause. A consumer AI tool typically offers no data processing agreement, no deletion guarantee, and may train on the input. The baseline fact is simple: identifiable health data does not belong in consumer AI tools.

Who is accountable if client health data leaks from an AI tool?

The firm, as data controller, and the Senior Manager responsible for it. The higher the category of data, the higher the stakes, and health data is the highest. Uploading it to a third-party tool transfers none of the accountability. If it leaks, the firm answers for the breach, not the vendor.

Can a Broker Use AI With Client Health Data Under GDPR?

Yes. A broker can use AI on a protection case, and no rule prohibits it. But protection is the one corner of broking where the data itself changes the question. A protection fact-find does not just capture income and address. It captures health conditions, medical history, mental health, family history, sometimes alcohol and lifestyle. In law that is not ordinary personal data. It is special category data, the most protected class there is, and the moment it meets an AI tool a broker is standing on the clearest line in this whole subject.

Everything true of client data in general is true here, only more so. The difference is not one of degree. UK GDPR draws a hard boundary around health data and treats crossing it as a thing you must justify before you do it, not explain after.

Why protection is not like the rest of broking

Most of what a broker handles, name, income, address, bank details, is ordinary personal data. Sensitive, but ordinary in the legal sense. A protection fact-find routinely goes further: a diagnosis, a course of medication, a mental health history, a family history of illness. UK GDPR puts that in a category apart, and it is the category the law guards most closely.

Special category data carries a higher bar, by design

Article 9(1) of UK GDPR begins from a prohibition. The processing of "data concerning health", it says, "shall be prohibited", unless one of a narrow list of conditions applies. That is the opposite of the default for ordinary data, which you may process once you have a lawful basis. With health data you start from no, and you have to earn the yes.

Earning it means a lawful condition of its own under Article 9(2), on top of the ordinary Article 6 basis every processing needs. For a broker the realistic routes are the client's "explicit consent... for one or more specified purposes" (Article 9(2)(a)), or one of the conditions the Data Protection Act 2018 sets out in UK law, which include provisions for insurance business. Two locks, not one, and the second is the one brokers forget exists.

The AI tool is where the line gets crossed

Put a client's disclosed conditions into a consumer AI tool and you have sent special category data to a third-party model outside the firm's control. There is typically no data processing agreement, the processor terms UK GDPR expects under Article 28, no deletion guarantee, and on a free tier the possibility that the input trains the model. The Article 5 security principle, which requires "appropriate security... against unauthorised or unlawful processing and against accidental loss", applies here with maximum force, because the data is the kind whose loss does the most harm.

This is not a grey area to be reasoned around. Health data leaving the firm's controlled environment for a public tool is the single clearest data-protection line in broking, and the firm remains the controller and the accountable party whatever the tool's terms say.

Vulnerability sits on top of the data risk

Protection clients are, more often than most, vulnerable: a recent diagnosis, a bereavement, a serious illness in the family. That pulls in the Consumer Duty as well as UK GDPR. The Duty requires firms to "take account of the different needs of their customers, including those with characteristics of vulnerability" (FCA AI Update section 3.24), at all stages of the service, and the FCA is explicit that this obligation holds "where the product or service is heavily reliant on an AI or data solution" (sections 3.28 to 3.29). A tool that summarises a fact-find does not detect vulnerability, and the Duty does not let the broker hand that judgement to it.

Reading health data is one thing. Deciding from it is another.

There is a further line beyond storage. If an AI tool does not just hold a medical disclosure but reads it, and its output shapes an underwriting or suitability decision taken solely by automated means with "legal or similarly significant effects", the Article 22 safeguards are engaged (section 3.32), and section 3.37 expects the client to be given "meaningful information about the logic involved in the decision." Deciding a person's cover from health data they disclosed, through a process the broker cannot explain, is the sharp end of this whole question.

What actually determines the position

It is not the task, and it is not the tool. Is special category data involved? On a protection case, routinely, and it is the category the law protects most. Is there a lawful Article 9 condition, as well as the ordinary Article 6 basis, and is the data genuinely secured on infrastructure the firm controls or has contracted for? And is a named person accountable for any decision drawn from it? Those questions decide it. The tool is a detail hanging off the answers.

So, can a broker use AI with client health data?

Yes, with the highest care the subject allows, and no vendor's reassurance changes what is required. The regulator did not give permission, because it was never asked to, and UK law starts this particular question from a prohibition it expects you to lift deliberately, not drift past.

The mistake is to treat a protection case like any other file with a bit more detail on it. It is not. A wrong figure can be corrected before it reaches anyone. But a disclosed condition, once it has crossed into a model the firm does not run, cannot be recalled, and the law's price for mishandling the most protected data it recognises is the steepest there is. That is the exposure, and on a protection case it is never far from the surface.

This article is part of Regulator Decoded, one of three editorial streams from AI for Brokers. Plain-English breakdowns of what the FCA, ICO, and lenders are actually saying about AI, and what it means for UK brokers in practice.