A provider is whoever develops a system or has it developed and places it on the market, and the documentation is the price of that position.
Why it matters when the plan changes
Documentation is where a system's claims become checkable. Without it a deployer cannot exercise oversight, an assessor cannot judge conformity, and an affected person cannot be given a meaningful explanation. Written after the fact, it describes what the provider remembers; written alongside development, it describes what the system is. A target architecture built for this purpose logs document versions, evidence used, model version, confidence and human review as they happen, which is traceability by construction rather than reconstruction after the fact.
The tension is between completeness and commercial disclosure. Documentation detailed enough to be useful reveals how the system works, which a provider may regard as its advantage. The Act answers this through Article 17's quality management obligation: documentation exists for the assessor and the deployer, not the public, and a provider under Article 3, whoever develops a system and places it on the market, who will not document is in no position to place it there.
In practice
A deployer asks a vendor for the technical documentation behind an assessment system. The vendor sends a product sheet and a whitepaper. Neither says what the model was trained on, how its accuracy was measured, or where it is known to fail. The deployer cannot meet its own oversight duty with what it has, and the conversation about what documentation actually means begins two years late.
Evidence
A provider is whoever develops an AI system or has it developed and places it on the market.
Article 3, European Union Artificial Intelligence Act (2024)Providers of high-risk systems must run a documented quality management system.
Article 17, European Union Artificial Intelligence Act (2024)
What it cannot tell you
Provider documentation describes the system as built and tested, not the system as deployed in a particular context. It cannot tell a deployer whether the described performance holds in their own population, workflow or data distribution. Nor does it certify that the system works well commercially; it establishes only that the provider met a regulatory floor.
Questions
The technical documentation contains a general description of the system and its intended purpose, its design and development process, the data used, validation and testing results, performance metrics, known limits, the risk management system, and human oversight measures, kept current under the European Union Artificial Intelligence Act (2024).
The conformity assessor, market surveillance authorities on request, and the deployer to the extent needed for oversight and compliance. It is not a public document, which is the Act's answer to the concern that documenting a system means disclosing its commercial advantage.
A whitepaper argues; documentation records. Documentation states what data was used, how accuracy was measured on which population, where the system fails and what was changed when. A document that cannot answer those questions with specifics is marketing, whatever it is titled.
Yes, for a high-risk system placed on the market once the obligations apply. Article 17 requires providers to run a documented quality management system, which makes documentation a precondition for conformity assessment and market access, so it must be produced alongside development rather than assembled afterward.
Read it for the parts that bear on its own duties: what the system is for, what it should not be used for, how to oversee it, what the outputs mean and how confident they are. Filing it unread is common, and it leaves the deployer unable to meet obligations the document was written to support.