sota.io
2026-04-22·14 min read·

EU AI Act Art.25 Responsibilities along the AI Value Chain: Deemed-Provider Triggers, Substantial Modification, Written Agreement Requirements, and Art.25 × Art.16 × Art.22 × Art.26 × Art.47 Integration (2026)

Article 25 of the EU AI Act is the value-chain liability transformation provision. It defines the precise conditions under which a distributor, deployer, importer, or any other third party ceases to operate under their downstream-actor obligations and instead becomes a "deemed provider" — inheriting the full provider obligation stack under Art.16-22. Understanding Art.25 is essential for any organisation that modifies, rebrands, or repurposes high-risk AI systems received from another party.

The provision addresses a structural gap in supply chain regulation: without a clear transformation rule, parties could use contractual arrangements or brand structures to shift their position in the supply chain in ways that effectively orphan compliance obligations. Art.25 prevents that outcome by specifying three bright-line triggers that convert any downstream actor into a provider — regardless of what their contracts say, regardless of whether they consider themselves a reseller or integrator rather than an AI developer.

The Position of Art.25 in the Supply Chain Framework

The EU AI Act's supply chain compliance architecture assigns obligations based on role:

Art.25 is the transition mechanism. It answers the question: what happens when an importer, distributor, deployer, or other third party does something that changes the fundamental nature of their relationship with the AI system? The answer is that they become the provider — with all associated obligations — for the part of the system they have transformed.

Why Art.25 Matters Beyond Art.24(5):

Art.24(5) already provides that a distributor who makes a substantial modification or changes the intended purpose becomes a provider. Art.25 is broader: it applies to any third party — not just distributors. A deployer who substantially modifies a high-risk AI system becomes a provider under Art.25(1)(c). An importer who places the system on the market under their own name becomes a provider under Art.25(1)(a). Art.25 is the general transformation rule of which Art.24(5) is a specific instance.

Art.25(1): The Three Transformation Triggers

Any importer, distributor, deployer, or other third party shall be considered a provider for the purposes of the EU AI Act and shall be subject to the obligations of the provider under Art.16 in any of the following circumstances:

Art.25(1)(a): Own-Name Placement — Trademark and White-Labelling

The first transformation trigger applies when a downstream actor places a high-risk AI system on the market or puts it into service under their own name or trademark. This covers the white-labelling and own-branding scenarios that are common in commercial AI distribution.

Who this affects:

A software reseller who takes an AI system developed by a third-party provider, removes the original branding, adds their own name and trademark, and distributes the system as their own product is placing it on the market under their own name within the meaning of Art.25(1)(a). After that act of placement, the reseller is the provider. They bear Art.16 obligations — including maintaining or obtaining a quality management system, completing or commissioning a conformity assessment, maintaining technical documentation, registering in the EU database, and implementing post-market monitoring.

This does not require any technical modification to the system. The transformation is triggered by the commercial act of branding alone. A company that sells an AI hiring system developed by a third-party vendor under its own brand name — even if the underlying technology is entirely unchanged — becomes the provider.

The "made available" versus "placed on market" distinction:

Art.25(1)(a) applies when the third party "places on the market" or "puts into service" under their own name. This is different from Art.24, which governs making systems "available on the market" — a narrower act of downstream distribution without market placement. If a distributor merely passes through a system that bears the original provider's name and marking, Art.25(1)(a) does not apply. The trigger is the act of affixing one's own name or trademark and treating oneself as the party bringing the system to market.

White-labelling in SaaS and API contexts:

Art.25(1)(a) applies with particular force in the AI-as-a-service economy. A company that accesses a third-party foundation model API and provides its own user-facing AI application under its own brand is typically placing that capability on the market under its own name. Whether Art.25(1)(a) applies depends on whether the company is offering a high-risk AI system as defined by Art.6 and Annex III, and whether its product constitutes "placing on the market" rather than merely "using" the underlying AI. The intended purpose declared to end users, and how the product is positioned commercially, determine the answer.

Art.25(1)(b): Intended Purpose Change

The second transformation trigger applies when a downstream actor modifies the intended purpose of a high-risk AI system already placed on the market or put into service.

What "intended purpose" means:

Under Art.3(12) of the EU AI Act, "intended purpose" is the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the instructions for use, promotional material, or statements. The provider's intended purpose defines the scope of the conformity assessment, the risk management process, and the technical documentation.

The high-risk classification trigger:

The intended purpose change trigger in Art.25(1)(b) is particularly significant in the context of AI systems that are not initially classified as high-risk. Under Art.6(1), whether an AI system is high-risk depends in part on whether it is used as a safety component or in a safety-critical application. An AI system developed for a general document analysis purpose (not high-risk) that is repurposed by a deployer to evaluate creditworthiness (Annex III, point 5 — high-risk) changes both its classification and its regulatory status.

When this change occurs, the entity making the change — the deployer who has repurposed the system — becomes the provider for the new intended purpose. They must complete the full Art.16 obligation cycle: conduct or commission the conformity assessment for the new high-risk use case, prepare or update technical documentation to reflect the new intended purpose, register in the EU database, and issue a new Declaration of Conformity under Art.47.

Intended purpose change vs natural drift:

Not every evolution in how a system is used constitutes an Art.25(1)(b) intended purpose change. The original provider's instructions for use typically describe a range of permitted use cases. If a deployer uses the system within that range, they remain a deployer. The transformation trigger applies when the new use case falls outside the original intended purpose as defined in the provider's documentation — not merely when the deployer finds a new application within the described scope.

Art.25(1)(c): Substantial Modification

The third transformation trigger — and in practice the most complex to assess — applies when a downstream actor makes a substantial modification to a high-risk AI system already placed on the market or put into service.

What constitutes a substantial modification:

Recital 66 and the operative provisions clarify that a substantial modification is a change to the high-risk AI system that affects the system's compliance with the requirements of Chapter III Section 2 (Arts.9-15), or results in a change of the intended purpose. The modification assessment is fundamentally compliance-oriented: did the change affect whether the system meets the technical requirements for high-risk AI systems?

Changes that affect the training data, the model architecture, the objective function, key algorithmic parameters, or the output format are candidates for substantial modification assessment. Changes that are purely cosmetic (UI changes, branding, documentation updates) or that do not affect system behaviour (infrastructure migration without model changes) are typically not substantial modifications.

The system integrator risk:

System integrators who receive a high-risk AI system, connect it to additional data sources, fine-tune it on proprietary data, or integrate it with other software components are in a risk zone where Art.25(1)(c) may apply. Whether their integration work constitutes a substantial modification depends on whether the post-integration system would still pass the same conformity assessment as the original system. A fine-tuning operation that changes how the model makes predictions for the use case covered by the conformity assessment is likely a substantial modification. A configuration change that adjusts threshold values within the range specified in the technical documentation is likely not.

Recurrent modification vs single event:

Art.25(1)(c) applies to each substantial modification. A system integrator who makes multiple successive modifications — each potentially substantial — becomes the provider at each modification point. If the original provider has already transferred obligations under an Art.25(2) written agreement, the current "deemed provider" must assess whether their own subsequent modifications trigger a further transformation.

Art.25(2): The Written Agreement Mechanism

Art.25(2) provides that the original provider and the party who has become a deemed provider under Art.25(1) may conclude a written agreement. In that agreement:

What the agreement must cover:

An Art.25(2) agreement is a compliance allocation document. It must be specific enough to establish which party bears each obligation in the Art.16 list:

  1. QMS responsibility (Art.17): Who maintains the quality management system for the transformed system?
  2. Technical documentation (Art.18): Who maintains and updates the technical file?
  3. Logging obligations (Art.19): Who retains operational logs?
  4. Post-market monitoring (Art.72)**: Who runs the PMSP for the modified system?
  5. Conformity assessment (Art.43): Who commissions or conducts the conformity assessment for the new intended purpose or modified design?
  6. EU database registration (Art.49): Who registers the system?
  7. DoC (Art.47): Who issues the Declaration of Conformity?
  8. Corrective actions (Art.20): Who implements technical fixes and communicates with market surveillance?
  9. AR designation (Art.22): For third-country parties — who designates and instructs the authorized representative?

Agreement vs obligation substitution:

Art.25(2) does not allow the parties to contract around the substantive requirements — only to allocate which party discharges each obligation. The underlying obligations under Arts.16-22 cannot be eliminated by agreement; they can only be assigned. If neither party discharges an obligation, the market surveillance authority can hold either party responsible.

The absence-of-agreement scenario:

If no Art.25(2) agreement exists — because the original provider is unaware of the transformation, refuses to enter into an agreement, or because the parties have not identified that a transformation trigger has been met — the full Art.16 obligation stack falls on the party who triggered Art.25(1). The absence of a written agreement does not reduce liability; it concentrates it on the deemed provider.

Art.25(3): Cooperation Obligation

Where a third party has become a deemed provider under Art.25(1), they shall cooperate with the original provider in discharging their compliance obligations.

This cooperation obligation exists in parallel with the Art.25(2) agreement mechanism. Even without a formal allocation agreement, the transformation triggers an immediate cooperation duty. The original provider retains knowledge of the system's design, the original conformity assessment, the technical documentation, and the notified body certificate (where applicable). The new deemed provider needs access to this information to discharge their Art.16 obligations.

In practice, Art.25(3) means:

The traceability implication:

Art.25(3) cooperation obligations interact with the Art.24(3) and Art.23(3) backward traceability requirements. Market surveillance authorities who investigate a modified or repurposed high-risk AI system need to reconstruct the transformation history: who made what changes, when, with what materials, and based on what documentation. The Art.25(3) cooperation obligation requires both the original provider and the deemed provider to maintain records that support this reconstruction.

Art.25(4): Authorized Representative Obligation Transfer

Where the transformation under Art.25(1) results in a change of provider, and where an authorized representative had been designated by the original provider under Art.22, the obligation to designate and instruct an authorized representative transfers to the new deemed provider — unless the Art.25(2) written agreement specifies otherwise.

The Art.25(4) × Art.22 interaction:

Art.22 requires non-EU providers to designate an EU-established authorized representative before placing a high-risk AI system on the market. The authorized representative is the EU point of contact for market surveillance and the entity that holds the Art.22(3) mandate to cooperate with competent authorities.

When a transformation under Art.25(1) occurs, the new deemed provider may itself be EU-established — in which case Art.22 does not require an authorized representative. But if the new deemed provider is also a non-EU entity (a third-country importer who has white-labelled the system, for example), they must designate their own authorized representative for the modified or repurposed system. The original provider's authorized representative does not automatically transfer to the new provider.

The Art.25(2) agreement and AR continuity:

The Art.25(2) written agreement can address authorized representative continuity. The original provider and the deemed provider may agree that the original provider's authorized representative continues to serve in that role — provided the authorized representative consents and updates their mandate to reflect the new provider relationship. Without such an agreement, the authorized representative's mandate terminates with the original provider relationship and a new designation is required.

Art.25 in the Broader Obligation Architecture

Art.25 × Art.16: The Full Provider Stack

When Art.25(1) is triggered, the deemed provider does not acquire a partial or modified set of obligations. They acquire the full Art.16 obligation stack, including:

Art.17 — Quality Management System: The deemed provider must implement a QMS covering design specifications, quality control, risk management, post-market surveillance, incident reporting, and stakeholder communication. For a distributor or deployer who has never operated an AI development QMS, this is a significant organisational undertaking.

Art.18 — Technical Documentation: Technical documentation must exist and be maintained for the modified or repurposed system. If the original provider's technical documentation does not cover the new intended purpose or the modifications made, the deemed provider must supplement or replace it.

Art.43 — Conformity Assessment: If the modification or repurposing changes the intended purpose in a way that creates a new high-risk use case, a new conformity assessment is required. For systems subject to third-party assessment under Annex VII, this means commissioning a new notified body assessment.

Art.47 — Declaration of Conformity: The deemed provider must issue a new DoC for the modified or repurposed system. The original provider's DoC covers the system as it was originally placed on the market — not the modified or repurposed version.

Art.72 — Post-Market Monitoring: The deemed provider must establish or update a post-market monitoring system covering the modified or repurposed system's operational performance.

Art.25 × Art.22: Authorized Representative Chain

The Art.25(4) × Art.22 interaction creates an authorized representative transfer challenge. The original AR's mandate is specific to the original provider and the original system. When Art.25(1) is triggered, the AR relationship must be reassessed. Three scenarios:

  1. New deemed provider is EU-established: No AR required. The deemed provider deals directly with market surveillance authorities.
  2. New deemed provider is non-EU, original AR continues under Art.25(2) agreement: Possible if the AR consents and updates their mandate. The Art.25(2) agreement must explicitly cover AR continuity.
  3. New deemed provider is non-EU, no Art.25(2) agreement on AR: The deemed provider must designate a new EU-established AR before making the modified or repurposed system available on the market.

Art.25 × Art.24(5): The Distributor-Specific Instance

Art.24(5) provides that a distributor who makes a substantial modification or changes the intended purpose shall be considered a provider. Art.24(5) is a specific instantiation of Art.25(1)(b) and Art.25(1)(c) applied to distributors. The substantive effect is the same, but Art.24(5) is more visible to distributors who are focused on their Art.24 obligations.

The practical implication: a distributor assessing their obligations must check both Art.24(5) and Art.25(1). Art.24(5) covers substantial modification and intended purpose change by distributors. Art.25(1)(a) covers own-name placement — which Art.24(5) does not separately enumerate but which Art.25 captures directly. A distributor who white-labels a system relies on Art.25(1)(a), not Art.24(5).

Art.25 × Art.26(10): Deployer Transformation

Art.26(10) establishes that where a deployer substantially modifies a high-risk AI system — and Art.26(10) cross-references Art.25 — the deployer becomes a provider. The Art.25(1)(c) substantial modification trigger therefore applies to deployers as well as distributors and importers.

This is a significant risk for enterprise technology teams that customise AI systems for internal use. A company that receives a high-risk AI system for a specific purpose and then fine-tunes it, connects it to proprietary data pipelines, or modifies its decision logic has potentially triggered Art.25(1)(c) via the Art.26(10) pathway. If the modification is substantial, the company's IT department is now the provider of a high-risk AI system — with QMS, technical documentation, conformity assessment, and post-market monitoring obligations.

Art.25 × Art.47: Declaration of Conformity

The DoC issued by the original provider covers the system as originally specified. When Art.25(1) is triggered, the original DoC no longer covers the transformed system. Art.47(1) requires the DoC to identify the system and its version, the conformity assessment procedure followed, and the harmonised standards or common specifications applied.

A modified system with a new intended purpose is effectively a different high-risk AI system from a conformity assessment perspective. The deemed provider must either:

In either case, the deemed provider cannot continue to rely on the original provider's DoC as their compliance evidence for the modified or repurposed system.

Python Implementation: ValueChainTransformationTracker

from enum import Enum
from dataclasses import dataclass, field
from datetime import date
from typing import Optional


class TransformationTrigger(Enum):
    OWN_NAME_PLACEMENT = "art25_1a"       # Places on market under own name/trademark
    INTENDED_PURPOSE_CHANGE = "art25_1b"  # Changes intended purpose
    SUBSTANTIAL_MODIFICATION = "art25_1c" # Makes substantial modification


class TransformationStatus(Enum):
    NOT_TRIGGERED = "not_triggered"
    TRIGGERED_UNRESOLVED = "triggered_unresolved"
    AGREEMENT_IN_PLACE = "agreement_in_place"
    OBLIGATIONS_ASSUMED = "obligations_assumed"


class AgreementStatus(Enum):
    NOT_REQUIRED = "not_required"
    PENDING = "pending"
    EXECUTED = "executed"
    DISPUTED = "disputed"


@dataclass
class Art25Agreement:
    original_provider: str
    deemed_provider: str
    execution_date: Optional[date]
    status: AgreementStatus
    obligations_transferred: list[str] = field(default_factory=list)
    obligations_retained_by_original: list[str] = field(default_factory=list)
    ar_continuity_addressed: bool = False
    ar_designation_required: bool = False

    def is_complete(self) -> bool:
        required_obligations = [
            "qms_art17", "technical_documentation_art18",
            "logging_art19", "post_market_monitoring_art72",
            "conformity_assessment_art43", "eu_database_registration_art49",
            "declaration_of_conformity_art47", "corrective_actions_art20",
        ]
        covered = set(self.obligations_transferred + self.obligations_retained_by_original)
        return all(ob in covered for ob in required_obligations)


@dataclass
class TransformationEvent:
    trigger: TransformationTrigger
    detection_date: date
    description: str
    original_provider_name: str
    system_id: str
    original_intended_purpose: Optional[str] = None
    new_intended_purpose: Optional[str] = None
    modification_description: Optional[str] = None
    high_risk_classification_changed: bool = False


class ValueChainTransformationTracker:
    """
    Tracks Art.25 transformation triggers and manages deemed-provider obligations.

    Under Art.25(1), any downstream actor who triggers one of three conditions
    becomes a provider and inherits the full Art.16 obligation stack.
    """

    ART16_OBLIGATIONS = [
        "qms_art17",
        "technical_documentation_art18",
        "logging_art19",
        "corrective_actions_art20",
        "market_surveillance_cooperation_art21",
        "authorized_representative_art22",
        "conformity_assessment_art43",
        "ce_marking_art49",
        "eu_database_registration_art49",
        "declaration_of_conformity_art47",
        "post_market_monitoring_art72",
    ]

    def __init__(
        self,
        entity_name: str,
        entity_eu_established: bool,
        original_provider: str,
        system_id: str,
    ):
        self.entity_name = entity_name
        self.entity_eu_established = entity_eu_established
        self.original_provider = original_provider
        self.system_id = system_id
        self.transformation_events: list[TransformationEvent] = []
        self.agreement: Optional[Art25Agreement] = None
        self.status = TransformationStatus.NOT_TRIGGERED

    # ── Trigger Assessment ──────────────────────────────────────────────────

    def assess_own_name_placement(
        self,
        own_trademark_applied: bool,
        own_name_in_documentation: bool,
        placement_date: date,
    ) -> bool:
        """
        Art.25(1)(a): Triggered when entity places system on market under own name/trademark.
        """
        triggered = own_trademark_applied or own_name_in_documentation
        if triggered:
            self._record_trigger(
                TransformationTrigger.OWN_NAME_PLACEMENT,
                placement_date,
                f"Own-name placement: trademark={own_trademark_applied}, "
                f"documentation={own_name_in_documentation}",
            )
        return triggered

    def assess_intended_purpose_change(
        self,
        original_intended_purpose: str,
        new_intended_purpose: str,
        change_date: date,
        creates_high_risk_classification: bool = False,
    ) -> bool:
        """
        Art.25(1)(b): Triggered when entity changes the intended purpose.
        Particularly significant when new purpose triggers high-risk classification.
        """
        purposes_differ = original_intended_purpose.strip() != new_intended_purpose.strip()
        if purposes_differ:
            self._record_trigger(
                TransformationTrigger.INTENDED_PURPOSE_CHANGE,
                change_date,
                f"Intended purpose changed. "
                f"Original: '{original_intended_purpose}'. "
                f"New: '{new_intended_purpose}'. "
                f"High-risk classification change: {creates_high_risk_classification}",
                original_intended_purpose=original_intended_purpose,
                new_intended_purpose=new_intended_purpose,
                high_risk_classification_changed=creates_high_risk_classification,
            )
        return purposes_differ

    def assess_substantial_modification(
        self,
        modification_description: str,
        modification_date: date,
        affects_training_data: bool = False,
        affects_model_architecture: bool = False,
        affects_objective_function: bool = False,
        affects_output_format: bool = False,
        affects_intended_purpose: bool = False,
    ) -> bool:
        """
        Art.25(1)(c): Triggered when entity makes a substantial modification.
        Substantiality assessed by whether modification affects Chapter III Section 2 compliance.
        """
        substantiality_indicators = [
            affects_training_data,
            affects_model_architecture,
            affects_objective_function,
            affects_output_format,
            affects_intended_purpose,
        ]
        is_substantial = any(substantiality_indicators)
        if is_substantial:
            affected = [
                label for label, flag in zip(
                    ["training_data", "architecture", "objective", "output", "purpose"],
                    substantiality_indicators,
                ) if flag
            ]
            self._record_trigger(
                TransformationTrigger.SUBSTANTIAL_MODIFICATION,
                modification_date,
                f"Substantial modification: {', '.join(affected)}. {modification_description}",
                modification_description=modification_description,
            )
        return is_substantial

    # ── Agreement Management ────────────────────────────────────────────────

    def initiate_art25_agreement(self) -> Art25Agreement:
        """
        Art.25(2): Initiate written agreement with original provider.
        Agreement allocates Art.16 obligations between original and deemed provider.
        """
        if not self.transformation_events:
            raise ValueError(
                "No transformation trigger recorded. Art.25(2) agreement "
                "only applies after Art.25(1) trigger."
            )
        self.agreement = Art25Agreement(
            original_provider=self.original_provider,
            deemed_provider=self.entity_name,
            execution_date=None,
            status=AgreementStatus.PENDING,
            ar_designation_required=not self.entity_eu_established,
        )
        return self.agreement

    def record_agreement_executed(
        self,
        execution_date: date,
        obligations_transferred: list[str],
        obligations_retained: list[str],
        ar_continuity_agreed: bool = False,
    ) -> None:
        """Record execution of Art.25(2) written agreement."""
        if not self.agreement:
            raise ValueError("No agreement initiated. Call initiate_art25_agreement() first.")
        self.agreement.execution_date = execution_date
        self.agreement.obligations_transferred = obligations_transferred
        self.agreement.obligations_retained_by_original = obligations_retained
        self.agreement.ar_continuity_addressed = ar_continuity_agreed
        self.agreement.status = AgreementStatus.EXECUTED
        self.status = TransformationStatus.AGREEMENT_IN_PLACE

    # ── Compliance Status ───────────────────────────────────────────────────

    def get_outstanding_obligations(self) -> list[str]:
        """
        Returns Art.16 obligations not yet covered by Art.25(2) agreement.
        If no agreement: returns full Art.16 stack.
        """
        if not self.transformation_events:
            return []
        if not self.agreement or self.agreement.status != AgreementStatus.EXECUTED:
            return list(self.ART16_OBLIGATIONS)
        covered = set(
            self.agreement.obligations_transferred
            + self.agreement.obligations_retained_by_original
        )
        return [ob for ob in self.ART16_OBLIGATIONS if ob not in covered]

    def requires_new_doc(self) -> bool:
        """
        Returns True if a new Declaration of Conformity is required under Art.47.
        Required whenever a transformation trigger has been recorded.
        """
        return bool(self.transformation_events)

    def requires_new_conformity_assessment(self) -> bool:
        """
        Returns True if a new conformity assessment is required.
        Required for intended purpose changes that create new high-risk classification
        or substantial modifications that affect compliance with Arts.9-15.
        """
        for event in self.transformation_events:
            if event.trigger == TransformationTrigger.INTENDED_PURPOSE_CHANGE:
                if event.high_risk_classification_changed:
                    return True
            if event.trigger == TransformationTrigger.SUBSTANTIAL_MODIFICATION:
                return True
        return False

    def requires_ar_designation(self) -> bool:
        """
        Art.25(4): Returns True if entity must designate its own authorized representative.
        Required when deemed provider is non-EU-established and no Art.25(2) agreement
        addresses AR continuity.
        """
        if self.entity_eu_established:
            return False
        if not self.transformation_events:
            return False
        if self.agreement and self.agreement.ar_continuity_addressed:
            return False
        return True

    def generate_compliance_report(self) -> dict:
        """Produce a compliance status report for the Art.25 transformation."""
        outstanding = self.get_outstanding_obligations()
        return {
            "entity": self.entity_name,
            "system_id": self.system_id,
            "transformation_status": self.status.value,
            "triggers_recorded": [
                {
                    "trigger": e.trigger.value,
                    "date": e.detection_date.isoformat(),
                    "description": e.description,
                }
                for e in self.transformation_events
            ],
            "art25_2_agreement": {
                "status": self.agreement.status.value if self.agreement else "not_initiated",
                "complete": self.agreement.is_complete() if self.agreement else False,
            },
            "outstanding_obligations": outstanding,
            "requires_new_doc": self.requires_new_doc(),
            "requires_new_conformity_assessment": self.requires_new_conformity_assessment(),
            "requires_ar_designation": self.requires_ar_designation(),
            "compliant": len(outstanding) == 0 and not self.requires_ar_designation(),
        }

    # ── Private ─────────────────────────────────────────────────────────────

    def _record_trigger(
        self,
        trigger: TransformationTrigger,
        detection_date: date,
        description: str,
        original_intended_purpose: Optional[str] = None,
        new_intended_purpose: Optional[str] = None,
        modification_description: Optional[str] = None,
        high_risk_classification_changed: bool = False,
    ) -> None:
        event = TransformationEvent(
            trigger=trigger,
            detection_date=detection_date,
            description=description,
            original_provider_name=self.original_provider,
            system_id=self.system_id,
            original_intended_purpose=original_intended_purpose,
            new_intended_purpose=new_intended_purpose,
            modification_description=modification_description,
            high_risk_classification_changed=high_risk_classification_changed,
        )
        self.transformation_events.append(event)
        self.status = TransformationStatus.TRIGGERED_UNRESOLVED


# ── Usage Example ────────────────────────────────────────────────────────────

tracker = ValueChainTransformationTracker(
    entity_name="EuroSoft GmbH",
    entity_eu_established=True,
    original_provider="AIVendor Corp (US)",
    system_id="hiring-ai-v3-2026",
)

# Scenario: EuroSoft fine-tunes hiring AI and deploys under own brand
tracker.assess_own_name_placement(
    own_trademark_applied=True,
    own_name_in_documentation=True,
    placement_date=date(2026, 3, 1),
)
tracker.assess_substantial_modification(
    modification_description="Fine-tuned on EuroSoft HR dataset (50k samples)",
    modification_date=date(2026, 3, 1),
    affects_training_data=True,
    affects_objective_function=False,
)

agreement = tracker.initiate_art25_agreement()
tracker.record_agreement_executed(
    execution_date=date(2026, 3, 15),
    obligations_transferred=[
        "qms_art17", "technical_documentation_art18",
        "conformity_assessment_art43", "declaration_of_conformity_art47",
        "eu_database_registration_art49", "post_market_monitoring_art72",
        "corrective_actions_art20", "market_surveillance_cooperation_art21",
    ],
    obligations_retained=[
        "logging_art19",  # Original vendor retains log access
    ],
    ar_continuity_agreed=True,  # EU-established: no AR needed
)

report = tracker.generate_compliance_report()
# report["compliant"] → True (all obligations covered, EU-established)
# report["requires_new_doc"] → True
# report["requires_new_conformity_assessment"] → True (substantial modification)

Art.25 Compliance Checklist

Transformation Trigger Assessment (Before Making System Available or Modifying)

Post-Trigger Obligations (If Art.25(1) Triggered)

Authorized Representative (Non-EU Deemed Providers)

Art.25 Comparison: Three Transformation Triggers

DimensionArt.25(1)(a) Own-NameArt.25(1)(b) Purpose ChangeArt.25(1)(c) Substantial Modification
Trigger eventOwn trademark/name on marketNew use case outside original intended purposeTechnical changes affecting Arts.9-15 compliance
Technical change required?NoNo (but often accompanies change)Yes
Classification impactNone per seMay trigger Annex III high-riskMay affect compliance with existing classification
New conformity assessment?Depends — if system unchanged: noYes if new high-risk use caseYes — compliance impact presumed
New DoC required?Yes — new provider identityYes — new intended purposeYes — modified system
Most common actorsDistributors, SaaS resellersDeployers, system integratorsSystem integrators, fine-tuning operators
Art.24(5) overlap?Not in Art.24(5)Yes — Art.24(5) covers distributorsYes — Art.24(5) covers distributors
Art.26(10) overlap?Not in Art.26(10)Art.26(10) references Art.25Art.26(10) references Art.25

Key Takeaways for EU AI Act Compliance Teams

Art.25 is not a distributor-only provision. While Art.24(5) gives distributors early warning of the transformation risk, Art.25 applies to any party in the value chain — importers, distributors, deployers, and others. Technology teams that modify AI systems, legal teams that draft integration agreements, and procurement teams that license AI capabilities all need Art.25 on their radar.

Own-name placement is a bright-line trigger. No technical assessment is required to determine whether Art.25(1)(a) has been triggered — affixing your name or trademark to a high-risk AI system and distributing it under that name makes you the provider. For commercial arrangements where one party wants to distribute another's AI system under their own brand, the Art.25(2) agreement must be structured and executed before distribution commences.

The Art.25(2) written agreement is a compliance mechanism, not a liability shield. It allocates which party discharges each obligation — but if obligations are not discharged, both parties remain exposed. The agreement's value lies in clarity and operational assignment, not in eliminating the underlying obligations.

Deployer modification risk is underappreciated. Enterprise teams that fine-tune AI models on proprietary data, connect AI systems to new data pipelines, or modify system logic to fit internal processes should conduct an Art.25(1)(c) assessment before deployment. The Art.26(10) pathway into Art.25 catches these scenarios even when the entity started as a deployer.