Does Using a Third-Party AI Vendor Shift EU AI Act Responsibility Away from the Deployer?

Provider and deployer duties are separate

The EU AI Act allocates duties by role. The provider places the system on the market or puts it into service and supplies the instructions for use that accompany it. The deployer is the party that uses the system. The Commission describes the post-market split this way: authorities handle market surveillance, deployers ensure human oversight and monitoring, providers keep a post-market monitoring system, and providers and deployers report serious incidents and malfunctioning.

Two Article 26 duties are central for a deployer of a high-risk system. Article 26(1) requires appropriate technical and organisational measures to ensure the system is used in accordance with the instructions for use. Article 26(2) requires human oversight to be assigned to natural persons who have the necessary competence, training and authority, as well as the necessary support. The recitals add that deployers should ensure those persons have an adequate level of AI literacy, and that further obligations apply to monitoring the functioning of AI systems and to record-keeping, as appropriate.

Article 26(3) states that these obligations are without prejudice to other deployer obligations under Union or national law, and to the deployer's freedom to organise its own resources and activities to implement the human oversight measures indicated by the provider. The provider's conformity work does not discharge any of this. It describes the system. Article 26 assesses how the deployer actually runs it.

When a deployer is treated as a provider

The Act says any distributor, importer, deployer or other third party is considered a provider of a high-risk AI system, and is subject to the provider obligations under Article 16, in listed circumstances. Recital 11 explains the purpose: legal certainty, so that the party in that position assumes all the relevant obligations.

One listed circumstance is putting your name or trademark on a high-risk AI system already placed on the market or put into service. This matters for white-labelling and rebranding. A regulated enterprise that offers a vendor's system to customers or staff under its own brand should review that decision against Article 25 before launch, not after.

The provision is stated to be without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated. Contracts are therefore expressly relevant to this reclassification trigger. That is a narrow statement about this provision. It is not a general rule that contracts can reassign Article 26 duties.

What vendor material can cover and what the deployer must show

Vendor documentation and contracts are useful inputs. They do not replace the deployer's own demonstration of how the system was used.

• Instructions for use: Vendor supplies them. The deployer must show its use followed them and that technical and organisational measures enforce this.
• Human oversight design: Vendor indicates the measures. The deployer must show named people with competence, training, authority and support.
• Conformity claims: Vendor asserts them. They do not remove Article 26 duties, which sit alongside other deployer obligations under Union or national law.
• Post-market monitoring system: Provider obligation. The deployer separately monitors functioning and keeps records of use.
• Supplier agreements: The Act's written-agreement provision runs between the provider and its suppliers. Deployers negotiate their own access to information and records.
• Indemnities: Commercial risk allocation. Do not treat them as a transfer of regulatory accountability.

What contracts can and cannot do

The consolidated text requires the provider of a high-risk system and the third party supplying AI systems, models, tools, services, components or processes integrated in it to specify by written agreement the information, capabilities, technical access and other assistance the provider needs to comply fully. That provision is addressed to the provider and its suppliers. It gives a deployer no rights by itself.

For procurement, this suggests a practical split. Use the contract to secure what the deployer needs to meet its own duties: instructions for use in a form that can be mapped to controls, information about system functioning, and access to records of use. Use indemnities and warranties for what they are, a way to allocate financial risk between the parties. The material on Article 26 gives no indication that an indemnity changes who is accountable to a regulator.

It also helps to ask the vendor what its own agreements with suppliers contain, and what information and assistance reach the deployer as a result.

Where runtime enforcement fits, and timing

Trussed enforces policy in the execution path of models, agents, tools and MCP servers. Each interaction or tool call can be allowed, redacted, blocked or escalated for human approval, and the enforcement produces audit-ready evidence mapped to the EU AI Act. This supports the deployer-side work described above: limiting what a third-party system is permitted to do and keeping a record of what it did. Deployment is self-managed in the customer cloud, with configurable retention and data residency, so the records stay under the deployer's control. It does not change the provider's obligations or replace the deployer's own oversight arrangements.

On timing, the Commission states that obligations for high-risk AI systems apply from 2 December 2027, as of November 2026. The consolidated text has been amended since original publication, so confirm dates against the current text. The controls above take time to design and evidence, so building them before the application date is the practical course.