the mandatory determination of whether you're a provider, deployer, distributor, importer, or all of the above under the EU AI Act, per AI system, because the company that fine-tuned a vendor model accidentally became a provider with provider obligations nobody knew about.
The mandatory determination of an organisation’s EU AI Act operator role — provider, deployer, distributor, importer, product manufacturer, or GPAI model provider — per AI system. Defined in Articles 3 and 25 of Regulation (EU) 2024/1689. The classification determines which obligations apply: providers bear conformity assessment, CE marking, technical documentation, quality management, and post-market monitoring obligations. Deployers bear human oversight, FRIA, transparency, and monitoring obligations. Article 25 triggers reclassification from deployer to provider when an organisation puts its name on a system, makes a substantial modification, or changes the intended purpose. Misclassification does not reduce liability; it creates it.
Why It Matters
AI Actor Classification is the single most consequential governance decision under the EU AI Act. Every downstream obligation — conformity assessment, technical documentation, FRIA, post-market monitoring, incident reporting — flows from this classification. Get it wrong and you are either over-investing in obligations that do not apply or, far more dangerously, failing to meet obligations that do.
The classification is deceptively complex because it is determined per AI system, not per organisation. A bank that uses a vendor’s fraud detection model as-is may be a deployer for that system. The same bank that fine-tunes a vendor’s credit scoring model with its own data may be a provider for that system. And if the bank white-labels either system under its own brand, it becomes a provider regardless of whether it modified the system. One organisation, three systems, potentially three different operator roles, each with different obligations.
The Article 25 reclassification triggers are where most organisations get caught. Fine-tuning, prompt engineering with system prompts that materially alter behaviour, and purpose modification can all constitute “substantial modification” — converting a deployer into a provider. The vendor’s compliance does not transfer. The vendor’s technical documentation does not cover your modifications. You are now responsible for the full provider obligation stack for a system you thought someone else was governing.
The Stress Test
Your organisation uses 27 AI systems. For each one, a market surveillance authority asks: what is your operator role under the EU AI Act? You need to produce, per system: the classification determination, the legal analysis supporting it, identification of any Article 25 reclassification triggers, and evidence that the obligations corresponding to your role are being met.
You discover that 12 systems use vendor models with fine-tuning or custom system prompts. Nobody assessed whether those modifications constitute “substantial modification” under Article 25. Three systems are white-labelled under your brand — automatic provider reclassification. Two systems were originally deployed for one purpose but are now used for another. Your AI system inventory lists 27 deployer relationships. The actual count is 27 systems with at least 5 provider obligations nobody has been fulfilling.
In the Wild
A European financial services firm deployed a large language model from a major US vendor for internal regulatory document analysis. The firm fine-tuned the model on proprietary regulatory interpretation data and deployed it under its own internal product name. The firm classified itself as a deployer. External counsel, engaged for an EU AI Act readiness assessment, determined that the combination of fine-tuning with proprietary data and white-labelling under the firm’s brand constituted both a substantial modification and a branding trigger under Article 25 — making the firm a provider. The firm had been operating for eight months without conformity assessment documentation, a quality management system, or post-market monitoring for the system.
The firm did not fail to comply. It failed to classify. Without classification, compliance is impossible because you do not know which obligations to comply with.
The EU AI Act introduces a new operator category: General-Purpose AI model provider, with obligations effective August 2025. This category applies to organisations that develop or place GPAI models on the EU market — regardless of whether the model is integrated into a high-risk system. For enterprises using foundation models from OpenAI, Anthropic, Google, or Meta, the classification question becomes: is your vendor meeting their GPAI provider obligations? And if you fine-tune their model, do you become a GPAI provider yourself? The answers are not yet settled by enforcement practice, but the compliance obligations are already in force.
The GPAI category adds a layer of classification complexity that most enterprise AI governance programmes have not yet addressed. Your vendor’s obligations are not your obligations. But if you modify their model, your obligations may be larger than you think.
The European Commission published guidelines in 2025 addressing the most frequently asked classification questions, including the definition of “substantial modification” under Article 25. The guidelines clarified that not every modification triggers reclassification — routine parameter adjustment, prompt engineering within the system’s intended purpose, and bug fixes generally do not constitute substantial modification. However, changes to the model architecture, training on new data categories, or deployment for a materially different purpose do trigger reclassification. The guidelines explicitly noted that the determination must be documented and the reasoning must be defensible to a market surveillance authority.
The Commission drew the line, but it is a fact-specific line. Each modification decision requires documented analysis, not assumption. “We thought we were still a deployer” is not a defence.
How to Govern It
Classification is not a legal opinion filed once. It is an operational determination that must be reassessed every time the system or its context changes.
Within the AI Control Index, AI Actor Classification governance spans the Strategy layer and multiple shields:
- Strategy (L1) — AI system inventory with operator role classification per system, Article 25 trigger assessment for every modification, and role reassessment workflows triggered by system changes. This is where classification lives.
- GRC (S1) — Evidence Factory captures classification determinations, legal analysis, modification assessments, and the corresponding obligation mapping. The Evidence Factory makes classification auditable.
- Strategy (L1) — Gate — Gate controls that require classification determination before any AI system progresses to deployment. No classification, no deployment authorisation.
- Observability (S4) — Change detection that flags when an AI system is modified in ways that may trigger Article 25 reclassification, feeding back into the classification assessment workflow.
- GRC (S1) — Risk Appetite — Board-level risk appetite statement that defines the organisation’s tolerance for classification ambiguity and sets the threshold for when external legal review is required.
When It’s Relevant
Every organisation within scope of the EU AI Act, for every AI system in its portfolio. Classification is not optional and not deferrable. It is the prerequisite for every other EU AI Act compliance activity.
Classification urgency is highest when:
- You use vendor-provided AI models that your teams have fine-tuned or substantially modified
- You white-label or rebrand AI systems under your organisation’s name
- AI systems originally deployed for one purpose are being used for another
- You have not assessed which of your AI systems qualify as high-risk under Article 6
- Your AI system inventory does not include operator role classification per system
Related Terms
References
- [1] European Parliament and Council of the European Union (2024) Regulation (EU) 2024/1689, Articles 3, 25, and Annex III. Official Journal of the European Union.
- [2] European Commission (2025) Guidelines on the definition of an AI system and on prohibited AI practices. C/2025/971, Brussels.
- [3] Hacker, P. (2024) ‘The European AI Liability Directives — Critique of a Half-Hearted Approach and Lessons for the Future’, Computer Law & Security Review, 51, 105871. doi: 10.1016/j.clsr.2023.105871.
- [4] Ebers, M., Hoch, V.R.S., Rosenkranz, F., Ruschemeier, H. and Steinrötter, B. (2021) ‘The European Commission’s Proposal for an Artificial Intelligence Act — A Critical Assessment by Members of the Robotics and AI Law Society (RAILS)’, Multidisciplinary Scientific Journal, 4(4), pp. 589–603.
- [5] European AI Office (2025) Guidance Note on Operator Roles and Obligations under Regulation (EU) 2024/1689. European Commission, Brussels.
- [6] OECD (2024) OECD AI Policy Observatory: Mapping AI Governance Frameworks Across Jurisdictions. OECD Publishing, Paris.
- [7] Smuha, N.A. (2021) ‘From a ‘Race to AI’ to a ‘Race to AI Regulation’: Regulatory Competition for Artificial Intelligence’, Law, Innovation and Technology, 13(1), pp. 57–84. doi: 10.1080/17579961.2021.1898300.
AI Control Index v6.0 · Glossary · June 2026 · i-DEPOT 158508 (BOIP) · CC BY-NC-ND 4.0
By Jeroen Janssen, Apparens