EU AI Act Art.53 GPAI Models with Systemic Risk: Adversarial Testing, Incident Reporting & Cybersecurity — Developer Guide (2026)
EU AI Act Article 53 is the enhanced obligation tier for General-Purpose AI models with systemic risk. While Art.52 establishes baseline obligations for every GPAI provider — technical documentation, training data transparency, copyright compliance, and model cards — Art.53 adds four mandatory requirements that apply only when the systemic risk threshold is crossed: a formal adversarial testing program, mandatory serious incident reporting to the European Commission, cybersecurity measures protecting model weights and inference infrastructure, and energy efficiency reporting.
Art.53 became applicable on 2 August 2025 as part of Chapter V of the EU AI Act (Regulation (EU) 2024/1689). The systemic risk threshold — 10^25 FLOPs of cumulative training compute — is defined in Art.51 and places current frontier models (GPT-4 class and above, Gemini Ultra class, Claude Opus class) squarely within Art.53's scope. If you train, fine-tune at scale, or operate a GPAI model meeting the Art.51 systemic risk classification, Art.53 obligations are legally binding today.
For SaaS developers and infrastructure providers downstream of GPAI APIs, Art.53 is important for a different reason: it determines what adversarial testing results, incident notifications, and cybersecurity documentation your GPAI provider is legally required to hold — and what flows to you via Art.55 downstream obligations. Understanding Art.53 helps you evaluate the compliance posture of your AI dependencies.
Art.53 in the GPAI Obligation Cascade
Art.53 sits at the third article of Chapter V, applying only to the systemic risk tier established by Art.51(1)(b):
| Article | Title | Applies To |
|---|---|---|
| Art.51 | GPAI model classification | Defines systemic risk threshold (10^25 FLOPs) |
| Art.52 | General GPAI obligations | All GPAI providers — both tiers |
| Art.53 | Systemic risk obligations | Systemic risk tier only |
| Art.54 | Authorised representative | Non-EU systemic risk providers only |
| Art.55 | Downstream provider obligations | All GPAI providers — to downstream integrators |
| Art.56 | Code of practice | Systemic risk tier — compliance pathway |
The relationship between Art.52 and Art.53 is additive, not alternative. A GPAI model with systemic risk must comply with all of Art.52 (the baseline) plus all of Art.53 (the enhanced tier). There is no opt-out from Art.52 obligations because Art.53 applies.
Art.53 imposes four enhanced obligations:
- Art.53(1)(a) — Conduct and document adversarial testing (model evaluation, red-teaming) before placing the model on the market and throughout its lifecycle
- Art.53(1)(b) — Report serious incidents to the European Commission without undue delay upon awareness
- Art.53(1)(c) — Implement and maintain cybersecurity measures adequate to the systemic risk, protecting model weights, training infrastructure, and inference systems
- Art.53(1)(d) — Report energy consumption of model training and inference to the Commission and the AI Office
Art.53(1)(a): Adversarial Testing Program
Art.53(1)(a) requires GPAI model providers with systemic risk to "perform model evaluation in accordance with standardised protocols and tools and report the results to the AI Office." The legal term is model evaluation — the practical implementation is an adversarial testing program covering capability assessment and red-teaming.
What Art.53(1)(a) Requires
The obligation has two components: the testing itself, and the reporting of results to the AI Office.
Testing scope — Art.53(1)(a) does not specify a fixed test suite, but the AI Office's guidelines (developed under Art.56 Code of Practice) indicate that testing should address:
| Risk Category | Testing Focus | Why It Matters for Systemic Risk |
|---|---|---|
| CBRN (chemical, biological, radiological, nuclear) | Whether the model provides operational uplift for CBRN weapon creation, synthesis routes, or deployment guidance | Systemic risk by definition includes potential for mass harm — CBRN uplift is a core evaluand |
| Cyberattack capabilities | Ability to generate novel malware, exploit development, intrusion tooling | Frontier models with coding capabilities can potentially reduce the barrier to sophisticated cyberattacks |
| Manipulation and psychological harm | Large-scale influence operations, personalised manipulation at population scale, autonomous social engineering | GPAI models deployed at scale create unique manipulation surface area |
| Autonomous capabilities | Ability to operate autonomously in extended tasks, access external systems, self-replicate or self-modify | Agentic frontier models may exhibit emergent autonomous capabilities requiring specific testing |
Testing timing — Art.53(1)(a) requires testing both:
- Before market placement — pre-deployment evaluation is mandatory, not optional
- After significant updates — continuous evaluation obligation when capabilities change materially
Reporting requirement — Results must be reported to the AI Office (not just retained internally). The AI Office can request additional evaluations if the reported results are insufficient.
Art.53(1)(a) × Art.52(1)(a) Performance Evaluation
Art.52(1)(a) already requires general performance evaluation in technical documentation. Art.53(1)(a) is distinct:
| Dimension | Art.52(1)(a) — General Evaluation | Art.53(1)(a) — Adversarial Testing |
|---|---|---|
| Scope | Standard benchmark performance (MMLU, HarmBench, TruthfulQA, domain-specific) | Adversarial probes specifically targeting misuse capabilities |
| Adversarial dimension | Optional (encouraged, not required) | Mandatory — adversarial testing is the obligation |
| Reporting destination | Retained in technical documentation; provided to Commission on request (Art.52(2)) | Proactively reported to AI Office |
| Frequency | Updated when documentation is revised | Continuously — before market placement and after significant updates |
| Focus | Capabilities and limitations for downstream integrators | Systemic risk vectors — CBRN, cyber, manipulation, autonomy |
In practice, Art.52 evaluation tests normal capability; Art.53 evaluation tests capability under adversarial conditions specifically designed to probe misuse potential.
Art.53(1)(a) Red-Teaming: Implementation Structure
Effective adversarial testing programs for Art.53 compliance typically follow a structured methodology:
Phase 1: Capability Assessment
- Identify all model capabilities relevant to systemic risk categories
- Document the capability surface area: coding, instruction following, planning, tool use, agentic behavior, multimodal interpretation
- Establish capability baselines against which adversarial probes will be measured
Phase 2: Adversarial Probe Design
- Design probes targeting CBRN information retrieval (synthesis routes, precursor information, weaponisation guidance)
- Design probes targeting cyberattack support (exploit development, malware generation, vulnerability scanning automation)
- Design probes targeting manipulation (persuasion optimisation, persona-based social engineering, disinformation generation at scale)
- Design probes targeting autonomous behavior (goal-directed multi-step task execution, tool-use chains, self-directed resource acquisition)
Phase 3: Evaluation Execution
- Internal red team execution (first-party)
- Independent third-party red team (strongly recommended for Art.56 Code of Practice conformity)
- Document methodology, prompt corpus, evaluation criteria, and results
Phase 4: Documentation and Reporting
- Compile evaluation report: scope, methodology, results, residual risks, mitigation measures
- Report summary findings to AI Office via designated reporting channel
- Retain full evaluation documentation for Commission access (Art.52(2))
Art.53(1)(b): Serious Incident Reporting
Art.53(1)(b) requires GPAI model providers with systemic risk to "report to the Commission without undue delay after they become aware of any serious incident." This creates a proactive notification obligation that is distinct from (and potentially concurrent with) the Art.73 market surveillance notification for high-risk AI.
Defining "Serious Incident" in the GPAI Context
The EU AI Act defines "serious incident" for high-risk AI in Art.3(49). For GPAI models with systemic risk, the definition must be read in light of Art.51 systemic risk criteria — events that could cause the widespread, societal-scale harms that systemic risk classification targets.
A serious incident in the GPAI context would include:
| Category | Example | Why Notifiable |
|---|---|---|
| Mass harm | Model provides operational CBRN uplift that contributes to an attack causing death or serious injury to multiple people | Direct systemic harm causation |
| Critical infrastructure disruption | Model-generated exploit code used in attack that disrupts electricity grid, water system, or financial market | Systemic infrastructure impact |
| Large-scale fundamental rights violation | Model deployed at scale for population-level surveillance or automated discrimination affecting thousands | Rights dimension of systemic risk |
| Cascading model compromise | Security incident results in model weight extraction or training data exfiltration with systemic implications | Infrastructure security dimension |
| Autonomous harm | Agentic deployment causes uncontrolled real-world actions with serious consequences before human intervention possible | Autonomous risk dimension |
Art.53(1)(b) Reporting Timeline
The obligation is to report "without undue delay" after becoming aware of the incident. The AI Act does not specify an exact timeline for GPAI systemic risk incident reporting (contrast with Art.73 which specifies 15 working days for high-risk AI). However:
- Immediate awareness (direct notification or operator report): Report within 15 working days (consistent with Art.73 by analogy)
- Constructed awareness (discovered through monitoring): Report as soon as the incident is characterised and documented
- Ongoing incidents: Report initial notification promptly; update as new information becomes available
Art.53(1)(b) × Art.73: Dual Notification Structure
A serious incident involving a GPAI model with systemic risk may trigger notifications under both Art.53(1)(b) and Art.73:
| Notification | Recipient | Legal Basis | Timing |
|---|---|---|---|
| Art.53(1)(b) | European Commission (AI Office) | Art.53(1)(b) GPAI systemic risk obligation | Without undue delay |
| Art.73 | Market surveillance authority (national) | Art.73 serious incident reporting for high-risk AI | 15 working days |
If the GPAI model was deployed as a high-risk AI system (or embedded in one), both notifications may apply to the same incident. The Art.53(1)(b) notification goes to the AI Office (EU-level); the Art.73 notification goes to the national market surveillance authority where the incident occurred.
Practical implication: Incident response procedures for systemic risk GPAI models should contain two parallel notification tracks — one targeting the Commission/AI Office, one targeting applicable national authorities — triggered by the same incident classification event.
Art.53(1)(c): Cybersecurity Measures
Art.53(1)(c) requires GPAI model providers with systemic risk to "ensure an adequate level of cybersecurity protection for the GPAI model with systemic risk and the physical infrastructure of the model." This is a result-oriented obligation — the Act does not prescribe specific technical controls but requires protection adequate to the systemic risk.
What Must Be Protected
Art.53(1)(c) cybersecurity protection extends to:
| Asset Category | Protection Scope | Systemic Risk Rationale |
|---|---|---|
| Model weights | Unauthorised access, exfiltration, or modification of trained model parameters | Weight extraction enables adversarial capability cloning; weight modification enables backdoor injection |
| Training infrastructure | Systems used for model training, fine-tuning, and alignment procedures | Compromise during training can introduce undetectable vulnerabilities or alter alignment properties |
| Training data | Unauthorised access to or modification of training datasets | Data poisoning attacks can affect model behaviour at population scale |
| Inference infrastructure | Systems serving model outputs to end users and downstream integrators | Inference-time attacks (adversarial prompts at scale, API abuse) can extract capabilities or circumvent safety measures |
| Model cards and documentation | Documentation required under Art.52(1)(b) distributed to downstream providers | Documentation integrity is required for Art.55 downstream compliance chain |
Cybersecurity Measures Adequate to Systemic Risk
"Adequate to the systemic risk" means the protection level should be commensurate with the potential harm if the protected asset is compromised. For systemic risk GPAI models, this is a high bar:
Model weight protection:
- Encryption at rest (AES-256 or equivalent) for stored checkpoints
- Strict access control — weight access limited to operationally necessary personnel
- Audit logging for all weight access events
- Anomaly detection on access patterns
- Export controls preventing bulk weight exfiltration
Training infrastructure security:
- Network segmentation isolating training clusters from public-facing infrastructure
- Supply chain security for ML framework dependencies (confirmed compromised ML libraries have been observed in the wild)
- Hardware-level integrity verification for training accelerators
- Insider threat monitoring during training runs
Inference infrastructure security:
- Rate limiting and anomaly detection to identify capability extraction attempts
- Prompt injection defences (critical for agentic or tool-using deployments)
- Monitoring for adversarial input patterns targeting safety mitigations
- Incident response runbook for API-layer attacks
Jurisdiction note: If training or inference infrastructure runs on US cloud providers (AWS, Azure, GCP), the CLOUD Act creates a parallel access vector — US government compelled access can reach model weights, training data, and inference logs stored on US infrastructure regardless of EU data residency commitments. Art.53(1)(c) cannot be fully satisfied if a single compelled access order could extract the protected assets. EU-native infrastructure removes this structural vulnerability.
Art.53(1)(d): Energy Efficiency Reporting
Art.53(1)(d) requires GPAI model providers with systemic risk to "document and report to the Commission and the national competent authorities, upon request, information about the energy consumption of the GPAI model with systemic risk." This is a transparency obligation — reporting energy use, not reducing it (though reduction is encouraged by Recital 93).
Energy Efficiency Metrics for GPAI Models
| Metric | Definition | Measurement Point |
|---|---|---|
| Training compute | Total FLOPs consumed in the primary training run | Accumulated across all training stages (pre-training + post-training) |
| Energy per training run | kWh consumed during the primary training run | Measured at hardware level, documented per compute cluster |
| Inference energy per query | watt-hours consumed per 1,000 tokens or per API call | Measured under standardised load conditions |
| Carbon intensity | gCO2eq per kWh for the electricity consumed | Depends on grid mix of data centre location |
| Hardware utilisation | Average GPU/TPU utilisation during training | Affects energy efficiency — low utilisation wastes energy per effective FLOP |
EU-native infrastructure advantage: Data centres in EU member states with high renewable energy mix (Nordic countries: ~95% renewable; Germany ~50%+; France ~70%+ nuclear) produce lower carbon intensity per kWh than equivalent infrastructure in regions with coal-heavy grids. Art.53(1)(d) reporting will reflect infrastructure location — EU-native training has a compliance narrative advantage.
Art.53 × Art.52: Baseline vs. Enhanced Obligations
| Obligation | Art.52 (All GPAI) | Art.53 (Systemic Risk) |
|---|---|---|
| Technical documentation | ✅ Required — Annex XI | ✅ Required (Art.52 inherited) + adversarial testing results |
| Training data transparency | ✅ Required | ✅ Required (Art.52 inherited) |
| Copyright compliance policy | ✅ Required | ✅ Required (Art.52 inherited) |
| Machine-readable model card | ✅ Required | ✅ Required (Art.52 inherited) |
| Adversarial testing program | ❌ Not required | ✅ Required — Art.53(1)(a) |
| AI Office reporting of test results | ❌ Not required | ✅ Required — Art.53(1)(a) |
| Serious incident reporting | ❌ Not required | ✅ Required — Art.53(1)(b) |
| Cybersecurity measures | ❌ Not explicitly required | ✅ Required — Art.53(1)(c) |
| Energy consumption reporting | ❌ Not required | ✅ Required — Art.53(1)(d) |
| Commission documentation access | ✅ On request (Art.52(2)) | ✅ On request + ongoing reporting |
Art.53 × Art.56: Code of Practice as Compliance Pathway
Art.56 establishes a Code of Practice for GPAI models with systemic risk. The Code is being developed under the oversight of the AI Office with participation from GPAI model providers, downstream integrators, and civil society. Art.56(2) creates a presumption of conformity: if a GPAI provider adheres to a Code of Practice approved by the Commission, the provider is presumed to comply with Art.53 obligations (to the extent the Code addresses them).
Practical implications for Art.53 compliance:
| Art.53 Obligation | Code of Practice Coverage | Presumption Effect |
|---|---|---|
| Art.53(1)(a) adversarial testing | Covered — testing protocols, evaluation suites, reporting formats | Adherence to Code testing protocols creates Art.53(1)(a) conformity presumption |
| Art.53(1)(b) incident reporting | Covered — incident classification criteria, reporting format, timeline | Adherence to Code incident reporting procedures creates Art.53(1)(b) conformity presumption |
| Art.53(1)(c) cybersecurity | Partially covered — minimum security measures defined | Adherence creates partial conformity presumption; implementation details remain provider responsibility |
| Art.53(1)(d) energy reporting | Covered — standardised energy reporting format | Adherence to Code reporting format creates Art.53(1)(d) conformity presumption |
Code of Practice participation: Art.56(3) allows GPAI providers to participate in the Code drafting process. For providers developing compliance programs now, engaging with the AI Office Code of Practice working group provides early visibility into what "adequate" will formally mean for each Art.53 obligation.
CLOUD Act × Art.53: The Dual Compellability Problem
Art.53 creates compliance records that have high sensitivity from a jurisdictional perspective:
| Art.53 Record Type | CLOUD Act Access Risk | Mitigation |
|---|---|---|
| Adversarial test results (Art.53(1)(a)) | US government subpoena can compel test results revealing model weaknesses and safety mitigations — intelligence value | Store adversarial test documentation on EU-jurisdictional infrastructure only |
| Serious incident reports (Art.53(1)(b)) | Reports to Commission are EU regulatory records — but copies stored on US infrastructure are CLOUD Act accessible | Incident management systems on EU-native infrastructure; Commission submission via EU-regulated channel |
| Cybersecurity measure documentation (Art.53(1)(c)) | Security documentation describes model protection architecture — exposure to adversarial states is a security risk | Security documentation on air-gapped or EU-only systems |
| Energy consumption data (Art.53(1)(d)) | Lower sensitivity, but training compute documentation reveals model scale and investment levels | Standard EU data residency controls sufficient |
| Model weights (Art.53(1)(c) protected asset) | If stored on US cloud, CLOUD Act compelled access can extract weights — precisely the asset Art.53(1)(c) requires to be protected | EU-native weight storage is the only structural defence |
The intersection of Art.53(1)(c) (protect model weights) and CLOUD Act (compelled production of data on US infrastructure) creates a structural conflict: storing model weights on US cloud infrastructure means the asset Art.53(1)(c) requires to be protected is simultaneously exposed to a legal compelled access mechanism. The only architecturally sound solution is EU-native weight storage.
Python Implementation
SystemicRiskAdversarialTestRecord
from dataclasses import dataclass, field
from datetime import date, datetime
from enum import Enum
from typing import Optional
import json
class RiskCategory(Enum):
CBRN = "cbrn"
CYBER = "cyber_attack_capability"
MANIPULATION = "manipulation_psychological_harm"
AUTONOMOUS = "autonomous_harmful_behavior"
OTHER = "other_systemic_risk"
class TestingPhase(Enum):
PRE_DEPLOYMENT = "pre_deployment"
POST_SIGNIFICANT_UPDATE = "post_significant_update"
PERIODIC_ONGOING = "periodic_ongoing"
TRIGGERED_BY_INCIDENT = "triggered_by_incident"
@dataclass
class AdversarialTestResult:
risk_category: RiskCategory
probe_count: int
uplift_detected: bool
uplift_severity: Optional[str] # "none" | "marginal" | "significant" | "substantial"
mitigation_in_place: bool
mitigation_description: Optional[str]
evaluator: str # "internal" | "third_party:{firm_name}"
evaluation_date: date
@dataclass
class SystemicRiskAdversarialTestRecord:
"""Art.53(1)(a) adversarial testing compliance record."""
provider_name: str
model_name: str
model_version: str
testing_phase: TestingPhase
test_start_date: date
test_end_date: date
methodology_description: str
results: list[AdversarialTestResult] = field(default_factory=list)
third_party_evaluator: Optional[str] = None
ai_office_reported: bool = False
ai_office_report_date: Optional[date] = None
report_reference: Optional[str] = None
def add_result(self, result: AdversarialTestResult) -> None:
self.results.append(result)
def any_significant_uplift(self) -> bool:
return any(
r.uplift_detected and r.uplift_severity in ("significant", "substantial")
for r in self.results
)
def unmitigated_risks(self) -> list[AdversarialTestResult]:
return [r for r in self.results if r.uplift_detected and not r.mitigation_in_place]
def validate_art53_compliance(self) -> list[str]:
gaps = []
if not self.results:
gaps.append("Art.53(1)(a): No adversarial test results recorded")
if not self.third_party_evaluator:
gaps.append("Art.53(1)(a): No independent third-party evaluator engaged (recommended for Code of Practice conformity)")
if self.testing_phase == TestingPhase.PRE_DEPLOYMENT and not self.test_end_date:
gaps.append("Art.53(1)(a): Pre-deployment testing not completed — required before market placement")
if not self.ai_office_reported:
gaps.append("Art.53(1)(a): Results not yet reported to AI Office")
categories_tested = {r.risk_category for r in self.results}
required_categories = {RiskCategory.CBRN, RiskCategory.CYBER, RiskCategory.MANIPULATION}
missing = required_categories - categories_tested
if missing:
gaps.append(f"Art.53(1)(a): Risk categories not tested: {[c.value for c in missing]}")
if self.unmitigated_risks():
cats = [r.risk_category.value for r in self.unmitigated_risks()]
gaps.append(f"Art.53(1)(a): Unmitigated uplift detected in: {cats}")
return gaps
def to_ai_office_report(self) -> dict:
return {
"provider": self.provider_name,
"model": self.model_name,
"version": self.model_version,
"testing_phase": self.testing_phase.value,
"test_period": {
"start": self.test_start_date.isoformat(),
"end": self.test_end_date.isoformat() if self.test_end_date else None
},
"methodology": self.methodology_description,
"third_party_evaluator": self.third_party_evaluator,
"results_summary": [
{
"category": r.risk_category.value,
"probes_evaluated": r.probe_count,
"uplift_detected": r.uplift_detected,
"uplift_severity": r.uplift_severity,
"mitigated": r.mitigation_in_place,
}
for r in self.results
],
"overall_assessment": "pass" if not self.unmitigated_risks() else "conditional_pass_with_mitigations",
}
SeriousIncidentReport
from dataclasses import dataclass, field
from datetime import date, timedelta
from enum import Enum
from typing import Optional
class IncidentCategory(Enum):
MASS_HARM = "mass_harm_death_serious_injury"
CRITICAL_INFRA = "critical_infrastructure_disruption"
RIGHTS_VIOLATION = "large_scale_fundamental_rights_violation"
SECURITY_BREACH = "model_security_breach_exfiltration"
AUTONOMOUS_HARM = "autonomous_model_harm"
OTHER = "other_systemic_harm"
class NotificationStatus(Enum):
IDENTIFIED = "identified"
UNDER_INVESTIGATION = "under_investigation"
REPORTED_AI_OFFICE = "reported_ai_office"
REPORTED_MSA = "reported_market_surveillance_authority"
CLOSED = "closed"
@dataclass
class SeriousIncidentReport:
"""Art.53(1)(b) serious incident reporting record."""
incident_id: str
provider_name: str
model_name: str
awareness_date: date
incident_date: Optional[date]
incident_category: IncidentCategory
incident_description: str
affected_scope: str # description of scale and affected parties
harm_type: str # actual or potential harm description
caused_by_model: bool # direct causal link vs. contributing factor
contributing_factor: bool # model contributed but not sole cause
# Notification tracking
ai_office_notification_date: Optional[date] = None
ai_office_report_reference: Optional[str] = None
msa_notification_date: Optional[date] = None
msa_authority_name: Optional[str] = None
# Mitigation
immediate_action_taken: Optional[str] = None
root_cause: Optional[str] = None
corrective_measures: list[str] = field(default_factory=list)
status: NotificationStatus = NotificationStatus.IDENTIFIED
def reporting_deadline(self) -> date:
"""Art.53(1)(b): 'without undue delay' — 15 working days by analogy with Art.73."""
return self.awareness_date + timedelta(days=21) # ~15 working days
def is_overdue(self) -> bool:
return (
self.ai_office_notification_date is None
and date.today() > self.reporting_deadline()
)
def dual_notification_required(self) -> bool:
"""True if both Art.53(1)(b) (AI Office) and Art.73 (MSA) notification may apply."""
return self.incident_category in (
IncidentCategory.MASS_HARM,
IncidentCategory.CRITICAL_INFRA,
IncidentCategory.RIGHTS_VIOLATION,
)
def validate_reporting_completeness(self) -> list[str]:
gaps = []
if self.ai_office_notification_date is None:
if self.is_overdue():
gaps.append(f"Art.53(1)(b): OVERDUE — AI Office notification not submitted (deadline: {self.reporting_deadline().isoformat()})")
else:
gaps.append(f"Art.53(1)(b): AI Office notification pending (deadline: {self.reporting_deadline().isoformat()})")
if self.dual_notification_required() and self.msa_notification_date is None:
gaps.append("Art.73: Market surveillance authority notification may also be required for this incident category")
if not self.immediate_action_taken:
gaps.append("Art.53(1)(b): No immediate action documented — required in incident report")
return gaps
def to_commission_notification(self) -> dict:
return {
"incident_id": self.incident_id,
"provider": self.provider_name,
"model": self.model_name,
"awareness_date": self.awareness_date.isoformat(),
"incident_date": self.incident_date.isoformat() if self.incident_date else "unknown",
"category": self.incident_category.value,
"description": self.incident_description,
"affected_scope": self.affected_scope,
"harm_type": self.harm_type,
"causal_link": "direct" if self.caused_by_model else "contributing_factor",
"immediate_action": self.immediate_action_taken,
"status": self.status.value,
}
CybersecurityMeasureTracker
from dataclasses import dataclass, field
from datetime import date
from enum import Enum
from typing import Optional
class ProtectedAsset(Enum):
MODEL_WEIGHTS = "model_weights"
TRAINING_INFRASTRUCTURE = "training_infrastructure"
TRAINING_DATA = "training_data"
INFERENCE_INFRASTRUCTURE = "inference_infrastructure"
MODEL_DOCUMENTATION = "model_documentation_art52"
class SecurityControlStatus(Enum):
IMPLEMENTED = "implemented"
IN_PROGRESS = "in_progress"
PLANNED = "planned"
NOT_APPLICABLE = "not_applicable"
GAP = "gap_no_control"
@dataclass
class SecurityControl:
asset: ProtectedAsset
control_name: str
description: str
status: SecurityControlStatus
implementation_date: Optional[date] = None
responsible_team: Optional[str] = None
last_tested: Optional[date] = None
cloud_jurisdiction: Optional[str] = None # "EU" | "US" | "mixed"
@dataclass
class CybersecurityMeasureTracker:
"""Art.53(1)(c) cybersecurity measures compliance tracker."""
provider_name: str
model_name: str
last_review_date: date
controls: list[SecurityControl] = field(default_factory=list)
def add_control(self, control: SecurityControl) -> None:
self.controls.append(control)
def gaps(self) -> list[SecurityControl]:
return [c for c in self.controls if c.status == SecurityControlStatus.GAP]
def us_infrastructure_exposure(self) -> list[SecurityControl]:
"""Identify controls where CLOUD Act exposure exists."""
return [
c for c in self.controls
if c.cloud_jurisdiction in ("US", "mixed")
and c.asset in (ProtectedAsset.MODEL_WEIGHTS, ProtectedAsset.TRAINING_INFRASTRUCTURE)
]
def validate_art53_compliance(self) -> list[str]:
gaps = []
assets_with_controls = {c.asset for c in self.controls if c.status == SecurityControlStatus.IMPLEMENTED}
required_assets = {
ProtectedAsset.MODEL_WEIGHTS,
ProtectedAsset.TRAINING_INFRASTRUCTURE,
ProtectedAsset.INFERENCE_INFRASTRUCTURE,
}
uncovered = required_assets - assets_with_controls
if uncovered:
gaps.append(f"Art.53(1)(c): No implemented controls for: {[a.value for a in uncovered]}")
for gap_control in self.gaps():
gaps.append(f"Art.53(1)(c): GAP — {gap_control.asset.value}: {gap_control.control_name}")
cloud_act_risks = self.us_infrastructure_exposure()
if cloud_act_risks:
assets = [c.asset.value for c in cloud_act_risks]
gaps.append(
f"Art.53(1)(c) × CLOUD Act: Protected assets on US infrastructure — CLOUD Act compelled access undermines protection: {assets}. "
"Recommendation: migrate to EU-native infrastructure."
)
return gaps
def compliance_summary(self) -> dict:
total = len(self.controls)
implemented = sum(1 for c in self.controls if c.status == SecurityControlStatus.IMPLEMENTED)
return {
"provider": self.provider_name,
"model": self.model_name,
"review_date": self.last_review_date.isoformat(),
"total_controls": total,
"implemented": implemented,
"coverage_pct": round(implemented / total * 100, 1) if total else 0,
"gaps_count": len(self.gaps()),
"cloud_act_exposure_count": len(self.us_infrastructure_exposure()),
}
Art.53 Compliance Checklist (40 Items)
Adversarial Testing Program — Art.53(1)(a)
- Art.53-1 — Adversarial testing program formally established before market placement
- Art.53-2 — Testing scope defined: CBRN risk category covered by dedicated probes
- Art.53-3 — Testing scope defined: cyber attack capability category covered
- Art.53-4 — Testing scope defined: manipulation and psychological harm category covered
- Art.53-5 — Testing scope defined: autonomous harmful behaviour category covered
- Art.53-6 — Testing methodology documented: probe design, evaluation criteria, scoring
- Art.53-7 — Internal red team execution completed with results documented
- Art.53-8 — Independent third-party evaluator engaged for pre-deployment testing
- Art.53-9 — Third-party evaluator independence verified (no material conflict of interest)
- Art.53-10 — All significant mitigation measures triggered by testing results documented
Adversarial Testing — AI Office Reporting
- Art.53-11 — Testing results summary prepared in AI Office-compatible format
- Art.53-12 — Pre-deployment testing results reported to AI Office before market placement
- Art.53-13 — Post-update testing process defined — triggering events for re-evaluation specified
- Art.53-14 — Ongoing evaluation schedule defined for deployed model lifecycle
Serious Incident Reporting — Art.53(1)(b)
- Art.53-15 — Incident classification criteria defined — what constitutes a "serious incident" in operational context
- Art.53-16 — Incident detection and escalation procedures operational
- Art.53-17 — Art.53(1)(b) notification pathway to AI Office established (contact point, format)
- Art.53-18 — Reporting timeline SLA defined — aligned with "without undue delay" requirement
- Art.53-19 — Dual notification assessment procedure in place (Art.53(1)(b) + Art.73 check)
- Art.53-20 — Incident register maintained with all reported and investigated incidents
- Art.53-21 — Post-incident review process defined — root cause analysis and corrective measures
- Art.53-22 — Incident response runbook tested at least annually
Cybersecurity Measures — Art.53(1)(c)
- Art.53-23 — Model weight encryption at rest implemented (AES-256 or equivalent)
- Art.53-24 — Model weight access control implemented — least-privilege enforcement
- Art.53-25 — Audit logging for model weight access operational
- Art.53-26 — Training infrastructure network segmentation implemented
- Art.53-27 — ML framework dependency supply chain security controls in place
- Art.53-28 — Inference API rate limiting and anomaly detection operational
- Art.53-29 — Prompt injection defences implemented for agentic deployments
- Art.53-30 — Model extraction attempt detection deployed and monitored
- Art.53-31 — Cybersecurity measure review scheduled at minimum annually
- Art.53-32 — CLOUD Act infrastructure exposure assessed — EU-native infrastructure used for weight storage
Energy Efficiency — Art.53(1)(d)
- Art.53-33 — Training compute documented in FLOPs per training run
- Art.53-34 — Training energy documented in kWh per training run
- Art.53-35 — Inference energy benchmarked: kWh per 1,000 tokens or per API call under standardised load
- Art.53-36 — Carbon intensity documented: gCO2eq/kWh for training and inference data centres
- Art.53-37 — Energy reporting format aligned with AI Office standardised format (Art.56 Code of Practice)
- Art.53-38 — Energy reporting production procedure defined for Commission/authority requests
Art.52 Baseline Compliance (Prerequisite)
- Art.53-39 — All Art.52 baseline obligations confirmed: technical documentation, training data transparency, copyright compliance, model card
- Art.53-40 — Art.52 documentation updated to include Art.53 adversarial testing results and cybersecurity measures summary
See Also
- EU AI Act Art.52 GPAI Model General Obligations: Technical Documentation, Training Data & Copyright — Developer Guide (2026)
- EU AI Act Art.51 GPAI Model Classification: Systemic Risk Threshold and Provider Obligations — Developer Guide (2026)
- EU AI Office & GPAI Model Regulation: Developer Guide (EU AI Act Art.51-56)
- EU AI Act Article 15 Accuracy, Robustness and Cybersecurity: Developer Guide (High-Risk AI 2026)
- EU AI Act 2026: Conformity Assessment Guide for PaaS and SaaS Developers