EU AI Act Art.53(1)(d): Cybersecurity and Physical Infrastructure Protection for GPAI Systemic Risk Models (2026)

Art.53 of the EU AI Act imposes four obligations on providers of GPAI models with systemic risk. Three of those obligations — adversarial testing, risk assessment, and incident reporting — receive substantial attention in the GPAI Code of Practice Chapter 3 and in developer compliance guides. The fourth obligation, Art.53(1)(d), is consistently underexplored: the requirement to "ensure an adequate level of cybersecurity protection for the GPAI model with systemic risk and the physical infrastructure of the model."

This is not a minor supplement to adversarial testing. Art.53(1)(d) is a standalone statutory obligation that covers the security of the entire operational stack of a systemic risk GPAI model — from the data center housing the training compute to the inference API endpoints, from the protection of model weights as intellectual property to the integrity of the training data pipeline. The GPAI CoP Chapter 3 covers three cybersecurity measures (S-08 prompt injection, S-09 weight access control, S-10 anomaly monitoring) as part of the adversarial testing framework. Art.53(1)(d) is broader.

This guide covers what Art.53(1)(d) actually requires in operational terms, how it differs from Art.15 cybersecurity for high-risk AI, what "adequate" means in the absence of a fixed standard, and how to build a systemic risk GPAI security program that satisfies the obligation.

Art.53(1)(d) Scope: What Is Protected and Why

Art.53(1)(d) protects two categories of assets:

The GPAI model with systemic risk — the trained model artifact, its weights, its architecture documentation, and the inference stack that serves the model to downstream providers and end users.

The physical infrastructure of the model — the compute infrastructure used for training and inference, including co-location facilities, network connections, hardware acceleration systems, and the operational technology that supports the model's deployment.

The inclusion of "physical infrastructure" is deliberate and consequential. The EU legislature was aware that GPAI models represent high-value targets not just for capability-related misuse (addressed by Art.53(1)(a) adversarial testing) but for theft, sabotage, and intelligence collection. A GPAI model's weights represent years of compute investment and contain proprietary architectural knowledge. The infrastructure that runs frontier-scale models is a critical node in EU AI capacity. Both assets need protection under Art.53(1)(d).

What Art.53(1)(d) Does Not Cover

Art.53(1)(d) does not apply to:

• GPAI models below the 10^25 FLOPs systemic risk threshold that are not AI Office-designated
• High-risk AI systems that use GPAI models as upstream providers (these are covered by Art.15)
• Downstream providers using GPAI APIs (their cybersecurity obligations derive from their own product obligations, not Art.53)
• Non-AI infrastructure of the GPAI provider (general IT security, corporate network security)

Art.53(1)(d) vs Art.15: The Key Distinction

Art.15 of the EU AI Act addresses cybersecurity for high-risk AI systems. Art.53(1)(d) addresses cybersecurity for systemic risk GPAI models. These are different obligations with different scopes.

A GPAI model that is also a high-risk AI system (unusual but possible) would need to satisfy both Art.15 and Art.53(1)(d).

What "Adequate Cybersecurity Protection" Means in Practice

The EU AI Act does not define "adequate" for Art.53(1)(d). The AI Office's guidance on systemic risk GPAI compliance references the ENISA AI Security threat taxonomy (published 2023) and the GPAI CoP Chapter 3 cybersecurity measures as a floor. "Adequate" means security measures proportionate to:

1. The systemic risk designation itself — a 10^25 FLOPs model that triggered automatic designation faces a different threat environment than a borderline-designated model
2. The sensitivity of the capabilities — a model with demonstrated CBRN-uplift or cyberoffensive capabilities requires stronger protections than a model whose systemic risk is based on societal influence capabilities
3. The deployment context — inference-only cloud APIs face different threats than research environments where weights are more widely accessible
4. The state of the art in AI security — "adequate" evolves as the AI security field develops, requiring ongoing reassessment

The GPAI CoP Chapter 3 measures (S-08, S-09, S-10) represent the minimum floor. The Art.53(1)(d) obligation encompasses that floor plus the additional dimensions described below.

Physical Infrastructure Security

Art.53(1)(d) explicitly covers "the physical infrastructure of the model." This section maps what physical security requirements follow from that obligation.

Data Center and Facility Requirements

Tier classification: Training infrastructure and inference infrastructure for systemic risk GPAI models should meet at least Tier III data center standards (N+1 redundancy, 99.982% availability). The justification is two-fold: availability is a component of cybersecurity (denial-of-service attacks targeting inference infrastructure are a real threat vector for GPAI providers), and physical resilience reduces the attack surface for infrastructure compromise.

Physical access controls:

• All access to server rooms hosting GPAI training compute or inference infrastructure must require multi-factor authentication and be logged
• Unescorted access must be restricted to personnel with documented operational need
• Third-party access (hardware maintenance, facilities contractors) must follow visitor procedures with escorted access and documented visit logs
• Physical intrusion detection covering server rooms, power supply infrastructure, and network termination points

Hardware security:

• Server hardware for GPAI training and inference must be sourced through supply chains with documented integrity verification (preventing hardware implant attacks at the component level)
• TPM (Trusted Platform Module) attestation for inference servers — ensuring that the runtime environment matches the expected configuration before model weights are loaded
• Physical tamper evidence on hardware hosting model weights for inference

Network and power segregation:

• GPAI training infrastructure should be on a segregated network segment with no public internet access during training runs — reducing the attack surface for exfiltration during training
• Inference infrastructure may be internet-facing by necessity, but should be architecturally separated from training infrastructure
• Redundant power supply with UPS and generator backup — infrastructure sabotage via power disruption is a real threat model for high-value AI compute

CLOUD Act and EU-Sovereign Infrastructure

Physical infrastructure protection under Art.53(1)(d) intersects with a legal risk that is not purely a cybersecurity question: the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713).

The CLOUD Act authorizes US law enforcement to compel US persons and US-incorporated entities to produce data stored on servers located anywhere in the world — including EU-based data centers operated by US cloud providers. For GPAI model weights and training data stored in US-hyperscaler infrastructure (AWS, Azure, GCP), a US government order can require production of those assets to US authorities without an EU court process.

This creates a direct tension with Art.53(1)(d)'s physical infrastructure protection obligation:

The EU AI Act does not explicitly require EU-sovereign infrastructure for GPAI models. But the physical infrastructure protection obligation of Art.53(1)(d), combined with the CLOUD Act risk, creates a strong practical argument for EU-sovereign hosting. If model weights can be compelled to a foreign jurisdiction without EU authorization, the "physical infrastructure of the model" is not adequately protected against a specific category of legal/technical risk.

Model Weight Security: Beyond S-09

The GPAI CoP S-09 measure requires basic model weight access control — logical access restrictions, multi-person authorization for weight export, and audit logging. Art.53(1)(d) extends this floor.

Model Exfiltration Threat Model

Model weights for systemic risk GPAI models represent a threat category specific to frontier AI: exfiltration by a sophisticated adversary to replicate the model's capabilities. This threat differs from typical IP theft because:

• Model weights encode not just business value but potentially dangerous capabilities (CBRN uplift, cyberoffensive) that the EU AI Act aims to keep under governance controls
• A stolen copy of a systemic risk GPAI model is outside the Art.53 compliance framework — an adversary with a copy of GPT-5-equivalent weights is not subject to EU AI Act incident reporting or adversarial testing requirements
• Exfiltration can occur through legitimate API channels (model extraction attacks) or through infrastructure compromise

Exfiltration vectors for GPAI model weights:

Hardware Security Module (HSM) Integration

For the highest-sensitivity weight storage, Art.53(1)(d) physical infrastructure requirements point toward hardware security module (HSM) integration:

• Weight encryption at rest: Model weights stored on disk should be encrypted with keys stored in an HSM or TPM, not in software key stores
• Key derivation for inference: During inference, decryption keys are derived from hardware-attested state — a server that has been modified or is running in an unexpected configuration cannot obtain the decryption key
• Secure weight loading: Model weights are decrypted into memory within a Trusted Execution Environment (TEE) on attestation-capable hardware, preventing memory scraping attacks

This approach is used in practice by frontier AI providers for their most sensitive model artifacts. The CoP S-09 describes the policy requirement; TEE-based weight loading is one implementation path.

Model Extraction Attack Prevention

Model extraction attacks are a specific threat to GPAI providers that Art.53(1)(d) must address. Unlike infrastructure-based exfiltration, model extraction works entirely through the public inference API.

Model Extraction Taxonomy

Model distillation attacks: An attacker systematically queries the target GPAI model with a curated dataset and uses the outputs to train a smaller "student" model that approximates the target's behavior. For large enough query budgets, distillation can recover a substantial fraction of the target model's capabilities in specific domains. This attack is relevant for Art.53(1)(d) because the distilled model is not subject to Art.53 compliance obligations.

Membership inference attacks: An attacker queries the model with examples from the suspected training set to infer what data the model was trained on. This is relevant to Art.52 training data transparency obligations but also implicates Art.53(1)(d) as a privacy and data security threat.

Model inversion attacks: An attacker uses the model's outputs to reconstruct aspects of its training data. For GPAI models trained on sensitive data, this is both a privacy violation and an indicator that the model is inadvertently memorizing training data in a recoverable way.

API-Level Defenses

Rate limiting and query budget monitoring:

• Per-user and per-organization rate limits calibrated to legitimate use cases — high-volume systematic querying should trigger review
• Long-window query budget tracking: a user who stays under per-minute rate limits but accumulates a very high total query count over weeks should be flagged for review
• Query pattern analysis: systematic querying with structured inputs (gridded parameter variations, semantic similarity clusters) is a signature of model extraction and should trigger investigation

Output perturbation:

• Controlled randomness in outputs (temperature-based variation) reduces the quality of distilled models by introducing noise into the training signal
• Output perturbation must be balanced against API quality requirements — excessive noise degrades legitimate use

Query watermarking:

• For authorized research and downstream provider access to model weights or fine-tuning APIs, outputs can be watermarked with provider-specific signals
• Watermarks survive the distillation process and allow the original provider to prove provenance if a distilled model surfaces in the market
• The GPAI CoP Chapter 1 (Transparency) requires output labeling for AI-generated content; cryptographic watermarking at the model level goes further and enables provenance attribution

Training Pipeline Integrity

Art.53(1)(d) physical infrastructure protection extends to the training pipeline — not just the trained model artifact. A compromised training pipeline produces a compromised model.

Adversarial Data Injection (Data Poisoning)

If an attacker can inject adversarial data into the training corpus, they can embed backdoors or degrade specific capabilities in the resulting model. For internet-scale pretraining corpora, complete elimination of adversarial data is not feasible — but controls can significantly reduce the risk:

Data provenance tracking:

• Maintain an AI Bill of Materials (AIBOM) documenting the sources, collection methods, and filtering criteria for all training data
• Hash-based integrity verification: each data shard should have a stored hash that is verified before training runs
• Source attribution: for data collected from web sources, maintain logs of collection timestamps and source URLs to enable forensic analysis if a poisoning attack is suspected

Data pipeline integrity:

• All transformation steps between raw data collection and training-ready format should be logged and reproducible
• Code signing for data processing pipelines — unauthorized modifications to pipeline code should prevent pipeline execution
• Isolated execution environments for data processing — the pipeline that generates training data should not have access to production model weights or inference infrastructure

Training monitoring:

• Capability evaluation during training, not just post-training: systematic evaluation of the model's capabilities on holdout evaluation sets at regular intervals during training allows detection of unexpected capability emergence that might indicate data poisoning
• Training loss anomaly detection: unusual loss curves or sudden changes in training dynamics may indicate corrupted data batches

AI Vulnerability Disclosure Program

Art.53(1)(d) physical infrastructure protection implies a structured process for receiving and handling external reports of security vulnerabilities — an AI-specific Vulnerability Disclosure Program (AI VDP).

Traditional CVE-based vulnerability disclosure is designed for software flaws. GPAI security vulnerabilities include categories that have no direct CVE equivalent: prompt injection bypass techniques, capability-unlocking jailbreaks, output watermark removal methods, and model inversion attack vectors. An Art.53(1)(d)-compliant AI VDP should address:

Scope definition:

• In-scope: Novel prompt injection bypasses that circumvent S-08 controls; discovery of CBRN-relevant outputs that the S-01 adversarial testing did not detect; model extraction techniques that circumvent API defenses; infrastructure vulnerabilities in the GPAI provider's inference or training systems
• Out-of-scope: Complaints about model outputs that are within the model's intended behavior; general jailbreaks that do not demonstrate capability-level risk; legal or policy disputes

Reporter protection:

• Safe harbor for security researchers who discover and responsibly disclose vulnerabilities following the program's guidelines
• No legal action against researchers for testing within defined scope
• Acknowledgment of valid reports

Response timelines:

• Initial acknowledgment: 72 hours (mirroring the S-06 incident reporting window)
• Triage decision (valid vs. invalid, severity classification): 14 days
• Fix or mitigation: timeline depends on severity — critical vulnerabilities (capability-level risks in S-01 categories) should be addressed within 30 days
• Disclosure: coordinated disclosure after fix or mitigation, typically 90 days from report

Connection to S-05 Incident Reporting: A reported vulnerability that, when assessed, reveals that the vulnerability has already been exploited in production may trigger the S-05 serious incident classification process. The AI VDP team must have a clear escalation path to the incident response team.

Third-Party Security Audits

Art.53(1)(d) physical infrastructure protection requires that the provider not rely solely on internal security assessments. The standard of "adequate" cybersecurity for a systemic risk GPAI model implies third-party audit.

Audit scope for Art.53(1)(d) compliance:

• Physical data center audit: verification that physical access controls, hardware inventory, and network segregation meet documented requirements
• Weight access control audit: review of access logs, authorization records, and key management procedures
• Infrastructure architecture review: assessment of training/inference segregation, network security, and cloud provider jurisdiction risks
• Training pipeline integrity review: assessment of SBOM, data pipeline logging, and code signing practices
• API security assessment: penetration testing of inference API endpoints for model extraction and DDoS risks
• AI VDP effectiveness review: assessment of whether the vulnerability disclosure program is functioning

Audit frequency:

• Annual third-party audit for deployed systemic risk GPAI models
• Audit after material infrastructure changes (migration to new data center, significant architecture change, new cloud provider)
• Audit trigger: if an S-05 serious incident with cybersecurity root cause occurs, a targeted post-incident audit should be conducted as part of the corrective action plan

Audit documentation:

• Third-party audit reports are retained for five years
• Produced on request to the AI Office under Art.91 information requests
• Material findings that indicate systemic compliance failures may trigger AI Office investigation under Art.92

Python GPAISecurityObligationChecker

from dataclasses import dataclass, field
from enum import Enum
from typing import List, Optional
import json


class SystemicRiskBasis(Enum):
    FLOPS_THRESHOLD = "flops_threshold"        # Art.51(1)(a): >= 10^25 FLOPs
    AI_OFFICE_DESIGNATION = "ai_office_designation"  # Art.51(1)(b): AI Office designated


class InfrastructureType(Enum):
    US_HYPERSCALER_EU_REGION = "us_hyperscaler_eu_region"   # AWS/Azure/GCP EU: CLOUD Act risk
    EU_SOVEREIGN_CLOUD = "eu_sovereign_cloud"                 # EU-incorporated, no US parent
    ON_PREMISES_EU = "on_premises_eu"                         # Private EU infrastructure
    HYBRID = "hybrid"                                          # Mixed


class CapabilityRiskLevel(Enum):
    HIGH = "high"        # CBRN or cyberoffensive capabilities demonstrated
    MEDIUM = "medium"    # Societal influence or critical infrastructure risks
    LOW = "low"          # Systemic risk based on scale, not specific dangerous capabilities


@dataclass
class PhysicalInfrastructureProfile:
    infrastructure_type: InfrastructureType
    tier_level: int                          # Data center Tier (I-IV)
    has_tpm_attestation: bool                # TPM-based runtime attestation
    has_physical_access_logging: bool        # All physical access logged
    has_hardware_tamper_evidence: bool       # Tamper-evident hardware
    has_network_segregation: bool            # Training/inference network separation
    cloud_act_risk_mitigated: bool           # EU-sovereign or on-prem


@dataclass
class WeightSecurityProfile:
    has_hsm_encryption: bool                 # HSM/TPM-based key management
    has_multi_person_authorization: bool     # Weight export requires >1 person
    has_weight_access_audit_log: bool        # Full audit trail of weight access
    has_tee_inference: bool                  # TEE-based weight loading for inference
    has_aibom: bool                          # AI Bill of Materials for training data
    has_pipeline_code_signing: bool          # Signed training pipeline code


@dataclass
class APISecurityProfile:
    has_rate_limiting: bool
    has_long_window_query_monitoring: bool   # Multi-day query budget tracking
    has_extraction_pattern_detection: bool  # Model extraction query signature detection
    has_output_watermarking: bool            # Cryptographic output watermarking
    has_ddos_protection: bool


@dataclass
class GovernanceProfile:
    has_ai_vdp: bool                         # AI Vulnerability Disclosure Program
    has_third_party_audit: bool              # Annual third-party security audit
    last_audit_date: Optional[str]           # ISO date of last audit
    has_post_incident_audit_procedure: bool  # Audit trigger after serious incident


@dataclass
class Art53dComplianceGap:
    domain: str
    gap_description: str
    statutory_basis: str
    severity: str                            # critical / high / medium
    remediation: str


def assess_art53d_compliance(
    systemic_risk_basis: SystemicRiskBasis,
    capability_risk: CapabilityRiskLevel,
    infra: PhysicalInfrastructureProfile,
    weights: WeightSecurityProfile,
    api: APISecurityProfile,
    governance: GovernanceProfile,
) -> List[Art53dComplianceGap]:
    """
    Assess Art.53(1)(d) compliance gaps for a systemic risk GPAI provider.
    Returns list of identified gaps sorted by severity.
    """
    gaps: List[Art53dComplianceGap] = []

    # Physical infrastructure checks
    if infra.infrastructure_type == InfrastructureType.US_HYPERSCALER_EU_REGION \
            and not infra.cloud_act_risk_mitigated:
        gaps.append(Art53dComplianceGap(
            domain="physical_infrastructure",
            gap_description="Model weights and training data stored in US-hyperscaler "
                            "EU region are subject to CLOUD Act compulsion by US "
                            "government without EU legal process.",
            statutory_basis="Art.53(1)(d) — physical infrastructure of the model",
            severity="critical" if capability_risk == CapabilityRiskLevel.HIGH else "high",
            remediation="Migrate GPAI training and inference infrastructure to EU-sovereign "
                       "cloud provider (no US parent) or on-premises EU infrastructure.",
        ))

    if infra.tier_level < 3:
        gaps.append(Art53dComplianceGap(
            domain="physical_infrastructure",
            gap_description=f"Data center Tier {infra.tier_level} provides insufficient "
                            "availability and physical security for systemic risk GPAI "
                            "infrastructure.",
            statutory_basis="Art.53(1)(d) — adequate cybersecurity protection",
            severity="high",
            remediation="Upgrade to Tier III+ data center facilities with documented "
                       "physical access controls and availability SLA.",
        ))

    if not infra.has_tpm_attestation:
        gaps.append(Art53dComplianceGap(
            domain="physical_infrastructure",
            gap_description="Inference servers lack TPM-based runtime attestation, "
                            "preventing verification that model weights are loaded in "
                            "an expected, unmodified environment.",
            statutory_basis="Art.53(1)(d) — cybersecurity protection for GPAI model",
            severity="high",
            remediation="Implement TPM attestation for all inference servers hosting "
                       "systemic risk GPAI model weights.",
        ))

    # Model weight security checks
    if not weights.has_hsm_encryption:
        gaps.append(Art53dComplianceGap(
            domain="model_weight_security",
            gap_description="Model weights encrypted with software key stores — keys "
                            "are vulnerable to memory-scraping attacks and infrastructure "
                            "compromise.",
            statutory_basis="Art.53(1)(d) — cybersecurity protection for GPAI model",
            severity="high" if capability_risk == CapabilityRiskLevel.HIGH else "medium",
            remediation="Integrate HSM or TPM-based key management for weight encryption "
                       "keys. Implement TEE-based weight loading for inference.",
        ))

    if not weights.has_aibom:
        gaps.append(Art53dComplianceGap(
            domain="training_pipeline_integrity",
            gap_description="No AI Bill of Materials (AIBOM) documenting training data "
                            "sources, collection methods, and integrity hashes — cannot "
                            "verify training pipeline integrity or detect data poisoning.",
            statutory_basis="Art.53(1)(d) — physical infrastructure of the model "
                            "(training pipeline)",
            severity="high",
            remediation="Implement AIBOM with per-shard hash verification, source "
                       "attribution logging, and data pipeline code signing.",
        ))

    # API security checks
    if not api.has_extraction_pattern_detection:
        gaps.append(Art53dComplianceGap(
            domain="api_security",
            gap_description="No model extraction attack pattern detection — systematic "
                            "querying for model distillation or capability mapping is "
                            "not monitored.",
            statutory_basis="Art.53(1)(d) — cybersecurity protection for GPAI model",
            severity="high" if capability_risk == CapabilityRiskLevel.HIGH else "medium",
            remediation="Implement long-window query budget monitoring and model "
                       "extraction signature detection. Add output watermarking for "
                       "authorized downstream access.",
        ))

    # Governance checks
    if not governance.has_ai_vdp:
        gaps.append(Art53dComplianceGap(
            domain="governance",
            gap_description="No AI Vulnerability Disclosure Program — external security "
                            "researchers have no sanctioned channel to report novel "
                            "capability-level vulnerabilities.",
            statutory_basis="Art.53(1)(d) — adequate cybersecurity protection (standard "
                            "of care for systemic risk AI)",
            severity="medium",
            remediation="Establish AI VDP with defined scope (capability-level risks, "
                       "prompt injection bypasses, infrastructure vulnerabilities), "
                       "safe harbor for researchers, and escalation path to incident "
                       "response team.",
        ))

    if not governance.has_third_party_audit:
        gaps.append(Art53dComplianceGap(
            domain="governance",
            gap_description="No third-party security audit — 'adequate' cybersecurity "
                            "for systemic risk GPAI models requires independent "
                            "verification.",
            statutory_basis="Art.53(1)(d) — adequate cybersecurity protection",
            severity="high",
            remediation="Commission annual third-party security audit covering physical "
                       "infrastructure, weight access controls, training pipeline "
                       "integrity, and API security.",
        ))

    # Sort by severity
    severity_order = {"critical": 0, "high": 1, "medium": 2}
    gaps.sort(key=lambda g: severity_order.get(g.severity, 3))
    return gaps


# Example: EU-domiciled GPAI provider on US-hyperscaler infrastructure
gaps = assess_art53d_compliance(
    systemic_risk_basis=SystemicRiskBasis.FLOPS_THRESHOLD,
    capability_risk=CapabilityRiskLevel.HIGH,
    infra=PhysicalInfrastructureProfile(
        infrastructure_type=InfrastructureType.US_HYPERSCALER_EU_REGION,
        tier_level=3,
        has_tpm_attestation=False,
        has_physical_access_logging=True,
        has_hardware_tamper_evidence=False,
        has_network_segregation=True,
        cloud_act_risk_mitigated=False,  # US parent = CLOUD Act risk
    ),
    weights=WeightSecurityProfile(
        has_hsm_encryption=False,
        has_multi_person_authorization=True,
        has_weight_access_audit_log=True,
        has_tee_inference=False,
        has_aibom=False,
        has_pipeline_code_signing=False,
    ),
    api=APISecurityProfile(
        has_rate_limiting=True,
        has_long_window_query_monitoring=False,
        has_extraction_pattern_detection=False,
        has_output_watermarking=False,
        has_ddos_protection=True,
    ),
    governance=GovernanceProfile(
        has_ai_vdp=False,
        has_third_party_audit=False,
        last_audit_date=None,
        has_post_incident_audit_procedure=False,
    ),
)

for gap in gaps:
    print(f"[{gap.severity.upper()}] {gap.domain}: {gap.gap_description[:80]}...")

25-Item Art.53(1)(d) Compliance Checklist

Part A: Physical Infrastructure (Items 1–8)

• 1. Training and inference infrastructure hosted in facilities meeting Tier III+ data center standards
• 2. All physical access to GPAI infrastructure rooms logged with multi-factor authentication
• 3. TPM-based runtime attestation on inference servers before model weight loading
• 4. Hardware tamper evidence on servers hosting model weights
• 5. Network segregation between training infrastructure and inference infrastructure
• 6. Training networks isolated from public internet during training runs
• 7. Infrastructure jurisdiction assessed: CLOUD Act risk identified and documented
• 8. EU-sovereign infrastructure used for weight storage OR CLOUD Act risk formally accepted with documented mitigation strategy

Part B: Model Weight Security (Items 9–14)

• 9. Model weights encrypted at rest with keys in HSM or TPM (not software key store)
• 10. Weight export and download operations require multi-person authorization
• 11. Full audit log of all weight access, download, and transfer operations, retained ≥5 years
• 12. TEE-based weight loading for production inference (or documented alternative with equivalent protection)
• 13. Weight integrity verification: hash verification against training-output checksum before each deployment
• 14. Weight provenance chain documented from training output to production deployment

Part C: Training Pipeline Integrity (Items 15–18)

• 15. AI Bill of Materials (AIBOM) maintained with per-shard hash verification and source attribution
• 16. Data processing pipeline code is signed; unsigned modifications prevent pipeline execution
• 17. Training runs conducted in environments with no access to production model weights or inference infrastructure
• 18. Capability monitoring during training at regular intervals to detect unexpected capability emergence

Part D: API and Inference Security (Items 19–22)

• 19. Per-user and per-organization rate limits calibrated to legitimate use cases
• 20. Long-window query budget tracking (multi-day) with anomaly alerts for systematic querying
• 21. Model extraction query pattern detection: signature analysis for distillation and capability mapping attacks
• 22. Output watermarking for authorized downstream provider weight access or fine-tuning APIs

Part E: Governance (Items 23–25)

• 23. AI Vulnerability Disclosure Program (AI VDP) in place: defined scope, safe harbor, escalation path to incident response
• 24. Annual third-party security audit commissioned covering all Art.53(1)(d) dimensions
• 25. Post-serious-incident audit procedure: Art.53(1)(d) targeted audit triggered by any cybersecurity-root-cause serious incident

Common Art.53(1)(d) Implementation Mistakes

Mistake 1: Equating Art.53(1)(d) with GPAI CoP Chapter 3 cybersecurity measures

CoP Chapter 3 measures S-08, S-09, and S-10 are a floor, not a ceiling. They cover prompt injection, basic weight access control, and anomaly monitoring. Art.53(1)(d) covers physical infrastructure, model extraction defense, training pipeline integrity, and governance measures that are not addressed in Chapter 3. Meeting S-08 to S-10 does not fully satisfy Art.53(1)(d).

Mistake 2: Treating Art.53(1)(d) as equivalent to Art.15 high-risk AI cybersecurity

Art.15 is designed for the inference-time behavior of high-risk AI systems — resistance to adversarial inputs, robustness of outputs. Art.53(1)(d) covers the entire operational stack of a GPAI model provider including training infrastructure. The two obligations have different scopes, different threat models, and partially different technical controls.

Mistake 3: Assuming US-hyperscaler EU regions satisfy "physical infrastructure" protection

The EU AI Act does not explicitly prohibit US-hyperscaler infrastructure. But the CLOUD Act creates a jurisdiction gap that is directly relevant to Art.53(1)(d)'s physical infrastructure protection requirement. A risk acceptance decision to remain on US-hyperscaler infrastructure for systemic risk GPAI model weights must be documented, and the rationale must be defensible to the AI Office.

Mistake 4: No AI VDP because "we don't do bug bounties"

A traditional software bug bounty program is not the same as an AI VDP. The AI VDP is specifically scoped to capability-level vulnerabilities, novel jailbreaks that circumvent S-08 Chapter 3 controls, and infrastructure security reports. The safe harbor and reporting channel are part of the "adequate cybersecurity protection" standard for a systemic risk GPAI provider.

EU-Sovereign Infrastructure as Art.53(1)(d) Risk Reduction

sota.io is an EU-sovereign PaaS platform — incorporated and operated entirely within EU jurisdiction, with no US parent entity. For GPAI providers deploying inference infrastructure on sota.io:

CLOUD Act risk eliminated: sota.io is not a US person or entity subject to CLOUD Act jurisdiction. Model weights stored and inference workloads running on sota.io infrastructure cannot be compelled to US government under CLOUD Act, satisfying the physical infrastructure protection rationale of Art.53(1)(d).

Art.70 confidentiality protection: The EU AI Act's Art.70 confidentiality obligations for trade secrets in AI systems interact with physical infrastructure jurisdiction. EU-jurisdiction infrastructure means Art.70 protections are the applicable framework for any government access requests, not US compulsion procedures.

DORA Art.30(2)(e) alignment: For financial sector GPAI providers subject to both Art.53(1)(d) and DORA, Art.30(2)(e) contractual data location requirements align naturally with EU-sovereign GPAI infrastructure — satisfying both regulatory frameworks with a single infrastructure decision.

Related Posts

• GPAI CoP Chapter 3: Adversarial Testing, Red-Teaming, and Incident Reporting
• EU AI Act Art.53 GPAI Systemic Risk Obligations
• EU AI Act Art.15: Accuracy, Robustness, and Cybersecurity for High-Risk AI
• EU AI Act + DORA: Dual Compliance for Financial Sector AI Systems
• GPAI Code of Practice Final: Implementation Guide