Provider, deployer, and the Article 25 role flip

Two obligation sets, one dividing line, and a mechanism that moves firms across it without warning. Getting this right per system is the highest-value classification work a governance function does, because every other duty follows from it.

The provider set, in outline

A provider of a high-risk system carries the engineering quality system described in Articles 9 to 15: risk management across the lifecycle, data governance, technical documentation to Annex IV, automatic logging, instructions for use meeting Article 13(3), human oversight designed in, and accuracy, robustness and cybersecurity. It carries Article 17's quality management system, documented as written policies, procedures and instructions covering the compliance strategy, design control, development and quality assurance, examination and testing, data management, post-market monitoring, incident reporting, record-keeping, resource management and an accountability framework. It carries Article 72 post-market monitoring, Article 73 incident reporting, and Article 19 log retention of at least six months.

Article 13(3) deserves attention because it is the interface between the two roles. The instructions for use must give the provider's identity; the characteristics, capabilities and performance limitations including the accuracy metrics the system was validated against; the risks arising from foreseeable misuse; pre-determined changes; the human oversight measures; the computational and hardware resources, expected lifetime and maintenance required; and how to interpret the logs. That is the document a deployer needs in order to discharge its own duties. A vendor who will not supply it has made your compliance impossible, and that should be a procurement decision rather than a governance problem discovered afterwards.

The deployer set, in outline

Article 26: use per the instructions; assign oversight to people with competence, training and authority; ensure input data relevance where you control the input data; monitor and inform the provider; suspend and notify on identifying a risk; retain logs for at least six months; inform workers' representatives and affected workers before workplace use; register where you are a public authority; use the provider's Article 13 information to carry out a GDPR data protection impact assessment; and inform natural persons that they are subject to an Annex III decision.

Article 27 adds a fundamental rights impact assessment for a deliberately narrow population: bodies governed by public law, private entities providing public services, and deployers of Annex III creditworthiness systems and Annex III life and health insurance pricing systems. Insurers and lenders are inside it; most other private deployers are not. The six required elements are the deployer's processes in which the system will be used; the period and frequency of use; the categories of persons and groups likely to be affected; the specific risks of harm to them; how the human oversight measures will be implemented; and the measures to take if the risks materialise, including internal governance arrangements and complaint mechanisms. The results are notified to the market surveillance authority, and the Digital Omnibus allows a FRIA to incorporate or cross-refer to a GDPR DPIA rather than duplicating it.

The flip

Article 25 moves a deployer into the provider set in three circumstances: putting its name or trade mark on the system; making a substantial modification; or changing the intended purpose so that the system becomes high-risk. There is no notification, no transitional period and no partial application. The consequence of the flip is the entire provider set, including technical documentation for a system you did not build and cannot document.

This is why the flip is a design constraint rather than a compliance fact. A firm that decides in advance that it will not rebrand third-party AI in customer-facing surfaces, and will not fine-tune beyond a defined threshold without a governance decision, has removed two of the three routes by policy. The third, changed intended purpose, is managed by controlling what systems may be pointed at.

Worked example: the same tool, three roles

A bank licenses a document-understanding platform. Three business units adopt it.

Operations uses it as supplied to classify incoming post. The bank is a deployer. The system is not in an Annex III category. Duties: AI literacy, whatever data protection law requires, and a register entry with a recorded classification explaining why Annex III does not apply.

Credit configures it to extract fields from applicant financial statements, which feed the creditworthiness model. Still a deployer, but the extraction now sits inside a high-risk decision chain. The Article 26 set applies, and because creditworthiness is Annex III 5(b), the Article 27 fundamental rights impact assessment applies to the deployer.

HR points it at CVs and builds a shortlisting workflow on top, branded internally as the bank's own recruitment assistant. That is a changed intended purpose into an Annex III employment category, and internal branding raises the first Article 25 route. The bank is now, on a plain reading, a provider of a high-risk system, and owes technical documentation to Annex IV for a platform whose training data it has never seen.

One licence, one vendor, three legal positions. A register that records the vendor rather than the use cannot represent this, which is why the register entry is per system and per use, not per contract.

As of 24 September 2026.