Supplier Evidence for EU AI Act Product Compliance in 2026

AI Trust & Governance

25 July 2026 | By Ashley Marshall

The EU AI Act will hit many UK firms through the supply chain first. Product teams need evidence packs customers can actually use.

The 2026 compliance problem is a supply chain problem

For many UK businesses, the EU AI Act will not first arrive as a direct letter from a regulator. It will arrive as a supplier questionnaire from a manufacturer, distributor, importer, notified body, EU customer, procurement team or insurer asking for evidence about an AI feature inside a product. That is the practical shift to prepare for in 2026. If your product uses AI to detect, classify, recommend, control, triage, optimise or alert, the commercial question becomes simple: can you prove what the AI does, where it came from, how it was tested, who monitors it, and how changes are controlled?

The reason is buried in the product compliance logic of the Act. The official Regulation (EU) 2024/1689 applies to providers, deployers, importers, distributors and product manufacturers placing AI systems on the EU market. It also covers providers and deployers outside the EU where the output of an AI system is used in the Union. The Commission describes the Act as a risk-based framework, with high-risk systems subject to obligations around risk management, data quality, logging, technical documentation, human oversight, robustness, accuracy and cybersecurity. Those are not marketing claims. They are evidence categories.

This matters especially where AI is embedded in a physical or regulated product. Article 6 treats an AI system as high-risk where it is intended to be used as a safety component of a product, or is itself a product, covered by Union harmonisation legislation listed in Annex I and the product requires third-party conformity assessment before being placed on the EU market. The Commission gives examples such as AI-based safety components of products and robot-assisted surgery. It also says high-risk rules for systems embedded into regulated products have a longer transition path than many other AI Act duties.

What this means in practice is that UK suppliers should stop treating AI evidence as an optional appendix to product files. It belongs in the same operating rhythm as technical documentation, supplier declarations, design change records, cybersecurity assurance and post-market surveillance. The buyer may be the visible product manufacturer, but your model card, test evidence, incident process and update policy may decide whether their compliance file is complete enough to sell into the EU.

Sources: Regulation (EU) 2024/1689 and the European Commission AI Act overview.

The dates are phased, but supplier pressure starts earlier

One common mistake is to read the AI Act timetable as permission to wait. That is risky. The Commission states that the AI Act entered into force on 1 August 2024 and will become fully applicable two years later, on 2 August 2026, subject to exceptions. Prohibited AI practices and AI literacy obligations applied from 2 February 2025. Governance rules and obligations for providers of general-purpose AI models applied from 2 August 2025. Transparency obligations apply from August 2026. The Commission also explains that high-risk AI systems embedded into regulated products have an extended transition period, currently described as 2 August 2028 following simplification changes.

For a UK board, procurement team or product owner, those dates should not be treated as a single compliance deadline. Product evidence does not appear overnight. Supplier records, data provenance, risk management files, quality management processes, cybersecurity controls and post-market monitoring plans need to be designed, gathered, checked and kept current. If a customer needs your evidence to support their own conformity assessment, they will ask long before the formal deadline because they cannot leave their own product launch, CE marking, notified body review or market access decision to the final quarter.

There is a second timing issue. The AI Act is not the only system affecting UK firms. OPSS guidance says manufacturers and importers placing products on the UK market need to minimise risks, generate and keep technical documentation, place appropriate labelling on products and provide safe-use instructions. It also notes that businesses bringing products into Great Britain from the EU are likely to be importers rather than distributors, with extra legal responsibilities. That UK product compliance mindset maps closely to the evidence discipline needed for AI features, even though the UK has chosen a different AI regulatory model.

What this means in practice is that a 2026 readiness programme should be built backwards from commercial milestones, not from legal dates alone. If your EU customer plans a 2027 product launch, they may need your supplier pack in 2026. If the AI component might affect health, safety, product control, user warnings or regulated decision flows, evidence gathering should be treated as part of release management. The earlier question is not whether the regulator has knocked. It is whether your customer can ship with you in the supply chain.

Sources: European Commission AI Act application timeline and GOV.UK OPSS product safety advice for businesses.

What evidence customers will ask suppliers to provide

Supplier evidence for AI Act product compliance should be practical, versioned and mapped to the role you play in the product chain. A small UK company selling an AI inspection module into an EU machinery product will not have the same obligations as the final manufacturer, but it may still need to provide evidence that allows the manufacturer, importer or authorised representative to complete their own file. The evidence should answer four questions: what is the AI system, what risk does it create, how was that risk controlled, and what happens after release?

A strong supplier pack normally starts with system identity. That means intended purpose, version, model or algorithm family, inputs and outputs, user interface, operating constraints, dependencies, integration assumptions and known limitations. The AI Act defines intended purpose by reference to provider information, including instructions for use, promotional or sales materials and technical documentation. That means product teams should be careful that sales claims, manuals and technical evidence tell the same story. If the brochure says the system detects dangerous faults, the compliance file cannot describe it as a convenience feature.

The next layer is risk and test evidence. High-risk AI obligations in the Act include risk management, data governance, technical documentation, record keeping, transparency, human oversight, accuracy, robustness and cybersecurity. In product contexts, customers are likely to ask for risk registers, validation summaries, test coverage, accuracy limitations, false positive and false negative handling, foreseeable misuse analysis, human override design, logging behaviour, incident triggers, supplier change notification terms and support arrangements. They may also ask whether the AI feature uses a third-party model, cloud API, open-source component or externally hosted service.

The third layer is lifecycle evidence. Article 11 says technical documentation for a high-risk AI system must be drawn up before the system is placed on the market or put into service and kept up to date. Article 18 requires providers to keep specified documentation, including technical documentation and quality management records, for 10 years after a high-risk AI system has been placed on the market or put into service. Even where a UK supplier is not the formal provider under the Act, EU customers will often flow down similar retention and update obligations through contract. That is where many 2026 supplier conversations will become commercial rather than purely legal.

Sources: Articles 11 and 18 of Regulation (EU) 2024/1689.

UK firms need a dual lens, not two separate files

The UK has not copied the EU AI Act. GOV.UK's AI regulation white paper set out a pro-innovation, context-based approach underpinned by five cross-cutting principles: safety, security and robustness, appropriate transparency and explainability, fairness, accountability and governance, and contestability and redress. It also said the UK would not initially put those principles on a statutory footing, preferring implementation through existing regulators. That creates a different legal structure, but it does not remove the need for disciplined evidence if a UK company sells products, components or AI-enabled services into EU markets.

This is the point many suppliers miss. Compliance teams sometimes ask, 'Are we governed by UK rules or EU rules?' The better question is, 'Which market, role and product chain are we serving?' A UK business may develop the AI in Britain, host the model in Britain, contract under English law and still need evidence because an EU customer places the finished product on the Union market. The AI Act also reaches some providers and deployers outside the EU where the output produced by the AI system is used in the Union. In practical terms, location alone is not a neat escape route.

The dual lens should be operational, not duplicative. The UK principles can become the organising structure for internal governance, while the EU AI Act evidence categories become the outward-facing product compliance pack. Safety, security and robustness map naturally to risk controls, testing, incident processes and resilience. Transparency and explainability map to instructions for use, limitations and human oversight. Accountability and governance map to ownership, supplier contracts, approval records and change control. Contestability and redress map to complaint handling, escalation and user challenge routes where the AI affects people.

What this means in practice is that UK firms should build one evidence base with market-specific mappings. A supplier questionnaire should not trigger a frantic new document every time. Instead, maintain a controlled evidence library: system description, data note, model note, risk register, validation report, cybersecurity note, change log, incident plan, deployment instructions and customer-facing limitations. Then map that library to UK regulator expectations, EU customer requests and sector-specific product rules. The win is not a thicker file. It is a file your commercial team can trust under pressure.

Sources: GOV.UK AI regulation white paper.

Cybersecurity and data protection are part of the product evidence pack

AI product evidence is not only about model performance. It also has to cover the security and data protection assumptions that make performance trustworthy in the real world. NCSC's Guidelines for secure AI system development are aimed at providers of any systems that use AI, including systems built on top of tools and services provided by others. The guidance is organised around secure design, secure development, secure deployment, and secure operation and maintenance. It explicitly includes supply chain security, documentation, asset management, logging, monitoring, update management and information sharing.

DSIT's AI Cyber Security Code of Practice, published on 31 January 2025, makes the same point in a policy form. GOV.UK says the code sets baseline cyber security principles to help secure AI systems and the organisations that develop and deploy them. It also says DSIT, working with NCSC, will submit the code and implementation guide into ETSI as the basis for a new global standard, TS 104 223, and accompanying implementation guide, TR 104 128. For UK suppliers, this is useful because it gives a credible structure for answering EU customer questions about AI security controls without pretending the AI Act is the only relevant source.

Data protection evidence also belongs in the pack where personal data is used. The ICO's AI guidance points organisations to resources on AI and data protection, explaining decisions made with AI, biometric recognition and an AI and data protection risk toolkit. The AI Act does not replace UK GDPR or EU GDPR duties. If your product uses images, voice, worker data, patient data, driver behaviour, customer profiles or biometric signals, a buyer will expect data minimisation, lawful basis, data quality, retention, explainability and rights handling to be coherent with the AI technical story.

The practical supplier pack should therefore include a short security and privacy schedule. It should identify model hosting, access control, dependency management, logging, prompt or input protection where relevant, vulnerability handling, incident contacts, data sources, personal data categories, retention periods, sub-processors and cross-border transfer assumptions. This does not need to become a 90-page report for every product. It does need to be specific enough that a product manufacturer can rely on it, challenge it, and update it when the AI feature changes.

Sources: NCSC Guidelines for secure AI system development, GOV.UK AI Cyber Security Code of Practice and ICO AI guidance.

The counterargument: we only buy the AI, so the supplier owns compliance

The most common counterargument is understandable: 'We do not build the model. We only buy an AI component or API, so compliance is the supplier's problem.' That may be partly true for some technical obligations, but it is commercially dangerous as a product strategy. The AI Act's operator model recognises multiple roles across the value chain, including providers, product manufacturers, deployers, importers and distributors. A party can also assume provider obligations in specific circumstances, such as putting its name or trademark on a high-risk AI system already placed on the market or making certain substantial modifications.

Product manufacturers should be particularly careful. The Act states that where a high-risk AI system that is a safety component of a product covered by listed Union harmonisation legislation is not placed on the market or put into service independently from the product, the product manufacturer should comply with provider obligations. In plain English, if the AI is inside your product and your product goes to market under your name, you may not be able to point vaguely at an upstream AI vendor and call the job done. You still need a product-level compliance story.

The same logic applies to UK suppliers selling into EU product chains. You may not be the final regulated manufacturer, but your customer's evidence file will depend on you. If your contract says you must notify changes, provide technical documentation, maintain security controls, support incident investigations or preserve logs, those duties are real even if they are contractual rather than direct statutory duties. The legal label matters, but the commercial evidence burden often arrives through procurement, quality assurance and supply chain contracts first.

A balanced view is important. Not every AI feature is high-risk. The Commission says the vast majority of AI systems currently used in the EU fall into minimal or no risk categories, with examples such as AI-enabled video games or spam filters. Many product features will remain outside the strictest obligations. But that is not an argument for doing nothing. It is an argument for classification. Make a reasoned assessment, record why the feature is out of scope or lower risk, and keep enough evidence to defend that decision when a customer, insurer or regulator asks. The misconception is that compliance begins only when a lawyer declares the system high-risk. In practice, commercial trust begins when you can show your workings.

Sources: Regulation (EU) 2024/1689 operator provisions and European Commission AI Act risk categories.

Frequently Asked Questions

Does the EU AI Act apply to UK companies?

It can. A UK company may be affected where it places an AI system on the EU market, supplies into an EU product chain, has AI outputs used in the Union, or supports an EU customer that must evidence compliance.

Does every AI feature in a product become high-risk?

No. Classification depends on intended purpose, product context and the AI system's role. AI used as a safety component in certain regulated products is much more likely to trigger high-risk evidence requirements.

What should a supplier evidence pack include first?

Start with intended purpose, system version, inputs and outputs, integration assumptions, known limitations, risk classification, validation evidence, cybersecurity controls, human oversight, incident handling and change control.

Do UK firms need a separate EU compliance file?

Usually they need one controlled evidence base with EU mappings, not a completely separate file. The same records can support UK governance, customer due diligence and EU product compliance if they are structured properly.

What if the AI model is bought from a third-party vendor?

You still need evidence about how the vendor system is used in your product, what assumptions you rely on, what data flows through it, how changes are managed and what your customer can safely claim.

When should product teams start preparing?

In 2026, before procurement questionnaires and customer audits arrive. Evidence gathering should be tied to product release gates, EU sales plans and supplier contract reviews.

Is this only a legal department issue?

No. Legal can interpret obligations, but product, engineering, quality, cybersecurity, data protection, procurement and sales all own parts of the evidence customers will ask for.

What is the biggest misconception?

The biggest misconception is that compliance can be passed entirely upstream to the AI vendor. In product chains, customers need a product-level story that explains how the AI behaves in the actual product and market context.