EU AI Act Art.56 Code of Practice for GPAI Models: The Systemic Risk Compliance Pathway — Developer Guide (2026)

EU AI Act Article 56 answers a critical question for every GPAI provider subject to Chapter V: what is the approved compliance pathway, and how do you demonstrate conformity with the Art.52–55 obligation cluster without submitting to a full conformity assessment by the Commission on a one-off basis?

The answer is the Code of Practice (CoP) — a co-regulatory instrument drafted by GPAI providers under AI Office facilitation. Art.56 is the compliance architecture article of Chapter V. It does not impose new substantive obligations; instead, it creates a structured mechanism through which systemic risk GPAI providers can demonstrate compliance with Art.53 and the broader Chapter V framework through adherence to a recognized Code of Practice.

Art.56 became applicable on 2 August 2025 as part of Chapter V of the EU AI Act (Regulation (EU) 2024/1689). The AI Office published the first draft General-Purpose AI Code of Practice in November 2024 during the GPAI Code development process initiated under Art.56(1). Understanding Art.56 is essential for every GPAI provider navigating systemic risk obligations, and for downstream developers who need to understand whether their upstream provider is compliant through CoP adherence or alternative means.

This article completes the Chapter V GPAI Models series (Art.51 → Art.52 → Art.53 → Art.54 → Art.55 → Art.56). With Art.56, Chapter V is fully covered.

Art.56 in the Chapter V GPAI Obligation Cascade

Art.56 is the capstone of Chapter V. While Art.52–55 define what systemic risk GPAI providers must do, Art.56 defines how they prove they are doing it. A provider that participates in and adheres to an approved Code of Practice is presumed to comply with the relevant Chapter V obligations. A provider that does not adhere to a CoP must demonstrate compliance through other means — with no safe harbour.

Art.56(1): AI Office Facilitation and CoP Development

Art.56(1) assigns the AI Office the role of encouraging and facilitating the development, updating, and implementation of Codes of Practice for GPAI providers. Key structural features:

What Art.56(1) Mandates

• The AI Office takes the active facilitation role — it does not simply receive voluntary submissions, it drives the process
• GPAI providers are expected to participate in the drafting process — non-participation is a risk signal to supervisors
• The CoP covers both general tier GPAI providers (Art.52) and systemic risk tier providers (Art.53)
• A single CoP may cover all Chapter V obligations, or separate CoPs may address different obligation clusters

AI Office as Convener

The AI Office, established within the Commission under Art.64(1), acts as:

Timeline: The GPAI CoP Development Process

Art.56(2): Participation Structure

Art.56(2) defines who participates in CoP development: GPAI providers (both general and systemic risk tier), downstream providers, and civil society representatives. The broad participation requirement reflects the co-regulatory nature of the instrument.

Participant Categories Under Art.56(2)

Developer Implications of Art.56(2)

If you are a downstream provider (SaaS developer using GPAI APIs):

1. You are a legitimate stakeholder in CoP development — Art.56(2) explicitly includes downstream providers
2. Industry associations representing downstream developers (e.g., BITKOM, EuroCloud, EEMA) can participate on your behalf
3. CoP terms affect your rights — if the CoP defines how Art.55 information must be delivered, downstream providers should ensure those delivery standards are workable

For EU infrastructure providers like sota.io, Art.56(2) participation creates a positioning opportunity: an EU-native PaaS that actively engages in the GPAI CoP process as a downstream provider voice signals compliance credibility to enterprise customers.

Art.56(3): Mandatory Minimum Content of the CoP

Art.56(3) is the substantive heart of Art.56. It defines what a CoP for systemic risk GPAI providers must cover at minimum. A CoP that does not address these elements cannot achieve the Art.56(4) adequacy assessment.

Art.56(3) Mandatory Minimum Content Matrix

What Art.56(3) Does NOT Mandate

Art.56(3) sets the floor, not the ceiling. A CoP may go beyond Art.56(3) to address:

• Art.52 general documentation standards (technical documentation format, model card schema)
• Art.55 information delivery standards (API endpoint format, update notification protocols)
• Art.54 authorised representative coordination procedures
• Voluntary commitments beyond the statutory minimum (e.g., responsible scaling policies, capability thresholds)

The AI Office's first draft GPAI Code of Practice (November 2024) went significantly beyond Art.56(3) minimum content, addressing downstream developer obligations, model evaluation frameworks, and transparency registry integration.

Art.56(4): Commission Adequacy Assessment

Art.56(4) empowers the Commission to assess whether a CoP is adequate — whether it genuinely covers the Art.56(3) mandatory minimum content and creates meaningful compliance obligations. An adequate CoP produces the Art.56(4) presumption of conformity.

Adequacy Assessment Process

CoP Drafting
    ↓
AI Office Facilitation (Art.56(1))
    ↓
Multi-Stakeholder Consultation (Art.56(2))
    ↓
Draft CoP Submission to Commission
    ↓
Commission Adequacy Assessment (Art.56(4))
    ├── ADEQUATE → CoP published, conformity presumption active
    └── INADEQUATE → Revision required OR Commission implementation act (Art.56(6))

What "Adequate" Means

A CoP is adequate if:

Presumption of Conformity

When a CoP achieves adequacy, adherence to that CoP creates a presumption of conformity with the Chapter V obligations it covers:

A GPAI provider that can demonstrate adherence to an adequate Code of Practice is presumed to comply with the Art.52–55 obligations addressed by that CoP.

This presumption is rebuttable — the AI Office or Commission can still investigate and find non-conformity if evidence suggests the provider's actual practices deviate from CoP commitments.

Art.56(5): Voluntary Adoption Before the Art.56(3) Deadline

Art.56(5) explicitly provides that GPAI providers may voluntarily adopt a CoP before the Chapter V deadline. This provision:

1. Encourages early compliance signalling — adopting a CoP before it is required demonstrates good faith
2. Creates a safe harbour window — providers who adopt a CoP early are insulated from enforcement scrutiny on the covered obligations
3. Allows iterative compliance — providers can adopt a draft CoP while it awaits the Art.56(4) adequacy assessment, updating their practices as the CoP is finalized

Strategic Value of Early CoP Adoption

Art.56(6): Commission Implementation Acts as Fallback

Art.56(6) is the regulatory backstop. If the AI Office's facilitation process does not result in an adequate CoP within a reasonable time, the Commission may adopt implementing acts to establish the compliance standards that the CoP was meant to provide.

When Art.56(6) Triggers

Implementing Acts vs. CoP

The threat of Art.56(6) is itself a compliance driver — providers that do not engage with the CoP process risk having binding standards imposed without input.

Art.56 × Art.53: The Compliance Pathway Mechanics

The most important cross-article relationship in Art.56 is its interaction with Art.53. Art.53 imposes four enhanced obligations on systemic risk GPAI providers. Art.56 defines the pathway to demonstrate compliance with those obligations.

Art.53 Obligation → Art.56 CoP Coverage → Conformity Presumption

Art.53(1)(a) Adversarial Testing
    → CoP Section: Testing methodology, scope, frequency, reporting
    → Conformity Presumption: Provider that follows CoP testing framework
       is presumed to comply with Art.53(1)(a)

Art.53(1)(b) Incident Reporting  
    → CoP Section: Incident definition, reporting timeline, notification format
    → Conformity Presumption: Provider that follows CoP incident procedure
       is presumed to comply with Art.53(1)(b)

Art.53(1)(c) Cybersecurity
    → CoP Section: Security baseline, weight protection, API security
    → Conformity Presumption: Provider that meets CoP security standards
       is presumed to comply with Art.53(1)(c)

Art.53(1)(d) Energy Efficiency
    → CoP Section: Energy reporting format, compute disclosure
    → Conformity Presumption: Provider that reports per CoP format
       is presumed to comply with Art.53(1)(d)

What Happens Without CoP Adherence

A systemic risk GPAI provider that does not adhere to a CoP must demonstrate Art.53 compliance independently:

Without the CoP safe harbour, the evidential burden is higher and the regulatory exposure is greater — any deviation from internally committed standards can constitute non-conformity.

Art.56 × Art.52: General Baseline Obligations Are Unaffected

A critical clarification: Art.56 CoP adherence does not substitute for Art.52 general baseline obligations. Even with a fully adequate CoP:

Art.52 obligations apply to all GPAI providers including general tier providers. The CoP is primarily designed for systemic risk providers (Art.53 obligations). General tier providers may adhere to the portions of a CoP that cover Art.52, but Art.52 obligations are not contingent on CoP existence.

CLOUD Act × Art.56: CoP Adherence Records Jurisdiction Risk

For GPAI providers storing their CoP compliance records on US-based infrastructure, there is a documented CLOUD Act risk:

CLOUD Act-Reachable Art.56 Records

EU-Native Infrastructure as Mitigation

Storing CoP adherence records on EU-incorporated, EU-sovereign infrastructure (not subject to CLOUD Act) creates a single-regime compliance record set — accessible only to EU authorities through EU legal channels. This is directly relevant to downstream integrators evaluating upstream GPAI providers:

GPAI Provider on EU Infrastructure (e.g., sota.io)
  → CoP records stored in EU
  → Accessible only via EU MLA channels
  → Downstream integrator's Art.9 risk file: jurisdiction risk = LOW

GPAI Provider on US Infrastructure (AWS / Azure / GCP US)
  → CoP records dual-compellable
  → US CLOUD Act access is structural, not case-by-case
  → Downstream integrator's Art.9 risk file: jurisdiction risk = HIGH

Python Implementation: CodeOfPracticeAdherenceRecord and GPAICoPrequirements

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


class CoPAdherenceStatus(Enum):
    """Art.56 Code of Practice adherence status."""
    NOT_PARTICIPATING = "not_participating"           # No CoP participation
    DRAFTING_PARTICIPANT = "drafting_participant"     # Art.56(2) drafting participant
    VOLUNTARY_ADOPTER = "voluntary_adopter"           # Art.56(5) voluntary early adoption
    FORMAL_ADHERENT = "formal_adherent"               # Formal adherence to adequate CoP
    NON_CONFORMING = "non_conforming"                 # Adherent but non-conforming


class CoPAdequacyStatus(Enum):
    """Commission adequacy assessment status under Art.56(4)."""
    DRAFT = "draft"                # CoP in drafting — Art.56(1) process active
    UNDER_ASSESSMENT = "under_assessment"  # Submitted to Commission for Art.56(4) review
    ADEQUATE = "adequate"          # Commission found CoP adequate
    INADEQUATE = "inadequate"      # Commission found CoP inadequate — revision required
    IMPLEMENTING_ACT = "implementing_act"  # Commission issued Art.56(6) implementing act


@dataclass
class CodeOfPracticeAdherenceRecord:
    """
    EU AI Act Art.56 Code of Practice adherence record.
    Documents a GPAI provider's CoP participation and compliance status.
    """
    # Provider identification
    provider_name: str
    provider_legal_entity: str
    gpai_model_identifier: str
    is_systemic_risk: bool  # Art.51(1)(a) — if True, Art.56(3) mandatory minimums apply
    
    # CoP reference
    cop_name: str = ""                      # Official CoP name (e.g., "GPAI Code of Practice v1.0")
    cop_version: str = ""                   # Version adopted
    cop_publication_date: Optional[date] = None  # When CoP was published by AI Office
    adequacy_status: CoPAdequacyStatus = CoPAdequacyStatus.DRAFT
    adequacy_decision_date: Optional[date] = None  # Commission Art.56(4) decision date
    
    # Adherence status
    adherence_status: CoPAdherenceStatus = CoPAdherenceStatus.NOT_PARTICIPATING
    participation_start_date: Optional[date] = None   # Art.56(2) participation date
    voluntary_adoption_date: Optional[date] = None    # Art.56(5) early adoption date
    formal_adherence_date: Optional[date] = None      # Date of formal adherence declaration
    
    # Art.56(3) mandatory content coverage (systemic risk providers)
    cop_covers_adversarial_testing: bool = False    # Art.53(1)(a) coverage
    cop_covers_incident_reporting: bool = False     # Art.53(1)(b) coverage
    cop_covers_cybersecurity: bool = False          # Art.53(1)(c) coverage
    cop_covers_energy_efficiency: bool = False      # Art.53(1)(d) coverage
    
    # Conformity presumption status
    conformity_presumption_active: bool = False     # True when CoP adequate + provider adherent
    presumption_covers_obligations: list[str] = field(default_factory=list)
    
    # Infrastructure jurisdiction (CLOUD Act risk)
    cop_records_jurisdiction: str = ""              # e.g., "EU-DE", "US-VA"
    cloud_act_risk: str = ""                        # "high", "medium", "low"
    
    def cop_minimum_content_complete(self) -> bool:
        """
        Check if CoP covers all Art.56(3) mandatory minimum content.
        Only relevant for systemic risk providers.
        """
        if not self.is_systemic_risk:
            return True  # Art.56(3) minimums only apply to systemic risk tier
        return all([
            self.cop_covers_adversarial_testing,
            self.cop_covers_incident_reporting,
            self.cop_covers_cybersecurity,
            self.cop_covers_energy_efficiency,
        ])

    def conformity_presumption_available(self) -> bool:
        """
        Determine whether the Art.56(4) conformity presumption is available.
        Requires: adequate CoP + provider adherence.
        """
        return (
            self.adequacy_status == CoPAdequacyStatus.ADEQUATE
            and self.adherence_status == CoPAdherenceStatus.FORMAL_ADHERENT
            and self.cop_minimum_content_complete()
        )

    def compliance_gap_summary(self) -> dict:
        """
        Return a structured gap analysis for Art.56 compliance.
        """
        gaps = []
        
        if self.adherence_status == CoPAdherenceStatus.NOT_PARTICIPATING:
            gaps.append({
                "gap": "No CoP participation",
                "obligation": "Art.56(2)",
                "risk": "HIGH — no compliance pathway, higher evidential burden for Art.53",
                "action": "Engage with AI Office drafting process or join existing CoP"
            })
        
        if self.is_systemic_risk and not self.cop_minimum_content_complete():
            missing = []
            if not self.cop_covers_adversarial_testing:
                missing.append("adversarial testing (Art.53(1)(a))")
            if not self.cop_covers_incident_reporting:
                missing.append("incident reporting (Art.53(1)(b))")
            if not self.cop_covers_cybersecurity:
                missing.append("cybersecurity (Art.53(1)(c))")
            if not self.cop_covers_energy_efficiency:
                missing.append("energy efficiency (Art.53(1)(d))")
            gaps.append({
                "gap": f"CoP does not cover mandatory Art.56(3) elements: {', '.join(missing)}",
                "obligation": "Art.56(3)",
                "risk": "MEDIUM — CoP inadequate for systemic risk obligations",
                "action": "Ensure CoP addresses all Art.56(3) elements before Commission adequacy assessment"
            })
        
        if self.cloud_act_risk == "high":
            gaps.append({
                "gap": "CoP adherence records on US infrastructure",
                "obligation": "CLOUD Act × Art.56",
                "risk": "MEDIUM — dual-compellability for adversarial test + cybersecurity records",
                "action": "Migrate CoP documentation to EU-sovereign infrastructure"
            })
        
        return {
            "provider": self.provider_name,
            "model": self.gpai_model_identifier,
            "gaps_found": len(gaps),
            "conformity_presumption_available": self.conformity_presumption_available(),
            "gaps": gaps,
        }


@dataclass
class GPAICoPrequirements:
    """
    Checks whether a GPAI provider's practices meet the Art.56(3)
    mandatory CoP minimum content requirements for systemic risk providers.
    """
    provider_name: str
    
    # Art.56(3)(a): Adversarial testing requirements
    adversarial_testing_methodology_documented: bool = False
    adversarial_testing_scope_cbrn: bool = False
    adversarial_testing_scope_cyber: bool = False
    adversarial_testing_scope_manipulation: bool = False
    adversarial_testing_scope_autonomous: bool = False
    adversarial_testing_frequency: str = ""  # e.g., "before each major release + annually"
    adversarial_testing_independence: str = ""  # e.g., "third-party evaluator" or "internal red team"
    adversarial_testing_ai_office_reporting: bool = False
    
    # Art.56(3)(b): Incident reporting requirements
    incident_definition_documented: bool = False
    incident_reporting_timeline_defined: bool = False  # "without undue delay"
    incident_commission_notification_format: bool = False
    incident_downstream_notification_procedure: bool = False
    
    # Art.56(3)(c): Cybersecurity requirements
    model_weight_protection_standard: str = ""
    training_infrastructure_security_baseline: bool = False
    inference_api_security_requirements: bool = False
    supply_chain_security_protocol: bool = False
    
    # Art.56(3)(d): Energy efficiency requirements
    training_energy_reporting_format: bool = False
    inference_energy_estimation_methodology: bool = False
    carbon_intensity_reporting: bool = False
    eu_datacenter_location_disclosed: bool = False
    
    def cop_readiness_score(self) -> float:
        """
        Calculate CoP readiness as a percentage (0.0 – 1.0).
        Based on Art.56(3) mandatory minimum content.
        """
        checks = [
            # Adversarial testing
            self.adversarial_testing_methodology_documented,
            self.adversarial_testing_scope_cbrn,
            self.adversarial_testing_scope_cyber,
            self.adversarial_testing_scope_manipulation,
            self.adversarial_testing_scope_autonomous,
            bool(self.adversarial_testing_frequency),
            bool(self.adversarial_testing_independence),
            self.adversarial_testing_ai_office_reporting,
            # Incident reporting
            self.incident_definition_documented,
            self.incident_reporting_timeline_defined,
            self.incident_commission_notification_format,
            self.incident_downstream_notification_procedure,
            # Cybersecurity
            bool(self.model_weight_protection_standard),
            self.training_infrastructure_security_baseline,
            self.inference_api_security_requirements,
            self.supply_chain_security_protocol,
            # Energy efficiency
            self.training_energy_reporting_format,
            self.inference_energy_estimation_methodology,
            self.carbon_intensity_reporting,
            self.eu_datacenter_location_disclosed,
        ]
        return sum(checks) / len(checks)

    def readiness_report(self) -> dict:
        """Generate an Art.56(3) readiness report for CoP participation."""
        score = self.cop_readiness_score()
        return {
            "provider": self.provider_name,
            "cop_readiness_percent": round(score * 100, 1),
            "readiness_level": (
                "READY" if score >= 0.85 else
                "MOSTLY_READY" if score >= 0.70 else
                "PARTIALLY_READY" if score >= 0.50 else
                "NOT_READY"
            ),
            "adversarial_testing_complete": all([
                self.adversarial_testing_methodology_documented,
                self.adversarial_testing_scope_cbrn,
                self.adversarial_testing_ai_office_reporting,
            ]),
            "incident_reporting_complete": all([
                self.incident_definition_documented,
                self.incident_reporting_timeline_defined,
                self.incident_commission_notification_format,
            ]),
            "cybersecurity_complete": all([
                bool(self.model_weight_protection_standard),
                self.training_infrastructure_security_baseline,
            ]),
            "energy_efficiency_complete": all([
                self.training_energy_reporting_format,
                self.eu_datacenter_location_disclosed,
            ]),
            "recommendation": (
                "Proceed with formal CoP adherence declaration" if score >= 0.85 else
                "Address identified gaps before formal adherence" if score >= 0.70 else
                "Significant preparation required — engage AI Office for guidance"
            ),
        }

Art.56 Compliance Checklist (40 Items)

Use this checklist to assess your organization's Art.56 compliance posture. Applicable to systemic risk GPAI providers, downstream integrators assessing upstream provider status, and legal/compliance teams.

Section 1: Scope Determination (Items 1–8)

• 1. Confirmed whether model meets Art.51(1)(a) systemic risk threshold (≥10^25 FLOPs cumulative training compute) — Art.56(3) mandatory minimums apply only to systemic risk tier
• 2. If Commission designation applies under Art.51(2), confirmed systemic risk status and Art.56 obligations
• 3. For general tier GPAI models: confirmed that Art.52 obligations apply but Art.56(3) mandatory minimums do not
• 4. Identified all GPAI models in scope for Art.56 across the organization's portfolio
• 5. Confirmed whether organization is a GPAI provider (Art.3(3)) or downstream provider for Art.56(2) participation purposes
• 6. For non-EU providers: confirmed whether Art.54 authorised representative is required in parallel with Art.56 CoP adherence
• 7. For downstream integrators: identified which upstream GPAI providers are subject to Art.56 obligations
• 8. Reviewed AI Office published list of CoPs in development and adequate CoPs

Section 2: CoP Participation (Items 9–16)

• 9. Engaged with AI Office under Art.56(1) to participate in CoP development or confirmed participation channel (industry association, working group)
• 10. Identified and registered as Art.56(2) participant (GPAI provider / downstream provider / civil society)
• 11. Assigned internal representative to CoP working group with authority to commit to compliance positions
• 12. Reviewed first draft GPAI Code of Practice (November 2024 AI Office publication)
• 13. Assessed whether existing practices meet draft CoP requirements — CoP gap analysis completed
• 14. For Art.56(5) voluntary early adoption: confirmed date of voluntary adoption and documented it
• 15. For CoPs under adequacy assessment: confirmed which obligations are covered and which are not yet adequate
• 16. For non-participating providers: documented alternative compliance pathway for each Art.53 obligation

Section 3: Art.56(3) Mandatory Content Coverage (Items 17–24)

• 17. Verified that CoP adhered to covers Art.53(1)(a) adversarial testing — methodology, scope, frequency
• 18. Confirmed CoP adversarial testing scope includes CBRN uplift risk assessment
• 19. Confirmed CoP adversarial testing scope includes cyber attack capability assessment
• 20. Verified that CoP adhered to covers Art.53(1)(b) serious incident reporting — definition, timeline, format
• 21. Confirmed CoP incident reporting covers downstream notification procedure (Art.55(2) information chain)
• 22. Verified that CoP adhered to covers Art.53(1)(c) cybersecurity measures — model weight protection, API security
• 23. Verified that CoP adhered to covers Art.53(1)(d) energy efficiency reporting — training compute, inference
• 24. Confirmed that Art.56(3) minimum content coverage is complete — all four elements addressed

Section 4: Conformity Presumption (Items 25–32)

• 25. Confirmed Commission adequacy assessment status for CoP adhered to (Art.56(4))
• 26. If CoP is adequate: formal adherence declaration signed and dated
• 27. Confirmed which specific Art.52–55 obligations are covered by the conformity presumption
• 28. Confirmed which obligations (if any) are NOT covered by the CoP — independent compliance required
• 29. Documented the basis for conformity presumption in the Art.11 technical documentation (Annex IV Section 4)
• 30. For Art.56(6) implementing acts: confirmed applicability and compliance with Commission-set standards
• 31. Monitoring process established for CoP updates — Art.56(1) CoP is a living instrument
• 32. Prepared for Art.56(4) reassessment if CoP is updated — conformity presumption may need renewal

Section 5: Infrastructure Jurisdiction and CLOUD Act (Items 33–40)

• 33. Identified infrastructure location for CoP adherence records (adversarial testing results, incident reports, cybersecurity documentation, energy data)
• 34. If records stored on US-incorporated provider infrastructure: CLOUD Act dual-compellability risk assessed
• 35. Considered migrating adversarial testing results to EU-sovereign infrastructure — highest sensitivity records under CoP
• 36. Considered migrating cybersecurity documentation to EU-sovereign infrastructure — second-highest sensitivity
• 37. For downstream integrators: upstream GPAI provider's CoP adherence status confirmed in Art.9 risk management file
• 38. For downstream integrators: upstream GPAI provider's infrastructure jurisdiction assessed as part of Art.9 risk
• 39. Art.56 conformity presumption status documented in Art.17 QMS compliance records
• 40. Enforcement scenario prepared: if conformity presumption challenged, documented evidence of CoP adherence and alternative compliance basis

Cross-Article Documentation Matrix

EU-Native Infrastructure and Art.56

For downstream AI system providers deploying on EU-native infrastructure — including sota.io (EU-established, Frankfurt/Germany datacenter, GDPR-by-design) — Art.56 creates a three-layer compliance argument:

Layer 1: Upstream CoP Risk Assessment

When your upstream GPAI API provider adheres to an adequate CoP, you receive:

• Standardized Art.53(1)(a) adversarial testing summaries (Art.55(2)) — your Art.9 risk file can reference these
• Standardized incident notification under CoP protocol — your Art.72 post-market monitoring plan can integrate this
• Energy consumption data in CoP-standard format — your sustainability reporting is simpler

Layer 2: Your Own Infrastructure Compliance

When your deployment infrastructure is EU-sovereign:

• CoP-standardized documentation received from upstream providers is stored in a single EU jurisdiction
• No CLOUD Act dual-compellability for your compliance records
• Auditors and market surveillance authorities can access your records through EU channels only

Layer 3: Downstream Enterprise Assurance

For enterprise customers who must demonstrate their own EU AI Act compliance chain:

• You can provide a clean Art.9 risk management file that includes upstream CoP status
• Your EU infrastructure choice documents the jurisdiction risk = LOW in your Art.9 file
• The complete Chapter V chain (Art.51 → Art.52 → Art.53 → Art.54 → Art.55 → Art.56) is traceable and documentable

See Also

• EU AI Act Art.53: GPAI Models with Systemic Risk — Adversarial Testing, Incident Reporting & Cybersecurity Developer Guide
• EU AI Act Art.52: GPAI Model General Obligations — Technical Documentation, Training Data & Copyright Developer Guide
• EU AI Act Art.55: Downstream Provider Obligations — What GPAI API Users Can Demand Developer Guide
• EU AI Act Art.51: GPAI Model Classification — Systemic Risk Threshold and Provider Obligations Developer Guide
• EU AI Act Art.13: Transparency Obligations — Instructions for Use and Chatbot Disclosure Developer Guide