Do you need a DPIA before using AI on customer data?

Most UK businesses putting personal data through an AI tool never ask this question, and a good proportion of those that do ask it after the fact. The timing matters more than the answer: Article 35(1) requires the assessment prior to the processing, so a DPIA written once the tool is live is a record of non-compliance rather than compliance.

The good news is that the check is short. Two questions decide most cases, and this walks through them.

Step 1: does it involve personal data at all?

If nothing you put into the tool identifies a living person, directly or indirectly, stop here. Summarising your own internal policy documents, generating marketing copy, drafting code: no personal data, no DPIA question.

Be honest about “indirectly”. A support ticket with a name stripped out but a customer reference left in is still personal data.

If no personal data is involved, you are done. Record that you checked, and move on.

Step 2: read the actual trigger

The ICO’s guidance on when a DPIA is required quotes Article 35(1) in full. The operative words:

Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment.

Three things in that sentence do the work.

“In particular using new technologies.” AI is named in the guidance as exactly the kind of thing this contemplates. Using a new technology does not automatically require a DPIA, but it moves you toward the trigger rather than away from it.

“Likely to result in a high risk.” The ICO is explicit that this is about both likelihood and severity: risk implies “a more than remote chance of some harm”, and high risk implies a higher threshold, “either because the harm is more likely, or because the potential harm is more severe, or a combination of the two”.

“Prior to the processing.” Not before launch. Before you start processing the data, which includes the pilot.

Step 3: score yourself against the nine criteria

The ICO points to nine criteria published by the Article 29 working party (WP29) as indicators of likely high risk processing. Nine, and these are the ICO’s words:

1. Evaluation or scoring
2. Automated decision-making with legal or similar significant effect
3. Systematic monitoring
4. Sensitive data or data of a highly personal nature
5. Data processed on a large scale
6. Matching or combining datasets
7. Data concerning vulnerable data subjects
8. Innovative use or applying new technological or organisational solutions
9. Preventing data subjects from exercising a right or using a service or contract

Count how many your project hits.

The ICO’s own threshold: “In most cases, a combination of two of these factors indicates the need for a DPIA.” It then adds two qualifications that matter as much as the rule.

You can decide not to do one on two factors, “if you are confident that the processing is nevertheless unlikely to result in a high risk”, but the ICO is explicit that “you should document your reasons”.

And it can run the other way: “in some cases you may need to do a DPIA if only one factor is present”, and the ICO says it is good practice to do so.

Three of the nine catch AI work that feels routine. Criterion 8 is satisfied by almost any use of a new AI tool. Criterion 1 covers scoring and ranking, including where a person signs off at the end. Criterion 6 catches enriching your customer records with a second dataset, which is a common first AI project.

That is two of the nine before you have done anything unusual.

Step 4: check the automatic list

Separately from the risk factors, the ICO sets out types of processing that automatically require a DPIA. Read that list directly rather than through a summary, including this one: it is short, it is specific, and it changes.

If your project is on it, the assessment is required regardless of how low you think the risk is.

Step 5: write down the answer either way

This is the step people skip, and it is the one that costs them.

A one-page note with the date, the project, the questions above, your answers, and who decided. If the conclusion is “no DPIA needed”, that note is your compliance record. Without it you have no evidence you considered the question, which is materially worse than having considered it and said no.

If the conclusion is “DPIA needed”, that note becomes its first page.

Where this goes wrong

Doing it after the pilot. The most common failure, and the one the wording of Article 35(1) is designed to prevent. A pilot on real customer data is processing.

Assuming the vendor’s DPIA covers you. It does not. A vendor assesses their processing; you are the controller for yours. Their document is useful input and is not your assessment.

Treating “we told them in the privacy notice” as a risk reduction. Transparency is a separate obligation under Articles 13 and 14. Telling people does not remove any of the nine criteria, and none of them is about whether the processing was disclosed.

Scoping it to the tool rather than the use. One DPIA per AI product is wrong when the same product is used for three different things. Article 35(1) allows a single assessment to cover “a set of similar processing operations that present similar high risks”, and the operative word is similar.

What next

If the answer is yes, the ICO’s DPIA template is the fastest legitimate route and it is free.

If your project makes decisions about people rather than just processing their data, read what changed in UK automated decision rules in February 2026 as well. The DPIA question and the Article 22A question are separate, and a project can easily be caught by both.

This is not legal advice. It is a structured read of the ICO’s own published triggers, linked so you can check each one. Where the answer is close, take advice, and keep the note either way.