AI Tool Due Diligence in the UK: Is the Supplier's Word Enough?

Part of our topic guides on AI Governance & Data Strategy and AI Skills for Business.

By James Cotton, Founder, iO-Sphere

The ICO's passage on third-party AI

The regulator, the Information Commission, which succeeded the ICO on 30 September 2026, answers the question in the ICO's Guidance on AI and data protection, in a passage on outsourcing and third-party AI. When you buy AI in, you "need to conduct an independent evaluation of any trade-offs as part of your due diligence process" and are "required to specify your requirements at the procurement stage".

Where you cannot assess whether a third-party solution would be compliant, "you should, as a matter of good practice, opt for a different solution". The guidance's example trade-off is a CV screening tool that scores candidates well but needs a lot of data about each, which the buyer must be able to justify or have the provider change.

That guidance, last updated on 15 March 2023, is under review because of the Data (Use and Access) Act 2025, so "required" is the ICO's word in guidance that may change. Its guidance on impact assessments, contracts and explaining AI, quoted below, is under review too.

Beneath it sits UK GDPR Article 28(1): the controller, which decides why and how personal data is processed, "shall use only processors providing sufficient guarantees", a processor being one that processes the data on its behalf. The ICO's contracts guidance adds: "Controllers are primarily responsible for overall compliance with the UK GDPR, and for demonstrating that compliance."

Write the requirements before the demonstration

Requirements start from the ICO's own test: deploying AI on personal data "needs to be driven by evidence that there is a problem, and a reasoned argument that AI is a sensible solution to that problem, not by the mere availability of the technology".

The AI Playbook for the UK Government (Government Digital Service, 10 February 2025) told government buyers drafting AI requirements to start with the problem statement, focus on data quality, bias and limitations, plan against vendor lock-in and give suppliers dummy data where possible. Its kinds of solution included "an existing technology with bolt-on AI elements (paid or free)".

The Guidelines for AI procurement of 8 June 2020, from the Office for AI with the World Economic Forum Centre for the Fourth Industrial Revolution, the Government Digital Service, the Government Commercial Function and Crown Commercial Service, remain on gov.uk. Their Top 10 Considerations included a data assessment before procurement starts and avoiding black box algorithms and vendor lock-in.

PPN 017, a Cabinet Office note of 17 February 2025, gave buyers an optional question asking suppliers whether AI is used in what they will provide, meeting transcription being its example. All three were written for government, the last two for central government. In our view a private buyer can borrow all three.

Who the supplier is in law

Is the supplier a processor, a controller or both? In UK GDPR Article 4, a controller determines the purposes and means of processing, alone or jointly with others; a processor "processes personal data on behalf of the controller".

The contract's label does not settle it: the ICO says organisations that determine purposes and means "will be controllers regardless of how they are described in any contract". Each status should be assessed and documented, and an organisation can be a controller for some phases of an AI project and a processor for others.

The source of the training data, what the model predicts and how it is tested and updated are decisions that can make a supplier a controller. In the ICO's examples, which rule on no named product, a cloud machine-learning platform is likely a processor, and a provider of isolated client models is one if the isolation is complete and auditable.

A prediction service reached through an application programming interface (API) is likely a controller for training its model and a processor for each client's predictions. For generative AI, the ICO's consultation response on controllership says status follows "the practical realities of the processing"; "closed access" developers are "unlikely" to be processors at deployment.

A developer processing data for its own purposes is a controller for that processing, and joint controllership does not mean "joint and equal responsibility". UK GDPR Article 26 has joint controllers set out their responsibilities in an arrangement whose essence people can see, and lets people use their rights against each.

UK GDPR Article 28(10) treats a processor that determines purposes and means as "a controller in respect of that processing", and the ICO's 2024 audit of AI recruitment tools found providers calling themselves processors when they were controllers.

The regulator's plans pages list updates to its controllers and processors guidance and its contracts and liabilities guidance, with consultations planned for January 2027 and final versions for spring 2027, when its final agentic AI guidance is also planned.

The impact assessment is the buyer's to write

UK GDPR Article 35 requires the controller, "prior to the processing", to assess processing likely to result in a high risk to people's rights and freedoms, "in particular using new technologies". This data protection impact assessment (DPIA) must at least describe the processing and its purposes, assess its necessity, proportionality and risks to people, and set out the measures to address them.

The controller must seek the advice of its data protection officer, "where designated". The ICO reads the test as catching most uses of AI, each judged on its facts; where you judge a use not high risk, "you still need to document how you have made this assessment". A DPIA is also where you "demonstrate your accountability for the decisions you make in the design or procurement of AI systems".

The ICO's list of processing that needs one includes innovative technology, AI among it, where it is combined with one of the criteria from the European guidelines. A decision about someone's access to a product, service, opportunity or benefit needs one on its own if it rests to any extent on automated decision-making. "If in any doubt, we would always recommend that you do a DPIA".

The ICO's advice to recruiters of 6 November 2024 puts the DPIA "ideally at the procurement stage", where it "helps you to ask the right questions of your provider".

The ICO says the DPIA should set out your roles, any processors and any joint controllership with an outsourced provider, explain "any relevant variation or margins of error in the performance of the system", and record how far, and at what stage, people are involved in decisions.

A processor's flow diagram may be reproduced, but you should "generally avoid copying large sections of a processor's literature". The buyer adds the less risky alternatives it rejected and why, and, where AI replaces or complements human decisions, human and algorithmic accuracy side by side.

Data & AI Governance (Level 4), our apprenticeship, trains whoever will own this work; we teach AI governance within it. For colleagues reading the supplier's answers, we run team training.

Claims to test before signing

The ICO's chapter on accuracy says that when you buy AI, "you should examine and test any claims made by third parties as part of the procurement process".

Its fairness annex suggests asking for documentation on the groups a model was trained on, bias detected and fairness testing done, asking dataset suppliers about collection methods and encoded bias, and seeking assurances on bias testing or testing the model yourself: "It is unlikely for the model you procure to have been trained on the exact population you intend to deploy it on."

The ICO and The Alan Turing Institute, in Explaining decisions made with AI, say "you as the data controller have the primary responsibility for ensuring that the AI system you use is capable of producing an explanation for the decision recipient". Vendors should train and support your implementers; an off-the-shelf system without inherent explainability may need "another model alongside it".

The ICO's guidance on individual rights says: "When procuring an AI service, you must choose one which allows individual rights to be protected and enabled". A service not designed for those rights leaves the obligations unchanged, and the processor contract must require help with rights requests.

From 5 February 2026, section 80 of the 2025 Act, commenced by SI 2026/82, replaced UK GDPR Article 22 with a new Section 4A on automated decision-making. For any tool that screens, scores or decides about people, the new rules on automated decisions join these checks.

Security, and how seldom suppliers are reviewed

The Cyber Security Breaches Survey 2025/2026, official statistics published on 30 April 2026 and commissioned by the Department for Science, Innovation and Technology (DSIT) and the Home Office, covered 2,112 UK businesses from August to December 2025. Of UK businesses, 15% have formally reviewed the cyber security risks of their immediate suppliers and 6% their wider supply chain.

For immediate suppliers the range is 12% of micro to 48% of large businesses, and 11% require suppliers to hold any standard or accreditation (41% of large businesses, against 21% in 2024/2025). These figures cover the cyber security risk from suppliers of every kind.

For bought-in AI, the ICO's security chapter puts security and minimisation into "the procurement process due diligence", notes that "Very few organisations build AI systems entirely in-house", and asks for information sharing, in some cases a joint risk assessment, and staff with the skills to assess the risks.

The National Cyber Security Centre's (NCSC) Guidelines for secure AI system development (27 November 2023), published with the US Cybersecurity and Infrastructure Security Agency (CISA) and international partners, are written for providers, which makes them the standard to question a provider against.

They expect a due diligence evaluation of a model provider's security posture, controls on data sent to external APIs, suppliers held to your own software standards, failover for mission-critical systems, and model cards, data cards and software bills of materials. Where a risk cannot be mitigated, the provider should tell users what they are accepting.

The NCSC's guide for managers (13 February 2024) asks whether you can put to suppliers "the right questions on their own security".

The voluntary Code of Practice for the Cyber Security of AI (DSIT and the Department for Digital, Culture, Media and Sport, 31 January 2025) counted an organisation that only uses third-party AI components as a likely System Operator, within its scope.

Its provisions said a System Operator "shall" justify in writing any poorly documented or secured component (7.2), tell end-users before models are updated (7.4) and tell them where and how their data is used (10.1), information an external Developer "shall" provide.

When the data leaves the UK

SI 2026/82 also brought the 2025 Act's transfer provisions, section 85 and Schedules 7 to 9, into force on 5 February 2026. UK GDPR Article 44A now permits a transfer abroad only under adequacy regulations, appropriate safeguards or a derogation, and only if it complies with the rest of the Regulation.

Under Article 46, the controller or processor, "acting reasonably and proportionately", must consider the "data protection test" met: protection after the transfer "would not be materially lower", judged on all the circumstances, including the nature and volume of the data. The ICO's transfer guidance, updated on 15 January 2026, says UK legislation now calls a transfer risk assessment a "data protection test".

For a US provider, the ICO's guide to the UK Extension to the EU-US Data Privacy Framework (DPF) calls it "a partial adequacy finding", open only to businesses the Federal Trade Commission or the Department of Transportation regulates. Its checks are the DPF list, an active certification, and HR or non-HR data. Businesses self-certify annually, and the Extension "is only a transfer mechanism".

The contract, and the way out

Whenever a controller uses a processor, the ICO's contracts guidance says, "there must be a written contract (or other legal act) in place". UK GDPR Article 28(3) has it set out the subject-matter, duration, nature and purpose of the processing, the types of data and people, and the controller's obligations and rights.

The contract must also stipulate what the processor does. It acts only on documented instructions, transfers abroad included. It binds the people processing the data to confidentiality and takes Article 32's security measures. It meets the conditions for using another processor.

The processor also helps with rights requests, and with DPIAs and prior consultation. At the end it deletes or returns the data, as the controller chooses. It supplies what is needed to show compliance, and allows audits and inspections.

The processor must say at once if it thinks an instruction infringes the Regulation. Under Article 28(2) it may use another processor, a sub-processor, only with the controller's written authorisation and a chance to object; under 28(4) it stays "fully liable to the controller"; and 28(9) requires writing, electronic form included.

The ICO's 2024 advice to recruiters adds "explicit and comprehensive written instructions" and performance measures "such as statistical accuracy and bias targets". PPN 017 said departments "will likely want to ensure" that contract terms keep data out of training "unless this has been specifically agreed and approved in writing by the client". The Playbook raised intellectual property, successor suppliers and outages; the 2020 guidelines, end-of-contract roles and knowledge transfer.

Once the tool is live, the ICO says to "regularly review any outsourced services and be able to modify them or switch to another provider", to agree accuracy reviews against "concept/ model drift" and to monitor as often as a wrong output's impact warrants. The DPIA stays "live", reviewed under Article 35(11) at least when the risk changes; staff follow a use policy.

If the tool's output is used in the EU

In EU AI Act terms the buyer is a deployer: under Article 3(4), anyone using an AI system under its authority outside a personal non-professional activity. The high-risk rules for Annex III systems apply from 2 December 2027, one date in a longer calendar.

For those systems, Article 13 makes the provider supply instructions for use, covering tested accuracy metrics, robustness and cybersecurity, where appropriate performance for specific groups, human oversight measures, and expected lifetime and maintenance.

AI Act Article 26 has deployers use that information for their DPIA under the EU GDPR; a UK firm's own duty stays UK GDPR Article 35. AI Act Article 26 also has deployers report serious incidents to the provider first, tell people an Annex III system helps decide about them, and cooperate with authorities, "without prejudice" to other law.

Under Article 25 a deployer becomes the provider if it puts its name or trademark on a high-risk system, substantially modifies one, or changes a system's purpose so it becomes high-risk. The Digital Omnibus on AI added that the original provider must then supply documentation, known limitations and failure modes and technical access, and that component suppliers set out their support by written agreement.

The Omnibus put breaches of those duties in the same tier of fines as a deployer's breaches of AI Act Article 26. Whether any of this catches a UK firm is a legal question that turns on Article 2(1) and on what the firm does to the system.

The questions to send the supplier

Send these in writing before signing; the answers become evidence in your DPIA and terms in your contract.

1. Which processing decisions do you take, and do you use our data for your own purposes, training included?
2. Will you sign a contract with every UK GDPR Article 28(3) term, and which sub-processors will handle our data?
3. Where is our data processed, on what transfer basis, and, if you are a US business, is your UK Extension certification active?
4. What accuracy have you measured, on which population and with what margins of error, and may we first test the tool on our own or dummy data?
5. Which groups was the model trained on, where did its data come from, and what bias and fairness testing have you done?
6. How can an output be explained to the person it affects, and what training will our implementers get?
7. What security documentation can you share, such as model cards, and which risks would we be accepting?
8. Will you warn us before model updates and agree regular accuracy reviews?
9. Is AI used anywhere else in the service?
10. At the end, what happens to our data and work, and how would a move to another provider run?
11. Where the EU AI Act applies, will you supply the Article 13 instructions for use?

Frequently asked questions

Does a supplier's ISO/IEC 42001 certificate show that its tool complies?

ISO/IEC 42001 certification covers the supplier's management system for AI, so the tool still needs the checks above. ISO certifies no one: certification is voluntary, by independent bodies. UKAS lists five accredited bodies for AI management systems, the first accredited under UKAS on 15 January 2026; they certify management systems, not products or people.

Can we rely on the supplier's lawful basis?

A developer's own processing served a different purpose, building the system, so the ICO's lawfulness guidance says a buyer deploying it may need a different lawful basis. The recognised legitimate interest basis, in UK GDPR since 5 February 2026, applies only where a condition in Annex 1 is met, such as national security, emergencies, crime or safeguarding vulnerable people, and none of those conditions is commercial.

What if the DPIA finds a high risk we cannot reduce?

Prior consultation under UK GDPR Article 36 follows: where a DPIA shows a high risk in the absence of mitigating measures, the controller must consult the Information Commission before processing. The Commission has up to eight weeks from receiving the request to give written advice, extendable by six weeks.