EU AI Act Article 16. Ten obligations providers must meet before a high-risk AI system reaches any deployer.

Article 16 functions as an index. Each of its ten points cross-references a more detailed article that specifies what the obligation actually requires. Reading Article 16 alone gives a compliance team a checklist structure. Reading it alongside the cross-referenced articles gives them the substance. This analysis covers both levels: what Article 16 requires in summary and what the implementing articles specify in detail, with a focus on the evidence deployers should be able to obtain from their providers.

Article 16(a): Compliance with Chapter III Section 2 requirements

The first obligation is the broadest: providers must ensure the system complies with the requirements set out in Chapter III Section 2 of Regulation (EU) 2024/1689. Those requirements span Articles 9 through 15 and cover the risk management system, data and data governance, technical documentation, automatic logging, transparency and provision of information to deployers, human oversight measures, and accuracy, robustness, and cybersecurity.

Article 16(a) does not create new substantive obligations. It ties the provider to the full Chapter III Section 2 framework and makes clear that these are pre-market requirements, not post-deployment options. A provider who places a high-risk AI system on the market that does not comply with Articles 9 through 15 has violated Article 16(a) at the point of market placement.

For deployers, Article 16(a) establishes the legal baseline they can point to in supply negotiations. The provider has a statutory obligation to deliver a system that meets these requirements. If the provider cannot supply documentation showing compliance with each of Articles 9 through 15, the deployer has a legitimate contractual basis to withhold acceptance and a regulatory basis to report the non-compliance to the relevant national market surveillance authority.

Article 16(b): Quality management system

Article 17, cross-referenced by Article 16(b), requires providers to put in place a quality management system covering eight specific areas. These are: the provider's strategy for regulatory compliance; the design and development methodologies and procedures; the system verification and validation procedures; the data management and examination procedures; the post-market monitoring system; the serious incident reporting procedures; the procedures for cooperating with national authorities; and the resource management and accountability arrangements.

The quality management system must be documented, implemented, maintained, and reviewed. It is not a one-time production exercise. A provider who created a quality management system at the time of conformity assessment and has not reviewed it since does not satisfy Article 17 on an ongoing basis.

For deployers, the quality management system is one of the strongest signals of provider governance maturity. A provider who can supply a current quality management system policy, with evidence of recent review, is demonstrating that they are operating the Article 17 requirement as a live governance capability rather than a document produced for the conformity assessment and filed away. Deployers should ask specifically whether the quality management system was reviewed in the twelve months preceding procurement.

Article 16(c) and (d): Technical documentation and logging

Article 16(c) requires providers to draw up technical documentation in accordance with Article 11 and Annex IV. This documentation is extensive: it covers the system's intended purpose, the description of the system including architecture and algorithms, the training methodology and datasets, the risk management measures adopted, the conformity assessment results, and the post-market monitoring plan.

The technical documentation under Article 11 is not supplied to deployers as a matter of course. It is the provider's internal record, held for regulatory inspection. What deployers receive is the instructions for use mandated by Article 13 and Annex XIII, which is a curated subset of the technical documentation designed for the deployer audience.

Article 16(d) requires providers to keep logs generated automatically by their systems, where those logs are accessible to the provider. This complements Article 12, which requires high-risk AI systems to have automatic logging capabilities. The logs generated during the provider's own testing and validation phases are part of the Article 16(d) record.

Deployers should confirm in procurement that the system has the automatic logging capabilities required by Article 12, and that they will have access to the logs generated during their operational deployment, at minimum for the retention periods that national legislation and sector-specific regulation require. For financial services deployers, the MiFID II and Basel III supervisory record-keeping obligations will typically set the applicable retention period.

Article 16(e): Conformity assessment

Article 16(e) requires providers to ensure the appropriate conformity assessment procedure has been carried out under Chapter V. Chapter V provides for two routes. Article 43(1) covers most Annex III systems through internal control: the provider self-assesses compliance with Chapter III Section 2 requirements and draws up the EU declaration of conformity. Article 43(2) requires third-party assessment by a notified body for specific high-risk categories, most notably biometric identification and certain law enforcement systems.

For deployers, the conformity assessment output is the EU declaration of conformity and, where applicable, the notified body certificate. Deployers should request a copy of the EU declaration of conformity for any Annex III system they procure. This document confirms that the conformity assessment was conducted, identifies the assessment procedure followed, and is signed by the provider or their authorised representative.

The declaration of conformity does not provide a guarantee that the system is compliant in the deployer's specific context. It confirms that the provider assessed the system as compliant with the requirements at the time of assessment, in the intended use context described in the technical documentation. If the deployer's use case differs from that intended context, the declaration does not cover the difference.

Article 16(f): EU database registration

Article 49, cross-referenced by Article 16(f), requires providers to register their high-risk AI systems in the EU database administered by the AI Office before placing the system on the market or into service. The registration record includes the provider's identity, the system's name and version, the intended purpose, the conformity assessment procedure followed, and the market surveillance authority contact.

Deployers can verify registration by searching the public EU database. As of the August 2026 enforcement date, any high-risk AI system in operation without a registration record is in breach of Article 49 and therefore Article 16(f). This is a publicly verifiable compliance signal that requires no negotiation with the provider. If the system cannot be found in the database, the provider has not completed their pre-market obligations.

Certain categories of public sector deployer also have registration obligations under Article 49(2). Public bodies using high-risk AI in Annex III Category 5 to 8 deployments must register their deployments in the database, in addition to the provider's registration of the system itself.

Article 16(g): Corrective action under Article 20

Article 20, cross-referenced by Article 16(g), addresses what happens when a provider discovers that a high-risk AI system they have placed on the market does not comply with the requirements or poses an unforeseen risk. The obligation is immediate: take corrective action to bring the system into conformity, withdraw it, or disable it. Inform distributors and deployers of the non-compliance. If the risk is to health, safety, or fundamental rights, notify the national market surveillance authority and the AI Office.

This obligation reinforces the importance of supply agreement provisions on notification. A provider who discovers a material system defect and does not notify the deployer is in breach of Article 20. Deployers should ensure their supply agreements require written notification within a specified period whenever the provider discovers or receives information indicating that the system may not comply with the Act or poses a newly identified risk in the deployer's sector.

Article 16(h) and (i): Authority cooperation and CE marking

Article 21, cross-referenced by Article 16(h), requires providers to cooperate with national competent authorities in any action taken in relation to a high-risk AI system, including investigations, audits, and requests for documentation. This obligation extends to deployers, who must also cooperate under their own Article 26 obligations.

Article 48, cross-referenced by Article 16(i), requires providers to affix the CE marking to high-risk AI systems before placing them on the market. The CE marking for AI systems confirms conformity with the AI Act, not only with any separate product safety legislation that may also apply. The marking must appear on the system or its accompanying documentation in a manner that is legible, visible, and indelible.

Article 16(j): EU representative for non-EU providers

Article 22, cross-referenced by Article 16(j), requires providers established outside the European Union to designate an authorised representative in the EU before placing a high-risk AI system on the EU market. The representative must be named in the technical documentation and the EU declaration of conformity, and must be contactable by national market surveillance authorities for regulatory purposes.

For deployers procuring high-risk AI from non-EU providers, the EU representative is the entity within the Union that national regulators can reach for enforcement purposes. Deployers should confirm who the EU representative is and include that entity in supply agreement notification chains. If a non-EU provider has not designated a representative, the importer or the deployer themselves may inherit representative obligations under Article 25.

The deployer checklist derived from Article 16

Based on the ten obligations in Article 16, deployers procuring high-risk AI should, before accepting a system, obtain or confirm the following from their provider. First, the instructions for use produced under Article 13 and Annex XIII, which are the deployer-facing output of the Article 16(c) technical documentation obligation. Second, a copy of the EU declaration of conformity confirming that the Article 16(e) conformity assessment was completed. Third, the EU database registration number confirming Article 16(f) compliance. Fourth, the name and contact details of the provider's EU representative where the provider is non-EU, confirming Article 16(j) compliance. Fifth, a written representation that the provider will notify the deployer of any material changes to the system or corrections triggered by Article 20, satisfying the deployer's interest in the Article 16(g) obligation.

These five documents and representations are the minimum Article 16 evidence package for a deployer procurement review. They do not substitute for a full technical due diligence on the system, but they confirm that the provider has completed the regulatory procedures required before market placement. Without them, the deployer is operating a system that may not be lawfully on the market.

The full deployer obligations under Article 26 explained on this site provides the complementary analysis: having confirmed that the provider has met Article 16, what must the deployer then do on their own account. The two articles together give compliance teams the complete picture of the provider-deployer responsibility chain under the EU AI Act.

On the insurance side, providers that can demonstrate Article 16 compliance produce documentation that is directly usable in AI insurance underwriting. The Munich Re aiSure underwriting process and the AIUC-1 certification standard both require evidence of conformity assessment, technical documentation, and risk management system governance. An Article 16 evidence package from the provider, combined with the deployer's own Article 26 documentation, creates the evidence base that makes a substantive underwriting submission possible rather than speculative.