EU AI Act + CRA Dual Compliance: When Your AI System Is Also a Cyber Product

Post #1 in the EU AI Act + CRA Dual Compliance Developer Series (5 posts)

Two major EU regulations converge on the same software product in 2026 and 2027: the EU AI Act (high-risk AI provisions: August 2, 2026) and the Cyber Resilience Act (CRA: December 11, 2027). If you are building an AI system that is also a "product with digital elements" — which describes almost every commercial AI SaaS — both apply simultaneously. Yet most compliance roadmaps treat them as separate workstreams, missing substantial overlap that can reduce your compliance burden by 30–40%.

This series maps the intersection. Post 1 establishes which products fall under both and where the frameworks reinforce or conflict.

Who Triggers Both Regulations

EU AI Act Scope: Art.6 + Annex III High-Risk AI

The EU AI Act imposes its heaviest obligations on high-risk AI systems defined in Art.6 and Annex III. These include AI used in:

• Biometric identification and categorisation (Annex III §1)
• Management of critical infrastructure (Annex III §2)
• Education and vocational training — scoring and assessment systems (Annex III §3)
• Employment, worker management, access to self-employment (Annex III §4)
• Access to essential private and public services — creditworthiness, insurance risk assessment (Annex III §5)
• Law enforcement (Annex III §6)
• Migration, asylum and border control management (Annex III §7)
• Administration of justice and democratic processes (Annex III §8)

If your AI system falls into any Annex III category, you are a high-risk AI provider with obligations under Art.9–17 and a CE marking deadline of August 2, 2026.

CRA Scope: Art.2 + Art.12 High-Risk AI Systems

The CRA covers all products with digital elements (Art.2) — which includes software products with a remote data processing component. This scope captures virtually all commercial SaaS platforms.

CRA Art.12 is the critical provision: It explicitly addresses high-risk AI systems. Where a product with digital elements is also a high-risk AI system under the EU AI Act, the CRA's essential cybersecurity requirements (Annex I) apply in addition to the AI Act's Art.15 requirements. The CRA does not substitute AI Act obligations — it layers additional ones.

from dataclasses import dataclass
from enum import Enum

class RegulatoryScope(Enum):
    AI_ACT_ONLY = "ai_act_only"
    CRA_ONLY = "cra_only"
    DUAL_REGULATED = "dual_regulated"
    NEITHER = "neither"

@dataclass
class ProductClassification:
    product_name: str
    is_ai_system: bool           # EU AI Act Art.3 definition
    is_high_risk_ai: bool        # Annex III category
    has_digital_elements: bool   # CRA Art.2 scope
    has_remote_processing: bool  # CRA Art.2(1) — software with remote data component

def classify_product(p: ProductClassification) -> RegulatoryScope:
    """
    Classify a product for EU AI Act + CRA dual compliance scope.
    CRA Art.12: high-risk AI systems trigger additional cybersecurity requirements.
    """
    ai_act_applies = p.is_ai_system and p.is_high_risk_ai
    cra_applies = p.has_digital_elements and p.has_remote_processing
    
    if ai_act_applies and cra_applies:
        return RegulatoryScope.DUAL_REGULATED
    elif ai_act_applies:
        return RegulatoryScope.AI_ACT_ONLY
    elif cra_applies:
        return RegulatoryScope.CRA_ONLY
    return RegulatoryScope.NEITHER

# Example: HR screening AI SaaS
hr_ai_saas = ProductClassification(
    product_name="AutoRecruitAI",
    is_ai_system=True,
    is_high_risk_ai=True,      # Annex III §4: employment/worker management
    has_digital_elements=True,
    has_remote_processing=True  # Cloud-hosted SaaS
)
print(classify_product(hr_ai_saas))  # DUAL_REGULATED

The Dual-Regulated Product Matrix

Where the Two Frameworks Overlap

Cybersecurity Requirements: Art.15 ↔ CRA Annex I

EU AI Act Art.15 requires high-risk AI systems to be designed with appropriate levels of accuracy, robustness, and cybersecurity — specifically resilience against adversarial attacks, data poisoning, model evasion, and confidentiality attacks.

CRA Annex I lists essential cybersecurity requirements covering: secure by default design, minimal attack surface, confidentiality protections, data integrity, system security logging, vulnerability handling, and update mechanisms.

The overlap is substantial. A cybersecurity threat model that satisfies AI Act Art.15 can be structured to simultaneously satisfy CRA Annex I §1–8 with minor additions. The key divergence: AI Act Art.15 is AI-attack-specific (adversarial ML, model extraction), while CRA Annex I covers broader software security (dependency vulnerabilities, supply chain).

Practical approach: Build one unified cybersecurity requirements document that maps each control to both Art.15 and the relevant CRA Annex I paragraph. This counts as evidence for both conformity assessments.

Technical Documentation: Annex IV ↔ CRA Art.31

EU AI Act Annex IV requires technical documentation covering: general description, design specifications, training/validation/testing data, monitoring and functioning plan, and risk management evidence.

CRA Art.31 requires technical documentation covering: product description, design and production information, essential requirements compliance evidence, cybersecurity assessment results, and vulnerability disclosure policy.

Structural overlap: ~60% of content. A joint technical documentation package can satisfy both requirements with the following structure:

TechnicalDocumentationPackage/
├── 01_product_description.md          # AI Act Annex IV §1 + CRA Art.31(1)(a)
├── 02_design_specifications/
│   ├── architecture.md                # AI Act Annex IV §1(b) + CRA Art.31(1)(b)
│   └── ai_model_specifications.md    # AI Act Annex IV §1(c) — AI-specific
├── 03_risk_management/
│   ├── ai_risks.md                   # AI Act Art.9 + Annex IV §2(a)
│   └── cybersecurity_risks.md        # CRA Annex I + Art.31(1)(c) — CRA-specific
├── 04_testing_validation/
│   ├── accuracy_robustness.md        # AI Act Art.15 + Annex IV §5
│   └── security_testing.md          # CRA Annex I §13 + Art.31(1)(d)
├── 05_monitoring/
│   ├── post_market_monitoring.md     # AI Act Art.72 + Annex IV §8
│   └── vulnerability_disclosure.md  # CRA Art.14 + Art.31(1)(e)
└── 06_declarations/
    ├── eu_declaration_ai_act.md      # AI Act Art.47
    └── eu_declaration_cra.md        # CRA Art.28

Incident Reporting: Art.73 ↔ CRA Art.14

This is the most operationally critical overlap. Both regulations require incident notification, with different timelines and different recipients.

EU AI Act Art.73 (serious incidents for high-risk AI):

• Threshold: incidents causing death, serious harm, significant disruption of critical infrastructure, or serious fundamental rights violations
• Timeline: providers notify national market surveillance authority "without undue delay" (implementing acts specify exact windows — currently modelled on NIS2: 24h initial / 72h intermediate)
• Recipient: national market surveillance authority (NCA)

CRA Art.14 (vulnerability and incident notification):

• Threshold: actively exploited vulnerability OR incident with significant impact on security of the product
• Timeline: 24h early warning → 72h notification → final report within 14 days
• Recipient: ENISA + national CSIRT

Key insight: A single security incident in your dual-regulated AI product may trigger both Art.73 (NCA) and CRA Art.14 (ENISA + CSIRT) simultaneously, with different timelines and different content requirements. Your incident response runbook must fork at triage: does this incident involve AI system behavior (→ AI Act Art.73) or a vulnerability exploit (→ CRA Art.14)?

from enum import Enum, auto
from dataclasses import dataclass
from datetime import datetime, timedelta

class IncidentType(Enum):
    AI_SERIOUS_INCIDENT = auto()   # Art.73 trigger
    CRA_SECURITY_INCIDENT = auto() # CRA Art.14 trigger
    DUAL_INCIDENT = auto()         # Both — adversarial attack causing serious harm

@dataclass
class IncidentReport:
    incident_type: IncidentType
    detected_at: datetime
    
    def get_reporting_deadlines(self) -> dict:
        """Returns reporting obligations for dual-regulated incident."""
        deadlines = {}
        
        if self.incident_type in (IncidentType.AI_SERIOUS_INCIDENT, 
                                   IncidentType.DUAL_INCIDENT):
            # EU AI Act Art.73: notify NCA without undue delay
            deadlines["AI_ACT_NCA_INITIAL"] = self.detected_at + timedelta(hours=24)
            deadlines["AI_ACT_NCA_FULL"] = self.detected_at + timedelta(hours=72)
            deadlines["AI_ACT_NCA_FINAL"] = self.detected_at + timedelta(days=30)
        
        if self.incident_type in (IncidentType.CRA_SECURITY_INCIDENT,
                                   IncidentType.DUAL_INCIDENT):
            # CRA Art.14: notify ENISA + CSIRT
            deadlines["CRA_ENISA_EARLY_WARNING"] = self.detected_at + timedelta(hours=24)
            deadlines["CRA_ENISA_NOTIFICATION"] = self.detected_at + timedelta(hours=72)
            deadlines["CRA_ENISA_FINAL"] = self.detected_at + timedelta(days=14)
        
        return deadlines

# Adversarial data poisoning attack on HR AI → triggers both
dual_incident = IncidentReport(
    incident_type=IncidentType.DUAL_INCIDENT,
    detected_at=datetime.utcnow()
)
print(dual_incident.get_reporting_deadlines())
# Both Art.73 NCA and CRA Art.14 ENISA paths, different final timelines

Conformity Assessment: Art.43 ↔ CRA Art.32

Both regulations require conformity assessment before CE marking. For dual-regulated products:

EU AI Act Art.43 offers two routes for high-risk AI:

1. Internal control (self-assessment) — applies to most Annex III systems except biometric/law enforcement
2. Third-party notified body assessment — required for certain Annex III categories

CRA Art.32 offers three routes based on product class:

1. Internal control — for default class (most products)
2. Third-party assessment (EU-type) — for Important products (Annex III Class I)
3. Full quality assurance — for Critical products (Annex III Class II)

Critical synergy: If both regulations require third-party assessment, you can scope a single notified body engagement to cover both. The NB must be designated for both AI Act and CRA (not all NBs hold dual designation yet in 2026 — verify before engaging).

The Dual Deadline Timeline

2026-06-11  CRA Notified Bodies operational (June 2026)
2026-08-02  EU AI Act: High-risk AI provisions apply (August 2026) ← PRIMARY DEADLINE
2026-09-11  CRA: Vulnerability reporting obligations apply (September 2026) ← 3 months after
2027-06-11  CRA: Governance obligations for manufacturers apply
2027-12-11  CRA: Full CE marking and conformity assessment required ← 16 months after AI Act

For dual-regulated products, the sequencing matters:

1. Now (Q2 2026): Scope dual compliance. Map your product against Annex III + CRA Art.2. Identify if you need third-party assessment for either or both.
2. By August 2, 2026: AI Act conformity assessment complete, CE mark affixed, technical documentation finalised, EU Declaration of Conformity (Art.47) signed.
3. By September 11, 2026: CRA Art.14 vulnerability disclosure policy live, ENISA reporting pipeline tested.
4. By December 11, 2027: CRA CE mark, full technical documentation, notified body assessment (if required).

The August 2026 deadline is your forcing function. Teams that complete AI Act compliance first will find CRA compliance significantly faster — the documentation, risk management, and monitoring infrastructure overlaps.

Infrastructure Jurisdiction: The CLOUD Act Double Risk

EU AI Act and CRA both create evidence requirements that can be subpoenaed under the US CLOUD Act if your infrastructure runs on US-owned cloud providers (AWS, Azure, GCP):

• AI Act Annex IV technical documentation stored on AWS S3 or Azure Blob is reachable under CLOUD Act to US authorities
• CRA Art.14 incident reports drafted in Microsoft Word on M365 create jurisdiction exposure
• AI Act Art.72 post-market monitoring logs on AWS CloudWatch can be accessed without EU court order

EU-native infrastructure (Hetzner Germany, which powers sota.io) eliminates CLOUD Act jurisdiction for all compliance evidence. This is not a marginal point: both AI Act and CRA evidence packages must survive scrutiny from EU market surveillance authorities and be protected against extra-judicial disclosure to non-EU law enforcement.

30-Item Dual Compliance Checklist

Scoping (complete now)

• AI system classification against Art.6 + Annex III completed
• CRA product scope confirmed under Art.2 (digital product + remote processing)
• CRA Art.12 high-risk AI applicability confirmed or excluded
• Dual regulation map drawn: which obligations come from which regulation

Technical Documentation (by August 2026 for AI Act; December 2027 for CRA)

• Joint technical documentation package structured (Annex IV + CRA Art.31 sections)
• Product description satisfies both Art.3 AI system definition and CRA product scope
• Architecture documentation covers both AI-specific (model, training data) and CRA-required (attack surface, dependencies) elements
• Risk management documentation: AI risks (Art.9) + cybersecurity risks (CRA Annex I)
• Testing evidence: accuracy/robustness (Art.15) + security testing (CRA Annex I §13)
• Vulnerability disclosure policy drafted (CRA Art.14)

Cybersecurity Requirements

• Art.15 cybersecurity threat model covers adversarial ML attacks
• CRA Annex I §1–8 controls mapped and implemented
• Shared controls identified (eliminate duplication)
• Secure by default design verified (CRA Annex I §1)
• Authentication and access control implemented (CRA Annex I §3)
• Encryption in transit and at rest (CRA Annex I §4)
• Security update mechanism tested (CRA Annex I §8)

Incident Reporting Pipeline

• Art.73 serious incident definition applied to AI-specific failure modes
• CRA Art.14 triggering conditions defined (exploited vulnerability)
• Dual-incident triage procedure documented
• NCA notification template ready (AI Act Art.73)
• ENISA + CSIRT notification template ready (CRA Art.14)
• Incident classification logic tests completed (24h/72h deadlines)

Conformity Assessment

• Art.43 route confirmed (internal control vs third-party)
• CRA Art.32 route confirmed (Class + third-party requirement check)
• Notified body search complete (dual-designated NB if needed)
• EU Declaration of Conformity template (AI Act Art.47) prepared
• CRA EU Declaration of Conformity (CRA Art.28) prepared
• CE marking design covers both regulatory CE designations

Infrastructure

• Compliance evidence infrastructure confirmed EU-jurisdiction (no CLOUD Act exposure)
• Monitoring and logging systems hosted on EU-native infrastructure
• Art.73 and CRA Art.14 evidence collected in EU jurisdiction

What Comes Next in This Series

• Post 2: Technical documentation that satisfies both Annex IV and CRA Art.31 — a shared template with per-regulation annotations
• Post 3: Building one incident reporting pipeline for Art.73 + CRA Art.14
• Post 4: CE marking strategy for dual-regulated products
• Post 5: 50-item dual compliance developer checklist + the definitive August 2026 sprint plan

The key insight from this post: dual compliance is not 2× the work. For the 60% of technical documentation and cybersecurity requirements that overlap, one well-structured artefact satisfies both. The divergence is narrower than most teams expect — concentrated in incident reporting timelines, conformity assessment routes, and CE declaration content.

sota.io is EU-native managed PaaS running on Hetzner Germany — no US parent, no CLOUD Act exposure. Your AI Act and CRA compliance evidence packages stay in EU jurisdiction. From €9/month.