Contents
The European Union’s Artificial Intelligence Act (Regulation 2024/1689) (the “AI Act”) entered into force on 1 August 2024 and establishes the first comprehensive regulatory framework for artificial intelligence within the European Union (“EU”). Although now in force, the Act’s substantive requirements apply progressively. The provisions governing high-risk AI systems—those associated with significant risks to health, safety or fundamental rights—were initially set to apply from August 2026, but the European Commission has proposed postponing this date pending the availability of harmonised standards and conformity-assessment tools. This proposal has not yet been formally adopted.
The structure of the Act, however, is sufficiently stable to permit analysis of its operator model, which functions as the decisive mechanism for determining regulatory responsibility. The AI Act does not distribute obligations uniformly across all actors. Instead, it attaches differentiated duties to operators—provider, deployer, distributor, importer, authorised representative and product manufacturer—depending on their factual interaction with an AI system. This approach makes operator classification the precondition to the application of Chapters III and V. It also creates a regulatory fluidity: because provider status may arise through development, branding or certain types of modification, entities may assume this role even without intending to do so. Understanding the operator model is therefore essential to understanding the practical reach of the AI Act.
Executive summary
The EU’s Artificial Intelligence Act fundamentally changes how companies must manage, deploy and adapt AI systems within the EU. Its regulatory model does not focus on ownership, contractual labels or technical authorship. Instead, it assigns legal responsibility based solely on what a company does with an AI system in practice. This makes the concept of provider status the single most important determinant of compliance risk under the AI Act.
A company becomes a provider not only when it builds an AI system, but also when it has it built, rebrands it, deploys it internally under its own name, or—critically—modifies it in ways that influence behaviour, risk or intended purpose. For non-high-risk systems, provider status arises mainly when a company undertakes meaningful development work, such as fine-tuning or custom model engineering. But for high-risk systems, the threshold is significantly lower: rebranding, altering intended purpose, or making a “substantial modification” (a broad and functional concept under Article 25) can automatically transform a deployer, integrator, distributor or importer into the legally responsible provider — even if the company never intended to assume this role.
This distinction matters because providers carry the heaviest compliance burden: comprehensive risk-management systems, extensive documentation, logging obligations, EU database registration, ongoing monitoring, and a mandatory conformity assessment before the system is used or commercialised. These obligations are operationally significant and can require substantial organisational change.
The practical implication is clear:
**An organisation can slide into provider status more easily than expected—especially in high-risk contexts.**Activities that appear operational or technical (e.g., adapting a workflow, integrating a model into a business domain, or adjusting a system for a client) may carry regulatory consequences far greater than their technical complexity suggests.
Companies should therefore ensure that AI governance frameworks classify systems accurately as “high-risk” or not, establish strict internal controls around model modifications, and document every intervention capable of altering system behaviour or intended purpose. The AI Act rewards proactive governance and penalises informal or undocumented modification. For most organisations, the central challenge will not be whether they use AI—but whether they unexpectedly become providers without realising it.
I. Foundational definitions
To understand how the AI Act allocates regulatory obligations, the following terms must be defined as they appear in the legislation. For clarity, they are presented in a comparative table, followed by their corresponding statutory references.
These definitions establish the specific moments at which an AI system or model becomes subject to the AI Act, and therefore when regulatory duties begin to apply. “Placing on the market” concerns the entry of a system into external circulation. “Putting into service” concerns the moment an organisation operationalises a system internally. Both events activate the obligations of the “provider” (as defined below), even where the system is never commercially supplied.
With this terminological groundwork established, the six operator categories can now be set out.
II. The Operator landscape
The AI Act identifies six categories of operators whose conduct triggers distinct regulatory obligations. This second comparative table sets out their core identities.
Recital 83 and Article 25 make explicit that the operator roles are not mutually exclusive. A single legal entity may, depending on its conduct, act simultaneously as provider, deployer, distributor or importer, and must comply with the full set of obligations attached to each role. This functional approach is a deliberate legislative choice. The AI Act assigns regulatory responsibility based on the factual contribution of an entity to the lifecycle of an AI system, not on the commercial labels it adopts or the manner in which it describes its activities contractually.
The consequences are significant. An organisation that considers itself a mere deployer—whether because it uses an AI system internally or because it provides managed services to a client—may nonetheless become a provider de facto if its behaviour satisfies the statutory definition in Article 3(3) AI Act. The classification does not depend on intention, on the allocation of responsibilities in a commercial agreement, or on the technical sophistication of the organisation. It depends solely on whether the entity has developed or had the system developed, or whether it has placed it on the market or put it into service under its own name or trademark.
This structure creates a regulatory fluidity - a company may move between operator roles, or accumulate roles, as its involvement with a system evolves. A deployer that begins by using a system in its unmodified form may, through subsequent conduct such as substantial modification, rebranding, or commissioning further development, assume the full obligations of a provider. This shift occurs automatically when the factual circumstances arise; it does not require notification, intention, or amendment to contractual documentation.
III. The Provider Role
The provider is the principal bearer of regulatory responsibility under the AI Act. This follows from the structure of the legislation: the essential safeguards of the framework—risk management, data governance, transparency, oversight and accountability—attach primarily to the entity that places an AI system on the market or puts it into service under its name or authority. The compliance burden is substantial. Providers of high-risk AI systems must implement a comprehensive quality management system pursuant to Article 17, encompassing documented policies, procedures and instructions governing the system’s lifecycle. They must also produce and maintain the extensive technical documentation required under Article 18 and ensure the availability of system logs under Article 19 where the system remains within their control.
The most burdensome obligation, however, is the requirement to subject the system to a conformity assessment under Article 43 before it is placed on the market or put into service. This assessment is the entry point into the regulatory regime and presupposes that the system satisfies the substantive requirements of Articles 9–15 concerning risk management, data governance, technical documentation, record keeping, transparency, human oversight, robustness and cybersecurity. Compliance is further reinforced through the EU database registration obligation in Article 49, which requires providers of high-risk systems to upload core documentation prior to market entry.
These obligations illustrate why provider status is not merely a formal designation but a material regulatory position carrying significant operational, organisational and legal consequences.
Understanding the exact scope of this role is critical, particularly because entities may become providers even without directly developing AI systems.
Article 3(3) adopts a functional and expansive definition. An entity qualifies as a provider when it develops an AI system or GPAI Model, or has it developed, and places it on the market or puts it into service under its own name or trademark. Each component of this definition warrants practical elucidation.
1) First, development includes both in-house creation and outsorced development. An organisation that instructs a third party to build a system is deemed to have “had it developed”. The legal responsibility does not diminish because the technical work is outsourced. This includes commissioning a third party to build the system; in such cases, the commissioning entity ‘has the system developed’ within the meaning of Article 3(3), even if it performs no technical work itself.
2) Second, provider status attaches not only to external supply but also to internal use. A company that builds an AI system for internal operational needs becomes a provider once it puts the system into service under its authority, irrespective of whether it intends to commercialise it.
3) Third, the inclusion of branding—placement under one’s own name or trademark—means that white-labelling creates provider status even where the entity has not authored a single line of code. If a company takes a third-party system and rebrands it as its own, or markets it as part of its proprietary suite, it becomes the provider for purposes of the AI Act.
Provider status is therefore determined by conduct and identity, not by the technical contribution made to the model’s internal architecture. What follows is an examination of the factual circumstances under which an entity becomes a provider even though it was not the original developer. At this point, however, a foundational distinction must be introduced. The AI Act does not operate on a single pathway to provider status; rather, it differentiates the relevant mechanism according to whether the AI system is high-risk at the time of the operator’s intervention, or whether it is not. The classification is decisive, which we will discuss in the next section.
Non-high risk AI systems and high-risk AI systems
It necessary to define briefly what constitutes a high-risk AI system under the AI Act. The Regulation identifies two categories of high-risk systems, set out in Articles 6–7 and Annexes I and III. For present purposes, only a concise structural summary is required.
This dual structure is central to understanding the fluidity of operator roles under the AI Act, because identical conduct may produce different legal consequences depending on the system’s classification.
IV. Becoming a Provider Under the AI Act
The regulatory architecture of the AI Act establishes two distinct mechanisms through which an organisation may acquire provider status, depending on whether the underlying system is non-high-risk or high-risk. For non-high-risk systems, the mechanism is confined to Article 3(3) and hinges on whether the operator’s conduct amounts to development. For high-risk systems, the mechanism set out in Article 25 supplements Article 3(3) by introducing reclassification triggers—most notably substantial modification—that may apply even where the operator’s technical contribution does not meet the threshold of development. These mechanisms are structurally separate yet functionally comparable: each determines when downstream conduct causes an entity to assume responsibilities intended for those controlling the system’s identity, intended purpose or compliance posture.
1. Development (non-high-risk systems)
A. Definition
For systems that are not high-risk under Articles 6, Annex I or Annex III, Article 3(3) governs the attribution of provider status. An operator becomes the provider when it develops the system or has it developed and then places it on the market or puts it into service under its own name or trademark. Although the Act does not define “development,” the obligations in Articles 11, 17 and 18, together with Annex IV, indicate that development refers to engineering work that shapes the model’s behaviour, such as training, fine-tuning, architectural modification or other interventions that render the system functionally attributable to the operator.
B. Interpretive challenges
The principal challenge lies in distinguishing development from mere configuration or integration. Because many modern AI systems are used “as-a-service,” significant customisation is possible without altering model behaviour. Development should be understood as conduct that introduces, modifies or trains logic such that the system’s functional behaviour no longer corresponds to the version supplied by the original provider. Integration, deployment and routine parameter adjustment, by contrast, are insufficient unless they materially change the model’s behaviour.
C. Practical examples
- Fine-tuning with new training data generally qualifies as development where outputs materially diverge from the base model.
- Retraining or architectural changes (e.g., adding layers or altering embeddings) clearly constitute development.
- Inference-logic modification, such as editing routing code, may qualify if it changes functional behaviour.
- Extensive data-pipeline redesign may be development where it materially alters model outputs.
- Prompt-tool assemblies normally are integration but may constitute development where they mimic engineered capabilities.
D. Anticipated scenarios
Two non-high-risk scenarios carry elevated risk. First, internal data-science teams may fine-tune or adapt pre-existing models for domain-specific use; if the resulting behaviour is attributable to the organisation, it becomes the provider. Second, integrators offering customised AI services may inadvertently cross the development threshold when tailoring systems for clients, particularly where modifications stray beyond configuration.
E. What is not development
UI adjustments, workflow automation, prompt engineering, DevOps and general infrastructure, and other operational changes do not constitute development unless they alter the model’s behaviour in a meaningful way. These remain deployment or configuration activities.
F. Regulatory uncertainty
Because the AI Act adopts a functional rather than a technical definition, the precise boundary of development is unsettled. Enforcement practice is absent, and harmonised standards remain forthcoming. Organisations must therefore assume that any intervention capable of altering functional behaviour may trigger Article 3(3).
2. Substantial modification (high-risk systems)
Where the system is high-risk under Article 6, the introduces an additional mechanism in Article 25 that reassigns provider status to downstream operators. Article 25(1) identifies three independent triggers, any of which is sufficient:
- Rebranding – Article 25(1)(a): An operator becomes the provider by placing a high-risk AI system on the market under its own name or trademark.
- Substantial modification – Article 25(1)(b): A downstream operator becomes the provider by making a substantial modification to a high-risk AI system after market placement or putting into service.
- Modifying intended purpose – Article 25(1)(c): An operator becomes the provider by altering the intended purpose of an AI system (including a GPAI system) so that it becomes high-risk under Article 6.
These triggers operate irrespective of the operator’s prior role as deployer, distributor, importer or manufacturer.
A. Definition
Article 3(23) defines substantial modification as a post-market change not foreseen in the original conformity assessment that affects compliance with Articles 9–15 or changes intended purpose. Recital 128 clarifies that a modification is substantial where it alters the system’s compliance posture or extends intended purpose beyond what was initially assessed. The definition involves three cumulative criteria: (i) the modification occurs post-market; (ii) it was not foreseen or planned; and (iii) it affects compliance or intended purpose.
B. Interpretive challenges
The foreseeability criterion is ambiguous. The safest interpretation is that only modifications expressly documented are foreseen; anything else is presumptively unforeseeable. The materiality test—impact on compliance or intended purpose—is the most complex. Intended purpose (Article 3(12)) is formally determined by the provider; extending a system into a new Annex III context may constitute a substantial modification even without altering weights. Likewise, changes that undermine or interfere with risk management (Article 9), data governance (Article 10), robustness (Article 15) or human oversight (Article 14) may be material independent of technical depth.
C. Practical examples
- Fine-tuning of a high-risk system is frequently substantial where it alters risk-relevant behaviour.
- RAG augmentation becomes substantial if it enables the system to perform high-risk tasks not originally intended.
- Tool-prompt workflows may be substantial if they extend the system into Annex III use cases.
- Workflow embedding in HR, creditworthiness or law-enforcement processes may alter intended purpose.
- Model distillation almost always constitutes substantial modification and often development.
- Architectural changes unequivocally constitute substantial modification.
D. Anticipated scenarios
Two categories are particularly exposed.
- First, companies operating high-risk systems internally may adjust them for domain-specific workflows; even modest changes may alter intended purpose or compliance.
- Second, integrators customising high-risk systems for clients may unintentionally meet the substantial-modification threshold, thereby becoming the provider under Article 25(1)(b) despite contractual disclaimers.
E. What is not a substantial modification
Routine patching, UI adjustments, parameter tweaking within documented ranges, bug fixes or modifications expressly foreseen in the technical file do not constitute substantial modification. These do not disturb the original conformity assessment.
F. Regulatory uncertainty
The statutory test is functional, not technical. Weight changes are neither necessary nor sufficient for substantial modification. Until supervisory practice emerges or harmonised standards are adopted, operators must treat any modification that plausibly affects Articles 9–15 or intended purpose as potentially substantial.
Conclusion
The ease with which an operator may become a provider under the AI Act depends fundamentally on whether the system is non-high-risk or high-risk.
- For non-high-risk systems, reclassification requires conduct that qualifies as development or ‘having the system developed’ under Article 3(3). This threshold typically presupposes meaningful technical work, functional engineering or a commissioning relationship, and is not triggered by mere deployment.
- For high-risk systems, Article 25 lowers the threshold considerably: rebranding, substantial modification, or modifying intended purpose may each independently trigger provider status, often irrespective of the operator’s intentions or contractual role.
Consequently, the risk of sliding into provider status is materially higher in the high-risk regime. The same intervention—fine-tuning, workflow adaptation, tool integration—may be benign for non-high-risk systems yet decisive for high-risk systems. Organisations must therefore maintain rigorous governance, precise documentation and an explicit understanding of the system’s classification to prevent unintended assumption of the heaviest obligations under the AI Act.
Ultimately, the fluidity of these mechanisms—particularly within the high-risk regime—makes operator classification the practical foundation of any AI governance strategy.