EU AI Act Art.28 Obligations for Distributors: Developer Guide (High-Risk AI 2026)

EU AI Act Article 28 defines the distributor's compliance role within the high-risk AI supply chain. Distributors occupy the last commercial link before the end deployer: they receive high-risk AI systems from a provider or importer, make them available on the EU market (often bundled with hardware, SaaS platforms, or integration packages), and must verify five categories of pre-market obligations before doing so. Unlike providers (Art.16–Art.23) or importers (Art.24), distributors do not place systems on the market in their own name — but they cannot be passive conduits. Art.28 codifies their gatekeeping function.

Art.28 sits in Chapter III Section 2, the same section as Art.26 (deployer obligations) and Art.27 (FRIA). It closes the value-chain obligations loop: providers design and certify, importers verify at border entry, distributors verify at downstream distribution, deployers operate. Each link has defined obligations so that non-conforming high-risk AI cannot reach end users through compliance gaps in the middle of the chain.

This guide covers Art.28(1)–(5) in full, the Art.28 × Art.25 transformation conditions (when a distributor becomes a new provider or importer), the Art.28 × Art.20 corrective action notification trigger, the Art.28 × Art.21 MSA cooperation scope, CLOUD Act jurisdiction risk for distributor conformity and language records stored on US infrastructure, Python implementation for DistributorComplianceRecord, LanguageComplianceChecker, and DistributorMSACooperationTracker, and the 40-item Art.28 compliance checklist.

Art.28 in the High-Risk AI Value Chain

Art.28 is the distributor layer of Chapter III Section 2:

The distributor's obligations are narrower than the provider's but broader than a pure reseller's. Art.28 creates affirmative duties to verify, maintain, cooperate, and escalate — not merely to pass product downstream unchanged.

Art.28(1): Pre-Market Verification Obligations

Art.28(1) text (summarised): Before making a high-risk AI system available on the market, distributors shall verify that it bears the CE marking, that the declaration of conformity and the instructions for use are available in a language that can be easily understood by users in the Member State where it is made available, that the provider has complied with their registration obligations under Art.22, and that the importer (if any) has complied with Art.24.

Five pre-market verification gates under Art.28(1):

Practical note on CE marking in software: For software-only high-risk AI systems, the CE marking typically appears in the product documentation, the EU declaration of conformity, and the product's user interface — not on physical packaging. Distributors must verify the digital chain of CE marking evidence, not just look for a physical label.

The language compliance obligation is a distributor-specific burden. The provider produces the master IFU (typically in English); the distributor making the product available in, say, France, Poland, or Romania must ensure a French, Polish, or Romanian translation exists and is accurate before distribution. This obligation cannot be shifted upstream by contract — the distributor bears the legal burden in the target Member State.

Art.28(2): When a Distributor Becomes a Provider or Importer

Art.28(2) text (summarised): Where a distributor considers or has reason to believe that a high-risk AI system is not in conformity with the requirements, it shall not make it available until conformity is achieved. Where it poses a serious risk, it shall notify the provider and the national competent authority. A distributor who modifies a high-risk AI system shall be considered a provider.

Art.28(2) creates two transformation conditions drawn from Art.25:

The modification boundary (Art.3(23)): A "substantial modification" triggers provider status. The bright-line test: Does the modification affect the AI system's compliance with the requirements of Title III Chapter 2? Examples that cross the line: retraining the model on new data that changes output distribution, adding new use cases beyond the original intended purpose, integrating new components that alter the risk profile. Examples that do not: cosmetic UI changes, bug fixes that don't affect model behaviour, minor performance tuning within the original accuracy envelope.

Recital 69 guidance: Recital 69 clarifies that substantial modification should be assessed with reference to the AI system's intended purpose and the extent to which the modification could affect compliance with harmonised standards or common specifications. When a distributor rebrands and re-packages without modification, it does not become a provider — it remains subject only to Art.28.

Practical implication for SaaS distributors: Cloud resellers and managed service providers (MSPs) who bundle a provider's high-risk AI system with their own platform infrastructure face Art.28(2) scrutiny. If the MSP customises the model, fine-tunes on customer data, or extends the intended purpose, it crosses into provider territory. Distributors must document modification scope carefully.

Art.28(3): Serious Risk Notification Duty

Art.28(3) text (summarised): Distributors who have reason to believe that a high-risk AI system they have made available poses a serious risk within the meaning of Art.79(1) shall immediately inform the provider or importer, and shall cooperate with the competent authorities.

The Art.79(1) serious risk threshold: A risk is "serious" if it presents a risk that could lead to death, serious injury, significant damage to property, or significant adverse impact on fundamental rights. This is the same threshold that triggers the Art.73 serious incident reporting obligation for providers.

Distributor notification cascade under Art.28(3):

Distributor detects serious risk signal
    ↓
(1) Immediate notification to Provider (or Importer if product was imported)
    — Include: what risk was observed, which AI system version, deployment context
    ↓
(2) If provider/importer does not act within a reasonable period:
    Distributor notifies National Competent Authority (NCA) / Market Surveillance Authority (MSA)
    ↓
(3) Distributor cooperates with MSA corrective investigation (Art.21 applies)
    ↓
(4) Distributor withdraws product from market if instructed or if immediate danger persists

The "reason to believe" standard: Art.28(3) does not require certainty — it requires a reasonable basis to believe. Practical triggers include: an end-user report of discriminatory outputs, a pattern of anomalous system behaviour during integration testing, a third-party security report revealing model vulnerabilities, or a media report about the same system causing harm in another Member State.

Art.28(3) × Art.20 intersection: The Art.20 corrective action cascade runs from provider through deployer. Art.28(3) adds a parallel cascade where the distributor is the first link to detect a serious risk. Both cascades converge at the MSA notification point. Distributors should coordinate with providers to avoid duplicative or contradictory MSA notifications.

Art.28(4): Cooperation with Market Surveillance Authorities

Art.28(4) text (summarised): Upon a reasoned request from a competent authority, distributors shall provide all the information and documentation necessary to demonstrate that the high-risk AI system is in conformity with the requirements. They shall also cooperate with corrective actions taken or ordered by the authority.

Art.28(4) is the distributor-specific instantiation of the Art.21 general cooperation obligation. Key implications:

Confidentiality protection under Art.78: Art.78 protects trade secrets and commercially sensitive information disclosed to MSAs. Distributors providing supply chain documentation may invoke Art.78 to prevent public disclosure of proprietary distribution data. This protection is limited: Art.78 does not apply to information necessary to prevent serious risk to persons.

Art.28(5): Record Retention Obligation

Art.28(5) text (summarised): Distributors shall, for a period of ten years after the high-risk AI system has been placed on the market or put into service, keep a copy of the declaration of conformity, the technical documentation, and the instructions for use.

The 10-year retention clock: The clock starts from placement on the market or putting into service — whichever is earlier. For software products with continuous deployment, "placed on the market" is the first general commercial availability date of a specific version.

What distributors must retain:

CLOUD Act jurisdiction risk for distributor records: If a distributor stores these 10-year retention records on US cloud infrastructure (AWS, Azure, Google Cloud), those records are subject to CLOUD Act compelled disclosure to US law enforcement or intelligence agencies — parallel to the EU MSA's Art.21/28(4) access rights. This creates a dual-access regime: EU MSAs can request records under Art.28(4), and US authorities can compel them under CLOUD Act. The records may leave EU jurisdiction without the distributor's knowledge or consent.

EU-native hosting eliminates the dual-access problem. Retention records stored exclusively on EU-jurisdiction infrastructure (e.g., sota.io worker nodes in EU data centres) are accessible only to EU authorities through defined legal channels — no parallel CLOUD Act exposure. For high-risk AI distributors handling sensitive conformity documentation, EU-native record hosting is the legally defensible posture.

Art.28 × Art.17: QMS Integration for Distributor Obligations

Art.17 requires providers to maintain a Quality Management System (QMS). While Art.17 is a provider obligation, distributors who become providers under Art.28(2) inherit the QMS requirement. Even non-transforming distributors benefit from maintaining distribution-specific QMS processes that integrate with the provider's Art.17 QMS:

Distributor QMS integration points:

ISO/IEC 42001:2023 (AI Management Systems) maps to the Art.17 QMS framework. Distributors adopting ISO 42001 should include distribution-specific controls for Art.28(1) verification, Art.28(3) escalation, and Art.28(5) retention in their management system scope.

Python Implementation

DistributorComplianceRecord

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

@dataclass
class DistributorComplianceRecord:
    """
    Art.28(1) pre-market verification record for a high-risk AI system.
    Captures all five Art.28(1) verification gates before making the system available.
    """
    system_id: str
    system_version: str
    provider_name: str
    importer_name: Optional[str]
    target_member_states: list[str]
    verification_date: date
    
    # Art.28(1) verification results
    ce_marking_verified: bool = False
    declaration_of_conformity_available: bool = False
    ifu_language_compliant: bool = False
    eu_database_registration_verified: bool = False
    importer_art24_compliance_verified: bool = False
    
    # Art.28(2) modification assessment
    modification_applied: bool = False
    modification_scope: Optional[str] = None
    modification_triggers_provider_status: bool = False
    
    # Art.28(5) retention
    retention_start_date: Optional[date] = None
    retention_end_date: Optional[date] = None
    
    issues: list[str] = field(default_factory=list)

    def verify_ce_marking_obligations(self) -> dict:
        """
        Run Art.28(1) pre-market verification gate checks.
        Returns pass/fail per gate with remediation guidance.
        """
        gates = {
            "ce_marking": self.ce_marking_verified,
            "declaration_of_conformity": self.declaration_of_conformity_available,
            "ifu_language_compliance": self.ifu_language_compliant,
            "eu_database_registration": self.eu_database_registration_verified,
        }
        if self.importer_name:
            gates["importer_art24_compliance"] = self.importer_art24_compliance_verified

        failed = [g for g, v in gates.items() if not v]
        
        return {
            "system_id": self.system_id,
            "version": self.system_version,
            "target_states": self.target_member_states,
            "gates_passed": len(gates) - len(failed),
            "gates_total": len(gates),
            "failed_gates": failed,
            "distribution_cleared": len(failed) == 0,
            "modification_triggers_provider_status": self.modification_triggers_provider_status,
        }

    def set_retention_period(self, placement_date: date) -> None:
        """Set Art.28(5) 10-year retention window from market placement date."""
        from datetime import timedelta
        self.retention_start_date = placement_date
        self.retention_end_date = date(
            placement_date.year + 10,
            placement_date.month,
            placement_date.day
        )

LanguageComplianceChecker

@dataclass
class LanguageComplianceChecker:
    """
    Art.28(1) IFU language compliance verification.
    Verifies that instructions for use exist in all required Member State languages.
    """
    system_id: str
    # EU Member State → official language(s) requiring IFU translation
    EU_LANGUAGE_MAP: dict = field(default_factory=lambda: {
        "AT": ["de"], "BE": ["fr", "nl", "de"], "BG": ["bg"], "CY": ["el"],
        "CZ": ["cs"], "DE": ["de"], "DK": ["da"], "EE": ["et"],
        "EL": ["el"], "ES": ["es"], "FI": ["fi", "sv"], "FR": ["fr"],
        "HR": ["hr"], "HU": ["hu"], "IE": ["en", "ga"], "IT": ["it"],
        "LT": ["lt"], "LU": ["fr", "de", "lb"], "LV": ["lv"], "MT": ["mt", "en"],
        "NL": ["nl"], "PL": ["pl"], "PT": ["pt"], "RO": ["ro"],
        "SE": ["sv"], "SI": ["sl"], "SK": ["sk"],
    })
    
    available_ifu_languages: list[str] = field(default_factory=list)
    target_member_states: list[str] = field(default_factory=list)

    def missing_language_coverage(self) -> dict:
        """
        Identify which Member State / language combinations lack IFU coverage.
        Returns gap report with remediation priority (high = single-language states first).
        """
        gaps = []
        for state in self.target_member_states:
            required_langs = self.EU_LANGUAGE_MAP.get(state, [])
            missing = [lang for lang in required_langs if lang not in self.available_ifu_languages]
            if missing:
                gaps.append({
                    "member_state": state,
                    "missing_languages": missing,
                    "priority": "high" if len(required_langs) == 1 else "medium",
                })
        
        return {
            "system_id": self.system_id,
            "total_target_states": len(self.target_member_states),
            "states_with_gaps": len(gaps),
            "gaps": sorted(gaps, key=lambda x: x["priority"]),
            "art28_1_ifu_compliant": len(gaps) == 0,
        }

DistributorMSACooperationTracker

from dataclasses import dataclass, field
from datetime import datetime
from typing import Optional

@dataclass
class MSARequest:
    request_id: str
    authority: str
    member_state: str
    request_date: datetime
    request_type: str  # "conformity_docs" | "provenance" | "distribution_records" | "corrective_action"
    response_due: Optional[datetime]
    response_submitted: bool = False
    response_date: Optional[datetime] = None
    confidentiality_invoked: bool = False  # Art.78

@dataclass
class SeriousRiskNotification:
    notification_id: str
    system_id: str
    detection_date: datetime
    risk_description: str
    provider_notified: bool = False
    provider_notification_date: Optional[datetime] = None
    msa_notified: bool = False
    msa_notification_date: Optional[datetime] = None
    product_withdrawn: bool = False

@dataclass
class DistributorMSACooperationTracker:
    """
    Art.28(3)-(4) MSA cooperation and serious risk notification tracker.
    Manages Art.21 cooperation requests and Art.28(3) escalation records.
    """
    distributor_id: str
    msa_requests: list[MSARequest] = field(default_factory=list)
    serious_risk_notifications: list[SeriousRiskNotification] = field(default_factory=list)

    def msa_notification_report(self) -> dict:
        """
        Generate Art.28(3)-(4) compliance status report.
        Flags overdue MSA responses and unescalated serious risk notifications.
        """
        overdue_requests = [
            r for r in self.msa_requests
            if r.response_due and not r.response_submitted
            and datetime.now() > r.response_due
        ]
        
        unescalated_risks = [
            n for n in self.serious_risk_notifications
            if not n.provider_notified
        ]
        
        unnotified_msas = [
            n for n in self.serious_risk_notifications
            if n.provider_notified and not n.msa_notified
            # Provider had reasonable time but risk persists
        ]

        return {
            "distributor_id": self.distributor_id,
            "total_msa_requests": len(self.msa_requests),
            "overdue_responses": len(overdue_requests),
            "overdue_details": [
                {"request_id": r.request_id, "authority": r.authority, "due": str(r.response_due)}
                for r in overdue_requests
            ],
            "serious_risk_notifications": len(self.serious_risk_notifications),
            "unescalated_to_provider": len(unescalated_risks),
            "pending_msa_escalation": len(unnotified_msas),
            "art28_cooperation_status": "COMPLIANT" if not overdue_requests and not unescalated_risks else "ACTION_REQUIRED",
        }

Art.28 Intersection Matrix

Art.28 Enforcement Exposure

Art.28 violations are enforced under Article 99. The distributor-specific enforcement landscape:

Distributor liability note: Art.99 fines apply per violation, not per AI system. A distributor placing 50 non-conforming AI systems on the market without language-compliant IFU in 10 Member States faces potential exposure across all distribution events. Enforcement authorities assess proportionality (recitals 166–167), but the ceiling is the global turnover-linked maximum.

Art.28 Compliance Checklist (40 Items)

Art.28(1) Pre-Market Verification (10 items)

• 1. CE marking verified on system, packaging, or documentation (Art.49)
• 2. EU declaration of conformity obtained and covers the specific system version
• 3. Instructions for use (IFU) obtained from provider in master language
• 4. IFU verified for completeness against Art.13(1)(a)–(k) content elements
• 5. IFU translated into all official languages of target Member States
• 6. Translations verified for accuracy (back-translation or legal review for high-stakes systems)
• 7. EU AI Act database registration confirmed (Art.22) before distribution
• 8. If importer involved: Art.24 compliance verified (name on system, storage conditions)
• 9. CE marking authenticity verified (notified body reference for Annex VIII systems)
• 10. Pre-market verification record documented with date, verifier, and outcome

Art.28(2) Modification Assessment (5 items)

• 11. Modification scope assessed against Art.3(23) substantial modification definition
• 12. If modification applies: legal assessment whether it triggers provider status (Art.25)
• 13. If distributor becomes new provider: full Art.16–23 compliance programme initiated
• 14. If distributor imports from third country: Art.24 importer obligations assessed
• 15. Rebranding / white-labelling assessed for provider status implications

Art.28(3) Serious Risk Notification (8 items)

• 16. Serious risk monitoring process established for distributed systems
• 17. Art.79(1) "serious risk" threshold documented for internal training
• 18. Provider / importer notification contacts maintained and tested
• 19. MSA / NCA contact for each target Member State documented
• 20. Escalation timeline defined (immediate notification upon serious risk detection)
• 21. Market withdrawal procedure documented and tested
• 22. Serious risk notification records retained (date, system, risk description, notification chain)
• 23. Art.28(3) × Art.20 coordination with provider agreed (avoid duplicative MSA notifications)

Art.28(4) MSA Cooperation (7 items)

• 24. MSA cooperation procedure documented
• 25. Conformity documentation package assembled and accessible for MSA response
• 26. Supply chain provenance records maintained (provider → importer → distributor chain)
• 27. Distribution records maintained (which deployers received which version, in which Member States)
• 28. Art.78 confidentiality claims catalogued for trade-sensitive distribution data
• 29. MSA response timeline tracked (no overdue responses)
• 30. Corrective action cooperation procedure tested (simulated MSA recall order)

Art.28(5) Record Retention (5 items)

• 31. 10-year retention start date recorded for each distributed system (placement on market date)
• 32. Declaration of conformity retained per system version
• 33. IFU retained in all language versions produced
• 34. Technical documentation summary retained (as received from provider)
• 35. Retention records stored in EU-jurisdiction infrastructure to avoid CLOUD Act dual access

Intersection Compliance (5 items)

• 36. Art.17 QMS: distributor QMS processes integrate with provider's Art.17 QMS
• 37. Art.20 corrective action: distributor role in Art.20 cascade defined with provider
• 38. Art.22 database: distribution process blocked until EU database registration confirmed
• 39. CLOUD Act risk: legal assessment of distributor record storage jurisdiction
• 40. Art.25 transformation: annual review of whether any distributor activities now trigger provider/importer status

Infrastructure Jurisdiction for Distributor Compliance Records

Art.28 distributor compliance records — conformity verification logs, IFU translation archives, MSA cooperation files, 10-year retention documents — are frequently stored on general-purpose cloud infrastructure. When that infrastructure is operated by a US-domiciled cloud provider, the CLOUD Act creates a structural vulnerability:

CLOUD Act compellability for distributor records:

• US authorities can compel disclosure of EU distributor compliance records from US cloud providers (AWS, Azure, GCP) via National Security Letter or court order — without notifying the EU distributor.
• The EU MSA's Art.28(4) access right and the US CLOUD Act access right operate in parallel, with no coordination mechanism.
• Distributor records that reveal supply chain structure, conformity testing outcomes, or distribution networks are sensitive commercial information.

EU-native hosting closes the dual-access gap. Distributor compliance records stored on EU-jurisdiction PaaS infrastructure (Germany, Ireland, Netherlands data centres) are accessible only through EU legal channels — GDPR CJEU mechanisms, Art.21 MSA procedures — not via CLOUD Act. For distributors of high-risk AI systems whose conformity and supply chain records are commercially sensitive, EU-native record hosting is the legally defensible choice. sota.io worker nodes operate exclusively in EU data centres; distributor compliance applications deployed on sota.io carry no CLOUD Act exposure.

See Also

• EU AI Act Art.29 Obligations for Providers of General-Purpose AI Models: Developer Guide — Art.29 is the next chapter after Art.28, covering GPAI provider obligations (Chapter V) that distributors supplying GPAI models must understand
• EU AI Act Art.27 Fundamental Rights Impact Assessment (FRIA): Developer Guide
• EU AI Act Art.26 Obligations for Deployers: Developer Guide
• EU AI Act Art.22 EU Database of High-Risk AI Systems: Developer Guide
• EU AI Act Art.21 Cooperation with Competent Authorities: Developer Guide
• EU AI Act Art.20 Corrective Actions & Duty of Information: Developer Guide