EU AI Act Art.53: Additional Obligations for Providers of GPAI Models with Systemic Risk — Adversarial Testing, Incident Reporting, and Cybersecurity (2026)

Art.52 establishes the baseline obligations for every GPAI model provider on the EU market. Article 53 adds a second tier: four enhanced obligations that apply only to providers whose models cross the Art.51 systemic risk threshold. If Art.51 is the classification gate, Art.53 is what happens after you walk through it.

The four obligations — adversarial testing, incident reporting, cybersecurity measures, and energy efficiency reporting — reflect the EU legislature's judgment that frontier AI models warrant regulatory requirements beyond documentation and transparency. Unlike Art.52's primarily informational obligations, Art.53's requirements demand ongoing operational programs: recurring testing cycles, active incident monitoring, and real security infrastructure. These are not one-time compliance checklists but sustained compliance regimes.

Art.53 became applicable on 2 August 2025 as part of Chapter V of the EU AI Act (Regulation (EU) 2024/1689). Current frontier models — those with cumulative training compute exceeding 10²⁵ FLOPs — fall within Art.53's scope today.

The Two-Tier GPAI Obligation Structure

Before examining Art.53's specific requirements, it is essential to understand where Art.53 sits in the GPAI regulatory architecture.

The EU AI Act creates a layered obligation structure for GPAI providers:

Tier 1 — Art.52 (all GPAI providers):

• Technical documentation under Annex XI
• Downstream information package under Annex XII
• Copyright compliance policy with opt-out mechanism
• Training data transparency summary
• Open-source model exemption conditions

Tier 2 — Art.53 (systemic risk GPAI providers only):

• Adversarial testing program (Art.53(1)(a))
• Serious incident reporting (Art.53(1)(b))
• Cybersecurity measures (Art.53(1)(c))
• Energy efficiency reporting (Art.53(1)(d))

The tiering is cumulative: systemic risk providers must fulfil all of Art.52 and all of Art.53. The Art.52 obligations are not waived or replaced — they are a floor on which Art.53 adds further requirements.

The threshold determination is also cumulative. A provider qualifying for systemic risk classification (Art.51(1)(a): cumulative training compute > 10²⁵ FLOPs, or Art.51(1)(b): Commission decision on equivalent capabilities) must immediately comply with both Art.52 and Art.53. The Art.51 classification is not a future event requiring regulatory action — it is self-executing on meeting the threshold.

Art.53(1)(a): Adversarial Testing

The first Art.53 obligation requires systemic risk GPAI providers to conduct adversarial testing of the model. The text of Art.53(1)(a) requires providers to:

"perform model evaluation in accordance with standardised protocols and tools reflecting the state of the art, including conducting and documenting adversarial testing of the model with a view to identifying and mitigating systemic risks"

What Adversarial Testing Means Under Art.53

Adversarial testing under Art.53 is a structured evaluation process designed to probe model behaviour in ways that standard benchmarks do not capture. The key characteristics:

State-of-the-art requirement: The testing must reflect current best practice. This is a dynamic standard — as evaluation methodologies improve, the compliance floor rises. Providers cannot lock in an evaluation methodology approved in 2025 and rely on it indefinitely.

Standardised protocols: Art.53(1)(a) explicitly references "standardised protocols and tools." The AI Office is responsible under Art.55 for developing and publishing these protocols. Until AI Office protocols are finalised, providers are expected to apply recognised industry methodologies (NIST AI Risk Management Framework evaluations, Anthropic's Constitutional AI evaluation suite, MLCommons safety benchmarks, structured red-teaming protocols).

Systemic risk focus: The adversarial testing requirement is specifically aimed at identifying and mitigating "systemic risks" — the same risks that trigger the Art.51 classification. This creates a feedback loop: the characteristics that place a model in the Art.53 tier are the characteristics that adversarial testing must probe.

What Adversarial Testing Must Cover

While Art.53(1)(a) does not enumerate specific test categories, the recitals and the AI Office's early guidance documents indicate adversarial testing should address:

Misuse potential:

• Capability elicitation for CBRN (chemical, biological, radiological, nuclear) applications.
• Jailbreak resistance — systematic attempts to circumvent safety training.
• Dual-use content generation at scale.
• Autonomous agent behaviour when given access to tools or APIs.

Systemic harm scenarios:

• Information hazard generation: detailed instructions for dangerous activities.
• Disinformation production capabilities at scale.
• Discriminatory output patterns across protected characteristic groups.
• Reinforcement of dangerous social dynamics.

Infrastructure risk:

• Adversarial prompt injection in agentic deployments.
• Model behaviour under data poisoning conditions.
• Cross-modal attack vectors (text-to-image, text-to-code exploit generation).

Documentation Requirements for Adversarial Testing

Art.53(1)(a) requires providers to both conduct and document adversarial testing. Documentation must include:

• Testing methodology and protocol description.
• Scope of testing: which capabilities, scenarios, and risk categories were evaluated.
• Testing team composition: internal teams, external red-teamers, AI Office evaluators (Art.55(2)).
• Findings: vulnerabilities identified, severity classification, and reproduction details.
• Mitigations applied: technical and procedural responses to findings.
• Residual risks: findings not fully mitigated and rationale for residual acceptance.
• Test dates and model versions tested.

This documentation serves multiple purposes: it constitutes the compliance record for AI Office inspections under Art.55, it informs the risk management framework, and it provides the evidentiary basis for incident reporting if testing reveals risks that later materialise.

Red-Teaming as Industry Practice

Adversarial testing is already standard practice at frontier AI labs. Anthropic's model cards document structured red-team evaluations. OpenAI conducts third-party red-teaming before major releases. Google DeepMind applies systematic evaluation frameworks for Gemini models. Art.53(1)(a) gives these practices legal force and EU regulatory structure.

The key difference from voluntary practice: Art.53 testing must be documented for regulatory review, must apply standardised protocols (not purely internal methodologies), and must occur on an ongoing basis — not only before model release.

AI Office Cooperation in Adversarial Testing

Art.55(2) gives the AI Office the power to conduct "its own model evaluation" and to require providers to cooperate in evaluations. This extends to adversarial testing: the AI Office can require a provider to make model weights, inference access, or internal evaluation results available for AI Office evaluation programs. The AI Office evaluation is additive — it does not replace the provider's own adversarial testing obligation.

Art.53(1)(b): Serious Incident Reporting

The second Art.53 obligation requires systemic risk GPAI providers to report serious incidents to the AI Office:

"assess and possibly mitigate systemic risks at Union level that may stem from the development, placing on the market, or use of general-purpose AI models with systemic risk"

Art.53(1)(b) specifically requires providers to:

"assess and possibly mitigate systemic risks at Union level, including their sources, and, where possible, report to the AI Office any serious incidents or malfunctions, along with possible corrective measures"

What Constitutes a "Serious Incident" Under Art.53

Art.3(49) defines "serious incident" as an incident or malfunction that directly or indirectly leads to, or may reasonably lead to:

• Death or serious harm to health.
• Significant disruption to critical infrastructure.
• Irreversible large-scale property damage.
• Serious and irreversible societal harm at scale.

For GPAI models with systemic risk, the specific relevance is in the "societal harm at scale" category. A serious incident under Art.53(1)(b) could include:

Direct harm incidents:

• Model outputs that directly caused physical harm (e.g., dangerous medical advice followed by a patient).
• Model-assisted attacks on critical infrastructure.
• Large-scale discriminatory outcomes in high-stakes contexts.

Indirect/structural incidents:

• Discovery that the model can reliably generate effective CBRN synthesis instructions (even without a specific harm event).
• Evidence of coordinated misuse at scale that the provider becomes aware of.
• Detection of systemic discriminatory patterns with significant impact.
• Security breaches exposing model weights to adversarial actors.

Malfunction categories:

• Model capability changes not anticipated by safety training (capability elicitation via fine-tuning by downstream providers).
• Safety system failures allowing systematic bypass of guardrails.
• Agentic deployments exhibiting unanticipated autonomous harmful behaviour.

Incident Reporting Workflow

Art.53(1)(b) requires reporting "as soon as possible after the provider has knowledge of the serious incident." This creates a constructive knowledge standard: providers must have monitoring systems capable of detecting relevant incidents.

The reporting workflow should be designed as:

Detection: Continuous monitoring of deployment contexts, user reports, internal testing results, and downstream provider communications. Detection should not be limited to direct provider deployments — the provider must build feedback channels with downstream integrators.

Assessment: Upon detection of a potential serious incident, immediate triage to determine whether the Art.3(49) serious incident threshold is met. This assessment should involve legal, safety, and technical teams.

Notification to AI Office: Notification as soon as the provider reasonably concludes a serious incident has occurred or may have occurred. Art.53(1)(b) does not prescribe a specific notification deadline, but the "as soon as possible" standard implies hours to days, not weeks.

Corrective measures: Alongside the notification, providers should document and — where possible — implement corrective measures: model updates, deployment restrictions, safety layer adjustments, or operational mitigations.

Follow-up reporting: The AI Office may request additional information or follow-up reports on corrective measure effectiveness.

Art.53(1)(b) and the Art.87 Reporting Channel

Art.87 provides the general incident reporting framework for high-risk AI systems. GPAI providers subject to Art.53(1)(b) report directly to the AI Office (not national market surveillance authorities), reflecting the cross-border nature of frontier GPAI model deployments and the AI Office's specific mandate over GPAI.

This creates a parallel structure: deployers of high-risk AI systems built on GPAI models may have their own Art.87 obligations to national authorities, while the GPAI provider has a separate Art.53(1)(b) obligation to the AI Office. The two reporting obligations are independent.

Art.53(1)(c): Cybersecurity Measures

The third Art.53 obligation requires providers to implement and maintain cybersecurity protections:

"ensure an adequate level of cybersecurity protection for the general-purpose AI model with systemic risk and the physical infrastructure of the model"

Why Cybersecurity Is a Tier-2 Obligation

Cybersecurity appears in Art.53 rather than Art.52 because model weights for frontier systems represent critical intellectual and security assets. The theft of or unauthorised access to frontier model weights creates systemic risks:

Proliferation risk: Exfiltrated model weights can be deployed without safety controls by malicious actors, creating the exact "systemic risk" Art.53 is designed to address.

Adversarial fine-tuning: Stolen weights can be fine-tuned to remove safety layers, circumvent copyright compliance, or enable capabilities the original training specifically sought to exclude.

Infrastructure access: Access to inference infrastructure via compromised credentials enables misuse at scale without requiring model weight theft.

Supply chain attacks: Compromised training pipelines can introduce backdoors or capability alterations that are not detectable in the final model.

What "Adequate Level of Cybersecurity" Requires

Art.53(1)(c) does not specify particular technical controls. "Adequate" must be assessed against the model's risk profile and the current state of cybersecurity best practice. Relevant frameworks include:

Model weight protection:

• Encryption at rest and in transit for model weights.
• Access control systems with least-privilege principles for weight access.
• Audit logging of all weight access events.
• Secure multi-party computation for distributed training pipelines.
• Hardware security modules for model signing and integrity verification.

Inference infrastructure:

• Network segmentation isolating inference infrastructure from general enterprise networks.
• Intrusion detection and prevention systems monitoring inference endpoints.
• Rate limiting and anomaly detection on API access patterns.
• Zero-trust architecture for internal service communications.
• Regular penetration testing of inference APIs and supporting infrastructure.

Training pipeline security:

• Supply chain security for training data: provenance verification, integrity checking.
• Dependency scanning for training frameworks and tooling.
• Build system security: reproducible builds, signed artefacts.
• Insider threat controls: background checks, access reviews, separation of duties.

Incident response:

• Documented incident response plan covering model weight exfiltration scenarios.
• Security monitoring with SIEM integration.
• Threat intelligence sharing with AI Office and relevant CERTs.

Art.53(1)(c) and NIS2 Overlap

Frontier AI model providers operating in the EU may also be subject to the NIS2 Directive (Directive (EU) 2022/2555) as providers of digital services. The cybersecurity requirements under NIS2 Art.21 overlap with Art.53(1)(c). Providers subject to both frameworks should implement a unified cybersecurity program that satisfies both. The more stringent requirement in any given area controls.

Specifically, NIS2 Art.21 requires "appropriate and proportionate technical, operational and organisational measures" covering risk assessment, incident handling, supply chain security, network security, access control, and encryption. This aligns closely with what Art.53(1)(c) demands for GPAI model infrastructure.

Art.53(1)(d): Energy Efficiency Reporting

The fourth Art.53 obligation addresses energy consumption transparency:

"keep and make available to the AI Office, on request, documentation of the energy consumption of the model"

Scope and Content of Energy Reporting

Art.53(1)(d) requires documentation of energy consumption, not reduction to specific targets. The obligation is transparency-oriented: the AI Office must have visibility into the energy profile of frontier models as part of its systemic risk oversight function.

Documentation should cover:

Training energy:

• Total compute consumed in training: FLOPs, GPU-hours, hardware specifications.
• Data centre locations and power usage effectiveness (PUE) for training runs.
• Estimated carbon footprint of training (provider estimates or third-party verification).

Inference energy:

• Average energy per query at current deployment scale.
• Total inference energy per month across all deployments.
• Regional distribution of inference capacity and associated carbon intensity.

Fine-tuning and evaluation:

• Energy consumed in fine-tuning operations conducted or facilitated by the provider.
• Energy profile of adversarial testing and evaluation programs (Art.53(1)(a)).

Energy Reporting and the Broader EU Green Deal Context

Art.53(1)(d) reflects the EU's broader commitment to digital sustainability under the European Green Deal and the Digital Decade Policy Programme. The energy documentation requirement positions the AI Office to monitor the aggregate energy impact of frontier AI deployments in the EU market — information that may inform future delegated acts under Art.97 or energy efficiency standards.

Providers should anticipate that energy reporting will become more structured over time as the AI Office develops standardised reporting templates.

Art.53(2): Code of Practice as Compliance Pathway

Art.53(2) creates an important compliance mechanism: participation in a Code of Practice (Art.56) can constitute evidence of compliance with Art.53 obligations.

Art.56 empowers the AI Office to facilitate the development of voluntary Codes of Practice by frontier AI providers, academic institutions, civil society, and other stakeholders. A Code of Practice that addresses adversarial testing methodologies, incident reporting procedures, cybersecurity standards, and energy reporting formats provides:

Operational specificity: The Art.53 obligations are deliberately framework-level. A Code of Practice translates them into specific technical requirements, timelines, and procedures.

Safe harbour signal: While the EU AI Act does not formally create a Code of Practice "safe harbour," adherence to a recognised Code of Practice that has been validated by the AI Office creates a strong presumption of compliance.

Industry coordination: Codes of Practice allow providers to align on common testing protocols, incident classification criteria, and reporting formats — reducing compliance costs while maintaining regulatory standards.

The AI Office published a first draft of the GPAI Code of Practice in November 2024, with subsequent drafts in early 2025. Participation in the Code of Practice development process is a direct engagement pathway with the Art.53 compliance framework.

Art.53 × Art.54: AI Office Assistance and Scientific Panel

Art.54 establishes the role of the Scientific Panel of Independent Experts in supporting the AI Office's GPAI oversight functions. The Scientific Panel is relevant to Art.53 in several ways:

Adversarial testing guidance: The Scientific Panel can develop state-of-the-art guidance on adversarial testing methodologies, directly informing what "reflecting the state of the art" means under Art.53(1)(a).

Systemic risk assessment: The Panel advises the AI Office on systemic risk assessments, including whether specific model capabilities or incidents meet the Art.53(1)(b) serious incident threshold.

Technical standards: The Panel can contribute to standardised protocols referenced in Art.53(1)(a), serving as the expert body validating protocol quality.

Model evaluation: Art.55(2) empowers the AI Office to conduct model evaluations; the Scientific Panel provides technical expertise for those evaluations, which can intersect with the provider's own adversarial testing program.

Art.53 × Art.55: AI Office Powers of Enforcement

Art.55 gives the AI Office specific powers vis-à-vis systemic risk GPAI providers. Understanding Art.55 is essential for Art.53 compliance planning:

Information requests (Art.55(1)): The AI Office can request providers to provide documentation, access to model weights, internal test results, training data samples, and other information relevant to assessing Art.53 compliance.

Model evaluations (Art.55(2)): The AI Office can conduct its own model evaluations or require providers to cooperate in third-party evaluations. This extends the adversarial testing ecosystem beyond the provider's own program.

Temporary restrictions (Art.55(4)): Where a provider fails to comply with Art.53 obligations, the AI Office can recommend that the Commission restrict the model's availability in the EU market — a significant enforcement power that underscores the seriousness of Art.53 compliance.

Coordination with national authorities: Art.55 also creates coordination channels between the AI Office and national competent authorities for GPAI model oversight, relevant where GPAI models are used in high-risk AI systems regulated at the national level.

Python Implementation: SystemicRiskComplianceManager

The following implementation provides a structured framework for managing Art.53 compliance obligations:

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


class IncidentSeverity(Enum):
    SERIOUS = "serious"          # Art.53(1)(b) threshold met
    POTENTIAL = "potential"      # Under assessment
    BELOW_THRESHOLD = "below"   # Does not meet Art.3(49) criteria


class TestingStatus(Enum):
    SCHEDULED = "scheduled"
    IN_PROGRESS = "in_progress"
    COMPLETE = "complete"
    FINDINGS_OPEN = "findings_open"


@dataclass
class AdversarialTestRecord:
    """Art.53(1)(a) adversarial testing documentation."""
    test_id: str = field(default_factory=lambda: str(uuid.uuid4()))
    model_version: str = ""
    protocol_name: str = ""           # e.g., "MLCommons Safety v1.0", "AI Office Protocol Draft v2"
    test_scope: list[str] = field(default_factory=list)  # capability areas tested
    team_composition: list[str] = field(default_factory=list)  # internal, external red-team, AI Office
    start_date: Optional[date] = None
    completion_date: Optional[date] = None
    status: TestingStatus = TestingStatus.SCHEDULED
    findings: list[dict] = field(default_factory=list)  # [{id, severity, description, mitigated}]
    residual_risks: list[str] = field(default_factory=list)
    mitigations_applied: list[str] = field(default_factory=list)

    def is_compliant(self) -> bool:
        if self.status != TestingStatus.COMPLETE:
            return False
        open_critical = [f for f in self.findings
                        if f.get("severity") == "critical" and not f.get("mitigated")]
        return len(open_critical) == 0

    def to_documentation(self) -> dict:
        return {
            "test_id": self.test_id,
            "model_version": self.model_version,
            "protocol": self.protocol_name,
            "scope": self.test_scope,
            "team": self.team_composition,
            "period": {
                "start": str(self.start_date),
                "end": str(self.completion_date)
            },
            "findings_summary": {
                "total": len(self.findings),
                "mitigated": sum(1 for f in self.findings if f.get("mitigated")),
                "residual": len(self.residual_risks),
            },
            "compliant": self.is_compliant(),
        }


@dataclass
class SeriousIncidentReport:
    """Art.53(1)(b) incident reporting record."""
    report_id: str = field(default_factory=lambda: str(uuid.uuid4()))
    incident_date: Optional[datetime] = None
    detection_date: Optional[datetime] = None
    report_date: Optional[datetime] = None
    severity: IncidentSeverity = IncidentSeverity.POTENTIAL
    description: str = ""
    affected_scope: str = ""        # geographic/user scope
    systemic_risk_type: str = ""    # e.g., "CBRN capability elicitation", "critical infra disruption"
    corrective_measures: list[str] = field(default_factory=list)
    ai_office_notified: bool = False
    follow_up_required: bool = False
    resolution_date: Optional[date] = None

    def reporting_delay_hours(self) -> Optional[float]:
        if self.detection_date and self.report_date:
            delta = self.report_date - self.detection_date
            return delta.total_seconds() / 3600
        return None

    def is_timely(self, max_hours: float = 72.0) -> Optional[bool]:
        delay = self.reporting_delay_hours()
        if delay is None:
            return None
        return delay <= max_hours


@dataclass
class CybersecurityControl:
    """Art.53(1)(c) cybersecurity measure record."""
    control_id: str = field(default_factory=lambda: str(uuid.uuid4()))
    control_category: str = ""  # weight_protection, inference_security, training_pipeline, incident_response
    control_name: str = ""
    implementation_date: Optional[date] = None
    last_tested: Optional[date] = None
    status: str = "active"       # active, pending, remediation_needed
    testing_frequency_days: int = 90
    notes: str = ""

    def needs_retest(self, as_of: Optional[date] = None) -> bool:
        check_date = as_of or date.today()
        if not self.last_tested:
            return True
        days_since = (check_date - self.last_tested).days
        return days_since >= self.testing_frequency_days


@dataclass
class EnergyReport:
    """Art.53(1)(d) energy efficiency documentation."""
    reporting_period_start: Optional[date] = None
    reporting_period_end: Optional[date] = None
    training_flops: Optional[float] = None
    training_gpu_hours: Optional[float] = None
    training_kwh: Optional[float] = None
    inference_kwh_per_query: Optional[float] = None
    inference_total_kwh_monthly: Optional[float] = None
    datacenter_locations: list[str] = field(default_factory=list)
    average_pue: Optional[float] = None
    carbon_footprint_training_kgco2: Optional[float] = None
    methodology: str = ""


class SystemicRiskComplianceManager:
    """
    Art.53 compliance framework for GPAI models with systemic risk.
    Manages adversarial testing records, incident reports, cybersecurity
    controls, and energy efficiency documentation.
    """

    def __init__(self, model_name: str, model_version: str):
        self.model_name = model_name
        self.model_version = model_version
        self.adversarial_tests: list[AdversarialTestRecord] = []
        self.incidents: list[SeriousIncidentReport] = []
        self.cybersecurity_controls: list[CybersecurityControl] = []
        self.energy_reports: list[EnergyReport] = []

    # Art.53(1)(a) methods

    def register_adversarial_test(self, test: AdversarialTestRecord) -> str:
        self.adversarial_tests.append(test)
        return test.test_id

    def latest_adversarial_test(self) -> Optional[AdversarialTestRecord]:
        completed = [t for t in self.adversarial_tests
                     if t.status == TestingStatus.COMPLETE]
        if not completed:
            return None
        return max(completed, key=lambda t: t.completion_date or date.min)

    def adversarial_testing_current(self, max_age_days: int = 365) -> bool:
        latest = self.latest_adversarial_test()
        if not latest or not latest.completion_date:
            return False
        age = (date.today() - latest.completion_date).days
        return age <= max_age_days and latest.is_compliant()

    # Art.53(1)(b) methods

    def register_incident(self, incident: SeriousIncidentReport) -> str:
        self.incidents.append(incident)
        return incident.report_id

    def pending_notifications(self) -> list[SeriousIncidentReport]:
        return [i for i in self.incidents
                if i.severity == IncidentSeverity.SERIOUS and not i.ai_office_notified]

    def untimely_reports(self, max_hours: float = 72.0) -> list[SeriousIncidentReport]:
        return [i for i in self.incidents
                if i.ai_office_notified and i.is_timely(max_hours) is False]

    # Art.53(1)(c) methods

    def add_cybersecurity_control(self, control: CybersecurityControl) -> str:
        self.cybersecurity_controls.append(control)
        return control.control_id

    def controls_needing_retest(self) -> list[CybersecurityControl]:
        return [c for c in self.cybersecurity_controls if c.needs_retest()]

    def cybersecurity_coverage(self) -> dict:
        required_categories = {
            "weight_protection", "inference_security",
            "training_pipeline", "incident_response"
        }
        covered = {c.control_category for c in self.cybersecurity_controls
                  if c.status == "active"}
        missing = required_categories - covered
        return {
            "covered": list(covered),
            "missing": list(missing),
            "coverage_complete": len(missing) == 0,
        }

    # Compliance summary

    def compliance_summary(self) -> dict:
        return {
            "model": f"{self.model_name} v{self.model_version}",
            "art_53_1_a_adversarial_testing": {
                "compliant": self.adversarial_testing_current(),
                "tests_conducted": len(self.adversarial_tests),
                "latest_test": (
                    str(self.latest_adversarial_test().completion_date)
                    if self.latest_adversarial_test() else None
                ),
            },
            "art_53_1_b_incident_reporting": {
                "pending_notifications": len(self.pending_notifications()),
                "total_incidents": len(self.incidents),
                "untimely_reports": len(self.untimely_reports()),
            },
            "art_53_1_c_cybersecurity": self.cybersecurity_coverage(),
            "art_53_1_d_energy": {
                "reports_filed": len(self.energy_reports),
                "latest_period": (
                    str(self.energy_reports[-1].reporting_period_end)
                    if self.energy_reports else None
                ),
            },
        }

Art.53 Compliance Checklist

Interaction with Art.52: Baseline vs Enhanced Obligations

The Art.52 obligations and Art.53 obligations function as complementary layers, not alternatives:

Art.52 establishes:

• Documentation for regulators (Annex XI)
• Information for downstream providers (Annex XII)
• Copyright compliance policy
• Training data transparency summary

Art.53 adds:

• Active testing program (operational, ongoing)
• Live incident reporting channel (event-driven)
• Security infrastructure requirements (technical controls)
• Energy consumption documentation (ongoing reporting)

The distinction is between static compliance (producing documents at model launch) and dynamic compliance (operating programs that run continuously after launch). Art.53 transforms GPAI compliance from a pre-market activity into an ongoing operational responsibility.

See Also

• EU AI Act Art.52: Obligations for Providers of GPAI Models — Documentation, Copyright, Transparency
• EU AI Act Art.51: Classification of GPAI Models with Systemic Risk — The 10²⁵ FLOPs Threshold
• EU AI Act Art.50: Transparency Obligations — Chatbot Disclosure and AI-Generated Content Labeling