sota.io
2026-04-12·12 min read·sota.io team

EU AI Act Article 24: Obligations of Distributors of High-Risk AI Systems (2026)

Article 23 placed a five-point gate-check on importers — entities that bring a high-risk AI system from a non-EU provider into the EU market for the first time. Article 24 governs the next step in the supply chain: the distributor.

A distributor is any entity in the supply chain that makes a high-risk AI system available on the EU market — but who is neither the original provider nor the importer. Distributors have lighter obligations than importers, but those obligations are real and enforceable. And critically, Art.24 contains two transformation triggers that can convert a distributor into a provider overnight, with full provider liability.

Who Is a Distributor Under Art.24?

The EU AI Act defines distributors as any natural or legal person in the supply chain, other than the provider or importer, that makes a high-risk AI system available on the Union market. In practice, this covers:

The distributor position in the chain is defined by what you do not do: you do not place the system on the market for the first time (that is the provider/importer), and you do not substantially modify it. You make an already-placed system available to downstream users or operators.

Art.24 vs Art.23: Why the Distinction Matters

Before diving into Art.24 obligations, the importer/distributor distinction is worth internalizing because the liability exposure is very different.

DimensionImporter (Art.23)Distributor (Art.24)
First EU market entryYes — Art.23 covers first placementNo — system already on EU market
Gate-check scopeFive-point (conformity assessment, tech docs, CE marking, declaration, database registration)Three-point (CE marking, instructions, declaration copy)
Documentation retention10 years — Art.23(5)Not independently required — relies on provider/importer chain
Contact details on productMandatory — Art.23(3)Not mandatory unless becoming provider
Non-conformity obligationImport block + provider/MSA notificationMaking-available block + provider/importer/MSA notification
Transformation triggerOwn-name/trademark → provider (Art.23(4))Own-name/trademark or substantial modification → provider (Art.24(3)/(4))
MSA cooperationReasoned request response + documentation accessReasoned request response
Penalty exposure (Art.99)Up to €15M or 3% global turnoverUp to €15M or 3% global turnover

The key difference: importers bear primary accountability for the first crossing of the EU market threshold. Distributors bear a lighter verification obligation — but they cannot simply pass the buck upstream when non-conformity surfaces.

The Three-Point Distributor Check (Art.24(1))

Before making a high-risk AI system available on the EU market, distributors must verify three conditions. All three must be satisfied.

Check 1: CE Marking

The system must bear the CE marking required by Art.49. For software-only AI systems, CE marking typically appears in the documentation, user interface, or packaging rather than on a physical device. Distributors must verify:

A common mistake: treating CE marking as a formality because the provider says it's compliant. The importer already verified this under Art.23(1)(c), but Art.24(1) places an independent verification obligation on the distributor. "The importer checked it" is not a defence if you did not.

Check 2: Instructions of Use and Required Documentation

The system must be accompanied by instructions of use that meet the requirements of Art.13 and Annex VIII. These instructions must be provided in a language or languages that can be understood by the users in the Member States where the system is made available.

For the distributor, this means verifying:

Check 3: EU Declaration of Conformity

The distributor must verify that the EU declaration of conformity has been drawn up by the provider under Art.48. Unlike the importer (who must retain a copy under Art.23(5)), the distributor's obligation is verification — not independent retention. But you cannot verify what you cannot see, so in practice distributors should request and hold a copy.

The declaration must:

Art.24(2): Non-Conformity Discovery Protocol

If a distributor has reason to believe that a high-risk AI system is not in conformity with the EU AI Act, they must not make it available until conformity is established. This is a hard stop obligation — unlike some regulatory regimes where you can continue with conditions, Art.24(2) requires suspension.

The non-conformity notification chain has two mandatory targets:

Target 1: Provider or Importer. The distributor must inform the provider or importer of the non-conformity and the reasons for suspending availability. This must be documented — verbal notification is insufficient.

Target 2: National Market Surveillance Authority (MSA). If the distributor has reason to believe the system presents a risk under Art.79, they must also notify the MSA of the Member State where they make the system available. This is a parallel obligation — you do not wait for the provider to notify the MSA.

When to Trigger Non-Conformity Protocol

The threshold is "reason to believe" — a standard lower than certainty. Distributors should establish clear triggers:

TriggerAction Required
CE marking absent or visibly incorrectImmediate suspension + notification
Instructions of use missing or in wrong languageImmediate suspension + notification
EU declaration of conformity cannot be produced by providerImmediate suspension + notification
Provider notifies of serious incident involving same systemAssess — likely suspension + MSA notification
Significant update from provider that changes conformity scopeRe-verify all three checks before continuing
MSA contacts distributor about a specific system versionProvide documentation, assess suspension

Art.24(3): Distributor → Provider Transformation (Own Name or Trademark)

This is the most significant risk in Art.24 for commercial distributors: if you place a high-risk AI system on the market under your own name or trademark, you are deemed a provider under the EU AI Act — with full provider obligations under Art.16.

The transformation is automatic. There is no threshold, no de minimis, no intent requirement. The moment your name or trademark appears on the AI system (in the UI, in the documentation, on the packaging, in the App Store listing), you are the provider for EU AI Act purposes.

This directly parallels:

What "Under Your Own Name or Trademark" Means

The EU AI Act does not define this precisely, so developers and distributors should apply a broad interpretation:

Practical Rule

Before you put your brand anywhere near a high-risk AI system: stop and evaluate whether you intend to accept full provider obligations (Art.16: conformity assessment, technical documentation, post-market monitoring, EU database registration, authorised representative if non-EU, etc.). If not, your name cannot appear.

Art.24(4): Distributor → Provider via Substantial Modification

The second transformation trigger: if a distributor makes a substantial modification to the high-risk AI system, they are deemed a provider and must comply with Art.16.

Substantial modification is defined in Art.3(23) as a change to the AI system that affects the system's compliance with the requirements of Chapter III Section 2 (the technical requirements for high-risk AI: risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy/robustness/cybersecurity) or results in a change to the intended purpose.

What Counts as Substantial Modification

ModificationSubstantial?
Retraining the model on new dataLikely yes — may affect Art.10 data governance compliance
Fine-tuning for a new use caseLikely yes — changes intended purpose
Adding a new output modalityLikely yes — changes capabilities and safety profile
Changing the user interface without affecting the AI modelLikely no
Updating documentation or instructions of useNo
Security patches that do not affect model behaviourNo
Integrating the system with additional data sources the model ingestsCase-by-case — consult Art.9 risk management assessment

The key test: does the modification affect any of the Art.9–15 compliance requirements, or does it change what the system is for? If yes, you have likely crossed into substantial modification territory.

Art.24(5): MSA Cooperation

Distributors must cooperate with national Market Surveillance Authorities in their Member State of establishment. Specifically, they must:

The "reasoned request" requirement means MSAs cannot demand documentation arbitrarily — they must explain why the request is necessary. But distributors should not wait for a formal legal process: early cooperation is generally better than forcing the MSA to escalate.

Art.24(6): National Language Requirements

A distributor that makes a high-risk AI system available in a Member State must ensure that the instructions of use are provided in a language determined by the Member State in question.

This is operationally significant for multi-country distributors:

The practical implication: if you are distributing in Germany, France, Italy, and Spain, you need instructions of use in German, French, Italian, and Spanish — unless those Member States have determined otherwise, which is rare.

Art.24 × Art.25: The Supply Chain Hierarchy

Art.25 places additional obligations on downstream entities that use AI system outputs to build new AI systems or services. The relationship between Art.24 and Art.25 is about position in the supply chain:

EntityRolePrimary Article
Original developerProviderArt.16
EU-established entity placing a non-EU provider's systemImporterArt.23
Entity making an already-placed system availableDistributorArt.24
Entity integrating a high-risk AI into their own systemArt.25 downstreamArt.25(1)(a) if own-named
Entity operating a high-risk AI systemDeployerArt.26–28

The chain matters because:

  1. Each Art.24 distributor layer adds potential for the transformation triggers to fire (own-name or modification)
  2. MSA investigation of a non-conforming system will typically trace the chain back to the provider — but each distributor will be asked to produce their verification documentation
  3. Contractual agreements between chain participants should allocate documentation obligations and indemnification clearly

Art.24 × Art.26: Distributor vs Deployer

Distributors and deployers are often confused. A deployer (Art.26) is an entity that uses a high-risk AI system under its own authority. A distributor (Art.24) makes the system available to others but does not itself use it in a deployment context.

The same entity can be both: if you resell an AI compliance tool (distributor) and also use it internally for your own operations (deployer), Art.24 applies to your distribution activity and Art.26 applies to your internal use.

CLOUD Act × Art.24: Jurisdiction Risk for US-Parent Distributors

EU-based distributors with US parent companies face the same dual-compellability risk as importers. Under the US CLOUD Act, US law enforcement can compel a US company — and its affiliates — to produce records they control, regardless of where those records are stored.

For Art.24 distributors, the relevant records are:

Record TypeEU AI Act BasisCLOUD Act Risk
CE marking verification recordsArt.24(1)Moderate — commercial records held by EU distributor
EU declaration of conformity copyArt.24(1)(c)Moderate — especially if stored in US-parent systems
Non-conformity notification chainArt.24(2)High — communications about regulatory non-compliance
Distributor → Provider transformation analysisArt.24(3)/(4)High — legal exposure assessments
MSA cooperation recordsArt.24(5)Very high — direct regulatory communication

The mitigation: EU-sovereign infrastructure for all Art.24 compliance records. If MSA cooperation records are stored on US-parent cloud infrastructure, US law enforcement access to those records could compromise your EU regulatory position.

Python Implementation

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

class ConformityStatus(Enum):
    CONFORMING = "conforming"
    NON_CONFORMING = "non_conforming"
    UNDER_REVIEW = "under_review"
    SUSPENDED = "suspended"

@dataclass
class DistributorVerificationRecord:
    """Art.24(1): Three-point conformity check for distributors."""
    system_id: str
    system_version: str
    provider_name: str
    importer_name: Optional[str]
    verification_date: date
    
    # Check 1: CE marking
    ce_marking_present: bool
    ce_marking_location: str  # e.g. "documentation page 3", "UI footer"
    ce_marking_format_correct: bool
    
    # Check 2: Instructions of use
    instructions_present: bool
    instructions_languages: list[str]
    target_member_states: list[str]
    instructions_language_coverage: bool  # all target MS covered?
    
    # Check 3: EU declaration of conformity
    declaration_present: bool
    declaration_hash: Optional[str]  # SHA-256 of declaration document
    declaration_signed_by: str
    declaration_date: date
    
    verified_by: str
    notes: str = ""
    
    @property
    def all_checks_passed(self) -> bool:
        return (
            self.ce_marking_present
            and self.ce_marking_format_correct
            and self.instructions_present
            and self.instructions_language_coverage
            and self.declaration_present
        )
    
    @property
    def conformity_status(self) -> ConformityStatus:
        if self.all_checks_passed:
            return ConformityStatus.CONFORMING
        return ConformityStatus.NON_CONFORMING
    
    def generate_declaration_hash(self, declaration_bytes: bytes) -> str:
        """Generate SHA-256 hash of declaration document for integrity verification."""
        self.declaration_hash = hashlib.sha256(declaration_bytes).hexdigest()
        return self.declaration_hash


@dataclass 
class DistributorNonConformityNotification:
    """Art.24(2): Non-conformity discovery protocol."""
    system_id: str
    system_version: str
    discovery_date: datetime
    
    # What failed
    failed_checks: list[str]  # e.g. ["ce_marking_absent", "instructions_wrong_language"]
    reason_for_suspension: str
    
    # Mandatory notifications
    provider_notified: bool = False
    provider_notification_date: Optional[datetime] = None
    provider_contact: str = ""
    
    importer_notified: bool = False
    importer_notification_date: Optional[datetime] = None
    importer_contact: str = ""
    
    msa_notified: bool = False
    msa_notification_date: Optional[datetime] = None
    msa_member_state: str = ""
    msa_reference_number: str = ""
    
    # Suspension status
    availability_suspended: bool = True
    suspension_date: Optional[datetime] = None
    reinstatement_conditions: str = ""
    reinstatement_date: Optional[datetime] = None
    
    def notify_provider(self, contact: str, notification_time: datetime) -> None:
        """Record provider notification (Art.24(2))."""
        self.provider_notified = True
        self.provider_notification_date = notification_time
        self.provider_contact = contact
    
    def notify_msa(self, member_state: str, reference: str, notification_time: datetime) -> None:
        """Record MSA notification (Art.24(2) × Art.79)."""
        self.msa_notified = True
        self.msa_notification_date = notification_time
        self.msa_member_state = member_state
        self.msa_reference_number = reference
    
    @property
    def notification_chain_complete(self) -> bool:
        """Check if all required notifications have been made."""
        # Provider/importer notification always required
        upstream_notified = self.provider_notified or self.importer_notified
        # MSA notification required if risk present — assume required if non-conforming
        return upstream_notified and self.msa_notified


class TransformationTrigger(Enum):
    OWN_NAME = "own_name_trademark"
    SUBSTANTIAL_MODIFICATION = "substantial_modification"
    NONE = "none"


@dataclass
class DistributorProviderTransformationCheck:
    """Art.24(3)/(4): Check if distributor activities trigger provider transformation."""
    distributor_name: str
    system_id: str
    assessment_date: date
    assessed_by: str
    
    # Art.24(3): Own name / trademark
    own_name_on_ui: bool = False
    own_name_on_documentation: bool = False
    own_name_on_packaging: bool = False
    own_name_in_app_store: bool = False
    co_branded: bool = False
    
    # Art.24(4): Substantial modification
    model_retrained: bool = False
    fine_tuned_new_use_case: bool = False
    new_output_modality_added: bool = False
    new_data_sources_ingested: bool = False
    intended_purpose_changed: bool = False
    compliance_requirements_affected: bool = False
    
    @property
    def own_name_trigger(self) -> bool:
        """Art.24(3): Any own-name/trademark presence triggers provider status."""
        return any([
            self.own_name_on_ui,
            self.own_name_on_documentation,
            self.own_name_on_packaging,
            self.own_name_in_app_store,
            self.co_branded,  # treat co-branded as trigger risk
        ])
    
    @property
    def substantial_modification_trigger(self) -> bool:
        """Art.24(4): Any modification affecting Art.9-15 requirements."""
        return any([
            self.model_retrained,
            self.fine_tuned_new_use_case,
            self.new_output_modality_added,
            self.intended_purpose_changed,
            self.compliance_requirements_affected,
            # new_data_sources_ingested — case by case
        ])
    
    @property
    def transformation_trigger(self) -> TransformationTrigger:
        if self.own_name_trigger:
            return TransformationTrigger.OWN_NAME
        if self.substantial_modification_trigger:
            return TransformationTrigger.SUBSTANTIAL_MODIFICATION
        return TransformationTrigger.NONE
    
    @property
    def is_now_provider(self) -> bool:
        return self.transformation_trigger != TransformationTrigger.NONE
    
    def remediation_steps(self) -> list[str]:
        """Return required actions if transformation has occurred."""
        if not self.is_now_provider:
            return ["No transformation — distributor obligations apply"]
        steps = [
            "Immediately assume full provider obligations under Art.16",
            "Commission conformity assessment under Art.43 (or verify existing one covers your modified/branded version)",
            "Prepare technical documentation under Art.11 + Annex IV",
            "Draw up EU declaration of conformity under Art.48",
            "Apply CE marking under Art.49",
            "Implement quality management system under Art.17",
            "Implement post-market monitoring under Art.72",
            "Register in EU AI Database under Art.71",
            "Appoint authorised representative if not EU-established",
        ]
        if self.own_name_trigger:
            steps.insert(0, "Remove own name/trademark from system until provider obligations are met, OR proceed as provider")
        return steps

Five Common Distributor Mistakes

Mistake 1: Relying on the Importer's Verification

Art.24(1) is an independent obligation. The fact that an importer verified CE marking, documentation, and the declaration under Art.23(1) does not discharge the distributor's obligation to verify the same. Both must verify. Audit trails should be separate.

Mistake 2: Co-Branding Without Transformation Analysis

Distributors frequently add their logo to AI system documentation, app store listings, or UI as a commercial matter — without triggering a legal analysis under Art.24(3). Any co-branding decision should go through the transformation check before implementation.

Mistake 3: Treating Non-Conformity as an Upstream Problem

When a distributor discovers non-conformity, the immediate instinct is often to tell the provider to "fix it." Art.24(2) requires the distributor to also notify the MSA if there is risk under Art.79. This is a parallel obligation, not a sequential one. MSA notification cannot wait for the provider to respond.

Mistake 4: Ignoring Language Requirements for Each Member State

A distributor operating in multiple EU Member States often assumes the instructions of use language requirements are the same across the bloc. They are not. Each Member State sets its own language requirements. Distributors must track per-market language compliance — a single-language instruction set is almost never sufficient for multi-country distribution.

Mistake 5: Assuming "No Physical Modification" Means No Substantial Modification

Art.24(4) substantial modification is defined by impact on compliance requirements — not by physical or technical depth. Fine-tuning a model on new data that changes its accuracy profile (relevant to Art.15 accuracy requirements) is a substantial modification even if the architecture is identical. Always assess against Art.9–15, not against "did we change the model architecture?"

Art.24 × Art.99 Penalty Exposure

Non-compliance with Art.24 falls under Art.99's penalty regime:

Distributors who trigger provider transformation through Art.24(3)/(4) and then fail to meet provider obligations face the full Art.99(3) provider penalty schedule — not the lighter distributor exposure.

30-Item Distributor Compliance Checklist

Before Making a System Available (Art.24(1))

Ongoing Compliance

Non-Conformity Protocol (Art.24(2))

Transformation Risk (Art.24(3)/(4))

MSA Cooperation (Art.24(5)) and CLOUD Act

See Also