The Article 25 trap: when using AI makes you its provider

The AI Act puts most of its weight on providers. Article 3 defines a provider as the person or body that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer is the person or body using an AI system under its own authority, other than in a personal non-professional activity.

Buy a tool, use it at work, and you are a deployer. That is where most Irish businesses assume they sit, and for most of them the assumption is correct.

Article 25 is the provision that moves the line. It converts a distributor, importer, deployer or other third party into a provider in three defined circumstances. Once converted, you are subject to the obligations in Article 16, which are the developer's obligations, not the buyer's.

None of this bites before 2 December 2027, the date the Annex III high-risk rules now apply from. It is worth answering in 2026 anyway, because it changes what you buy and what you sign between now and then.

Article 25(1) states that a distributor, importer, deployer or other third party is considered a provider of a high-risk AI system, and subject to the provider obligations under Article 16, in any of three circumstances.

The first is branding: you put your name or trademark on a high-risk AI system that has already been placed on the market or put into service. Article 25(1)(a) is expressed without prejudice to contractual arrangements that allocate the obligations differently.

The second is substantial modification: you make a substantial modification to a high-risk system already on the market in such a way that it remains high-risk under Article 6. Article 3 defines a substantial modification as a change that was not foreseen or planned in the provider's initial conformity assessment, and that either affects the system's compliance with the requirements or changes its intended purpose.

The third is the one to read twice. You modify the intended purpose of an AI system, including a general-purpose AI system, which was not classified as high-risk and is already on the market, in such a way that it becomes high-risk under Article 6.

Note what the third route does not require. No code. No supplier. No contract. No product going out the door. It turns on what the system is now for.

A company of thirty people advertises two roles and gets four hundred applications. Nobody has time to read four hundred CVs. Someone in the office is already paying for a general assistant, so they write a prompt: score each CV out of ten against this list of criteria, and give one line of reasoning. The scores go into a spreadsheet. The bottom half never get read by a person.

Annex III point 4 covers AI systems intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates. That is a plain description of what the spreadsheet does.

The model's provider placed a general assistant on the market. Its stated intended purpose was not candidate evaluation. The company changed that, and in doing so brought the system inside Annex III. On the face of Article 25(1)(c), the company is now the provider.

Nothing about that afternoon looked like software development. There was no procurement decision, so nobody reviewed it. There was no vendor, so nobody asked about conformity. It took an hour, and it moved the company from Article 26 to Article 16.

Article 26 is a manageable list. A deployer of a high-risk system has to use it in line with the instructions for use, assign human oversight to a person who is competent, trained and has the authority and support to exercise it, make sure input data is relevant and sufficiently representative to the extent it controls that data, monitor operation and report serious incidents, keep the automatically generated logs for at least six months, inform workers' representatives and affected workers before putting the system into service at work, and tell people when they are subject to a decision made with it.

Article 16 is a different order of task. It requires compliance with the whole of the requirements in Chapter III Section 2: a risk management system running across the lifecycle (Article 9), data governance covering training, validation and testing data (Article 10), technical documentation drawn up before the system goes to market and kept current (Article 11), automatic logging (Article 12), instructions for use for downstream deployers (Article 13), human oversight designed into the system (Article 14), and accuracy, resilience and cybersecurity (Article 15). On top of that sit a quality management system under Article 17, conformity assessment before the system is placed on the market or put into service, an EU declaration of conformity, CE marking, and registration in the EU database under Article 49.

Note the direction of one of those. Article 13 requires a provider to give deployers instructions for use. If you converted yourself into a provider of an internal system, the deployer you are writing instructions for is you.

Non-compliance with the high-risk obligations carries administrative fines of up to 15 million euro or 3% of total worldwide annual turnover, whichever is higher, under Article 99. Read Article 99(6) with it: for a small or medium enterprise the cap is whichever of the two is lower, not higher, which for most readers of this is the 3% figure rather than the headline one.

Article 25(2) is the part people miss, and it is the part with money in it.

Where one of the three conversions happens, the provider that first placed the system on the market stops being the provider of that specific system. It must then cooperate closely with the new provider and make available the information, reasonably expected technical access and other assistance needed to meet the obligations in the Regulation, in particular for the conformity assessment of high-risk systems.

That is a useful right. Most of what Article 16 demands, such as the composition of training data or the results of testing, is knowledge only the original developer holds.

The sentence that follows takes it away. Article 25(2) does not apply where the initial provider has clearly specified that its AI system is not to be changed into a high-risk AI system, in which case it does not fall under the obligation to hand over documentation.

That exclusion costs a supplier one line in its terms of use, and a supplier of a widely sold general-purpose model has every reason to write it. If it is there and you convert anyway, you owe technical documentation about a system you cannot see inside.

Most uses of AI in an Irish business are nowhere near this. It is worth being precise about where the provision stops.

Using a tool the way its supplier intended, however heavily, is use and not modification. Configuring options the provider documented, adding your own selection criteria inside a recruitment product, or running ten times the volume you ran last year does not engage Article 25(1)(b). The test in Article 3 is whether the change was foreseen or planned in the provider's initial conformity assessment.

A use that is not in Annex III at all cannot convert you under Article 25(1)(c), because that route depends on the system becoming high-risk under Article 6. Drafting marketing copy, summarising meetings, writing first-draft code, answering support email and translating documents are not Annex III uses. No amount of prompting turns them into one.

Article 6(3) goes further. Even a system whose use is listed in Annex III is not high-risk where it does not pose a significant risk of harm to health, safety or fundamental rights, including where it does not materially influence the outcome of decision making. That covers systems performing a narrow procedural task, improving the result of a previously completed human activity, detecting decision-making patterns without replacing or influencing the human assessment, or doing preparatory work.

There is an exception to that exception, and it is the reason the CV example is hard to escape: a system that performs profiling of natural persons is always high-risk. Scoring a person against criteria to evaluate their suitability is profiling within the meaning of Article 4(4) GDPR, which the AI Act adopts.

The answer is decided system by system, not organisation by organisation. The same company can be the deployer of a payroll tool and the provider of a CV sifter it assembled in an afternoon.

Four questions settle it, and none of them needs a solicitor to start.

The high-risk obligations apply from 2 December 2027, following the Digital Omnibus on AI. Nobody is going to be fined in 2026 for the spreadsheet in the example above.

The reason to look now is procurement. Software contracts signed this year run past December 2027, and the terms that decide whether you get Article 25(2) cooperation are being agreed today, by people who are not reading Article 25.

It is also cheap to fix early. Changing a hiring process before it is embedded costs a conversation. Unpicking a conformity assessment obligation you acquired by accident, eighteen months after the workflow became the way the company hires, costs considerably more.