This second part continues EU market access for AI systems and models. Part I sets out the market-access framework, classification rules, principal duties and application dates.
Summary
A customer using a supplier's existing application normally fits the deployer definition. Commissioning a new own-name application can produce a different result, even when a contractor writes all its code. (AI Act, Articles 3(3), 3(4), 3(63) and 3(68).)
A supplier's express prohibition on conversion to high-risk use can remove the statutory cooperation entitlement without preventing the downstream conversion trigger. (AI Act, Articles 25(1)(c), 25(2) and 25(4).)
The system, entity and activity determine the role
For a system, Article 3(3) requires development, or having the system developed, together with own-name or own-trademark market placement or putting into service. Those conditions must be tested together. Writing code alone does not necessarily establish provider status. Owning intellectual property, funding development or hosting software also does not substitute for the remaining statutory conditions. Conversely, outsourcing all development does not prevent the commissioning organisation from satisfying them. (AI Act, Article 3(3).)
A deployer uses an AI system under its authority, outside the personal non-professional exception. An employer that selects a supplier's application and directs its business use can satisfy that definition without developing anything. Assigning employees to operate the application does not, by itself, displace the employer's role. Article 4 expressly addresses staff and other persons operating systems on an organisation's behalf. (AI Act, Articles 3(4) and 4(1).)
Classification must also distinguish legal entities within a group. A parent commissioning and supplying an application, a subsidiary operating it, and an external model supplier require separate assessments. A common corporate brand does not establish which entity developed, supplied or used the system. Nor does a group procurement agreement establish that every subsidiary is a provider. The decisive facts remain each entity's activity and authority over the identified system. (AI Act, Articles 3(3) to 3(11).)
Exclusions precede classification
The personal-use exception concerns natural persons acting on a purely personal, non-professional basis. A sole trader using AI professionally cannot rely on the exception merely because the business lacks a separate company. The statutory distinction turns on the activity's character. (AI Act, Articles 2(10) and 3(4).)
The Act excludes specified activities outside EU competence and systems used exclusively for military, defence or national-security purposes. A commercial supplier cannot extend that exclusivity exception to a separate civilian deployment. Article 2(4) contains a further, conditional exception for specified international law-enforcement and judicial cooperation. Public-sector involvement alone establishes none of those exclusions. (AI Act, Article 2(3) and (4).)
Internal deployment and outsourced development
An unlaunched development project requires a separate assessment of whether first intended use has occurred. (AI Act, Articles 2(8), 3(3) and 3(11).)
A procurement contract can describe two materially different arrangements. In one, the customer acquires access to the vendor's existing, vendor-named product. In the other, the customer has a new system developed and first operates it under its own name. The first arrangement establishes a deployer role when the customer uses the application under its authority. The second can establish provider status as well. Purchasing a licence does not conclusively distinguish those arrangements. (AI Act, Articles 3(3), 3(4), 3(9) and 3(11).)
A managed service requires similar separation between the service and its underlying system. Receiving a completed report is insufficient, without more, to establish use of an AI system under the recipient's authority. The outcome can differ where the customer directs recurring system operation, configures its decisions or commissions an own-name application. Contract terms, instructions and actual operating authority must establish the relevant elements; the invoice description alone cannot do so. (AI Act, Articles 3(3), 3(4) and 3(12).)
A contractor can remain responsible for its own system or model while developing a distinct application for a customer. That possibility prevents the mistaken assumption that one provider must account for every technical layer. The contracting parties should identify the separately supplied products and the entity named for each. This is a practical means of applying the definitions, rather than a statutory requirement for one particular document format. (AI Act, Articles 3(3), 3(63), 3(66) and 3(68).)
Configuration and integration require a product-boundary assessment
Routine use of an existing supplier system does not automatically satisfy the development element. Selecting available settings, supplying instructions or connecting business information can remain deployment of that product. A configuration option's existence is relevant to intended purpose, but it does not decide whether the customer has created a distinct system. The assessment must identify what functionality the supplier already supplies and what the customer develops or commissions. (AI Act, Articles 3(3), 3(4) and 3(12).)
An own-name application that combines a model API with retrieval, business rules and external tools can satisfy Article 3(3). That conclusion assumes the combination meets the system definition and the organisation develops or commissions it before market placement or first intended use. Article 3(68) supports treating the application supplier as a downstream provider. The conclusion does not require retraining the underlying model. (AI Act, Articles 3(1), 3(3), 3(11) and 3(68).)
The strongest contrary argument is that the customer merely operates a configurable vendor product. That argument succeeds where the alleged new application is, on the facts, still the supplier's existing system used under the customer's authority. It weakens where the customer specifies a distinct application, has it developed and supplies or puts it into service under its own name. An integration's size or the number of lines of code supplies no statutory threshold. (AI Act, Articles 3(3), 3(4) and 3(68).)
Prompt changes, retrieval data, tool permissions and output rules also require assessment when they alter an existing system's purpose or compliance. None automatically constitutes a substantial modification. Equally, unchanged model weights do not exclude such a modification. Article 3(23) addresses changes to the system, rather than a particular technical component. The separate Article 25 conditions determine when a downstream change creates high-risk provider responsibility. (AI Act, Articles 3(23) and 25(1)(b) and (c).)
Commencement dates and legacy systems
Article 111(1) separately requires qualifying components of the Annex X large-scale IT systems placed on the market or put into service before 2 August 2027 to comply by 31 December 2030, without prejudice to Article 5. (AI Act, Article 111(1) and (2).)
Article 111(4) gives providers of qualifying synthetic-content systems placed on the market before 2 August 2026 until 2 December 2026 to comply with Article 50(2). Its enacted wording refers to market placement, so internal putting into service alone does not establish that extension. (AI Act, Article 111(3) and (4).)
Article 25 creates three distinct conversion routes
The triggers are alternatives. A rebrander need not also modify code, and a purpose-changing operator need not also adopt a new trademark. The following applications assume the relevant high-risk provisions apply and no scope or transitional exception displaces them. (AI Act, Articles 25(1), 111 and 113(c).)
The first trigger concerns putting a name or trademark on a system that is already high-risk and already placed on the market or put into service. That route can apply without a technical change. It expressly preserves contractual arrangements stipulating that obligations are otherwise allocated. This wording prevents treating every contract allocation as legally irrelevant. (AI Act, Article 25(1)(a).)
The saving concerns the allocation of obligations within a provision that deems the rebrander a provider. It does not expressly erase that classification. A contract should therefore distinguish who bears a duty, who performs particular compliance work and who indemnifies whom. A generic clause calling the buyer a deployer does not establish the statutory effect of those separate arrangements. The same express contractual saving does not appear in the modification or purpose-change limbs. (AI Act, Article 25(1)(a) to (c).)
The second trigger concerns a substantial modification of an already high-risk system that remains high-risk. Article 3(23) addresses a post-placement or post-service change which is not foreseen or planned in the initial conformity assessment carried out by the provider and which affects Chapter III, Section 2 compliance or changes the assessed intended purpose. A technically extensive update need not satisfy that definition if the relevant conditions fail. A smaller change can satisfy it when the statutory consequences occur. (AI Act, Articles 3(23) and 25(1)(b).)
For a learning system, changes predetermined by the provider and assessed through the initial conformity assessment do not constitute substantial modifications under Article 43(4). The technical documentation must contain the relevant predetermined changes. Later vendor approval alone does not establish that the initial assessment covered them. Where a substantial modification occurs, Article 43(4) requires a new conformity assessment even if the current deployer retains the system for its own use. (AI Act, Article 43(4); Annex IV, point 2(f).)
The third trigger concerns changing a previously non-high-risk system's intended purpose, after it has been placed on the market or put into service, so that it becomes high-risk under Article 6. The changed purpose and resulting Annex III classification can satisfy this route without changes to model weights. The result remains subject to Article 6(3), including its profiling rule. (AI Act, Article 25(1)(c); Article 6(3); Annex III, point 4(a).)
A supplier's narrow purpose statement is relevant, but the downstream activity still needs examination. Article 3(13) separately defines foreseeable misuse. An isolated misuse does not, without further facts, prove that the operator has changed the system's intended purpose. Repeated deployment for a newly specified function can provide materially different evidence. (AI Act, Articles 3(12), 3(13) and 25(1)(c).)
Article 25(1)(a) cannot be applied indiscriminately to rebranding a non-high-risk chatbot. Its stated object is an already high-risk system. A new own-name chatbot can nevertheless meet the general provider definition if its supplier develops or commissions it and supplies or puts it into service. These are separate legal routes with different conditions and commencement consequences. (AI Act, Articles 3(3), 25(1)(a) and 113.)
Upstream cooperation and contract design
Article 25(2) ordinarily ends the initial provider's status for the specific system when an Article 25(1) circumstance occurs. The amended text identifies necessary documentation, known limitations and failure modes, and targeted technical access for testing and validation where relevant. The provision concerns the specific system; it does not state that the supplier loses its role for every other copy or for a separately supplied model. (AI Act, Article 25(2).)
The exception requires careful reading. The final subparagraph excludes paragraph 2 where the initial provider clearly specified that its system must not be changed into a high-risk system. It expressly removes the cooperation and documentation obligation in that case. Because the exclusion refers to the paragraph as a whole, automatic cessation of the original provider's status should not be assumed within that exception. Article 25(1)(c)'s separate downstream trigger contains no exemption for a conversion forbidden by the supplier. (AI Act, Article 25(1)(c) and (2).)
A downstream operator can consequently acquire provider obligations without a statutory entitlement to the assistance needed to meet them. A deployment plan should resolve that problem before conversion: obtain an authorised route with adequate documentation or avoid the unsupported high-risk use. A disclaimer can affect the supply relationship, but it cannot turn an actual high-risk purpose into a non-high-risk purpose. (AI Act, Articles 3(12), 6 and 25(1)(c) and (2).)
Article 25(4) requires the high-risk provider and a third-party supplier to specify necessary information, capabilities, technical access and assistance by written agreement. It covers supplied systems, models, tools, services, components and processes used or integrated in the high-risk system. The required assistance must permit compliance, assessed against the generally acknowledged state of the art. (AI Act, Article 25(4).)
That agreement requirement excludes qualifying publicly accessible free and open-source tools, services, processes and components, but expressly excepts general-purpose AI models from that exclusion. Article 25 also preserves intellectual property, confidential business information and trade secrets in the circumstances it specifies. Necessary access does not create an unrestricted entitlement to source code or all training data. The parties must identify the information required for the concrete compliance task. (AI Act, Article 25(4) and (5).)
A useful agreement records the intended purpose, prohibited conversions, responsible entity and system versions. It should allocate corrective work. Those terms are practical responses to the statutory duties, rather than a substitute for them. Contractual performance and indemnity cannot establish compliance where the system lacks the necessary assessment or safeguards. (AI Act, Articles 16, 20, 25 and 26.)
General-purpose models and downstream modifications
Fine-tuning presents a distinct question: whether the organisation has developed a general-purpose model that it places on the market under its own name. The answer requires the model definition, the nature of the changes and the supply arrangement. Article 25's system-conversion tests cannot simply be substituted for the Chapter V model analysis. Nor does avoiding model-provider status prevent the organisation from being a downstream system provider. (AI Act, Articles 3(3), 3(63), 3(68) and 25.)
Internal model use also needs care. Recital 97 explains that integrating an own model into an own system supplied on the market or put into service can constitute placing the model on the market. Its treatment of purely internal processes excludes models essential to providing a product or service to third parties or affecting natural persons' rights. That internal-process qualification does not extend to general-purpose models with systemic risk. An internal-use description therefore cannot decide the Chapter V question without examining the actual function. Recital 97 assists interpretation; Article 3(3) remains the operative provider definition. (AI Act, Article 3(3) and recital 97.)
A model's licence also does not establish the downstream application's intended purpose or the identity of its provider. (AI Act, Articles 2(12), 3(3), 3(12) and 53(2).)
Authorised representatives and product manufacturers
An authorised representative receives and accepts a written mandate. A representative's mandate does not itself transfer the provider's entire statutory identity. Its duties concern the procedures and obligations specified by the relevant provision. (AI Act, Articles 3(5), 22 and 54.)
A Section A product manufacturer can be treated as the high-risk provider when it supplies the safety-component system with its own-name product. The rule also covers putting that system into service under the manufacturer's name after market placement of the product. Article 25(3) therefore requires attention to the later installation as well as the initial product sale. Its express Section A limitation must remain part of the analysis. (AI Act, Article 25(3).)
The high-risk duty sets remain different
Article 26 requires deployers, where applicable, to use the provider's Article 13 information to carry out their own required data-protection impact assessments. The deployer must perform those duties even where a separate supplier developed the system. (AI Act, Article 26(7) to (9) and (11).)
Enforcement, affected persons and contractual exposure
Article 86 separately provides a qualified right to an explanation for certain affected persons subject to decisions based on Annex III high-risk outputs. The right concerns AI's role and the main elements of the decision; it is not a general right to receive model weights or source code. (AI Act, Articles 85 and 86.)
The 2026 amendment expressly added Article 25(2) and (4) obligations to Article 99(4). Cooperation and necessary supply agreements therefore have an enforcement consequence when the underlying obligations apply. A fine cannot be inferred merely from the label provider or deployer without identifying an applicable breached duty. (AI Act, Articles 75c, 99(4)(da), 101 and 113.)
A provider classification alone does not determine compensation, causation or contractual indemnity under another legal regime. Article 25(1)(a)'s contractual saving concerns allocation of obligations; it does not establish a damages entitlement. An indemnity clause must be assessed separately from the authority's determination of an applicable statutory breach. (AI Act, Articles 2(9), 25(1)(a), 85, 86 and 99.)
