When does an organisation using AI become the provider of a system?

Why the question comes up at all

Artificial intelligence rarely enters an organisation by a board decision. It arrives as a new feature in software bought years earlier, or as a tool built in-house on a general-purpose model. In neither case does anyone ask about the role, because nobody feels they are placing anything on the market.

The regulation does not ask whether an organisation is in the AI business. It asks about the role towards a specific system. The same organisation is a deployer of one tool and a provider of another.

On top of that sits the confusion around the July 2026 change to the timetable. The postponement covered Chapter III Sections 1, 2 and 3. Those are classification, requirements, and the obligations of providers and deployers of high-risk systems. It did not cover the prohibited practices, the AI literacy duty or the transparency obligations. The market took one sentence from this — „the AI Act has been postponed” — and stopped counting deadlines.

What to establish before deciding

Three circumstances in which the role changes

Article 25(1) names the distributor, the importer, the deployer and any other third party. Each of them is considered a provider of a high-risk AI system if any of three circumstances arises.

Own name or trade mark. The organisation puts its brand on a high-risk system already placed on the market. The provision adds a qualifier here. This applies without prejudice to contractual arrangements allocating obligations differently.

Substantial modification. The organisation modifies a high-risk system in such a way that it remains a high-risk system. The point is therefore a change within the same category, not an exit from it.

Change of intended purpose. The organisation uses a system that was not classified as high-risk in a way that makes it one. The provision names general-purpose AI systems explicitly.

The third circumstance is the most common in practice and the hardest to notice. A team builds an assistant on a general-purpose model and later points it at supporting decisions about job candidates. The model has not changed. The intended purpose has, and with it the role of the organisation.

What the original provider owes the new one

This part of the provision tends to be skipped, and it is the most practical one. After the change of role the original provider is no longer considered the provider of that particular system. In exchange it has a duty of close cooperation with the new provider.

Article 25(2) lists three elements of that cooperation.

• technical documentation sufficient to assess conformity with the requirements in Article 16;
• information about the known limitations of the system and its fallback modes;
• targeted technical access, including for testing and validation purposes.

For an organisation whose role has changed, this is the only realistic route to performing the provider obligations. Without technical documentation the conformity assessment cannot be carried out, and without technical access it cannot be evidenced.

The sentence in the contract that switches the mechanism off

Here the provision closes the loop. The duty of cooperation does not apply where the original provider has expressly stated that its system may not be turned into a high-risk system. In that case it owes neither cooperation nor documentation.

The consequence is practical and unwelcome. An organisation that accepted such a clause takes on the whole risk of a change of purpose. After such a change it is left with provider obligations and without the material to perform them. The contract does not protect it from the change of role. What it does is remove the support.

This is why the question belongs to the procurement stage rather than the deployment stage. Article 25(4), added by the July 2026 amendment, points the same way. It requires the provider of a high-risk system and a third party supplying components to specify in a written agreement the information, technical access and assistance needed to perform the obligations. Components released publicly under a free and open-source licence are excluded. The exclusion does not cover general-purpose AI models.

When this binds, and why the date does not excuse waiting

Articles 25 and 26 sit in Chapter III Section 3, so the postponement covers them. They start to apply on 2 December 2027 for high-risk systems under Annex III and on 2 August 2028 for systems under Annex I.

That date is not a start date for the work. It is the date by which the work has to be finished. Contracts with AI vendors signed today usually run longer than fifteen months. They will decide whether the organisation has access to documentation at the moment the provision starts to bind.

It is worth remembering separately that part of the regulation already applies. The AI literacy duty in Article 4 has applied since 2 February 2025. So have the prohibited practices in Article 5. Two new prohibitions take effect on 2 December 2026. The transparency obligations in Article 50 have applied since 2 August 2026.

Most common mistakes

• Asking about the role once, at the level of the organisation. The role attaches to a system, not to a company. Establishing that „we are a deployer” without naming the tool settles nothing.
• Assuming that buying a ready-made tool rules out the provider role. It rules it out only for as long as the organisation does not change the tool’s purpose. That change is often made by a product team rather than by the board.
• Reading the postponement as a suspension of the whole regulation. The postponement covered the requirements and obligations concerning high-risk systems. The remaining provisions apply.
• Reading Article 25(1) without the contractual qualifier in point (a) and without the exclusion in paragraph 2. Both sentences change the outcome of the analysis, and both are easy to miss on a quick reading.
• Postponing the contract review until the provision starts to bind. By December 2027 the terms will already have been agreed, and renegotiating an agreement takes longer than concluding one.

Conclusions and next steps

Establishing the role is a repeated exercise, not a one-off. It repeats with every new use case and with every change in how an existing one is used.

An order that keeps this work manageable.

1. List the AI use cases in the organisation together with their intended purpose. Without that list the question about the role has nothing to attach to.
2. For each use case, answer whether any of the three circumstances in Article 25(1) arises.
3. Check the contracts for a clause excluding conversion into a high-risk system. Such a clause changes the risk assessment of the project.
4. For new contracts, agree the scope of documentation and technical access before signing, in line with Article 25(4).
5. Build the role assessment into the procedure for launching new tools, so that a change of purpose does not happen outside the board’s knowledge.

The evidence that this work was done is a register of use cases with an assigned role and a record of the assessment behind each one. The same material answers questions from clients, insurers and auditors.

Related materials

• What should an AI use register contain? — the list that makes the question about the role possible to ask.
• Who is responsible for AI Act transparency obligations? — the second axis dividing duties between provider and deployer.
• Does every organization fall under NIS2? — the same qualification logic in the other regime.

Sources

• Regulation (EU) 2024/1689 (AI Act), consolidated text as of 27 July 2026, Articles 4, 25, 26 and 113 — eur-lex.europa.eu (accessed: September 1, 2026).
• Regulation (EU) 2026/1744 of 8 July 2026 amending Regulation (EU) 2024/1689 — OJ L 1744, 24 July 2026 (accessed: September 1, 2026).
• Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026, item 1003) (in Polish) (accessed: September 1, 2026).