Where provider programmes stall.
One register, thirteen artefacts.
Three ways companies become providers.
A SaaS company shipping a CV-ranking feature to EU customers.
- Annex III point 4 — employment. High-risk, and the full provider set applies.
- Annex IV assembles from the register; the IFU is generated for deployers to receive.
- Internal-control route under Annex VI, with the standards applied recorded.
- Registered under Art. 49 before it is placed on the market.
A company white-labelling a vendor's scoring model under its own brand.
- Art. 25(1)(a) — the name on the product makes them the provider.
- The classification asks the branding question rather than assuming a buyer's role.
- The vendor's documentation becomes an input, not a substitute for their own file.
- The duty transfers with the brand, which is the part most teams miss.
A team fine-tuning an open model for a regulated decision.
- A substantial modification, or a changed intended purpose, or both — Art. 25(1)(b) and (c).
- Data governance under Art. 10 covers the fine-tuning set, not only the base model.
- Accuracy, robustness and cybersecurity evidence under Art. 15 belongs to them now.
- One register carries both this and their deployer duties for bought tools.
The parts a provider reaches for later.
Straight answers for providers.
We only fine-tuned someone else's model. Are we really a provider?
Possibly. Article 25(1) makes a deployer, distributor or importer into a provider of a high-risk system in three cases: putting your name or trademark on it, making a substantial modification to it, or changing its intended purpose so that it becomes high-risk. Fine-tuning can meet the second or third test depending on what changed. The classification asks the questions that decide it rather than leaving you to guess.
What does the provider set actually contain?
For a high-risk system: risk management across the lifecycle (Art. 9), data governance (Art. 10), technical documentation to Annex IV (Art. 11), automatic logging (Art. 12), instructions for use (Art. 13), human oversight design (Art. 14), accuracy, robustness and cybersecurity (Art. 15), a quality management system (Art. 17), conformity assessment (Art. 43), the EU declaration of conformity (Art. 47), CE marking (Art. 48), registration (Art. 49), post-market monitoring (Art. 72) and serious-incident reporting (Art. 73).
Do we need a notified body?
It depends on the route. Most Annex III high-risk systems take the internal-control route of Annex VI, which the provider performs itself. Systems covered by Annex I sectoral legislation, and biometric systems where no harmonised standard has been applied, take the third-party route. The classification records which route applies and why, so the file says how the decision was reached.
How does the technical file get built?
Annex IV sections assemble from the live record — the system description, the development process, the risk-management outputs, the data used, the oversight design, the accuracy and robustness evidence. You edit and approve; you do not start from an empty template. Sealing produces a hash-stamped version, and a sealed document is never edited: a change makes a new version.
When is registration required?
Article 49 requires the provider of an Annex III high-risk system to register it in the EU database before placing it on the market or putting it into service. Veritome pre-fills the Annex VIII fields from the register and tells you which are still missing, so the portal submission is a paste rather than a rediscovery exercise.


