Most organisations placing AI on the EU market, or deploying it in EU processes, do not build every system they use. They buy models, platforms, scoring engines, cloud services and data sets from suppliers. Under the EU AI Act, the legal and operational consequences of that use still sit with the organisation that puts the system into a process affecting people or the business.
A supplier impact assessment is the structured examination of what a third-party AI system or component does, what it may do to people and to the organisation, and whether the supplier arrangement is adequate for that use. The Act does not use that heading. The duties in Articles 13, 25, 26 and 27 still require the work whenever a high-risk or otherwise regulated system, model or component comes from outside.
Why supplier assessments are necessary
An AI supplier typically controls training data, model behaviour, updates, subprocessors, logging and the location of processing. The customer controls the decision to use the system, the process in which it runs, and often the personal information fed into it. Harm and non-compliance can arise from either side - or from the gap between them.
A conventional vendor security questionnaire is not enough. It may cover access control and encryption. It rarely examines intended purpose, risk classification, effects on individuals, human oversight, change after deployment, or who holds which legal role.
A supplier impact assessment therefore looks at two things together:
- the impact of the supplied system in the intended use
- the adequacy of the supplier to support that use lawfully and safely
What the assessment should cover
A complete assessment usually addresses the following.
The system and its intended purpose
What the supplier's product does; whether it is an AI system, a general-purpose model, a component, or a service wrapped around one; and the purpose for which the organisation intends to use it. Purpose drift is a common failure: a tool sold for "productivity" is used to rank people for jobs or credit.
Legal roles
Who is provider, deployer, importer, manufacturer, responsible party, controller or processor. Roles change if the customer rebrands the system, substantially modifies it, or changes its intended purpose. Getting the role wrong is getting the duty wrong.
People likely to be affected
Applicants, customers, employees, patients, claimants or the public, including groups who may be disadvantaged by the use.
Impacts and risks
Effects on rights, safety, fairness, privacy, security and operational continuity. This includes risks that arise from the supplier's model and from the customer's process.
Data
What personal or other data the supplier receives, where it is processed, whether it is used to train or improve models, which subprocessors are involved, and how long it is kept.
Information the supplier can actually provide
Instructions for use, limitations, performance and known risks, logging capability, update practices, and evidence of testing. If the supplier cannot explain the system well enough for the customer to assess impact, that is itself a finding.
Oversight and response
Whether a competent person in the customer organisation can interpret outputs, intervene or stop use, and whether the supplier will support incident response, complaints and regulatory enquiries.
Change and dependency
How updates, model changes and service withdrawal are handled, and what happens if the supplier fails or is acquired.
Contractual allocation
What is written down about roles, information, access, audit, data use, notification and assistance. A contract cannot always move a statutory duty, but it can make performance of that duty possible.
The EU AI Act
The AI Act does not use the heading "supplier impact assessment." It does impose duties that make such an assessment necessary whenever a high-risk or otherwise regulated system, model or component is obtained from a third party.
Roles along the value chain (Article 25)
A distributor, importer, deployer or other third party is treated as the provider of a high-risk AI system if they:
- put their name or trademark on a high-risk system already on the market, or
- make a substantial modification that leaves it high-risk, or
- change the intended purpose of a system, including a general-purpose AI system, so that it becomes high-risk.
In those cases the original provider is no longer the provider of that system for the Act, but must cooperate and provide the information, technical access and assistance reasonably needed for the new provider to meet its obligations.
Article 25 also requires the provider of a high-risk system and a third party that supplies systems, tools, services, components or processes used or integrated in that high-risk system to agree in writing on the information, capabilities, technical access and other assistance needed for the provider to comply. Intellectual property and confidentiality are to be protected in that process.
Transparency for deployers (Article 13)
Providers of high-risk systems must give deployers information and instructions sufficient to understand the system and use it as intended. A supplier assessment tests whether that information exists and is usable in the customer's context.
Deployer obligations (Article 26)
The organisation that uses the system under its authority must follow the instructions for use, assign competent human oversight, monitor operation, keep logs under its control, and report serious incidents. Those duties cannot be performed if the supplier relationship has not been examined.
Fundamental rights impact assessment (Article 27)
Specified deployers must assess fundamental-rights impact before first use of certain high-risk systems. That assessment must take account of information from the provider. Where the system is supplied, the FRIA and the supplier assessment overlap: one cannot be completed properly without the other. The FRIA article on this site sets out what Article 27 itself requires; the supplier assessment is how the deployer tests whether the third party can support that work.
General-purpose AI
Providers of general-purpose AI models must give downstream providers documentation that enables integration and compliance. Organisations that embed a third-party model in a high-risk system need that documentation as part of the supplier assessment.
For organisations placing products on the EU market or deploying high-risk systems there, a supplier impact assessment is how these value-chain duties are made operational before the system is used. Where the organisation also operates an EN 18286 quality management system, the same records - roles, information received, change, incidents and residual decisions - belong in that system rather than in a one-off procurement file.
When it should be done
Assess before first use of a supplied AI system or component in a process that affects people, regulated decisions, or material operations. Repeat or update when:
- the intended purpose changes
- the supplier changes the model, data practice or subprocessors
- the customer fine-tunes, rebrands or substantially modifies the system
- monitoring or incidents show new harm or dependency
- the legal role of either party changes
A one-off procurement check that is never revisited will not keep pace with systems that learn or are updated under the supplier's control.
What "adequate" looks like in practice
An assessment that can be defended will:
- identify the supplier, the system or component, and the intended use
- state the legal roles of both parties
- identify affected persons and groups
- record specific impacts and risks, not only generic AI concerns
- record what information the supplier has given and what is missing
- describe oversight, logging, incident and complaint arrangements
- record data flows, training use, locations and subprocessors
- result in a written allocation of information, access and assistance
- lead to a clear decision: use, use with conditions, or do not use
- be updated when the facts change
If the supplier cannot provide enough information for that work, the organisation is not ready to deploy. Using the system anyway is a decision to accept impact that has not been assessed.
Summary
AI supply chains concentrate capability in a small number of vendors and then distribute effects across many organisations and many people. The EU AI Act, GDPR, the revised Product Liability Directive and EN 18286 all require the organisation that uses the system to understand those effects. Voluntary frameworks such as the NIST AI RMF describe a similar expectation in other markets; they are not a substitute for the Act.
A supplier impact assessment is how that requirement is met in practice. It examines the system, the people it may affect, and the supplier relationship that will have to support lawful and safe use after the contract is signed. Without it, later assessments - privacy, fundamental rights, risk or conformity - rest on assumptions the supplier has never been asked to prove.
Ready to turn this assessment into a working process?
Explore the Platform