Five compliance obligations for UK supply chain AI in 2026

The awkward point in a 2026 supply-chain AI procurement is no longer whether the UK has passed a single AI Act. It has not. The more useful question is whether the planning or procurement system in front of the evaluation team can be defended against the regimes that already apply before the first automated forecast, supplier score, allocation recommendation, or warehouse labor decision goes live.

For UK manufacturers, retailers, and logistics operators, the practical impact of UK AI regulation on supply chain AI adoption is a deployment-timing issue. The evidence burden sits with the organization deploying the tool, not with the software vendor. A vendor can supply model cards, security papers, data-processing terms, and policy templates. It cannot prove that the user’s scheduling process has a meaningful human review point, that procurement teams know when an automated score can be overridden, or that EU-facing outputs have been classified correctly.

That matters because the live compliance map is fragmented. Five regimes now need to be checked during vendor selection, not after contract signature: UK automated-decision rules under the Data (Use and Access) Act 2025; the ICO’s forthcoming statutory AI code and existing automated decision-making guidance; the EU AI Act where EU markets, users, or outputs are in scope; competition and consumer enforcement under the CMA and the Digital Markets, Competition and Consumers Act; and third-party governance for SaaS AI platforms handling operational or personal data.

The five-regime map before go-live

A simple way to stop the discussion drifting is to put each candidate use case into a register before the shortlist hardens. Demand forecasting for SKU-level inventory may sit mostly in operational-risk and vendor-governance territory. Procurement scoring may involve supplier contacts, sole-trader data, or customer effects. Labor scheduling, route allocation, and performance-linked recommendations can move quickly into automated-decision safeguards if they affect workers.

The register does not need to become a legal treatise. It does need enough precision to stop a system being described as “forecasting” in the business case, “decision support” in the contract, and “fully automated allocation” in the operating procedure. Those mismatches are where late-stage governance work usually begins.

Articles 22A-22D change the automated-decision conversation

The Data (Use and Access) Act 2025 replaced Article 22 UK GDPR with Articles 22A-22D, effective February 5, 2026. The practical effect is a shift away from a default position of “not permitted unless” toward “permitted provided” safeguards are in place and evidenced for qualifying automated decisions involving personal data.[1][2]

That shift is easy to misread. It may make some automation more deployable, but it does not make it lighter to document. If a supply-chain AI tool ranks workers for shifts, recommends disciplinary-relevant performance actions, allocates work in ways that materially affect earnings, or scores individual customers or sole-trader suppliers, the team still has to show what decision is being made, what data is used, what safeguard applies, and how a person can challenge or obtain review of the decision.

The vendor-selection implication is immediate: ask the vendor to separate prediction, recommendation, and decision execution. A demand forecast that proposes a replenishment quantity is not the same control problem as a procurement workflow that automatically rejects a supplier or a labor tool that assigns overtime without review. The demo should show where the human reviewer sees the recommendation, what explanation they receive, whether they can override it, and whether the override is logged.

For a planning director, the decisive artifact is not a generic “responsible AI” slide. It is a decision map: inputs, model output, downstream action, affected person, review point, escalation route, and retained evidence. If the supplier cannot expose that chain, the deploying business will struggle to prove that the safeguard is real.

What to ask before the commercial shortlist is fixed

• Which workflows can make or materially influence decisions about identifiable people?
• Can automated execution be switched off separately from recommendation generation?
• Where is human review inserted, and what information does the reviewer receive?
• Are overrides, challenges, explanations, and final outcomes retained in an auditable log?
• Who inside the deploying organization owns the decision and has authority to pause go-live?

The ICO code is not drafted, but the documentation work cannot wait

A new statutory duty for the ICO to produce an AI code took effect on May 12, 2026, although the code itself has not yet been drafted. Existing ICO guidance on automated decision-making already signals expectations around human involvement and safeguards, but any claim about the final code’s exact content would be premature.[1]

That uncertainty should change the deployment plan, not freeze it. The sensible working assumption is that personal-data use, automated-decision safeguards, accountability records, and explainability evidence will need to be easier to retrieve than they usually are in a rushed ERP-adjacent rollout. If the code later requires less, the team has a cleaner file. If it requires more, the system is not already embedded without the basic records.

The vendor pack should therefore include more than a data-processing agreement. It should include the categories of personal data used, the training and inference separation if relevant, subprocessor details, model-change notification commitments, retention periods, access-control evidence, and a description of how explanations are generated for operational users. If the tool is sold as configurable, the file should also record which configuration the business actually deployed.

This is where many projects lose time. Procurement evaluates the platform as a product. Compliance later has to evaluate the deployed workflow. Those are not the same object. A forecasting module connected to historical sales, warehouse capacity, promotion calendars, and named account-manager notes has a different data profile from the same module demonstrated on a clean sample dataset.

The EU AI Act still matters for UK operators

A UK company does not escape the EU AI Act simply because its head office is outside the EU. UK manufacturers and logistics operators shipping into the EU may be caught where AI systems, users, products, or outputs fall within the Act’s extraterritorial reach.[3][4]

The timing is uneven. The May 7, 2026 Digital Omnibus agreement delayed high-risk standalone obligations to December 2, 2027, while transparency obligations from August 2, 2026, watermarking obligations from December 2, 2026, and the prohibited-practice ban remain live according to the cited supply-chain analysis. Maximum penalties under the EU AI Act can reach €35 million or 7% of global turnover.[3]

For supply-chain AI, the first step is role and exposure classification. A UK logistics operator using AI to generate customer-facing delivery communications in the EU faces a different obligation set from a manufacturer using AI internally to recommend safety-stock levels. A procurement platform that generates supplier-risk summaries may also create transparency questions if users cannot tell when they are reading AI-generated content.

Watermarking and transparency can sound like marketing-content issues until they land in day-to-day operations. Supplier letters, customer delay explanations, automated customs-support narratives, and tender-response drafts may all move through supply-chain platforms rather than standalone generative AI tools. The evaluation team should ask where generated text or media appears, whether it is labelled, whether metadata is retained, and whether the vendor can separate EU-facing from non-EU-facing workflows.

The high-risk delay should not be treated as a reason to postpone classification. If a system might fall into a high-risk category later, the contract needs the right evidence rights now: technical documentation, logging, risk-management support, post-market monitoring assistance, and notice before material model changes. Waiting until 2027 to ask for those rights is a weak negotiating position.

Competition and vendor-ecosystem risk belong in the same review

The CMA’s expanded powers under the Digital Markets, Competition and Consumers Act, along with its 80-person Data, Technology and Analytics unit, make AI vendor partnerships and market behavior more relevant to supply-chain technology selection than they were in a purely functional RFP.[1][5]

This does not mean every AI planning purchase becomes a competition-law project. It does mean commercial design choices deserve scrutiny when a platform bundles optimization, data services, partner marketplaces, and implementation services into a tightly controlled ecosystem. The risk may be switching difficulty, restricted data export, opaque pricing for AI add-ons, or dependence on one vendor’s preferred integration path.

A practical procurement file should record why the selected vendor does not create avoidable lock-in. That means testing data portability, model-output export, historical audit-log access, termination assistance, and whether the customer can use alternative analytics or integration partners without losing core functionality. These are operational resilience questions first. They also become useful evidence if a vendor relationship later comes under regulatory or commercial pressure.

Third-party AI due diligence is not a vendor checkbox

Most supply-chain AI projects in 2026 are not built from scratch. They sit inside SaaS planning suites, procurement platforms, transport-management systems, or analytics layers connected to ERP, WMS, TMS, CRM, and finance data. That makes third-party governance one of the main control points.

The due-diligence test should follow the deployed process. If the AI model ingests supplier performance, delivery failures, inventory movements, customer demand, and named-contact data, the file should show where that data goes, who can access it, which subprocessors touch it, how long it is retained, and how model changes are controlled. A security certification does not answer all of those questions.

The contract needs audit rights that match the risk. For lower-risk forecasting, periodic documentation and change notices may be enough. For systems influencing worker allocation, supplier exclusion, or EU-facing generated outputs, the deploying organization needs stronger rights: incident notification, material-change approval or objection rights, access to logs, support for data subject requests where applicable, and assistance with regulator-facing evidence.

Named ownership is the part that tends to look bureaucratic until something goes wrong. Someone inside the business must own the register entry, approve the risk classification, and have authority to stop deployment. If ownership is split vaguely between IT, procurement, legal, data protection, and the implementation partner, the control is already weaker than the policy says.

Why this affects adoption speed, not just legal risk

Regulatory uncertainty is already changing AI adoption behavior. In DSIT’s 2025 AI adoption research, 72% of UK businesses cited unclear or uncertain regulation as a significant barrier to AI adoption.[6] By June 2026, UK business AI adoption had risen to 29%, up from 21% a year earlier, according to Infor’s reporting of ONS data; Infor’s YouGov survey of 257 UK business leaders also found persistent barriers beyond experimentation.[7]

Those figures should be read carefully. They do not prove that regulation is the only, or even the main, reason individual supply-chain AI projects stall. They do explain a familiar boardroom pattern: teams want the productivity and planning gains, but they hesitate when nobody can say which rules apply, what evidence is needed, or who signs off the residual risk.

Governance spending is likely to keep rising, but the precise market numbers should not be overused without the original source. One supply-chain article cites Gartner as projecting global AI governance spending above $1 billion by 2030, from $492 million in 2026; because that figure is second-hand in the available material, it is best treated as directional rather than as a verified planning baseline.[3]

For an implementation team, the budget question is more immediate than the global market size. If automated-decision review, EU AI Act classification, privacy documentation, vendor audit rights, and lock-in analysis are discovered after the preferred bidder is chosen, the project either slows down or accepts weaker controls. Neither outcome is inevitable if the review is built into the selection gates.

A defensible deployment sequence

The sequence below is deliberately front-loaded. It is easier to ask for evidence, configuration commitments, and audit rights while vendors are competing than after the project team has already committed to a preferred architecture.

1. Create an AI register entry for each candidate use case, including the business owner, data categories, affected people, EU exposure, and whether the system predicts, recommends, or executes.
2. Classify automated-decision exposure under Articles 22A-22D before the demo script is finalized, so the vendor has to show review, override, explanation, and logging controls in the workflow that will actually be deployed.
3. Run the ICO documentation uplift in parallel with data protection and security review, while noting that the statutory AI code is not yet drafted and existing ADM guidance is only a guide to likely expectations.
4. Classify EU AI Act exposure by workflow, geography, user, and output type, including transparency and watermarking obligations that arrive before delayed high-risk standalone duties.
5. Test vendor lock-in and ecosystem dependencies, including data portability, audit-log retention, AI add-on pricing, integration restrictions, and termination support.
6. Complete third-party AI due diligence before contract signature, with audit rights, model-change controls, subprocessor visibility, incident notification, and regulator-support clauses matched to the risk level.
7. Assign an accountable internal owner with stop-deployment authority and record the final go-live decision against the register entry, not in a loose email chain.

This sequence does not treat fragmented regulation as a reason to avoid AI in planning or procurement. It treats it as an implementation constraint. The teams that handle the constraint early can keep vendor selection honest: a platform either supports the necessary controls in the deployed workflow, or it does not. Finding that out before commercial lock-in is not delay. It is what prevents the AI rollout from becoming a governance clean-up exercise after the system is already part of the operating rhythm.

References

1. UK AI Regulation in 2026: What’s in Force, What’s Coming, and What Your Business Should Do, Scaffold Digital, June 18, 2026
2. AI regulation in the UK: the role of the regulators, Bird & Bird, January 15, 2026
3. The AI Regulation Gap: Risk, Cost, and Competitive Advantage, SCMR, June 2026
4. EU’s AI Act adds new compliance tasks on businesses along the supply chain, Reed Smith
5. AI Watch: Global regulatory tracker - United Kingdom, White & Case
6. AI Adoption Research, Department for Science, Innovation and Technology, 2025
7. UK AI adoption barriers: beyond experimentation, Infor, April 2026