EU AI Act Article 16: Obligations of Providers of High-Risk AI Systems

Article 16 of Regulation (EU) 2024/1689 is the master checklist for providers of high-risk AI systems. If you develop a high-risk AI system — or if you put your name on one, substantially modify one, or change its intended purpose (see Article 25) — Article 16 is the starting point for everything you must do before and after placing that system on the market.

The obligations run across thirteen distinct requirements. Each points to a more detailed article in Section 2 of Chapter III. This guide maps every obligation, explains what it means in practice, and covers who qualifies as a provider under the role-shift rules.

Under the Digital Omnibus agreed in May 2026, the high-risk provider obligations apply from 2 December 2027 for stand-alone Annex III systems, and from 2 August 2028 for high-risk AI that is a safety component of a product covered by EU product law (Annex I). The original date — 2 August 2026 — has been deferred. That is breathing room, not a reprieve: assembling a complete technical file alone typically takes several months.

---

Who is a "provider" under Article 16?

A provider is any natural or legal person that develops a high-risk AI system, or has one developed, and places it on the EU market or puts it into service under their own name or trademark — whether for payment or free of charge.

In plain terms: if you built it and ship it under your brand, you are the provider. Article 16 is your list.

Article 25 widens the circle. A distributor, importer, or deployer becomes a provider — and inherits the full Article 16 obligations — if they:

• place a high-risk AI system on the market under their own name or trademark;
• make a substantial modification to a high-risk AI system already on the market; or
• change the intended purpose of a system in a way that makes it high-risk when it was not previously so classified.

The practical consequence: a SaaS company that takes a third-party model, rebrands it, and sells it to clients as their own product becomes the provider. A company that fine-tunes a general-purpose model for a specific high-risk use case and ships it under their own name becomes the provider. The label on the product determines the obligation, not who originally built the underlying model.

---

The thirteen obligations of Article 16: what each requires

1. Ensure the system meets the Section 2 requirements (Articles 8–15)

The first obligation points to the entire technical backbone of high-risk compliance: Articles 8 through 15. Each covers a distinct requirement:

• Article 8 — the chapeau obligation to comply with all Section 2 requirements throughout the system's lifecycle.
• Article 9 — establish and operate a risk management system: iterative, documented, covering foreseeable risks to health, safety, and fundamental rights throughout the lifecycle.
• Article 10 — implement data and data governance standards for training, validation, and testing datasets: relevance, representativeness, absence of errors, appropriate statistical properties, checks for bias.
• Article 11 — compile and maintain technical documentation before market placement (see Annex IV for the full content list). The documentation must enable assessment of conformity and must be kept up to date.
• Article 12 — build in record-keeping capability: automatic logging of events throughout the operational lifetime, to the extent technically feasible.
• Article 13 — provide transparency information to deployers before the system is used: identity of the provider, capabilities and limitations, performance in specific populations or geographical areas, human oversight measures, and the data the system was trained on where relevant.
• Article 14 — design for human oversight: enable the people overseeing deployment to understand the system's capabilities and limitations, disregard or override outputs, interrupt or halt the system.
• Article 15 — achieve appropriate levels of accuracy, robustness, and cybersecurity throughout the lifecycle, including resilience against attempts to alter system behaviour.

These are not a sequential to-do list. They form an integrated system that must be in place before the system goes to market and maintained continuously while it is in service.

2. Labelling: indicate provider identity on the system or its packaging

Providers must indicate their name, registered trade name or registered trademark, and contact address either on the high-risk AI system itself or, where that is not possible, on its packaging or the accompanying documentation. This is the EU's minimum traceability requirement — any market surveillance authority, notified body, or user can identify who to contact.

For a SaaS product, this means the provider's legal entity name and a reachable contact address must appear in the product documentation or interface. A company trading as "Acme AI" must ensure that its legal name (e.g. Acme GmbH) and a contact email or postal address are clearly visible.

3. Operate a quality management system (Article 17)

Article 17 requires providers to establish, implement, document, and maintain a quality management system (QMS). The QMS must cover the full lifecycle: design, development, testing, deployment, and post-market monitoring.

Required elements include documented policies on regulatory strategy; procedures for design and development including risk assessment at each stage; testing methodologies; post-market monitoring plans; and corrective/preventive action procedures. Proportionality applies: the QMS for a 12-person HR-tech startup is not the same volume as for a 500-person enterprise, but it must cover the same categories.

The QMS is the management spine that holds the other obligations together. Without it, even well-documented systems lack the governance layer regulators expect to see.

4. Keep the technical documentation (Article 11)

The technical documentation must be compiled before market placement and kept up to date for as long as the system is on the market, then retained for ten years after the last unit was placed on the market or put into service. Annex IV specifies exactly what the file must contain: a general description of the system; a detailed description of its elements and development process; information about training, validation, and testing methodologies and data; monitoring, functioning, and control information; a description of its robustness, accuracy, and cybersecurity measures; and more.

For providers claiming the Article 6(3) exemption (the filter that allows providers to argue their Annex III system is not, in fact, high-risk), the documentation must include the assessment and reasoning behind that determination.

5. Keep automatically generated logs under your control (Article 19)

Where technically feasible, high-risk AI systems must automatically generate logs of their operation. Providers are responsible for keeping those logs — at least insofar as the logs are under the provider's control rather than a deployer's. Logs are kept for a minimum of six months, unless EU or national law or the system's intended purpose requires longer retention.

These logs are not optional audit trails. They are the factual record that allows an authority to reconstruct what the system did, when, and under what conditions. A provider whose system produces no logs, or who does not retain them, has no evidence of compliant operation.

6. Ensure conformity assessment before market placement (Article 43)

Before a high-risk AI system is placed on the market or put into service, it must undergo a conformity assessment — the EU's term for demonstrating, before launch, that the system meets the requirements of Section 2.

Article 43 sets out the routes:

• For most Annex III systems, providers may follow the internal control procedure (Annex VI) — a self-assessment in which the provider draws up technical documentation, implements a QMS, and self-declares conformity. No third-party notified body involvement is required for most Annex III categories.
• For Annex III systems in biometrics (remote biometric identification systems intended to be used in public spaces by law enforcement) and a few other specific categories, a third-party notified body must be involved.
• For high-risk AI embedded in regulated products covered by Annex I (machinery, medical devices, etc.), the conformity assessment pathway follows the applicable product law and integrates the AI Act requirements.

Providers must also follow the Article 43 procedure again when a substantial modification is made to an already-certified system.

7. Draw up the EU declaration of conformity (Article 47)

After a successful conformity assessment, the provider must draw up the EU declaration of conformity (DoC) — a formal written declaration that the system complies with the requirements of the EU AI Act. The DoC must contain the information specified in Annex V: identity of the provider, a description of the system, a statement of conformity, references to harmonised standards or common specifications applied, and a dated signature.

The DoC stays with the system. It must be kept up to date and retained for ten years after the last unit was placed on the market.

A provider cannot affix the CE marking (next step) without first completing the DoC.

8. Affix CE marking (Article 48)

Once the DoC is in place, the provider must affix the CE marking to the high-risk AI system — or, where the system's nature makes that impractical, to its packaging or accompanying documentation.

CE marking signals to market surveillance authorities and users that the system meets the EU AI Act's requirements. For high-risk AI embedded in a regulated product (e.g. a medical device), the CE marking process integrates with the product-law marking process.

Providers may not affix CE marking before completing conformity assessment and drawing up the DoC.

9. Comply with registration (Article 49)

Before placing a high-risk AI system on the EU market, providers must register themselves and their systems in the EU database established under Article 71. Article 49 sets out the registration obligation; the database is the publicly searchable record of high-risk systems in circulation.

Registration is mandatory and applies even when the provider uses the internal control conformity assessment route (i.e. no notified body required). Providers claiming the Article 6(3) exemption must also register that determination.

Do not confuse Article 49 with Article 47 (DoC) or with GPAI registration. They are distinct obligations with distinct content requirements.

10. Take corrective actions when necessary (Article 20)

If a provider has reason to believe that a high-risk AI system it has placed on the market is not in conformity with the EU AI Act, it must immediately take corrective action — withdrawing the system, disabling it, recalling it, or making it conform — as appropriate.

The provider must also inform the distributors of the system, and the competent national authorities in any Member State in which the system was made available or put into service, of the non-conformity and of the corrective action taken. If the system poses a risk to health, safety, or fundamental rights, the provider must inform the market surveillance authorities immediately.

Article 73 handles the specific obligation to report serious incidents to market surveillance authorities — generally within 15 days of becoming aware of the incident (or without delay where the incident involved a risk to the health or safety of persons).

11. Demonstrate conformity on request from a competent authority

Providers must, upon a reasoned request from a national competent authority, demonstrate that the system is in conformity with the EU AI Act. This means making technical documentation available, providing access to logs, explaining the conformity assessment methodology, and cooperating with the authority's investigation.

A "reasoned request" means the authority must state why it is making the request — it cannot demand documentation at random without grounds. But when a request arrives, the provider must respond with evidence, not assertions.

12. Ensure accessibility compliance

The EU AI Act requires that high-risk AI systems accessible to natural persons — in particular those used by consumers — are designed and developed with appropriate accessibility measures in line with applicable EU accessibility legislation (in particular the European Accessibility Act, Directive 2019/882).

For B2B SaaS providers whose systems are used exclusively by professional deployers and never by end-consumers directly, this obligation has limited practical bite. For providers offering consumer-facing AI — credit scoring tools, benefits eligibility tools, medical diagnostics — accessibility must be built in at the design stage.

13. Appoint an authorised representative if established outside the EU (Article 22)

A provider established outside the European Union that places a high-risk AI system on the EU market or puts one into service in the EU must, before doing so, appoint an authorised representative established in the EU by written mandate.

The authorised representative acts on the provider's behalf in all interactions with EU competent authorities and notified bodies. They hold a copy of the DoC and the technical documentation, register the system in the EU database, and are the point of contact for any enforcement action.

Non-EU providers cannot simply appoint a local distributor and assume compliance duties are covered: the authorised representative relationship is a specific mandate with specific legal responsibilities.

---

The Article 25 role-shift: when you become a provider by action

Article 25 is the mechanism that prevents companies from escaping provider obligations by structuring their involvement as something other than "developing" an AI system.

Three scenarios convert a downstream actor into a provider:

1. Placing a system on the market under your own name or trademark. A distributor that rebrands a third-party high-risk AI tool and markets it as its own product becomes the provider. The original developer's compliance documentation does not transfer — the new provider must conduct their own conformity assessment.

2. Substantial modification. A company that fine-tunes, retrains, or architecturally modifies an existing high-risk AI system in a way that affects its conformity with Section 2 requirements becomes the provider of the modified system.

3. Changing the intended purpose. A company that takes a system not previously classified as high-risk and re-deploys it for a high-risk use case (for example, re-using a general HR analytics tool as a CV-screening system that ranks candidates for hiring decisions) becomes the provider for that use in the high-risk context.

In each case, the original provider's CE marking, DoC, and technical file no longer cover the modified or rebranded system. The new provider starts fresh.

---

Worked example: a SaaS company as Article 16 provider

Consider a 35-person company that has built a recruitment screening tool — it ingests CVs and produces ranked candidate shortlists for employers. The system falls in Annex III, heading 4 (employment and workers management), and does not qualify for the Article 6(3) filter because it directly influences hiring decisions.

The company is a provider under Article 16. Here is what that means in practice, working through each obligation:

Before market placement:

• Compile the Annex IV technical file: architecture description, training data provenance, testing results disaggregated by gender and age, risk assessment (including bias findings), intended use definition.
• Establish a QMS under Article 17: written policies covering development process, change management, post-market monitoring, corrective action procedures.
• Run the conformity assessment under Article 43 using the Annex VI internal control route (no notified body required for this category).
• Draw up the EU DoC under Article 47 (Annex V content).
• Register in the EU database under Article 49.
• Add company legal name and contact address to the product documentation.

At launch:

• Provide the Article 13 information pack to each deployer (employer using the tool): capability description, accuracy metrics by demographic group, human oversight requirements, limitations, instructions for when to override the system.

Ongoing:

• Retain automatically generated operational logs for at least six months under Article 19.
• Monitor system performance post-market under Article 72; report serious incidents to market surveillance authorities under Article 73.
• Update the technical file and repeat conformity assessment if a substantial modification is made.
• Take corrective action and notify authorities under Article 20 if non-conformity is discovered.

The deadline for having all of this in place for a new-to-market stand-alone Annex III system is 2 December 2027. That gives roughly 18 months from today — which sounds generous until you consider that the technical file alone typically takes three to six months for a mid-size team that has never done this before.

The penalty for non-compliance with these obligations is up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). For companies with fewer employees, Article 99(6) caps the fine at the lower of the percentage or the fixed amount — a genuine proportionality protection.

---

How Confir helps providers meet Article 16

Confir's structured assessment maps directly to the Article 16 checklist. It runs each of its four compliance modules — AIRC (risk classification under Articles 5, 6, and 43), AITR (data and technical robustness under Articles 10, 11, and 15), AITO (transparency and human oversight under Articles 13 and 14), and AIGM (governance and post-market monitoring under Articles 9, 72, and 73) — and consolidates the results into a print-ready Annex IV technical documentation pack and an Article 47 / Annex V Declaration of Conformity.

The assessment logic is deterministic and rule-based: the same intake answers produce the same output every time, with the rule that fired visible for review. That reproducibility matters when a competent authority asks you to show your working.

Confir also derives your role — provider or deployer — from plain-English questions about how your system is placed on the market, covering the Article 25 scenarios. If you are a provider, the full obligation set activates automatically.

---

Article 16 in the compliance timeline

Deadline for new stand-alone high-risk systems (Annex III): 2 December 2027. Deadline for high-risk AI in Annex I products: 2 August 2028.

Start with the technical file and the QMS — they are the long-lead items and the ones most companies underestimate.

Related guides

• risk classification under Articles 6-11
• compliance software for Article 16
• AI system inventory management tools
• AI governance for EU AI Act compliance
• AI governance software solutions