Why role changes responsibility
The role determines which requirements to examine. Article 50's interaction disclosure and synthetic-output marking are provider duties, while deepfake and qualifying public-interest-text disclosures are deployer duties. High-risk providers design and document systems; deployers have operating responsibilities under Article 26. Literacy concerns both providers and deployers.
An incorrect role assumption can send work to the wrong team. A procurement team may assume all obligations remain with a supplier, while a product team may be operating an own-name system. An engineering team may combine model and system records even though the obligations attach at different levels. These are planning risks, not determinations about a specific enterprise.
The statutory roles
| Role | Core legal distinction | Responsibility boundary |
|---|---|---|
| Provider | Develops or has developed the system/model and meets the own-name market/service test, whether paid or free. | Provider status is not limited to commercial vendors or paid supply. |
| Deployer | Uses a system under its authority, apart from purely personal non-professional use. | Using a system does not transfer all provider duties to the deployer. |
| Importer | Union-established/located person places a third-country-named system on the Union market. | An overseas customer is not an importer merely because it buys the system. |
| Distributor | Supply-chain actor other than provider/importer makes a system available on the Union market. | Distributor and importer checks are distinct. |
| Authorised representative | Union-established/located person accepts a written mandate for specified provider duties. | Reselling alone does not establish an accepted written mandate. |
| Product manufacturer | Specified product activity can create high-risk system provider responsibility under Article 25(3). | The specified Article 25(3) product conditions must be met. |
"GPAI provider" applies the provider definition to a GPAI model and Union model placement. It is not a general label for every business using a generative application.
Identify the asset before the role
An AI system and a GPAI model are distinct. The system is the functional application or arrangement assessed under Article 3(1). A GPAI model has significant generality and performs competently across a wide range of tasks under Article 3(63). The model can be integrated into downstream systems; those systems may have different uses and duties.
Consider an illustrative customer-support application built on a third-party model. Identify the model provider, the entity developing or commissioning the application, the name under which the system is supplied or put into service, and the entity using it under its authority. Do not conclude that there is only one provider relationship because the architecture uses one upstream model.
Using an API alone does not settle the model-provider test. Likewise, receiving model documentation does not answer who owns the resulting system's customer notice or technical configuration. Article 53 downstream information and Article 50 system duties have different anchors.
Common enterprise arrangements
These are fact-gathering examples rather than categorical legal outcomes.
| Arrangement | Role questions to resolve |
|---|---|
| Buy and use an AI application | Which entity uses it under its authority? Does that entity also develop, commission, rebrand or modify it? |
| Develop an internal system | Who develops or has it developed, under whose name, and how is first own use attributed? |
| Integrate a third-party model into an own-name product | Separate the upstream model-provider and downstream system-provider tests. |
| Modify a high-risk system | Test Article 25's own-name, substantial-modification and intended-purpose branches. |
| Fine-tune a GPAI model | Apply the model-specific guidance to generality, capabilities, systemic risk and placement; do not mechanically use Article 25. |
The same company can be a deployer for a purchased system and a provider for another asset or activity. We therefore recommend recording the role with the legal entity, asset, activity, territory and period instead of assigning one permanent role to the company. The Act does not require this record format.
When high-risk responsibility can change
Article 25(1) can make a distributor, importer, deployer or other third party the provider of a high-risk system through specified activities. The rule covers own-name supply, a substantial modification that leaves the system high-risk, and a change in intended purpose that makes a previously non-high-risk system high-risk. Each route has its own conditions.
Before release, review changes to branding, system capability, workflow purpose and the supply arrangement. Calling a change a "configuration" does not answer the legal modification question. Article 111's phrase "significant changes in design" also differs from substantial modification in the conformity rules and the analysis of when the role changes.
Article 25 also addresses original-provider assistance and agreements in specified circumstances. The repository's baseline does not turn all supplier agreements into a universal transfer of regulatory responsibility. Record what assistance is available and which duties remain assigned by law.
GPAI modification uses a different analysis
Final GPAI guidance examines modifications that significantly change generality, capabilities or systemic risk. Its compute-based indicators are interpretive tools, not an automatic statutory rule that every fine-tuning task creates a model provider. Guidance also addresses the scope of a qualifying modifier's documentation, copyright policy and training summary.
The research records an additional guidance scenario where an overseas upstream actor clearly excludes EU distribution/use and a downstream integrator brings the model into an EU system. That scenario requires factual and legal review. It does not mean every integration creates GPAI-provider status.
Keep model modification history separate from system integration history. A model version can be reused across several systems, while a system release can change without a new model version. Recording both histories lets reviewers answer role and evidence questions for the relevant model, system and version. This is our recommended record design.
Role does not resolve territorial scope or classification
After identifying role, examine Article 2's territorial connections. Provider market or service activity, EU deployer location and third-country output used in the EU are separate tests. Then examine prohibited practices, Article 50, high-risk classification and applicable GPAI duties. A correct provider label alone does not establish which requirements apply.
Dates also attach to the relevant obligation and context. Article 50 generally applies from 2 August 2026, while the principal high-risk Chapter III dates differ by Annex III and Annex I route. Older systems and models have distinct transitions. Do not assign one "provider compliance deadline" to an enterprise.
What a role review needs
Bring the system design and the development, supply and operating arrangements into the same review. The product owner should identify what is offered under the enterprise's name. The operating team should identify who has authority over use. Engineering should distinguish system changes from underlying model modifications. Legal reviewers can then examine the Article 3 and Article 25 conditions against one factual description. This is our recommended review method.
Record unresolved facts and the person who can resolve them. If supplier assistance, branding or modification responsibility is unclear, preserve that uncertainty in the role determination. Do not translate a missing answer into "deployer only" or "provider of everything." The objective is a traceable, scoped determination that another reviewer can understand, with explicit triggers for reassessment when the arrangement changes.
Our recommended factual record includes legal entity, asset identity, development or commissioning arrangement, naming/branding, supply method, intended purpose, use authority, relevant market/service dates and modification history. Attach the evidence supporting each conclusion and identify missing facts.
Development agreements can explain commissioned work. Product and release records can explain the name and offering. Deployment records can identify operating authority. System design records can distinguish the system from the model. A reviewed determination should explain how the combined facts meet or fail the statutory conditions.
Assign an operational owner to maintain the record. Reevaluate it when development, supply, branding, intended purpose or system design changes. That maintenance approach is our recommendation; the Act does not mandate this exact role-register format.
FAQ and open questions
Can an internal system have a provider?
The provider and scope tests are not confined to external sales. First own use can be relevant to putting a system into service. Review development, naming and activity rather than assume internal use excludes provider status.
Does the supplier handle everything for a deployer?
No. Deployers have their own applicable duties, including literacy, specified Article 50 disclosure and high-risk operations within their scope and timetable.
Does fine-tuning automatically make the company a GPAI provider?
The baseline does not support that automatic conclusion. Final guidance examines significant changes and the actual facts. Edge cases remain recorded for legal review.
Can a contract decide the legal role?
Contract terms are relevant evidence and can allocate implementation work. The Article 3/25 conditions still require analysis of the actual development, supply, use and modification activities.
Next step
Use U.S. and non-EU scope analysis, high-risk classification and the readiness sequence after identifying the relevant role.
Primary sources
Use the consolidated text to navigate provisions and the authentic original and amending Official Journal acts for the legislation. Guidance and Q&A retain their separate legal status.
- Consolidated text: Regulation (EU) 2024/1689, 27 July 2026 · legislation.
- Regulation (EU) 2024/1689 of 13 June 2024 · legislation.
- Regulation (EU) 2026/1744 of 8 July 2026 · legislation.
- Commission Guidelines on the scope of obligations for providers of general-purpose AI models · final Commission guidance.