Does ICO guidance on AI and data protection apply to a UK firm using a vendor tool?

Yes, if the firm's use involves processing personal data. The ICO says organisations must identify each distinct AI processing operation, its purpose and an appropriate lawful basis. A vendor's development purpose is not automatically the firm's deployment purpose. The firm should also document which organisation acts as controller or processor for each relevant operation, rather than relying on a contract label alone.[1][2]

Is a DPIA required for every UK business AI tool?

No. The ICO says not every AI use is likely to create a high risk. It identifies Article 35(3)(a) as requiring a DPIA for systematic and extensive automated evaluation on which legal or similarly significant decisions are based. The same guidance identifies other high-risk patterns. The business must assess its actual data use and effects before deciding, then record the reasons.[2]

Can one lawful basis cover both training and use of an AI system?

Sometimes, but it cannot be assumed. The ICO requires organisations to separate distinct processing operations and identify a purpose and suitable basis for each. Development and deployment can have different purposes and risks, particularly when a third party developed the tool. The organisation should decide and document its basis before each operation starts, not copy a supplier's answer.[1]

What does fairness mean when an AI tool uses customer data?

Article 5(1)(a) of the UK GDPR requires lawful, fair and transparent processing. The ICO explains fairness in terms of reasonable expectations and avoiding unjustified adverse effects. Transparency means giving people proper information about how and why their data are processed. A business should examine both the way the tool operates and its effects on individuals, not merely publish a notice.[3]

Does calling a vendor a processor settle the UK GDPR roles?

No. The ICO says roles depend on actual control of purposes and means, and may differ across AI development and deployment. A controller decides why and how data are processed; a processor generally acts on a client's instructions without its own purpose. The firm should assess and document each organisation's role for each operation. A contractual label cannot override those facts.[2]

What should the business keep after an AI risk review?

Keep the operation and purpose map, the chosen lawful bases, the DPIA decision and any assessment, the fairness and transparency review, and the record of vendor roles. These items follow the ICO's guidance on separating operations, assessing risk and documenting responsibility. The exact detail depends on the processing. A generic statement that the tool is “compliant” does not show how the business reached its decisions.[1][2][3]

ICO guidance on AI and data protection for UK firms

Quick Answer: ICO guidance on AI and data protection asks a UK business using personal data in AI to map operations and purposes, choose lawful bases, test DPIA need, assess fairness and transparency, and document vendor roles. High-risk automated evaluations can require a DPIA under UK GDPR Article 35(3)(a).¹^,2^,3

Summary in a mind map

ICO guidance on AI and data protection for UK firms
│
├─ Map personal-data use
│   ├─ Separate development from deployment
│   ├─ Name each operation and its purpose
│   └─ Record data entering and leaving the tool
│
├─ Choose a basis
│   ├─ Fit a basis to each purpose
│   ├─ Decide and document before processing
│   └─ Supplier claims are not the firm's answer
│
├─ Assess risk and fairness
│   ├─ Test the Article 35 DPIA triggers
│   ├─ Look at effects and expectations
│   └─ Explain how and why data are used
│
├─ Set vendor roles
│   ├─ Actual control decides the role
│   ├─ Roles may differ by phase or purpose
│   └─ A contract label does not settle them
│
└─ Keep the record
    ├─ Save the DPIA decision and reasons
    ├─ Link safeguards to the actual workflow
    └─ Revisit the record when use changes

Start with the actual data use

A dental practice is considering a treatment-planning tool supplied by another company. Its worksheet should describe the data use. The “AI” label answers little. It should name patient or staff data entered. It should also record the outputs and every supplier operation on those data. The ICO requires distinct processing operations to be separated. Each needs a purpose and lawful basis.¹

The same tool can have more than one purpose. Development or training is one purpose. Making a prediction in a practice can be another. The ICO distinguishes development from deployment. This applies even where a third party built the system. A supplier may describe its training. That does not answer what happens to a patient's data when the practice uses the tool.¹

Question for the practice	Evidence to collect	ICO reason
Which personal data enter the tool?	Data fields and people affected	Lawfulness is assessed for each processing operation.¹
Why are the data used?	Purpose for each operation	Development and deployment may be separate purposes.¹
Who decides what happens?	Practice and vendor decisions	Roles depend on actual control.²

If no personal data are involved in a particular operation, the personal-data analysis for that operation changes. The firm must establish that fact from its workflow. A product label is insufficient. The ICO's guidance is framed around AI processing of personal data.¹^,2

Separate purposes and lawful bases

The ICO says an organisation must identify a purpose and lawful basis for each distinct AI operation, including development and deployment. For the practice, the first comparison is whether patient data are needed to provide the agreed service, whether people can give valid consent for a separate use, or whether a legitimate interest survives a balancing test. A vendor's training purpose needs its own assessment; it cannot inherit the practice's deployment basis.¹

Possible basis	Development question	Deployment question
Consent	Can people make a genuine choice about training with their data?	Can they choose this use without losing a service they need?¹
Contractual necessity	Is training truly necessary to perform a contract with each affected person?	Is this data use necessary to provide the agreed service, rather than merely convenient?¹
Legitimate interests	Identify the interest, show necessity, then balance it against people's rights.	Repeat the three-part test for the live use and its effects.¹

The ICO advises deciding and documenting the basis before processing starts. The basis must reflect the real purpose and relationship with each person. “The supplier has consent” is not the practice's answer for its own operation. Special-category data also require a separate condition.¹

For the dental example, the firm can record its intended use of patient information and ask the vendor whether submitted information is used for a separate development purpose. That question does not presume the answer. If purposes differ, each needs its own basis. Responsibility must also be checked. A single generic AI policy cannot supply those facts.¹^,2

Decide whether a DPIA is required

A data protection impact assessment is not automatic for every AI tool. The ICO acknowledges that some AI uses will not involve processing likely to create a high risk. Article 35(3)(a) is one trigger. It covers systematic and extensive automated evaluation of personal aspects when legal or similarly significant decisions are based on it. The ICO lists two more cases. They concern large-scale special-category processing and large-scale systematic monitoring of public areas.²

Risk question	What the ICO says	Practice response
Is there systematic, extensive automated evaluation with significant decisions?	Article 35(3)(a) requires a DPIA.²	Describe the decision and who it affects.
Are sensitive data processed at large scale?	This is another DPIA trigger identified by the ICO.²	Establish the actual scale and data types.
Is a new use likely to pose high risk?	Other AI operations may also create high risk.²	Assess the specific context, not the tool's name.

The ICO says a DPIA should describe the nature, scope, context and purposes of personal-data processing. It should explain how and why AI is used. The practice should record how data enter. It should also note what outputs inform and who is affected. The DPIA decision itself needs a clear rationale, even if a full assessment is judged unnecessary.²

A vendor's AI label never replaces the firm's operation-by-operation assessment.

In words, the route begins by asking whether personal data are used. For each such operation, the business records its purpose and basis. It then checks DPIA triggers and other high-risk features, reviews fairness and transparency, settles controller and processor roles, and retains the evidence. A changed use returns to the operation map.¹^,2^,3

Check fairness and explain the use

Article 5(1)(a) of the UK GDPR requires personal data to be processed lawfully, fairly and transparently. The ICO asks whether processing fits reasonable expectations. Unjustified adverse outcomes are another concern. It describes transparency as properly informing people how and why their data will be processed. A notice is part of the work. It does not cure an unfair effect or unsuitable basis.³

The practice should look at the route from input data to an output that could affect a patient. Who might receive a worse result? Would a person reasonably expect this use? What information would explain the use without hiding the purpose? These are assessment questions drawn from the ICO's fairness framing, not a guarantee that any particular treatment-planning system is fair. The answer depends on actual performance. Context matters too.³

The ICO also distinguishes the method of processing from its outcome. A fairness review should therefore consider both what data are selected and what happens to people after an output is used. If the tool is changed or used for another purpose, the original assessment cannot simply be copied without checking the new facts.³

Fix the vendor roles for each phase

The ICO says several organisations may participate in developing and deploying an AI system. It asks firms to identify whether each is a controller, joint controller or processor for the relevant processing. A controller has overall control of purposes and means; a processor acts on a client's instructions without its own purpose. Roles can differ by phase. They can differ by purpose.²

A dental practice may choose why it uses an AI tool while a supplier makes technical choices. Those facts need examination. Neither an invoice nor a contract label settles every role. The ICO says an organisation that determines purposes and means remains a controller regardless of how a processing-services contract describes it. Document the practice's decisions and the vendor's decisions for each operation.²

Responsibility	Controller decision	Processor's work within instructions
Retention	Decide how long patient data are retained for each purpose.²	Apply the instructed retention and deletion method.²
Rights requests	Decide how the organisation responds to a person's request.²	Retrieve, transfer or delete data as instructed so the controller can respond.²
Safeguards	Set the purpose and assess risks to individuals.²	Choose permitted technical storage and security measures within the instructions.²

The UK and EU AI governance comparison places those roles within wider governance. Where AI helps with operational work, the order-processing example offers a separate workflow context. Neither example resolves the dental practice's own vendor facts.

Record safeguards and revisit them

The ICO's accountability guidance tells organisations to assess risks to people's rights and freedoms when they design or decide to use AI. It also says a DPIA should describe the intended outcomes and consider less risky alternatives. The practice can keep one decision record. It can contain the operation map, bases and DPIA reasoning. Fairness questions, patient explanations and role analysis belong there too.¹^,2^,3

For each identified risk, the record should state its likely impact, the chosen safeguard, whether that safeguard was implemented and tested, and whether the risk was eliminated, reduced or accepted. It should state the residual risk after mitigation. The ICO expects these conclusions in a DPIA and calls for prior consultation if high risk cannot be sufficiently reduced.²

This record should identify who can review a changed purpose, dataset, output or vendor arrangement. A change may alter the lawfulness assessment or risk profile. The ICO's page about lawful bases says a decision should be documented before processing and should not be swapped later without good reason. A review date alone says little. Record what changed and why the original conclusion still holds.¹

For a system that may make decisions about individuals, the separate automated decision-making guide explains another part of the legal picture. The UK business-email guide addresses a different personal-data use. Neither replaces the operation-specific checks for the proposed AI tool.

What this guidance cannot decide for you

The ICO's general guidance cannot determine whether a particular vendor's model uses patient data for training, whether a dental workflow meets a DPIA trigger, or which firm controls each purpose. Contracts matter. Actual technical use matters too. The ICO also states that its AI lawfulness page is under review following the Data (Use and Access) Act. A business should check the current guidance when taking a live decision.¹

The guidance is about UK data protection law. It should not be read as an EU GDPR answer for a different jurisdiction. Where the business has both UK and EU operations, it must identify the law governing each operation before reusing an assessment.¹^,2

What to do next

Choose one proposed AI use and draw its data path from collection to output. Separate development from deployment. For each operation, record the purpose, lawful basis, people affected, DPIA decision, fairness and transparency review, and the role of each organisation. The result is a decision record the practice can test again when the tool or its use changes.¹^,2^,3