The EU AI Act does not assign accountability based on who built a system. It assigns accountability based on who controls its market entry, modification, and purpose. For governance teams, this means legal duties travel dynamically along the value chain — and the mechanisms governing that travel are now operative law.
The Statutory Mechanism of Duty Transfer: Article 25
Article 25 of the EU AI Act contains the regulation’s most consequential — and most frequently overlooked — accountability mechanism. It specifies the exact conditions under which a downstream party ceases to be a deployer and becomes a provider, assuming the full regulatory burden that status carries. Understanding these triggers is not an academic exercise. A deployer that crosses any of the three statutory lines without recognizing the shift in legal status assumes liability for conformity assessment, CE marking, quality management, and incident reporting obligations it may not be equipped to fulfill.
The Three Triggers for Provider Reclassification
Article 25(1) establishes three independent pathways to provider status. Each operates without regard to the parties’ contractual intent.
The first trigger, under Article 25(1)(a), captures white-labeling and rebranding. Any distributor, importer, deployer, or third party that places its name or trademark on a high-risk AI system already on the market becomes the provider for regulatory purposes. The Act does allow contractual arrangements that allocate obligations differently, but the regulatory default assigns provider status to the entity whose name appears on the system. Procurement teams negotiating SaaS resale or OEM agreements should treat this as a hard ceiling: a contract that shifts obligations to a vendor does not erase the statutory presumption that the name on the product carries the compliance burden.
The second trigger, under Article 25(1)(b), arises when a party makes a substantial modification to a high-risk AI system already placed on the market or put into service, provided the modified system remains high-risk under Article 6. A substantial modification is defined in Article 3(23) as a change not foreseen or planned in the initial conformity assessment that affects compliance with Chapter III, Section 2 requirements or modifies the intended purpose for which the system was assessed. This definition is narrow in theory and treacherous in practice. Fine-tuning a model on proprietary data, restructuring retrieval-augmented generation pipelines, or altering the decision threshold of a classification system can each affect compliance with risk management, data governance, or accuracy requirements. Deployers that treat vendor models as black boxes they may freely customize without legal consequence are misunderstanding the Act’s architecture.
The third trigger, under Article 25(1)(c), applies when a party modifies the intended purpose of an AI system — including a general-purpose AI system — that was not originally classified as high-risk, such that the modified system falls within Article 6 and becomes high-risk. This captures the increasingly common scenario in which an organization takes a general-purpose model or a narrow-purpose tool and redirects it toward an Annex III use case such as credit scoring, recruitment screening, or law enforcement analytics. The original non-high-risk classification becomes irrelevant the moment the intended purpose shifts across the regulatory threshold.
The Cessation and Cooperation Rule
Article 25(2) operates as a statutory severance and handover protocol. When any of the three triggers activates, the original provider ceases to be the provider of that specific system. The new provider steps into the full obligation stack. The original provider, however, does not walk away freely. It must closely cooperate with the new provider and make available the necessary information, technical access, and assistance required for the new provider to fulfill its obligations — particularly regarding conformity assessment.
This cooperation duty contains one explicit exception. If the original provider has clearly specified that its AI system is not to be changed into a high-risk AI system, the cooperation obligation does not apply. This reservation functions as a contractual shield for vendors that want to prevent downstream modifications from dragging them into ongoing compliance support. For deployers, it means that vendor terms containing this reservation will block access to the technical documentation and assistance needed to achieve conformity if the deployer later triggers Article 25(1)(b) or (c). The decision to accept such terms carries long-tail regulatory risk.
The Full Obligation Stack Upon Reclassification
A party that triggers Article 25(1) assumes every obligation under Article 16. The new provider must establish and maintain a quality management system under Article 17, implement risk management under Article 9, ensure data governance under Article 10, compile technical documentation under Article 11, maintain logs under Article 12, provide transparency information under Article 13, design for human oversight under Article 14, and ensure accuracy, robustness, and cybersecurity under Article 15. The new provider must also undergo conformity assessment under Article 43, affix CE marking under Article 48, draw up an EU declaration of conformity under Article 47, and register the system in the EU database under Article 49.
There is no grace period. The reclassification activates the full obligation stack immediately. A deployer that substantially modifies a system on a Tuesday must be prepared to demonstrate conformity as a provider on Wednesday. The financial exposure is severe. Article 99(4) of the Act imposes administrative fines of up to €15 million or 3% of total worldwide annual turnover for non-compliance with Article 16 provider obligations or Article 26 deployer obligations.
The Deployer’s Non-Delegable Baseline: Article 26
Even when a deployer does not trigger Article 25 reclassification, it retains a distinct and non-transferable set of obligations under Article 26. These duties exist in parallel to the provider’s obligations and cannot be contractually shifted to a vendor. A service agreement that requires the provider to “ensure AI Act compliance” may create a contractual indemnity, but it does not satisfy the deployer’s statutory duties to regulators.
Operational Compliance and Human Oversight
Article 26(1) requires deployers to take appropriate technical and organizational measures to ensure they use high-risk AI systems in accordance with the instructions for use. This is not a passive duty. It requires the deployer to read, understand, and enforce the boundaries set out in the provider’s documentation. If the instructions for use specify that the system must not be deployed without a human review step, the deployer must build that step into its operational workflow.
Article 26(2) mandates that deployers assign human oversight to natural persons who possess the necessary competence, training, and authority, and who receive the necessary support. The Act explicitly preserves the deployer’s freedom to organize its own resources for implementing the oversight measures indicated by the provider. This means the deployer cannot blame the provider for inadequate oversight design if the deployer assigned oversight to junior staff without domain expertise or decision-making authority.
Where the deployer exercises control over input data, Article 26(4) requires it to ensure that input data is relevant and sufficiently representative in view of the system’s intended purpose. A recruitment tool fed with historical hiring data that underrepresents certain demographics violates this provision regardless of whether the provider’s training data was balanced.
Monitoring, Risk Detection, and Incident Reporting
Article 26(5) imposes a continuous monitoring duty. Deployers must monitor the operation of the high-risk AI system on the basis of the instructions for use and inform providers in accordance with Article 72. If a deployer has reason to consider that use in accordance with the instructions may result in the system presenting a risk within the meaning of Article 79(1), it must inform the provider or distributor and the relevant market surveillance authority without undue delay, and suspend use of the system.
The reporting cascade intensifies for serious incidents. Deployers that identify a serious incident must immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities. If the deployer cannot reach the provider, Article 73 applies by analogy. This creates a direct line of accountability from the deployer to regulators that bypasses the provider entirely when communication fails.
Financial institutions subject to Union financial services law receive a limited carve-out. For these deployers, the monitoring obligation is deemed fulfilled by complying with the rules on internal governance arrangements, processes, and mechanisms under the relevant financial service law. This does not extinguish the incident reporting duty; it merely aligns the monitoring mechanism with existing prudential frameworks.
Log Retention
Article 26(6) requires deployers to keep the logs automatically generated by the high-risk AI system for a period appropriate to the intended purpose, of at least six months, unless Union or national law provides otherwise. The deployer’s obligation applies only to logs under its control. This creates a boundary dispute in cloud-hosted deployments where logs may reside on the provider’s infrastructure. Deployers should negotiate contractual access to these logs before deployment, not after a regulator requests them.
Worker and Individual Notification
Article 26(7) requires employers to inform workers’ representatives and affected workers before putting a high-risk AI system into use at the workplace. This obligation operates independently of data protection law and must be satisfied even where no personal data processing occurs. Article 26(11) adds a separate transparency duty: deployers of Annex III high-risk systems that make decisions or assist in making decisions related to natural persons must inform those persons that they are subject to the system. This obligation overlaps with but is distinct from the GDPR transparency requirements under Articles 13 and 14.
The Fundamental Rights Impact Assessment
Article 27 imposes a fundamental rights impact assessment (FRIA) on specific categories of deployers prior to deploying a high-risk AI system. The obligation applies to public bodies, private entities providing public services, and deployers of high-risk systems used for credit scoring or insurance pricing (Annex III, points 5(b) and (c)). The FRIA must include a description of the deployer’s processes, the period and frequency of use, the categories of persons likely to be affected, the specific risks of harm, the implementation of human oversight measures, and the mitigation measures including internal governance and complaint mechanisms.
The obligation applies to the first use of the system. Deployers may rely on previously conducted assessments or existing impact assessments carried out by the provider, provided the context is similar. If any element changes during use, the deployer must update the assessment. Once performed, the deployer must notify the market surveillance authority of the results, submitting the template the AI Office is required to develop under Article 27(5).
The temporal scope is critical. Article 27 obligations take effect on December 2, 2027 for Annex III standalone high-risk systems, and on August 2, 2028 for Annex I product-embedded high-risk systems. Where a GDPR data protection impact assessment is already required under Article 35 of Regulation (EU) 2016/679 or Article 27 of Directive (EU) 2016/680, the FRIA must complement rather than duplicate it. Deployers should begin mapping their GDPR DPIA processes against the Article 27 elements now, because the two assessments will need to be cross-referenced when the FRIA deadline arrives.
The Transparency Layer: Article 50 as a Shared Accountability Chain
Article 50 of the EU AI Act operates on a different accountability logic than Article 25. Where Article 25 transfers the entire provider obligation stack downstream, Article 50 imposes simultaneous and complementary duties on both providers and deployers. Neither party can contract out of its share. The provider must build detectability into the system. The deployer must deliver the disclosure to the individual. The chain only functions when both links hold.
The transparency obligations took effect on August 2, 2026. They apply to specific categories of AI systems regardless of risk classification, meaning a minimal-risk chatbot carries the same transparency burden as a high-risk diagnostic tool if it falls within Article 50’s scope. The European Commission published a Code of Practice on Transparency of AI-generated Content on June 10, 2026, and adopted final Guidelines on transparency obligations on July 20, 2026, to assist implementation. The Code is voluntary, but signatories benefit from a presumption of compliance and streamlined enforcement focused on adherence to the Code rather than case-by-case adequacy assessments.
Provider Technical Marking Obligations
Article 50(2) requires providers of AI systems that generate synthetic audio, images, video, or text to ensure that outputs are marked in a machine-readable format and are detectable as artificially generated or manipulated. This is a design-level obligation. It applies to the architecture of the system, not to the content distribution layer. Providers must embed technical markers — such as metadata, watermarks, or fingerprinting — at the point of generation. The Code of Practice specifies that signatories should implement a multi-layered approach using at least two methods, typically metadata and watermarking, with detection solutions made available to deployers, end-users, and authorities.
A limited transition period applies. AI systems already placed on the market before August 2, 2026 have until December 2, 2026 to comply with the machine-readable marking requirement. Systems placed on the market on or after August 2 must comply immediately. Providers relying on the transition period should document the basis for doing so, because market surveillance authorities may request evidence that the system was genuinely on the market before the cutoff.
Deployer Disclosure Obligations
Article 50(1), (3), and (4) impose separate duties on deployers that cannot be satisfied by the provider’s technical marking alone.
Under Article 50(1), deployers must ensure that individuals are informed when they interact directly with an AI system, unless the artificial nature of the interaction is already obvious to a reasonably well-informed, observant, and circumspect person. The disclosure must occur no later than at the time of the first interaction. A footnote buried in terms of service does not satisfy this requirement. The Commission Guidelines clarify that the notice must be clear, distinguishable, and accessible — not a faint label, a brief flash, or text hidden in a footer.
Article 50(3) requires deployers to inform individuals that they are exposed to emotion recognition or biometric categorization systems. This applies even where the system does not process personal data in a manner that triggers GDPR transparency obligations. The duty is triggered by exposure to the system, not by data collection.
Article 50(4) requires deployers to disclose deepfakes and AI-generated or manipulated text published to inform the public on matters of public interest, unless the content has undergone human review and editorial control. The Code of Practice introduces a standardized EU icon for this disclosure and distinguishes between “fully AI-generated” content and “AI-assisted” content, with different disclosure requirements for each. Deployers must label deepfake images, audio, and video at the time of first exposure, with specific placement rules varying by medium: persistent labels for video, visible labels for images, and audible disclaimers for audio.
The Coordination Problem
The shared nature of Article 50 creates a governance coordination problem. A deployer using a third-party generative AI system cannot satisfy its disclosure obligations if the provider has not implemented machine-readable markers. Conversely, a provider that embeds perfect metadata cannot ensure the deployer will surface the disclosure to end users. The accountability chain under Article 50 is only as strong as the weakest operational link. Procurement teams should verify both the provider’s marking infrastructure and their own disclosure workflows before deployment, because regulatory liability attaches to each party for its own statutory duties.
The Substantial Modification Trap: Where Deployers Unintentionally Become Providers
Article 25(1)(b) is the most dangerous trigger for deployers because it captures routine post-deployment activity that organizations do not recognize as a statutory event. The provision states that any party making a substantial modification to a high-risk AI system already on the market or in service, such that the system remains high-risk under Article 6, becomes the provider for regulatory purposes. The definition of “substantial modification” in Article 3(23) turns on two tests: whether the change was foreseen or planned in the initial conformity assessment, and whether it affects compliance with Chapter III, Section 2 requirements or modifies the intended purpose for which the system was assessed.
High-Risk Scenarios for Deployers
Several common deployment practices meet the Article 3(23) threshold.
Fine-tuning or retraining on proprietary data. A deployer that takes a vendor’s pre-trained high-risk model and fine-tunes it on internal customer data, domain-specific medical records, or proprietary transaction histories may alter the model’s accuracy, robustness, or bias profile in ways that affect compliance with Article 15. If the initial conformity assessment did not anticipate this specific fine-tuning regime, the modification is substantial.
Restructuring retrieval-augmented generation pipelines. Changing the retrieval mechanism, document corpus, or embedding strategy in a RAG-based system can fundamentally alter the outputs the system produces. If the original technical documentation specified a particular knowledge base or retrieval threshold, deviating from that specification may affect the system’s accuracy or the representativeness of its outputs under Article 10.
Altering decision thresholds or output logic. A credit scoring model shipped with a default classification threshold may be recalibrated by the deployer to optimize for a different false-positive rate. This directly affects the risk profile of the system and may invalidate the original conformity assessment under Article 43.
Changing the deployment context to shift intended purpose. A system originally assessed for internal HR analytics that is repurposed for external recruitment screening crosses into a different Annex III use case. The intended purpose has changed, and the new purpose may carry different high-risk classification criteria, different fundamental rights implications, and different conformity assessment requirements.
Integrating a non-high-risk GPAI model into a high-risk workflow. A general-purpose AI model that was not subject to high-risk obligations may become the core component of a high-risk system when integrated into an Annex III application. The integrator becomes the provider of the resulting high-risk system under Article 25(1)(c), and the full obligation stack attaches immediately.
The Absence of a Grace Period
Article 25 reclassification activates the full provider obligation stack the moment the trigger event occurs. There is no notification period, no transitional compliance window, and no safe harbor for good-faith efforts. A deployer that substantially modifies a system on a Tuesday must be capable of demonstrating a quality management system, technical documentation, and conformity assessment as a provider on Wednesday. The original provider’s cooperation duty under Article 25(2) may help, but only if the original provider has not reserved its right to withhold cooperation by specifying that the system is not to be changed into a high-risk AI system. Many standard vendor terms contain exactly this reservation.
The practical implication is that deployers must conduct pre-modification legal assessments before customizing any third-party AI system. The assessment should ask three questions: Was this modification foreseen in the original conformity assessment? Does it affect compliance with any Chapter III, Section 2 requirement? Does it modify the intended purpose? If the answer to any question is yes, the organization is no longer merely deploying. It has become a provider, and its compliance posture must change accordingly.
Contractual Infrastructure: Building the Accountability Chain in Vendor Agreements
The EU AI Act does not rely on market pressure or best-practice encouragement to align supply-chain incentives. It imposes specific contractual mandates that transform the provider-deployer relationship from a commercial transaction into a regulated compliance chain. Organizations that treat AI procurement as a standard software licensing exercise will find their vendor agreements structurally incompatible with the Act’s requirements.
The Article 25(4) Mandate
Article 25(4) requires providers of high-risk AI systems and third-party suppliers of tools, services, components, or processes used or integrated into those systems to enter into a written agreement. The agreement must specify the necessary information, capabilities, technical access, and other assistance required for the provider to comply with its obligations under the Act, based on the generally acknowledged state of the art. This is not a suggestion. It is a statutory condition for lawful supply-chain relationships involving high-risk systems.
The obligation applies to both parties. The high-risk provider must secure written terms from its upstream suppliers. The upstream supplier must provide them. The only exception applies to third parties that make tools, services, processes, or components available under a free and open-source license, provided they are not general-purpose AI models. A vendor shipping proprietary APIs, cloud inference services, or licensed training datasets cannot invoke this exception.
The AI Office may develop voluntary model contract terms for these agreements, but no such terms have been published. Until they appear, organizations must draft their own. The statutory floor is clear: the written agreement must cover information, capabilities, technical access, and assistance. What each of these requires in practice will vary by system, but the absence of any written agreement covering these four elements is itself a violation.
The Article 25(2) Cooperation Agreement
When Article 25(1) triggers and a deployer becomes a provider, Article 25(2) imposes a cooperation duty on the original provider. It must closely cooperate with the new provider and make available the necessary information and reasonably expected technical access and assistance required for fulfillment of the Act’s obligations. Deployers-turned-providers should ensure their upstream contracts contain clauses that secure this cooperation in advance, because the original provider’s willingness to cooperate may depend entirely on whether the deployer’s modifications voided any “not to be changed into high-risk” reservation in the original terms.
Essential Contractual Provisions for Deployers
Deployers procuring high-risk AI systems should demand specific contractual elements that standard SaaS agreements rarely include.
Technical documentation delivery. The contract should require the provider to deliver documentation satisfying Article 11, including training data provenance, accuracy benchmarks, known limitations, and risk management measures. This documentation is not merely useful for internal review. It is the evidentiary foundation for the deployer’s own compliance duties under Article 26 and for any future conformity assessment if Article 25(1) triggers.
Instructions for use with compliance boundaries. Article 13 requires providers to supply instructions for use that include the system’s intended purpose, conditions under which it must not be deployed, and human oversight requirements. The contract should mandate delivery of these instructions and prohibit deployment configurations that violate them. A deployer that uses a system outside its specified conditions may lose the ability to claim it operated “in accordance with the instructions for use” under Article 26(1).
Modification notification. The contract should require the provider to notify the deployer within a defined period of any substantial modification to the system. This protects the deployer from discovering mid-audit that the provider altered the model, training data, or architecture in a way that affects the deployer’s own compliance posture.
Log access and retention. Article 26(6) requires deployers to retain logs for at least six months. In cloud-hosted deployments, those logs often reside on the provider’s infrastructure. The contract must grant the deployer access to these logs and specify retention periods that meet or exceed the statutory minimum.
Regulatory cooperation. The contract should require the provider to cooperate with conformity assessment processes, market surveillance authority inquiries, and incident investigations. This is distinct from general support obligations. It specifically covers the provider’s duty to supply evidence, technical explanations, and corrective actions when regulators investigate the system.
The Non-Delegable Deployer Duties
No contract can transfer Article 26 obligations from a deployer to a provider. A vendor agreement that states the provider “shall ensure full AI Act compliance” creates a contractual remedy for breach, not a regulatory defense. If a market surveillance authority finds that a deployer failed to assign competent human oversight under Article 26(2), the deployer bears the administrative fine. It may then seek indemnification from the vendor under the contract, but the regulatory liability remains with the deployer.
This distinction matters for insurance and risk allocation. Cyber liability policies and professional indemnity coverage may respond to contractual breaches differently than they respond to statutory fines. Governance teams should review whether their coverage explicitly excludes regulatory penalties, because Article 99 fines are administrative, not criminal, and many policies carve out administrative sanctions.
Cross-Framework Accountability: NIST AI RMF and ISO/IEC 42001
The EU AI Act’s mandatory duty chain sits alongside voluntary governance frameworks that organizations frequently adopt for operational discipline, customer assurance, or regulatory anticipation. Understanding where these frameworks align with the Act and where they diverge is essential for avoiding the common misconception that certification or framework alignment satisfies legal obligation.
NIST AI RMF Supply Chain Governance
The NIST AI Risk Management Framework embeds supply-chain accountability through several functions. GOVERN 6 addresses policies for managing risks associated with third-party software and data. MAP 4 requires organizations to map risks and benefits for all components of the AI system, including third-party software and data. MANAGE 3 focuses on managing risks from third-party entities, including AI models, data, and software obtained from external sources.
These functions anticipate the provider-deployer accountability gaps that the EU AI Act addresses through statutory mandate, but they do so voluntarily. An organization that implements NIST AI RMF supply-chain controls has a governance structure that regulators may view favorably, but it does not have the specific contractual terms, conformity assessments, CE markings, or database registrations the Act requires. The NIST framework is a risk management methodology. The EU AI Act is a product safety regulation. They operate in different legal registers.
ISO/IEC 42001:2023 Supplier Controls
ISO/IEC 42001:2023 specifies requirements for establishing an Artificial Intelligence Management System (AIMS). Annex A.10 of the standard addresses controls for supplier relationships, including third-party AI assessment, contractual requirements for notification and auditing, and ongoing monitoring of supplier performance. Certification to ISO/IEC 42001 demonstrates that an organization has implemented a structured governance framework for AI.
Certification may support a “reasonable governance” argument in regulatory or litigation contexts, but it does not satisfy the EU AI Act’s system-specific compliance requirements. A certified organization that deploys a high-risk AI system without a conformity assessment, without CE marking, and without registering in the EU database is not compliant with the Act, regardless of its ISO certification status. The standard manages organizational processes. The Act regulates product-level safety and accountability.
The Regulatory Gap
Organizations that rely solely on NIST AI RMF or ISO/IEC 42001 may possess mature governance structures while lacking the specific legal instruments the EU AI Act demands. Framework alignment is useful evidence of organizational intent and operational discipline. It is not a compliance substitute. Governance teams should treat these frameworks as complementary infrastructure: NIST and ISO provide the management system, while the EU AI Act provides the legal obligations that must be embedded within it. The accountability chain under the Act requires contracts, conformity assessments, and regulatory registrations that no voluntary framework can generate on its behalf.
Temporal Dimensions: How the Digital Omnibus Reshapes the Accountability Timeline
The EU AI Act’s accountability chain does not operate on a single deadline. Different links in the chain activate at different moments, and the Digital Omnibus on AI (Regulation (EU) 2026/1744) has altered the schedule for some while leaving others untouched. Understanding which obligations are live now, which are deferred, and which operate independently of the deferral is essential for allocating compliance resources correctly.
The New Timeline
The Digital Omnibus was published in the Official Journal on July 24, 2026, and entered into force on July 27, 2026. It introduced a two-tier deferral for high-risk obligations. Standalone high-risk AI systems under Annex III — covering biometrics, critical infrastructure, education, employment, credit scoring, insurance, law enforcement, migration, and administration of justice — now have until December 2, 2027 to comply with the full Chapter III obligation stack. AI systems embedded in products already regulated under EU product-safety legislation, such as medical devices, machinery, and toys, have until August 2, 2028.
Several obligations remained on their original schedules and are already enforceable. The Article 5 prohibited-practices regime has applied since February 2, 2025. General-purpose AI model obligations under Articles 51–56 took effect on August 2, 2025. Article 50 transparency obligations for providers and deployers became enforceable on August 2, 2026, with a four-month grace period for machine-readable watermarking of systems already on the market before that date. The Commission’s enforcement powers under Chapter VII are fully active.
Why the Deferral Does Not Pause Governance
The deferral of Annex III high-risk obligations provides time to build compliance infrastructure, but it does not create a safe harbor for accountability chain failures. Article 25 reclassification operates independently of the general deferral. A deployer that substantially modifies a high-risk AI system in 2026 assumes the full provider obligation stack immediately, regardless of whether the original system was subject to the December 2027 deadline. The statutory trigger is the modification event, not the calendar.
Article 50 transparency duties are already live and create immediate shared accountability between providers and deployers. A deployer using a generative AI system without disclosing the artificial nature of the interaction to end users is violating Article 50(1) now, not in December 2027. The same applies to emotion recognition disclosures under Article 50(3) and deepfake labeling under Article 50(4).
Contractual lead times for renegotiating SaaS and API agreements often exceed twelve months. Organizations that wait until mid-2027 to demand Article 25(4) written terms from their vendors may find that negotiation cycles, procurement approvals, and technical integration timelines push compliance past the December deadline. The deferral is lead time, not a reprieve.
Building the Accountability Chain Before the Deadlines Arrive
Providers, deployers, and organizations that may occupy both roles should treat the deferral period as an opportunity to harden the accountability chain before regulatory scrutiny intensifies.
Providers should audit all downstream distribution, resale, and white-label agreements for Article 25(1)(a) exposure. Any agreement that permits a distributor or deployer to place its own name or trademark on the system without contractual allocation of provider obligations creates a direct path to shared — or transferred — regulatory liability. Providers should also prepare Article 25(2) cooperation protocols in advance, because a downstream modification that triggers reclassification will require immediate information sharing and technical access. Inserting “not to be changed into high-risk” reservations into standard terms may limit cooperation exposure, but it also reduces the provider’s ability to support downstream compliance when requested.
Deployers should inventory every AI system for modification activity that could trigger Article 25(1)(b) or (c). This inventory must include not only systems explicitly classified as high-risk but also general-purpose models and narrow-purpose tools that could be redirected toward Annex III use cases. Deployers should verify Article 50 transparency compliance for all customer-facing AI systems immediately, because these obligations are not deferred. They should also demand Article 25(4) written terms from any vendor supplying high-risk systems, specifying the information, capabilities, technical access, and assistance required for compliance. Standard SaaS agreements rarely contain these provisions.
Dual-role organizations — those that both develop and deploy AI systems, or that customize vendor systems for internal use — face the highest reclassification risk. These organizations should implement system-by-system role classification rather than relying on an organization-level designation. A company may be a provider for one system and a deployer for another, and the legal status of each system must be tracked independently. Development workflows should include review triggers that catch Article 25 reclassifications before they shift the compliance burden: any fine-tuning, integration, or purpose change should trigger a legal assessment asking whether the modification was foreseen in the original conformity assessment, whether it affects Chapter III compliance, and whether it alters the intended purpose.
The accountability chain under the EU AI Act is not a theoretical construct. It is a set of statutory mechanisms — reclassification triggers, cooperation duties, contractual mandates, and transparency obligations — that assign liability based on who controls the system’s market entry, modification, and use. Organizations that map these mechanisms now will enter the deferred enforcement period with the infrastructure to manage them. Those that wait until December 2027 will find that the chain has already tightened around them.
Covering responsible AI, governance frameworks, policy, ethics, and global regulations shaping the future of artificial intelligence.