AI Procurement in the UK: A Due-Diligence Framework

AI procurement is the single most consequential governance decision most UK mid-market firms will make in the next twenty-four months, and it is consistently treated as a technology-purchase question when it is actually a controller-level data-protection question with UK GDPR, Information Commissioner's Office (ICO) guidance, and sub-processor obligations sitting across the top. A firm that procures an AI tool without a due-diligence framework is typically one tool away from a data-protection exposure the firm does not know it carries. This article sets out, in plain terms, what a UK-specific due-diligence framework for AI procurement actually contains: the UK GDPR obligations that apply, when a Data Protection Impact Assessment (DPIA) is required, how to interrogate a vendor's sub-processor chain, what the ICO and the National Cyber Security Centre (NCSC) have said, and a clear next step.

The framing is descriptive. Nothing in this article claims ICO, NCSC, Department for Science, Innovation and Technology (DSIT), or any other public-body alignment, endorsement, or accreditation on behalf of Learn AI. Any procurement clause or DPIA that would bind the firm should be reviewed by the firm's Data Protection Officer, General Counsel, or external solicitor.

Why is AI procurement a controller-level question, not an IT purchase?

AI procurement is a controller-level question because the moment an AI tool touches personal data belonging to the firm's employees, customers, candidates, or clients, UK GDPR engages in full, and the firm (as controller) carries the legal responsibility for every downstream use of that data. The IT department procures the licence; the controller carries the obligation. Four points follow.

The controller obligation does not transfer to the vendor. UK GDPR Article 28 governs the controller-processor relationship. The firm, as controller, must use only processors providing sufficient guarantees that they will meet UK GDPR requirements. The vendor's sufficient-guarantees posture has to be assessed by the firm; it is not presumed from the fact that the vendor sells the product. A procurement process that skipped the Article 28 assessment has not satisfied the controller obligation.

Sub-processors require controller authorisation. Under UK GDPR Article 28(2), a processor cannot engage a sub-processor without prior specific or general written authorisation from the controller. AI tools routinely run on cloud infrastructure that is itself a sub-processor, and many AI tools rely on further downstream sub-processors for embeddings, search, or supplementary models. A firm that authorised the main vendor without reviewing the sub-processor chain has typically signed a blanket authorisation whose scope is wider than the firm realises.

International transfers require a transfer mechanism. Most mainstream AI tools process data outside the UK and the European Economic Area, typically in the United States. UK GDPR Chapter V requires an appropriate transfer mechanism (the UK International Data Transfer Agreement, the UK Addendum to the EU Standard Contractual Clauses, adequacy decisions, or Binding Corporate Rules) and a Transfer Risk Assessment. Consumer AI tools rarely document the mechanism cleanly; enterprise tools sometimes require the firm to opt into the compliant configuration.

Special-category data raises the threshold. Any AI tool that processes health data, data revealing racial or ethnic origin, data concerning sex life, or data revealing political opinions, religious beliefs, or trade union membership engages UK GDPR Article 9. The lawful basis is narrower than for ordinary personal data, and the due-diligence standard is higher. An HR tool that processes candidate data covered in AI in UK Hiring, a finance tool that processes payroll or medical-related expense data, and a consulting tool that processes client interview material touching health or beliefs are all potentially in Article 9 territory.

Read together, the four points place AI procurement inside the controller's accountability remit. The firm cannot discharge the obligation by procuring through IT; IT can execute the procurement, but the Data Protection Officer, the Finance Director, or the Managing Partner carries the controller decision.

When is a DPIA required for an AI procurement?

A Data Protection Impact Assessment is required under UK GDPR Article 35 when processing is likely to result in a high risk to the rights and freedoms of natural persons. The ICO has published guidance (updated through 2024 and 2025) on when a DPIA is required, and the list of processing operations the ICO considers likely high-risk includes several that apply directly to mainstream AI procurements.

Four patterns routinely trigger a DPIA obligation on an AI procurement.

Automated decision-making that produces legal or similarly significant effects. A tool that ranks or filters candidates, scores applicants for a service, or produces a decision influencing credit, employment, or benefits falls inside the Article 22 scope covered in AI in UK Hiring. The ICO's published list treats this category as high-risk and requires a DPIA.

Large-scale processing of special-category or criminal-offence data. AI tools processing medical records, candidate diversity data, or criminal-records checks sit in this category. Scale is not precisely defined; the ICO's guidance suggests the firm should assess data subject numbers, volume of data, geographic range, and duration.

Systematic monitoring of individuals. AI tools that transcribe and analyse meetings (including with customers or staff), tools that monitor employee productivity, and tools that analyse customer interactions on a standing basis sit in this category. The ICO has been clear that the consent, lawful basis, and transparency expectations tighten when monitoring is systematic.

Combining or matching datasets from different sources. AI tools that ingest multiple firm data sources, enrich with public data, or combine internal and external records to produce a composite view trigger the DPIA obligation because the combination of sources produces risks that none of the sources alone produces.

The DPIA is not an administrative step the firm completes to reach the purchase; it is a governance artefact that shapes the procurement. A properly-run DPIA can surface findings that change the specification, tighten the contractual terms, or block the procurement entirely. A firm that treats the DPIA as a sign-off after the contract is signed has inverted the purpose of Article 35.

How do you interrogate a vendor's sub-processor chain?

Interrogating a vendor's sub-processor chain is the single most informative step a procurement team can take on an AI tool, and it is the step most consistently skipped. The interrogation is procedural, not technical, and produces a usable register in a meeting or two.

Ask for the full sub-processor list. A credible AI vendor will provide a current list of sub-processors on request, typically with the infrastructure provider (AWS, Azure, GCP), the model provider if different from the product vendor, the support-tooling providers (logging, analytics, helpdesk), and any downstream AI services. A vendor that will not provide the list, or provides only a summary, has given the firm a procurement-risk signal.

Map each sub-processor to a data category. For each sub-processor, the procurement team should establish which data the sub-processor sees. The infrastructure provider typically sees all data at rest. The model provider may see prompts and responses. The support-tooling providers typically see metadata. The firm's data-protection assessment should attach to the most sensitive data each sub-processor actually processes, not to the least sensitive.

Map each sub-processor to a processing location. For each sub-processor, the location of processing determines whether an international transfer is engaged. A UK-hosted infrastructure tier does not make the onward sub-processing UK-hosted; the logging provider in another jurisdiction is still an international transfer. The procurement team should be able to produce a location map in one page.

Check the sub-processor's own sub-processor chain. Each sub-processor is itself a controller or processor in its own right and has its own sub-processor list. A major cloud provider will publish the list; a smaller logging or analytics provider may not. The firm's due-diligence obligation cascades down the chain, diminishing with distance but not disappearing.

Confirm the change-notification mechanism. UK GDPR Article 28(2) requires the processor to notify the controller of intended changes to the sub-processor list, giving the controller an opportunity to object. The procurement contract should specify the notification mechanism, the notice period, and the termination right if the controller objects. A vendor contract that does not address this is silent on an obligation that attaches regardless.

The workshop we run on the AI Readiness Assessment follow-on and the 90-Day AI Enablement subscription produces a one-page sub-processor register template firms can use on every new AI procurement.

What have the ICO and NCSC said about AI procurement?

The ICO and NCSC have published guidance through 2024 and 2025 that together set out the UK public-sector expectation on AI procurement. Firms in the private sector are not directly bound by the public-sector procurement frameworks, but the guidance is the clearest indicator of where the ICO's enforcement posture is heading.

ICO guidance on AI and data protection. The ICO's AI and data protection guidance (refreshed through 2024) sets out how UK GDPR applies to AI systems, covering lawful basis, fairness, transparency, accuracy, rights, and accountability. The guidance is framed as the enforcement position the ICO will apply to AI processing in its regulatory activity. A firm that procured an AI tool without having read the ICO guidance has no answer to the question "did you consider the ICO's position" that the ICO is likely to ask in a compliance review.

ICO guidance on DPIAs for AI. The ICO's DPIA guidance (refreshed through 2024) includes specific worked examples on AI-specific high-risk processing, including automated decision-making, systematic monitoring, and large-scale special-category processing. The worked examples are closer to a procurement checklist than to an academic document and map cleanly onto mainstream AI procurements.

NCSC guidelines for secure AI system development. The NCSC published guidelines for secure AI system development in November 2023 (co-signed by counterparts in the United States and other jurisdictions) that set out security expectations on AI systems across the lifecycle. The guidelines are not regulatory, but they are the UK government's stated security position and inform the public-sector procurement frameworks. A private-sector firm procuring AI in 2026 that does not benchmark against the guidelines has foregone the clearest UK security benchmark available.

DSIT procurement guidance on AI (public sector). DSIT has published procurement guidance on AI for the public sector through 2024 and 2025. Private-sector firms are not bound by it, but firms that sell into the UK public sector will increasingly need to answer against the guidance, and firms that do not but share the same procurement questions can use the guidance as a template.

Read together, the four sources produce a usable benchmark. A UK firm procuring an AI tool can ask: does our procurement process address each of the areas the ICO and NCSC guidance identifies? If it does, the firm has a defensible posture; if it does not, the gap is identifiable and closable.

What a UK firm does next

The posture is available. It is a five-step sequence a Finance Director, Operations Director, or Data Protection Officer can complete across the next procurement cycle.

First, establish the AI procurement register. Every AI tool currently in use or under consideration at the firm, the owner, the data categories, the sub-processors, the processing locations, and the DPIA status. The register is a single sheet, not a programme.

Second, adopt a DPIA trigger test. A one-page decision tree that a procurement lead can run in ten minutes, answering: does this tool involve automated decision-making, systematic monitoring, special-category data, or data-source combination? Any yes triggers a DPIA.

Third, adopt a sub-processor interrogation template. A one-page template that goes out with every new AI procurement request, covering the five questions above. Vendors that will not answer cleanly are filtered out at this stage rather than at signature.

Fourth, update the procurement contract template. Standard clauses covering Article 28, sub-processor change notification, transfer mechanism, termination on objection, audit rights, and deletion on termination. A drafting session with the firm's external solicitor turns the current template into an AI-ready template; the effort pays back on every subsequent procurement.

Fifth, train the procurement team and the senior function owners. An operations-role treatment sits on AI for Operations; a finance-role treatment sits on AI for Finance Teams; a firm-wide governance treatment sits on AI Readiness for UK SMEs.

AI procurement is not going to get simpler over the next two years. What is going to happen is that the firms that built the due-diligence framework early will procure new AI tools in days rather than weeks, and the firms that did not will face a cumulative exposure that surfaces, eventually, in a data-subject access request, a regulator's compliance review, or a client procurement question. The five-step sequence above is not exotic. It is the procurement discipline a firm already applies to any other controller-level vendor, applied to a category of vendor whose data exposure is unusually high. The governance question is whether the discipline is documented, trained, and evidenced.