Every AI Act obligation attaches to a specific actor: provider, deployer, distributor, importer, or in some cases authorized representative. Which actor your organization is determines which obligations you owe. And the actor classification is not a constant, Article 25 transfers obligations between actors when a deployer substantially modifies a system or puts its own trademark on it. This is the lesson where a Procurement Director who has been told "we just buy the SaaS, the vendor handles compliance" finds out the contract she signed last quarter quietly converted her organization into a provider under Article 16, with a fully different obligation set than she budgeted for. This lesson is the actor-classification framework, the five-vendor walkthrough, the Article 25 transfer mechanics, and the contractual language Procurement teams now need in 2026 to keep actor status stable.

The Four Actors - Definitions, Then Obligations

Article 3 of the EU AI Act defines the four primary actors:

• Provider (Article 3(3)) - A natural or legal person, public authority, agency, or other body that develops an AI system or has an AI system developed and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge.
• Deployer (Article 3(4)) - A natural or legal person, public authority, agency, or other body using an AI system under its authority, except where the AI system is used in the course of a personal non-professional activity.
• Distributor (Article 3(7)) - A natural or legal person in the supply chain, other than the provider or the importer, that makes an AI system available on the Union market.
• Importer (Article 3(6)) - A natural or legal person located or established in the Union that places on the market an AI system that bears the name or trademark of a natural or legal person established outside the Union.

A fifth actor, the authorized representative (Article 3(5)), is the EU-established natural or legal person designated by a non-EU provider to perform obligations on the provider's behalf. Article 22 covers provider authorized representatives; Article 54 covers GPAI authorized representatives. The authorized representative is not a separate actor with its own obligation set. It is a vehicle for the provider's obligations to be discharged inside the Union.

The classification is fact-driven. The same organization can be a provider for one system, a deployer for another, and an importer for a third. The classification is also per-system, not per-organization. The portfolio mapping must classify each row independently.

Provider Obligations - Article 16 and the Heavy Bar

Article 16 of the EU AI Act lays out the provider obligation set for providers of high-risk AI systems. The bar is comprehensive:

• Article 16(a): Compliance with all the requirements of Chapter III Section 2 (Articles 8-15: risk management system, data governance, technical documentation, record-keeping, transparency to deployers, human oversight, accuracy / robustness / cybersecurity).
• Article 16(b), Indication of the provider's identification on the system or its packaging.
• Article 16(c), Quality management system under Article 17.
• Article 16(d), Technical documentation under Article 11 + Annex IV.
• Article 16(e), Automatically generated logs under Article 12.
• Article 16(f), Conformity assessment under Article 43 prior to placing on the market or putting into service.
• Article 16(g), Drawing up the EU declaration of conformity under Article 47 and CE marking under Article 48.
• Article 16(h), Registration in the EU database under Article 49 (provider registration, system registration where applicable).
• Article 16(i): Corrective action if the system is not in conformity, including withdrawal, recall, or disabling of the system.
• Article 16(j), Cooperation with competent authorities.
• Article 16(k), Demonstration of conformity at the request of a competent authority.

The Article 16 obligation set is the heaviest in the Act. For a high-risk Annex III system, the per-system Article 16 cost in the first twelve months can run six figures across technical-file production, QMS standup, conformity-assessment fees (with or without notified body), CE-marking integration, EU database registration, and ongoing post-market monitoring. Article 99(3) penalty exposure for Article 16 failures is €15M / 3% of global turnover.

Deployer Obligations - Article 26 and the Operational Side

Article 26 lays out the deployer obligation set for deployers of high-risk AI systems:

• Article 26(1). Take appropriate technical and organizational measures to ensure use of the system in accordance with the provider's instructions for use.
• Article 26(2): Assign human oversight to natural persons with the necessary competence, training, authority, and support.
• Article 26(3). Ensure that input data is relevant and sufficiently representative in view of the intended purpose.
• Article 26(4), Monitor the operation of the high-risk AI system on the basis of the instructions for use and inform the provider of any serious incident.
• Article 26(5). Keep logs automatically generated by the high-risk AI system to the extent under their control, for a period appropriate to the intended purpose.
• Article 26(6), Inform the relevant workers' representatives and affected workers that they will be subject to a high-risk AI system, prior to putting it into service or use in the workplace.
• Article 26(7), Where applicable, perform the Article 27 FRIA before deploying.
• Article 26(8). Use the system in compliance with the GDPR for data protection impact assessment purposes where applicable.
• Article 26(9), If a high-risk AI system makes decisions about natural persons, inform the affected natural persons of that fact.
• Article 26(10), Where the AI system performs natural-person profiling, cooperate with competent authorities on data subject rights.
• Article 26(11), Cooperate with the competent authority on any action taken in relation to the high-risk system.

The deployer bar is lighter than the provider bar but is still substantial. Article 26 effectively imposes an operational regime: instruction-compliance, human-oversight assignment, input-data quality, monitoring, log retention, worker notification (workers' councils consultation in many Member States), FRIA where applicable, GDPR overlay, decision-affected-person notification, profiling cooperation, authority cooperation. Article 99(3) penalty exposure for Article 26 failures sits at €15M / 3%, the same tier as Article 16.

Distributor and Importer Obligations - Articles 23 and 24

Articles 23 (importer) and 24 (distributor) impose a more limited set of obligations:

Article 23 (importer) requires the importer to verify, before placing the high-risk system on the Union market, that: the provider has carried out conformity assessment; the technical documentation has been drawn up; the system bears the CE marking; the system is accompanied by the EU declaration of conformity and instructions for use; the provider has indicated its name and address on the system or its packaging; and an authorized representative has been appointed where required. The importer must indicate its own name and address on the packaging or accompanying documentation. The importer must keep a copy of the EU declaration of conformity and the certificate of the notified body where applicable. The importer must ensure storage and transport conditions do not jeopardize compliance, must cooperate with authorities, must provide information on the supply chain on request.

Article 24 (distributor) requires the distributor to verify that the system bears the CE marking, is accompanied by the EU declaration of conformity and instructions for use, and that the provider and importer have complied with their obligations under Article 16(b) and Article 23. The distributor must ensure storage and transport do not jeopardize compliance. The distributor must take corrective action where it considers or has reason to believe the system is not in conformity, including withdrawal or recall in cooperation with the provider.

Both importer and distributor obligations sit under Article 99(3) at €15M / 3%. A reseller of an EU-AI-Act-regulated AI system is typically an importer or distributor and inherits a real, though more limited, obligation set.

Article 25 - The Transfer-of-Obligations Mechanic

Article 25 is the most consequential single article for actor classification. It lays out three circumstances in which a downstream actor (deployer, distributor, importer) becomes considered the provider of the high-risk AI system for purposes of the AI Act:

• Article 25(1)(a). They put their name or trademark on a high-risk AI system already placed on the market or put into service, without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated.
• Article 25(1)(b). They make a substantial modification to a high-risk AI system that has already been placed on the market or put into service in such a way that it remains a high-risk AI system.
• Article 25(1)(c). They modify the intended purpose of an AI system, including a general-purpose AI system, that has not been classified as high-risk and has already been placed on the market or put into service, in such a way that the system becomes a high-risk AI system.

The effect of Article 25 transfer is that the downstream actor inherits the full Article 16 provider obligation set on the modified or trademarked system. Article 25(2) requires the original provider to be notified and to cooperate by providing access to the technical documentation. Article 25(3) covers GPAI-specific transfer in a substantial-modification scenario.

The Article 25(1)(a) trademark trigger has a critical caveat: "without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated." Contractual allocation between the upstream provider and the downstream party can keep the obligations with the upstream party even after trademarking: but the allocation must be specific, mutual, and clear. White-labeled SaaS contracts in 2026 need explicit clauses on Article 25 allocation. A silent contract defaults to the downstream party inheriting the provider obligations.

The Article 25(1)(b) substantial-modification trigger has no contractual escape. Substantial modification is defined in Article 3(23) and assessed against Article 43(4). If the deployer substantially modifies, the deployer becomes the provider, full stop. The original provider's continued involvement is governed by Article 25(2) cooperation obligations.

The Article 25(1)(c) intended-purpose-change trigger pulls non-high-risk systems into high-risk classification when the downstream party changes the use case. A deployer that takes a minimal-risk customer-service chatbot and reuses it for credit-decision support has changed the intended purpose to a high-risk Annex III §5(b) use; the deployer becomes the provider of the high-risk system through Article 25(1)(c).

Five-Vendor Walkthrough - Applying the Actor Classification

Vendor 1 - Workday Talent Acquisition AI (Pure SaaS, No Modification, No Trademark)

Actor classification: Workday is the provider under Article 16. The customer is the deployer under Article 26. No Article 25 transfer occurs: the customer does not modify the system, does not put its trademark on it, does not change the intended purpose.

Customer obligations: Article 26 deployer obligations (use per instructions, human oversight, input-data quality, monitoring, log retention, worker notification, FRIA, GDPR overlay, decision-affected-person notification). Article 4 literacy. No Article 16 provider obligations.

Procurement contract checklist: Verify Workday's Annex IV technical-file readiness; verify Article 47 EU declaration of conformity; verify Article 71 EU database registration; verify Article 13 instructions for use are sufficient for Article 26 deployer compliance; verify Article 50 disclosures where applicable; verify Article 25 allocation language ("Workday remains the provider; customer is the deployer; no trademark transfer; no substantial modification right granted without notice"); verify incident-coordination clauses for Article 26(4) / Article 73 reporting.

Vendor 2 - White-Labeled SaaS Hiring Tool Rebranded as "Acme HR Insights"

Actor classification: The vendor is the original provider. Acme has trademarked the system. Article 25(1)(a) is triggered, Acme is now considered the provider for AI Act purposes, unless the contract explicitly allocates otherwise.

Customer obligations: If the contract is silent on Article 25 allocation, Acme inherits the full Article 16 provider obligation set on top of any Article 26 deployer obligations on systems Acme purchases from third parties unchanged. If the contract explicitly allocates the provider obligations to the upstream vendor under Article 25(1)(a) ("without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated"), the upstream vendor remains the provider, and Acme is treated as deployer.

Procurement contract checklist: The contract MUST address Article 25(1)(a) explicitly. The default rule in 2026 procurement is to allocate provider obligations to the upstream vendor when feasible, the vendor has the technical-file production capability and the QMS infrastructure. Without the explicit allocation, the trademarking triggers Acme's full Article 16 exposure. The contract should also address Article 25(1)(b) substantial-modification (no modifications without written agreement) and Article 25(1)(c) intended-purpose changes (no use-case expansion without written agreement).

Vendor 3 - OpenAI GPT-4 Fine-Tuned on Internal Customer-Service Transcripts and Used as a Customer-Service Agent

Actor classification: OpenAI is the GPAI provider under Article 53. The customer is the deployer of the customer-service agent. The fine-tuning is the question. If the fine-tuning is sufficiently substantial to be classified as substantial modification under Article 3(23), Article 25(1)(b) triggers, the customer becomes the provider of the fine-tuned model. If the fine-tuning is light (e.g., a few hundred examples, narrow domain adaptation), the analysis is more nuanced and may turn on whether the modification "remains a high-risk AI system" under Article 25(1)(b). Most enterprise fine-tunes of foundation models on internal data are substantial; assume Article 25(1)(b) triggers unless the analysis specifically shows otherwise.

Customer obligations: Article 26 deployer obligations on the customer-service agent (Article 50(1) chatbot disclosure especially); Article 16 provider obligations on the fine-tuned model if Article 25(1)(b) triggered (Annex IV technical file for the fine-tune, QMS for the fine-tuning process, Article 47 declaration if the fine-tuned model is placed on the market or put into service in a high-risk context); Article 4 literacy. The customer typically does not inherit OpenAI's Article 55 GPAI-with-systemic-risk obligations unless the fine-tuning crosses the Article 51 designation threshold for the fine-tuned model, rare but possible for very large fine-tunes.

Procurement contract checklist: Verify OpenAI's Annex XII downstream-deployer information is sufficient for the customer's Article 26 + Article 16 (post-transfer) work. Address Article 25(1)(b) explicitly, what fine-tuning operations constitute substantial modification; what notifications the customer owes OpenAI under Article 25(2); how Annex IV technical documentation flows from OpenAI to the customer for the fine-tuned model. Address Article 53(1)(d) public training-data summary review for both the base model and the fine-tune. Address Article 50(2) machine-readable marking if the agent generates synthetic content.

Vendor 4 - A Reseller Distributing an EU-AI-Act-Regulated High-Risk System Into the U.S. Market

Actor classification: The reseller is a distributor under Article 3(7) if the system was already placed on the EU market by the provider. The reseller is potentially an importer under Article 3(6) if the original provider is established outside the Union and the reseller places the system on the EU market. The U.S. distribution itself is outside the EU AI Act territorial scope under Article 2(1) unless the outputs are used in the Union.

Customer obligations: Article 24 distributor obligations for any EU-market distribution: verify CE marking, EU declaration of conformity, instructions for use, provider/importer compliance with Article 16(b) and Article 23; ensure storage and transport do not jeopardize compliance; take corrective action where the system is not in conformity. For U.S. distribution, U.S. federal and state law applies (no EU AI Act overlay unless EU outputs are involved).

Procurement contract checklist: Address the EU AI Act distributor / importer obligations explicitly for any EU-bound product. Address pass-through of provider information per Article 16(b). Address the cooperation framework for Article 23 importer-side documentation. Address authorized representative coordination if the upstream provider is non-EU.

Vendor 5 - Customer Buys Anthropic Claude API Access; Builds an Internal Coding Assistant; No Modification, No Trademark

Actor classification: Anthropic is the GPAI provider (Article 53) and the AI system provider for the underlying Claude API. The customer's internal coding assistant is the customer's deployed AI system. The customer is the deployer of the coding assistant. No Article 25 transfer: no trademark on Claude itself, no substantial modification of Claude, no high-risk use case (coding assistance does not land in Annex III).

Customer obligations: Article 26 deployer obligations on the coding assistant (instructions for use compliance, human oversight assignment); Article 4 literacy for the engineering org; Article 50 obligations if the coding assistant interacts with natural persons (typically not for an internal IDE plug-in); reliance on Anthropic's Article 53 + Article 55 evidence via Annex XII downstream-deployer information.

Procurement contract checklist: Verify Anthropic's Annex XII deliverables; verify Code-of-Practice signatory status (Anthropic is a signatory); verify acceptable-use policy alignment with intended customer use; verify Article 50(2) marking commitments for any synthetic-content generation; verify incident-coordination clauses for Article 26(4) reporting to Anthropic and Anthropic's reciprocal Article 55(1)(c) reporting.

The Portfolio Actor Mapping - The L1 Artifact

The L1 artifact for this lesson is an actor mapping: a per-system row that classifies the customer's actor status (provider / deployer / distributor / importer / authorized representative / multiple), names the upstream vendor, identifies any Article 25 trigger (and the contractual allocation if any), names the obligation set that attaches, and identifies the contractual-amendment status. A representative actor mapping:

• Row 1: Workday Talent Acquisition AI - Deployer only; Workday is provider; no Article 25 trigger; contract Article 25 allocation language present; Article 26 + Article 27 FRIA + Article 4 literacy attach.
• Row 2: White-labeled "Acme HR Insights": Trademarked by Acme; Article 25(1)(a) trigger; contract allocation TBD; if allocation clear to upstream, deployer + contractual support; if silent, Acme becomes provider.
• Row 3: GPT-4 fine-tuned customer-service agent, Article 25(1)(b) substantial-modification trigger likely; Acme becomes provider of the fine-tune; Annex IV technical file owed; QMS owed; Article 47 declaration owed.
• Row 4: Reseller of EU-AI-Act system into U.S. - Distributor or importer for EU-bound product; Article 24 / Article 23 obligations attach for EU distribution; U.S. distribution under U.S. law.
• Row 5: Anthropic Claude internal coding assistant, Deployer only; Anthropic is GPAI provider; no Article 25 trigger; Article 26 + Article 4 attach.
• Row 6: Internal Llama 3.1-405B fine-tune for IT helpdesk agent, Article 25(1)(b) trigger; Meta is non-signatory; Acme becomes provider of fine-tune; non-signatory Annex XI / XII diligence overhead.
• Row 7: Google Vertex AI deployment of Gemini for marketing analytics, Deployer; Google is provider + GPAI provider; no Article 25 trigger.
• Row 8: White-labeled Anthropic Claude as "Acme Helpdesk" deployed across HR / Finance / Procurement - Trademarked by Acme; Article 25(1)(a) trigger; contract allocation TBD; deployer + provider depending on allocation.

Each row carries an actor classification with the Article 25 analysis explicit and the contractual-amendment status flagged. The mapping is the artifact procurement carries into every contract renegotiation.

Common Actor-Classification Mistakes

Mistake 1 - Assuming Default Deployer Status

"We just buy the SaaS, the vendor handles compliance", wrong if trademarking or substantial modification has occurred, or if the intended-purpose change rule applies. The default classification is fact-driven, not preference-driven. Run the Article 25 analysis on every procurement.

Mistake 2 - Silent Contract on Trademarking

White-labeled SaaS contracts that do not explicitly address Article 25(1)(a) allocation default to the downstream party (the trademarker) inheriting the full Article 16 provider obligation set. This is the most expensive mistake on the actor-classification side because the obligation differential between provider (heavy) and deployer (lighter) is substantial. 2026 procurement contracts for white-labeled AI must address Article 25(1)(a) explicitly.

Mistake 3 - Treating Fine-Tuning as Light Modification

Most enterprise fine-tunes of foundation models on internal data are substantial under Article 3(23): the model's behavior, performance, and risk profile changes materially. Article 25(1)(b) likely triggers. Treating fine-tuning as a light operation that does not trigger Article 25 is the second most expensive actor-classification mistake.

Mistake 4 - Intended-Purpose Creep

A deployer that takes a minimal-risk system and expands the use case into a high-risk Annex III category triggers Article 25(1)(c), the deployer becomes the provider of the high-risk system. Use-case expansion is a common pattern in agile organizations; the change-control gate must include Article 25(1)(c) analysis.

Mistake 5 - Skipping the Distributor / Importer Analysis

Resellers of regulated AI systems into the EU market inherit Article 24 distributor or Article 23 importer obligations. Channel partners, value-added resellers, system integrators bundling regulated AI into broader offerings, all may be in scope. The contract should specify the actor classification and the allocation of verification responsibilities.

Mistake 6 - Treating the Authorized Representative as a Separate Actor

The Article 22 / Article 54 authorized representative is a vehicle for non-EU providers to discharge obligations inside the Union, not a separate actor with its own obligation set. The AR's obligations derive from the provider's obligations. Programs sometimes overstate the AR's independent role; the AR is functionally an EU-resident proxy for the non-EU provider.

Contractual Language Procurement Should Now Demand

In 2026 every AI procurement contract should include explicit clauses addressing actor classification and Article 25 transfer. Five required clauses:

• Article 25 allocation clause: Explicit allocation of provider obligations between upstream vendor and customer; default rule for trademarking, fine-tuning, and intended-purpose changes; notification process under Article 25(2).
• Annex XI / XII delivery clause: Specific deliverables, delivery dates, format alignment with AI Office templates, update obligations on technical changes.
• Article 73 / Article 26(4) incident-coordination clause: Timing, scope, communication owners, retention for cross-party serious-incident reporting.
• Substantial-modification change-control clause, What changes constitute substantial modification; notification process; provider/deployer cooperation under Article 25(2).
• Acceptable-use clause. Use cases authorized vs. prohibited; trigger conditions for re-classification; restrictions on intended-purpose change.

Procurement teams trained on these five clauses in 2026 prevent the actor-classification surprises that surface in audits. The contractual-language work is the most leveraged investment Procurement can make in AI Act readiness.

Key Takeaways

• The AI Act has four primary actors plus the authorized representative. Provider (Article 3(3), Article 16), deployer (Article 3(4), Article 26), distributor (Article 3(7), Article 24), importer (Article 3(6), Article 23), authorized representative (Article 22 / Article 54).
• Classification is per-system, fact-driven, not per-organization preference. The same organization can be a provider for one system, a deployer for another, an importer for a third.
• Article 16 provider obligations are the heaviest tier. Compliance with Chapter III Section 2; identification; QMS; technical documentation; logs; conformity assessment; declaration; CE marking; EU database registration; corrective action; authority cooperation; demonstration on request.
• Article 26 deployer obligations are substantial. Instructions compliance, human oversight, input-data quality, monitoring, log retention, worker notification, FRIA, GDPR overlay, decision-affected-person notification, profiling cooperation.
• Article 25 transfers obligations between actors in three scenarios. Article 25(1)(a) trademarking (contractually rebuttable); Article 25(1)(b) substantial modification (no contractual escape); Article 25(1)(c) intended-purpose change converting non-high-risk to high-risk.
• Trademarking + silent contract = customer inherits provider obligations. White-labeled SaaS contracts must explicitly address Article 25(1)(a) allocation.
• Fine-tuning is typically substantial modification. Most enterprise fine-tunes trigger Article 25(1)(b); the customer becomes provider of the fine-tuned model.
• Intended-purpose change triggers Article 25(1)(c). Use-case expansion that pulls a minimal-risk system into Annex III high-risk converts the deployer into the provider.
• The L1 artifact is the actor mapping. Per-system row with actor classification, Article 25 analysis, obligation set, contractual-amendment status. Flows into every procurement contract review.
• Procurement contracts in 2026 need five explicit clauses. Article 25 allocation, Annex XI/XII delivery, Article 73 / Article 26(4) incident coordination, substantial-modification change control, acceptable-use restrictions. These prevent the actor-classification surprises that surface in audits.