Provider responsibilities

Inventory and intended purpose

Record each system’s purpose, release owner, model dependencies, users and distribution path. This creates a basis for identifying potentially applicable provisions.

If the system is high-risk

Provider duties can include risk management, data governance, technical documentation, logging capability, instructions for use, human oversight design, accuracy, robustness and cybersecurity, along with conformity processes. The specific route depends on the system.

After release

Relevant high-risk providers should plan for quality management, post-market monitoring and incident handling under the applicable provisions. Assign owners and retain evidence of decisions.

Is every developer a provider?

The provider definition turns on developing or having an AI system developed and placing it on the market or putting it into service under one’s own name or trademark. A supplier, integrator and customer may occupy different roles across products. Article 25 also describes situations in which another actor assumes provider obligations for a high-risk system, including certain rebranding, substantial modification or changes of intended purpose. Contract labels alone do not settle the statutory role.

What does a high-risk provider prepare?

The requirements in Articles 9 to 15 address risk management, data governance where relevant, technical documentation, logging, information for deployers, human oversight, accuracy, robustness and cybersecurity. Article 16 then assigns provider duties including conformity assessment, declarations and marking where applicable. The exact procedure depends on the high-risk route. Build these elements into the product lifecycle, not as a final release checklist.

• Trace requirements to design and test evidence
• Write usable instructions for deployers
• Keep a clear conformity and release record

What information should flow downstream?

A deployer needs an accurate description of intended purpose, capabilities, limitations, expected performance, oversight measures and use conditions. Article 13 sets specific transparency and instructions requirements for high-risk systems. A general-purpose model provider may also need to provide information to downstream system providers under Article 53. The content and recipient differ, so a single generic “AI disclosure” document may not suffice.

Release is not the end of the work

Where applicable, a high-risk provider should maintain quality management, post-market monitoring and serious-incident reporting processes. Keep version histories, observed failures, corrective decisions and channels for receiving information from deployers. An internal inventory can join these records to the system’s intended purpose and the compliance route chosen at release.