Provider obligations and the value chain

The Article 16 obligation list

Article 16 sets out twelve duties that every provider of a high-risk AI system must fulfil 32024R1689 Article 16@2024-06-13. They span technical, documentary, and market-access dimensions:

• Technical compliance — the system must meet all requirements in Section 2 of the Regulation.
• Identification — the provider's name, registered trade name or registered trade mark, and contact address must appear on the system or, where not possible, on its packaging or accompanying documentation.
• Quality management — a quality management system conforming to Article 17 must be in place.
• Documentation — the technical documentation required under Article 18 must be kept.
• Logs — where logs automatically generated by their high-risk AI systems are under the provider's control, they must be retained in accordance with Article 19.
• Conformity assessment — the appropriate procedure under Article 43 must be completed before the system is placed on the market or put into service.
• EU declaration of conformity — a declaration must be drawn up in accordance with Article 47.
• CE marking — the CE marking must be affixed to the system or, where not possible, to its packaging or documentation.
• Registration — the provider must comply with the registration obligations under Article 49(1).
• Corrective action — necessary corrective actions must be taken and information provided as required by Article 20.
• Demonstration on request — upon a reasoned request from a national competent authority, the provider must demonstrate that the system meets Section 2 requirements.
• Accessibility — the system must comply with applicable Union accessibility directives 32024R1689 Article 16@2024-06-13.

The quality management system

Beyond the Article 16 checklist, providers must establish a documented quality management system (QMS) 32024R1689 Article 17@2024-06-13. The QMS must take the form of written policies, procedures, and instructions, and cover at minimum the following areas: a regulatory compliance strategy including compliance with conformity assessment procedures and management of modifications; design control and verification techniques; development quality control and quality assurance procedures; pre-, during-, and post-development testing and validation schedules with their required frequency; applicable technical specifications and standards, with compensating measures where harmonised standards do not fully cover the requirements; data management across the full data lifecycle — acquisition, collection, analysis, labelling, storage, filtering, mining, aggregation, retention, and related operations; the risk management system under Article 9; post-market monitoring; serious incident reporting procedures; communication with national competent authorities, other relevant authorities, including those providing or supporting the access to data, notified bodies, other operators, customers, and other interested parties; record-keeping systems; resource management including supply-security measures; and an accountability framework assigning responsibilities to management and other staff 32024R1689 Article 17@2024-06-13.

The QMS obligation is proportionate to the size of the provider's organisation, but the degree of rigour must remain sufficient to ensure compliance. Providers already subject to QMS obligations under sectoral Union law may integrate the Article 17 requirements into those systems. Financial institutions subject to internal governance requirements under Union financial services law satisfy the QMS obligation through those governance rules, except for the risk management, post-market monitoring, and serious incident reporting elements, which remain separate 32024R1689 Article 17@2024-06-13.

When others become the provider: the Article 25 value chain rules

Provider obligations do not remain permanently attached to the party that first placed a system on the market. Article 25 identifies three circumstances in which a distributor, importer, deployer, or other third party becomes the provider and assumes the full Article 16 obligation set 32024R1689 Article 25@2024-06-13:

1. Re-branding — they put their name or trademark on a high-risk AI system already on the market or in service, even where contractual arrangements have otherwise allocated obligations.
2. Substantial modification — they make a substantial modification to a system already on the market or in service such that it remains a high-risk AI system under Article 6.
3. Purpose change — they modify the intended purpose of an AI system — including a general-purpose AI system — that was not previously classified as high-risk and has already been placed on the market or put into service, in a way that renders it high-risk under Article 6.

When any of these circumstances arises, the original provider is no longer considered the provider of that specific system for the purposes of the Regulation 32024R1689 Article 25@2024-06-13. The original provider retains a cooperation duty, however: it shall closely cooperate with new providers and must make available the necessary information and provide the reasonably expected technical access and other assistance to enable the new provider to fulfil its obligations — unless the original provider has clearly specified that the system is not to be changed into a high-risk AI system, in which case paragraph 2 as a whole — including the provider-status rule and the cooperation duty — does not apply.

Where a high-risk AI system functions as a safety component of a product covered by Union harmonisation legislation listed in Section A of Annex I, the product manufacturer becomes the provider if the system is placed on the market together with the product, or put into service, under the manufacturer's name or trademark 32024R1689 Article 25@2024-06-13.

Contractual governance of the value chain is also addressed: the provider of a high-risk AI system and the third party that supplies an AI system, tools, services, components, or processes that are used or integrated in a high-risk AI system shall, by written agreement, specify the necessary information, capabilities, technical access and other assistance based on the generally acknowledged state of the art, in order to enable the provider of the high-risk AI system to fully comply with the obligations set out in this Regulation 32024R1689 Article 25@2024-06-13. This requirement does not apply to third parties making accessible to the public tools, services, processes, or components under a free and open-source licence, other than general-purpose AI models 32024R1689 Article 25@2024-06-13.

This block connects to your organisation's own AI governance policy. In the full product it shows, cited to your policy, how YOUR organisation implements the regulation above — private to your organisation. (Demo placeholder.)

The cases below are labeled as illustrative context only and are not regulatory decisions under the EU AI Act.

Provider suspension in response to regulatory deadlines CASE-1CASE-2

In July 2026, major Chinese AI providers — including ByteDance's Doubao, Alibaba's Qwen, and Tencent's Yuanbao — suspended custom AI agent and companion features ahead of a national regulatory deadline on AI systems exhibiting human-like personalities CASE-1CASE-2. The episode illustrates, outside the EU framework, how providers must take concrete product-level action when regulatory requirements change the permissible operating envelope of a deployed system. Under the EU AI Act, a structurally similar scenario arises when a deployer or distributor modifies an AI system's intended purpose such that it crosses into high-risk classification: Article 25 designates that party the new provider, and the full Article 16 obligation set — including a fresh conformity assessment — must be completed before the modified system remains in service.

Provider accountability and audit scrutiny CASE-3

A billing-audit service launched in mid-2026 targets token-spend billing errors from major AI providers and has positioned itself as a recovery mechanism for enterprise customers CASE-3. While token billing accuracy is distinct from the QMS and conformity requirements of Articles 16 and 17, the emergence of this kind of third-party audit signals that deployers are increasingly seeking verifiable, granular records of AI system usage. The Article 17 requirement for systematic record-keeping systems and resource management documentation within the QMS reflects the same underlying expectation at the regulatory level: that providers maintain auditable control over how their systems are operated and charged for across the value chain.