EU AI Act Art.37 Obligations of Importers: Developer Guide (2026)

EU AI Act Article 37 governs a supply-chain role that is easy to overlook but carries substantial compliance exposure: the importer. Where Art.25 addresses providers who place systems on the EU market directly, Art.37 addresses the intermediary case — a company established in the EU that brings an AI system developed by a third-country provider into the EU market. This role is common in enterprise software: a German VAR reselling a US-built AI decision engine, a French systems integrator bundling a South Korean computer-vision API into a product, or a Dutch distributor placing a Japanese AI-powered device on the European market.

Art.37 imposes five categories of obligation on importers: pre-market compliance verification, identity labelling, storage and transport compliance preservation, cooperation with market surveillance authorities, and EU database registration. Unlike distributors (Art.28), importers bear these obligations regardless of whether they have any technical ability to inspect or modify the underlying AI system. The obligation arises from the market placement act itself.

For developers, Art.37 matters in two directions: if your company acts as an importer of a third-country AI system, you must satisfy Art.37 before deployment; and if your company's AI system is placed on the EU market by a third-party importer, you must ensure that importer has the documentation and certifications they need to fulfil their Art.37 obligations.

Art.37 in the EU AI Act Supply Chain

Art.37 fits into the EU AI Act's role-based liability framework alongside Art.25 (providers), Art.26 (deployers), Art.28 (distributors), and Art.24 (manufacturers of regulated products):

The key distinction between importer (Art.37) and distributor (Art.28) is market placement: the importer is the first entity in the EU supply chain to place the product on the market. The distributor makes it subsequently available in the supply chain. This distinction is significant because Art.37 importers bear pre-market verification obligations — they must act before placement, not after.

The secondary distinction is geographic origin: Art.37 applies specifically to AI systems whose provider is established outside the EU. A US company's AI system placed on the EU market by an EU subsidiary or partner triggers Art.37. A French company's AI system does not — the provider is already EU-established and Art.25 applies directly.

Art.37(1): Importer Definition and Scope

Art.37(1) defines an importer as a natural or legal person established in the European Union who places an AI system from a third-country provider on the EU market.

Three elements must be satisfied simultaneously:

Element 1 — EU Establishment: The importer must be legally established in the EU. A US company with an EU subsidiary counts as EU-established for the purposes of that subsidiary's activities. A US company operating solely through a website accessible in the EU is not — it is a third-country provider subject to Art.25(3) (authorised representative obligation).

Element 2 — Third-Country Provider: The original developer and owner of the AI system must be established outside the EU. "Established" follows standard EU commercial law: registered office, central administration, or principal place of business determines establishment.

Element 3 — Market Placement Act: The importer must be the entity that first makes the AI system available in the EU market. This is a commercial act — signing a distribution agreement, placing the product on the EU market for sale, or including it in a product or service offered in the EU.

What "Third-Country AI System" Means in Practice

The concept is technology-agnostic. It covers:

• A SaaS API from a US AI company integrated into an EU product
• Hardware with embedded AI from a Japanese manufacturer distributed in the EU
• A pre-trained model from a Chinese research lab integrated into an EU software product
• A South Korean robotics AI system sold by an EU robotics integrator

It does not cover:

• An AI system developed by an EU company, even if hosted on US infrastructure
• A GPAI model accessed as a service (different supply chain — provider is the GPAI provider, deployer obligations under Art.26 apply)

Art.37(2): The Five Pre-Market Verification Gates

Art.37(2) is the operational core of the article. Before placing a third-country AI system on the EU market, the importer must verify that the provider has satisfied five conditions. These are blocking gates — failure on any one of them prevents lawful market placement.

Gate 1: Conformity Assessment Completed (Art.37(2)(a))

The importer must verify that the appropriate conformity assessment has been carried out. For high-risk AI under Annex III:

• Annex VI route (internal control): The provider has completed the six-step self-assessment procedure and produced an internal assessment report
• Annex VII route (notified body): A designated notified body has issued a valid EU-type examination certificate or QMS certification

The importer cannot conduct the assessment themselves — that is the provider's obligation under Art.25(1)(a). But the importer must verify evidence of completion: obtain the conformity assessment report summary, the declaration of conformity (Art.48), and any notified body certificates.

For notified-body routes, the importer must additionally verify:

• The notified body is currently designated (NANDO database check — Art.33)
• The body's designation has not been suspended or withdrawn (Art.36 check)
• The certificate covers the specific AI system version and scope the importer is placing on the market

Gate 2: Technical Documentation Available (Art.37(2)(b))

The provider must have drawn up technical documentation conforming to Annex IV. The importer does not need to hold the full documentation — but must verify it exists and is accessible for market surveillance authorities (Art.21).

Practically, this means:

• Obtain a written confirmation from the provider that Annex IV documentation has been completed
• Verify the documentation covers the specific system version being placed on the market
• Confirm the documentation is held by the provider (or their authorised representative) in the EU for MSA access
• For Art.32 non-public categories (biometric ID, law enforcement, migration, justice), confirm separate secure access arrangements exist

Gate 3: CE Marking and Declaration of Conformity (Art.37(2)(c))

The AI system must bear the CE marking (Art.49) and the provider must have drawn up a Declaration of Conformity (Art.48). The importer must verify:

• CE marking is affixed to the AI system, its packaging, or accompanying documentation (per Art.49 requirements for the specific product category)
• Declaration of Conformity has been issued and covers the current version
• The DoC references the correct conformity assessment route and standards applied

The CE marking on AI systems follows the rules established in Decision 768/2008/EC (NLF framework), applied through the EU AI Act's specific requirements. For AI systems embedded in regulated products (Annex I), the CE marking covers both the product and the AI component — the importer must verify both are covered.

Gate 4: Authorised Representative Established (Art.37(2)(d))

Where the provider is not established in the EU, they must appoint an authorised representative per Art.22(1). The importer must verify:

• An authorised representative has been formally mandated (obtain mandate documentation)
• The representative is established in the EU in one of the Member States where the AI system will be placed on market
• The mandate covers the obligations under Art.22 (technical documentation access, market surveillance cooperation, registration in EU database)

Note that the importer and the authorised representative are distinct roles — the importer places the system on the market; the authorised representative acts as the provider's legal proxy for compliance obligations. An EU company cannot simultaneously be both importer and authorised representative for the same AI system.

Gate 5: Provider Registration in EU Database (Art.37(2)(e))

Where the provider is subject to registration in the EU database (Art.32), the importer must verify that registration is complete and current before market placement. This requires:

• Checking the EU AI Office database for the provider's registration record (accessible April 2026+)
• Verifying the system's Annex VIII registration fields match the specific version being placed on market
• For non-public categories (Annex III pts. 1, 6, 7, 8): verification through MSA channels rather than public database

Registration must precede market placement — this is a hard sequential dependency. The trigger chain is: conformity assessment → Declaration of Conformity → CE marking → EU database registration → then market placement by importer.

Art.37(3): Importer Identity Labelling

Art.37(3) requires the importer to indicate their name, registered trade name or registered trade mark, and postal address on the AI system — or, where that is impossible due to size or nature, on the packaging or an accompanying document.

This serves a dual purpose: market transparency (consumers and authorities can identify who placed the system on the market) and enforcement traceability (MSAs can identify and contact importers for corrective action).

Practical Implementation

For software-based AI systems, "the AI system" can mean several things in practice:

For AI systems embedded in regulated products (Annex I), importer labelling requirements under Art.37(3) apply alongside the labelling requirements of the sector regulation (MDR, Machinery Regulation, etc.) — not as alternatives.

Art.37(3) vs. Provider Labelling Under Art.25

A frequently confused point: Art.25(1)(b) requires providers to include their name and contact details on the AI system. Art.37(3) requires importers to do the same. Both obligations are additive — not alternative. The final product or service should identify both the original provider and the EU importer.

Art.37(4): Storage and Transport Compliance Preservation

Art.37(4) requires the importer to ensure that storage and transport conditions do not jeopardise the AI system's compliance with the requirements of Chapter 3 (Art.8–15: the substantive technical obligations for high-risk AI).

This obligation is most operationally relevant for AI systems embedded in hardware — robotics, medical devices, safety-critical sensors. Software-only AI systems have a limited set of storage/transport compliance risks, but they are not zero:

Software AI compliance risks during storage/transport:

• Model weights corrupted during transfer (integrity verification required)
• Training data provenance records lost during storage migration
• Licence and conformity documentation lost during system transfer
• Logging and record-keeping systems not preserved during deployment handover
• Version integrity broken — different version deployed than what was assessed

For hardware-embedded AI, the Art.37(4) obligation parallels existing obligations under product safety legislation (Storage/transport instructions, environmental conditions documentation).

Art.37(5): EU Database Registration

Art.37(5) creates an independent registration obligation for importers — distinct from the provider's Art.32 registration.

Importers who place high-risk AI systems under Annex III on the EU market must register in the EU database before market placement. The registration covers:

• Importer identity (name, address, registration number)
• The AI system being imported (linked to provider's registration entry)
• The Member States in which the system will be placed on market
• Any changes to the system's EU distribution scope

This creates a dual-entry structure in the EU database: the provider registers the system (Art.32); the importer registers their placement act (Art.37(5)). Market surveillance authorities can use either entry to identify responsible parties.

For the non-public categories (Annex III points 1, 6, 7, 8 — biometric identification, law enforcement, migration, justice), importer registration follows the same restricted-access rules as provider registration: entries are visible only to the EU AI Office and designated national MSAs, not to the public.

Art.37 × Art.25: When the Importer Becomes a Provider

Art.37's obligations presuppose that the importer is distinct from the provider — they are placing a third party's system on the market. But Art.37 contains a crucial boundary: if the importer substantially modifies the AI system, they become a new provider under Art.25(1)(d).

Three transformation scenarios:

Art.3(23) "substantial modification" is defined as a change that affects the AI system's compliance with requirements or alters its intended purpose — not merely configuration, parameterisation, or superficial adaptation. The Art.3(23) boundary is the same one that triggers provider transformation for distributors under Art.28(2).

Importers who customise, fine-tune, or extend third-country AI systems must assess each customisation against Art.3(23) before concluding they remain an importer rather than a new provider.

Art.37 Intersection Matrix

CLOUD Act × Art.37: The US-Headquartered Importer Problem

Art.37 creates a specific CLOUD Act exposure scenario: the US-headquartered EU importer.

Consider an EU subsidiary of a US corporation that acts as the EU importer for the US parent's AI systems. The subsidiary is EU-established (satisfies Art.37(1) EU establishment requirement) and places the system on the EU market. But the subsidiary's parent — the US corporation — is subject to the US CLOUD Act.

Under the CLOUD Act, US authorities can compel US corporations (and their subsidiaries and affiliates) to disclose data stored anywhere in the world, including in EU subsidiaries. This creates a specific compliance risk for Art.37 importers:

Art.37 CLOUD Act Risk Vectors:

The dual-compellability scenario: EU market surveillance authorities have access to Art.37 importer records under Art.21 (MSA powers) and Art.78 (cooperation obligation). If those records are held on US-parent infrastructure, they are simultaneously accessible under Art.21 (EU right) and under CLOUD Act (US right) — without either authority knowing about the parallel access.

EU-native solution: An EU importer using EU-native infrastructure (not US-headquartered or US-cloud-dependent) for storing Art.37 compliance records faces only EU-sovereign access requests. This is the single-jurisdiction model that eliminates parallel CLOUD Act compellability.

For EU subsidiaries of US corporations, the solution requires deliberate infrastructure design: Art.37 compliance documentation must be stored in EU-controlled systems that fall outside the CLOUD Act's reach — not merely in a European AWS or Azure region, which remains subject to CLOUD Act compellability through the parent corporation.

Python Implementation

ImporterComplianceRecord

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

class VerificationGate(Enum):
    CONFORMITY_ASSESSMENT = "conformity_assessment"
    TECHNICAL_DOCUMENTATION = "technical_documentation"
    CE_MARKING_DOC = "ce_marking_doc"
    AUTHORISED_REPRESENTATIVE = "authorised_representative"
    EU_DATABASE_REGISTRATION = "eu_database_registration"

@dataclass
class ImporterComplianceRecord:
    importer_name: str
    importer_eu_establishment: str  # Country code of EU establishment
    system_slug: str
    provider_name: str
    provider_country: str  # Must be non-EU for Art.37 to apply
    annex_iii_category: Optional[str]
    assessment_route: str  # "annex_vi" or "annex_vii"
    notified_body_id: Optional[str]
    notified_body_nando_verified: bool = False
    gates_passed: dict[str, bool] = field(default_factory=dict)
    placement_date: Optional[date] = None
    
    def verify_gate(self, gate: VerificationGate, passed: bool, evidence_ref: str = "") -> None:
        self.gates_passed[gate.value] = passed
    
    def is_placement_authorised(self) -> bool:
        """All five Art.37(2) gates must pass before market placement."""
        required = [g.value for g in VerificationGate]
        return all(self.gates_passed.get(g, False) for g in required)
    
    def placement_gate_report(self) -> dict:
        required = [g.value for g in VerificationGate]
        return {
            "authorised": self.is_placement_authorised(),
            "gates": {g: self.gates_passed.get(g, False) for g in required},
            "blocking_gates": [g for g in required if not self.gates_passed.get(g, False)],
            "provider_country_triggers_art37": self.provider_country not in EU_MEMBER_STATES
        }

EU_MEMBER_STATES = {
    "AT","BE","BG","CY","CZ","DE","DK","EE","ES","FI","FR","GR",
    "HR","HU","IE","IT","LT","LU","LV","MT","NL","PL","PT","RO",
    "SE","SI","SK"
}

ConformityVerificationTracker

@dataclass
class NotifiedBodyStatus:
    body_id: str
    nando_status: str  # "designated", "suspended", "withdrawn"
    scope_categories: list[str]
    last_verified: datetime
    suspension_date: Optional[date] = None

@dataclass
class ConformityVerificationTracker:
    """Tracks Gate 1 verification: conformity assessment + certificate validity."""
    system_slug: str
    assessment_route: str
    certificate_id: Optional[str] = None
    certificate_expiry: Optional[date] = None
    notified_body: Optional[NotifiedBodyStatus] = None
    doc_of_conformity_ref: Optional[str] = None
    
    def certificate_is_valid(self) -> bool:
        if self.certificate_expiry and self.certificate_expiry < date.today():
            return False
        if self.notified_body and self.notified_body.nando_status != "designated":
            return False
        return self.certificate_id is not None
    
    def annex_vii_gate_passed(self) -> tuple[bool, list[str]]:
        """Returns (passed, list_of_failures) for notified-body route."""
        failures = []
        if not self.certificate_id:
            failures.append("No certificate ID recorded")
        if self.certificate_expiry and self.certificate_expiry < date.today():
            failures.append(f"Certificate expired: {self.certificate_expiry}")
        if self.notified_body:
            if self.notified_body.nando_status == "suspended":
                failures.append(f"Notified body {self.notified_body.body_id} is suspended (Art.36)")
            elif self.notified_body.nando_status == "withdrawn":
                failures.append(f"Notified body {self.notified_body.body_id} designation withdrawn (Art.36)")
        if not self.doc_of_conformity_ref:
            failures.append("No Declaration of Conformity reference")
        return (len(failures) == 0, failures)
    
    def conformity_summary(self) -> dict:
        if self.assessment_route == "annex_vii":
            passed, failures = self.annex_vii_gate_passed()
        else:  # annex_vi
            passed = self.doc_of_conformity_ref is not None
            failures = [] if passed else ["No Declaration of Conformity for Annex VI route"]
        return {
            "route": self.assessment_route,
            "gate_passed": passed,
            "failures": failures,
            "certificate_valid": self.certificate_is_valid()
        }

ImporterRegistrationManager

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

@dataclass
class EUDatabaseEntry:
    importer_name: str
    importer_address: str
    importer_registration_number: str
    system_slug: str
    provider_registration_id: str  # Provider's Art.32 registration ID
    target_member_states: list[str]
    registration_date: Optional[date] = None
    non_public: bool = False  # True for Annex III pts 1/6/7/8

@dataclass
class ImporterRegistrationManager:
    records: list[EUDatabaseEntry] = field(default_factory=list)
    
    def register(self, entry: EUDatabaseEntry) -> None:
        """Register importer before market placement (Art.37(5))."""
        entry.registration_date = date.today()
        self.records.append(entry)
    
    def is_registered(self, system_slug: str, importer_name: str) -> bool:
        return any(
            r.system_slug == system_slug and r.importer_name == importer_name
            for r in self.records
        )
    
    def update_member_states(self, system_slug: str, importer_name: str, 
                              new_states: list[str]) -> bool:
        for r in self.records:
            if r.system_slug == system_slug and r.importer_name == importer_name:
                r.target_member_states = new_states
                return True
        return False
    
    def pre_placement_gate_check(self, system_slug: str, importer_name: str,
                                  provider_registration_id: str) -> dict:
        """Final gate before market placement: verify registration complete."""
        registered = self.is_registered(system_slug, importer_name)
        return {
            "importer_registered": registered,
            "provider_reg_id": provider_registration_id,
            "gate_passed": registered and bool(provider_registration_id),
            "blocking_reason": None if registered else "Importer not registered in EU database (Art.37(5))"
        }

40-Item Compliance Checklist

Pre-Market Verification (Art.37(2)) — Items 1–20

1. Confirmed provider is established outside EU (Art.37(1) scope check)
2. Confirmed your entity is EU-established (Art.37(1) importer qualification)
3. Verified conformity assessment type: Annex VI (internal) or Annex VII (notified body)
4. Obtained conformity assessment summary report from provider
5. Verified assessment covers specific system version being placed on market
6. For Annex VII: verified notified body NANDO designation is current
7. For Annex VII: verified notified body has not been suspended (Art.36) since certificate issue
8. For Annex VII: verified certificate scope covers Annex III category of your system
9. Obtained confirmation that Annex IV technical documentation is complete
10. Verified technical documentation covers current system version (not prior version)
11. Confirmed technical documentation is accessible to EU MSAs on request
12. Verified CE marking is correctly affixed (Art.49) on system/packaging/documentation
13. Obtained Declaration of Conformity (Art.48) from provider
14. Verified DoC references correct conformity assessment route and standards
15. Confirmed authorised representative appointed (Art.22) if provider not EU-established
16. Verified authorised representative EU establishment covers target Member States
17. Obtained mandate documentation for authorised representative
18. Verified provider's Art.32 registration in EU database (where applicable)
19. Verified registration covers specific system version being placed on market
20. Confirmed sequential dependency satisfied: assessment → DoC → CE marking → registration → placement

Importer-Specific Obligations (Art.37(3)–(5)) — Items 21–30

1. Affixed importer name, trade name/mark, and postal address on AI system (Art.37(3))
2. Confirmed labelling placement: on system, packaging, or accompanying document
3. Verified importer labelling does not obscure or contradict provider's Art.25 labelling
4. Documented storage condition requirements for hardware-embedded AI
5. Documented transport condition requirements (environmental, handling)
6. Implemented version integrity verification for software AI transfer
7. Ensured logging and record-keeping systems preserved during deployment handover
8. Registered importer details in EU database before first market placement (Art.37(5))
9. Registered all target Member States in EU database entry
10. Established process for updating EU database registration on distribution scope change

Provider-Transformation Boundary — Items 31–35

1. Assessed all customisations against Art.3(23) substantial modification definition
2. Documented which modifications are below Art.3(23) threshold (configuration, parameterisation)
3. Documented which modifications trigger Art.3(23) and consequent Art.25 provider obligations
4. Verified own-name marketing does not occur without assuming Art.25 provider obligations
5. Established internal review process for new customisation requests against Art.3(23)

Infrastructure and CLOUD Act — Items 36–40

1. Identified whether importer entity is subject to CLOUD Act (US parent corporation)
2. Assessed which Art.37 compliance documents are stored in US-parent infrastructure
3. Evaluated CLOUD Act compellability risk for each document category
4. Designed EU-native storage solution for Art.37 compliance records (non-US-parent infrastructure)
5. Confirmed Art.37 compliance documentation storage location supports single-jurisdiction MSA access

40 Keywords

See Also

• EU AI Act Art.36 Suspension of Notified Body Designation: Developer Guide — Art.37(2)(a) Gate 1 requires importers to verify notified body designation is current; Art.36 governs when and how designation is suspended
• EU AI Act Art.33 Obligations for Notified Bodies: Developer Guide — NANDO database verification for Art.37 Gate 1; notified body accreditation and scope requirements
• EU AI Act Art.31 Conformity Assessment Procedure: Developer Guide — Annex VI vs. Annex VII route selection that importers must verify under Art.37(2)(a)
• EU AI Act Art.28 Obligations of Distributors: Developer Guide — Distributor obligations (Art.28) downstream from importer; Art.37 vs. Art.28 role boundary
• EU AI Act Art.32 EU Database of High-Risk AI Systems: Developer Guide — Registration mechanics that Art.37(5) importer registration and Art.37(2)(e) provider verification rely on