EU AI Act + DORA: FinTech and InsurTech Developer Cross-Compliance Guide 2026

Post #1577 in the sota.io EU AI Act + DORA Intersection Series

A FinTech startup deploys a credit-scoring AI in January 2026. It is high-risk under EU AI Act Annex III Category 6(b). It is also an ICT system subject to DORA because the startup has obtained a payment institution licence. On August 2, 2026 — the day EU AI Act obligations for high-risk AI providers activate — the same system must simultaneously comply with DORA's ICT Risk Management Framework (in force since January 2025), EU AI Act Art.9 Risk Management System requirements, and, if the startup provides services to insurance undertakings, Solvency II model governance and IDD obligations.

Three overlapping regimes. One development team. Fifty-six days.

This guide gives FinTech and InsurTech developers a precise, article-level map of where EU AI Act and DORA requirements converge, where they diverge, and how to build a single implementation that satisfies both without running parallel compliance programmes.

Who Is Simultaneously in Scope?

The Dual-Scope Scenario

The EU AI Act and DORA share scope in every scenario where a financial entity (DORA Art.2(2)) deploys or provides an AI system that falls into EU AI Act high-risk categories relevant to financial services:

• Annex III Category 2 — AI used in management and operation of critical infrastructure, including payment networks
• Annex III Category 6(b) — AI used to evaluate creditworthiness or establish credit scores, except for fraud detection
• Annex III Category 6(c) — AI used for risk assessment and pricing of life and health insurance
• Annex III Category 4(a) — AI used for recruitment, selection, or promotion of workers in financial firms

InsurTech developers face an additional intersection: AI used for claims automation that falls under Solvency II Pillar II Internal Model governance if outputs feed into capital calculations, and AI-assisted distribution tools that must comply with IDD Art.17 suitability and appropriateness obligations.

DORA-Regulated Financial Entities (Art.2(2))

DORA applies to: credit institutions, payment institutions, e-money institutions, investment firms, trading venues, central counterparties, insurance and reinsurance undertakings, IORPs, crypto-asset service providers (CASPs) under MiCA, credit rating agencies, crowdfunding service providers.

Microenterprise exemption: Entities employing fewer than 10 persons with annual turnover or balance sheet under €2 million qualify for the simplified ICT risk management framework under DORA Art.16, which reduces the scope of Arts.6-15 obligations but does not eliminate them. AI developers building for microenterprise financial clients must still ensure the simplified framework is satisfied.

Article-by-Article Mapping: EU AI Act Art.9 vs DORA ICT Risk Framework

The most operationally important overlap is between EU AI Act Art.9 (Risk Management System for high-risk AI) and the DORA ICT Risk Management Framework (Arts.6-14). They share the same lifecycle logic — identify, protect, detect, respond, recover — but with fundamentally different risk taxonomies.

EU AI Act Art.9: Risk Management System Requirements

Art.9 mandates a continuous, iterative risk management system for high-risk AI systems throughout the entire lifecycle. Concretely:

• Art.9(2)(a): Identification and analysis of known and reasonably foreseeable risks associated with each high-risk AI system
• Art.9(2)(b): Estimation and evaluation of risks that may emerge when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse
• Art.9(2)(c): Evaluation of other possible risks that emerge based on analysis of post-market monitoring data (Art.72)
• Art.9(4): Risk management measures through design and development choices, and through implementation of adequate mitigation measures in the deployment context
• Art.9(7): Testing procedures to ensure the AI system meets Art.9 requirements before market placement — at defined intervals and in circumstances that reflect realistic operating conditions

DORA ICT Risk Management Framework (Arts.6-14)

DORA Art.6 requires a documented ICT Risk Management Framework — a strategy, policies, procedures, tools, and governance structure. Arts.8-14 specify the five operational pillars:

• Art.8 (Identify): Classify all ICT assets by criticality, map functions, identify and document all ICT risks, maintain asset inventory
• Art.9 (Protect): ICT security controls, access management, encryption, patch management, physical protection of ICT infrastructure
• Art.10 (Detect): Mechanisms to promptly detect anomalous activities affecting ICT availability, authenticity, integrity, confidentiality
• Art.11 (Respond and Recover): ICT response plans, business continuity, recovery time and point objectives, communication during incidents
• Art.14 (Communicate): ICT incident communication plans to staff, clients, and competent authorities

The Precise Cross-Walk

Key insight: EU AI Act Art.9 risk management and DORA ICT risk management are never redundant — they cover different risk dimensions of the same system. Running one does not satisfy the other.

InsurTech-Specific Intersections

Solvency II Pillar II and EU AI Act Art.9

Insurance undertakings under Solvency II Directive (2009/138/EC) must satisfy Pillar II Internal Model governance requirements if an AI system feeds into capital calculations. This adds a third governance layer on top of DORA and the EU AI Act:

• Solvency II Art.120: Internal models for the Solvency Capital Requirement must meet use test, statistical quality, calibration, documentation, and validation standards.
• EU AI Act Annex III Category 6(c): AI used for risk assessment and pricing in life and health insurance is high-risk.
• DORA Art.8: The AI system feeding the internal model is an ICT asset requiring risk assessment.

Where an InsurTech's AI pricing model also feeds Solvency II capital calculations, the same model must satisfy three validation regimes: Solvency II use test and back-testing, EU AI Act Art.9(7) pre-market and post-market testing, and DORA ICT resilience testing (Art.26). Building unified validation documentation satisfying all three simultaneously reduces audit burden by approximately 60% compared to three separate programmes.

IDD Art.17 and EU AI Act Art.14 Human Oversight

The Insurance Distribution Directive (2016/97/EU) Art.17 requires insurance distributors to act in the best interests of customers, which ESAs have interpreted to include AI-assisted advice tools. Where an InsurTech uses AI to generate product recommendations:

• IDD Art.17(1): Distributors must not place commercial interests above the customer's interests. AI recommendation systems must be designed and monitored to ensure outputs reflect genuine suitability, not conversion optimisation.
• EU AI Act Art.14: High-risk AI systems must have human oversight measures enabling operators to monitor, understand, and — where necessary — override outputs. For AI-assisted insurance advice, this means designated human reviewers for edge cases and audit trails.

The IDD best-interests obligation and EU AI Act Art.14 human oversight reinforce each other: both require the deployer to maintain meaningful human control over AI-generated recommendations. A single human oversight implementation satisfying Art.14 — with operator training, override capability, and escalation procedures — simultaneously discharges the IDD Art.17 governance obligation.

Dual Incident Reporting: The 4-Hour Problem

When One AI Failure Triggers Both Regimes

A payment institution's fraud-detection AI fails silently and approves 40,000 fraudulent transactions over 6 hours. This is simultaneously:

1. A major ICT-related incident under DORA Art.17 — number of clients affected exceeds thresholds, duration exceeds 4 hours, significant financial impact
2. Potentially a serious incident under EU AI Act Art.3(49) — if the AI system failure caused serious harm to natural persons through wrongful fund loss (depending on MSA interpretation)

DORA Art.19: Three-Stage Reporting Timeline

DORA Art.19(4) specifies three mandatory reporting stages for major ICT-related incidents:

1. Initial notification (Art.19(4)(a)): Within 4 hours of classifying the incident as major, or within 24 hours of becoming aware of it if classification requires investigation
2. Intermediate report (Art.19(4)(b)): Within 72 hours of the initial notification, with update on classification, estimated scope, and actions taken
3. Final report (Art.19(4)(c)): Within 1 month of the intermediate report, with root cause, lessons learned, and remediation measures

Reports go to the national competent authority designated under DORA — for payment institutions in Germany, this is the BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht).

EU AI Act Art.73: Serious Incident Reporting

Under EU AI Act Art.73(1), providers of high-risk AI systems must report serious incidents to the market surveillance authority without undue delay and within 15 working days of becoming aware of the incident. In Germany, the EU AI Act market surveillance authority for financial sector AI is expected to be separate from BaFin.

Art.3(49) defines a serious incident as any incident or malfunction directly or indirectly leading to:

• Death of a natural person or serious harm to health
• A serious breach of obligations under fundamental rights law
• Serious disruption to the management or operation of critical infrastructure

The Practical Problem: Two Competent Authorities, Two Timelines

For a FinTech startup that is both the provider of a high-risk AI system (builds it) and the deployer (operates it in its own financial service), both Art.73 provider obligations and DORA deployer obligations apply simultaneously.

Developer action: Build a dual incident classification function at the intake of every incident. DORA's 4-hour initial notification deadline governs the overall response cadence. The AI Act's 15-day deadline is secondary but requires a separate parallel notification track to a different authority.

Python Dual-Compliance Risk Pipeline

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

class FinancialSector(Enum):
    PAYMENT_INSTITUTION = "payment_institution"
    CREDIT_INSTITUTION = "credit_institution"
    INVESTMENT_FIRM = "investment_firm"
    INSURANCE_UNDERTAKING = "insurance_undertaking"   # + Solvency II
    CASP = "crypto_asset_service_provider"             # + MiCA
    E_MONEY_INSTITUTION = "emi"

class AISystemRole(Enum):
    PROVIDER = "provider"       # builds the AI system
    DEPLOYER = "deployer"       # operates it in a financial service
    BOTH = "provider_deployer"  # startup scenario: both simultaneously

class AnnexIIICategory(Enum):
    CAT2_CRITICAL_INFRA = "critical_infrastructure"  # payment networks
    CAT6B_CREDIT_SCORING = "credit_scoring"
    CAT6C_INSURANCE_PRICING = "insurance_risk_pricing"
    CAT4A_WORKER_MANAGEMENT = "worker_management"
    NOT_HIGH_RISK = "not_high_risk"

@dataclass
class AISystemProfile:
    name: str
    sector: FinancialSector
    role: AISystemRole
    annex_iii_category: AnnexIIICategory
    is_third_party_ai: bool = False          # external API provider
    feeds_solvency2_internal_model: bool = False  # InsurTech-specific
    used_for_idd_distribution: bool = False       # InsurTech-specific
    is_critical_function: bool = False        # DORA Art.3(22) CIF
    in_dora_ict_register: bool = False        # Art.8(1)
    has_ai_act_tech_doc: bool = False         # Art.11 + Annex IV
    has_human_oversight: bool = False         # Art.14
    has_unified_risk_register: bool = False   # Art.9 + DORA Art.8
    incident_response_dual_track: bool = False  # DORA Art.17 + Art.73
    post_market_monitoring: bool = False      # Art.72

@dataclass
class ComplianceGap:
    framework: str  # "DORA" | "EU AI Act" | "Solvency II" | "IDD" | "Both"
    article: str
    issue: str
    severity: str   # "critical" | "high" | "medium"
    deadline: str
    fix: str

def classify_incident(
    clients_affected: int,
    duration_hours: float,
    cross_border: bool,
    caused_personal_harm: bool,
    disrupted_payment_network: bool
) -> dict:
    """Determine incident reporting obligations under DORA Art.17 and EU AI Act Art.73."""
    
    # DORA major incident — simplified thresholds (full criteria in RTS per Art.18(3))
    dora_major = (
        clients_affected > 5000 or
        duration_hours > 4.0 or
        cross_border or
        disrupted_payment_network
    )
    
    # EU AI Act serious incident — Art.3(49)
    ai_serious = caused_personal_harm or disrupted_payment_network
    
    now = datetime.utcnow()
    result = {
        "dora_major": dora_major,
        "ai_act_serious": ai_serious,
        "dual": dora_major and ai_serious,
    }
    
    if dora_major:
        result["dora_initial_deadline"] = now + timedelta(hours=4)
        result["dora_intermediate_deadline"] = now + timedelta(hours=76)  # 4h + 72h
        result["dora_final_deadline"] = now + timedelta(days=31)           # +1 month
        result["dora_authority"] = "national competent authority (e.g. BaFin for DE)"
        result["dora_reference"] = "DORA Art.19(4)"
    
    if ai_serious:
        # 15 working days ~ 21 calendar days
        result["ai_act_deadline"] = now + timedelta(days=21)
        result["ai_act_authority"] = "market surveillance authority (EU AI Act Art.73)"
        result["ai_act_reference"] = "EU AI Act Art.73(1)"
        result["note"] = (
            "15 working days from awareness of serious incident. "
            "DORA 4-hour initial deadline governs combined response cadence."
        )
    
    return result

def assess_compliance(profile: AISystemProfile) -> list[ComplianceGap]:
    """Identify DORA + EU AI Act + sector-specific compliance gaps."""
    gaps: list[ComplianceGap] = []
    
    # DORA Art.8 — ICT asset register
    if not profile.in_dora_ict_register:
        gaps.append(ComplianceGap(
            framework="DORA",
            article="Art.8(1)",
            issue=f"{profile.name} not registered as ICT asset",
            severity="critical",
            deadline="Already in force (DORA applies since Jan 2025)",
            fix="Add to ICT asset register: system name, criticality, business function, "
                "dependency map, TPSP reference if third-party"
        ))
    
    # EU AI Act Art.11 + Annex IV — technical documentation
    if (profile.annex_iii_category != AnnexIIICategory.NOT_HIGH_RISK
            and not profile.has_ai_act_tech_doc):
        gaps.append(ComplianceGap(
            framework="EU AI Act",
            article="Art.11 + Annex IV",
            issue="High-risk AI system missing technical documentation",
            severity="critical",
            deadline="2026-08-02 (high-risk obligations activation)",
            fix="Prepare Annex IV documentation: system description, training data governance, "
                "testing results, accuracy and robustness metrics, intended use, residual risks"
        ))
    
    # EU AI Act Art.14 — human oversight
    if (profile.annex_iii_category != AnnexIIICategory.NOT_HIGH_RISK
            and not profile.has_human_oversight):
        gaps.append(ComplianceGap(
            framework="EU AI Act",
            article="Art.14",
            issue="No human oversight measures for high-risk AI outputs",
            severity="critical",
            deadline="2026-08-02",
            fix="Implement: operator training programme, override capability for high-stakes "
                "decisions, monitoring procedure, escalation path to qualified reviewer"
        ))
    
    # Dual risk register
    if not profile.has_unified_risk_register:
        gaps.append(ComplianceGap(
            framework="Both",
            article="DORA Art.8 + EU AI Act Art.9",
            issue="No unified risk register covering both ICT operational and AI-specific risks",
            severity="high",
            deadline="2026-08-02",
            fix="Create register with two taxonomies: (1) DORA: availability, integrity, "
                "confidentiality risks; (2) AI Act: bias, accuracy drift, misuse, output harm"
        ))
    
    # Dual incident response
    if not profile.incident_response_dual_track:
        gaps.append(ComplianceGap(
            framework="Both",
            article="DORA Art.17-19 + EU AI Act Art.73",
            issue="Incident response does not address dual reporting obligations",
            severity="high",
            deadline="Already in force for DORA; 2026-08-02 for AI Act",
            fix="Add decision tree: classify under DORA Art.17 AND EU AI Act Art.3(49). "
                "Identify both competent authorities. Set 4-hour DORA initial notification "
                "as primary timeline driver. Run AI Act 15-day track in parallel."
        ))
    
    # Post-market monitoring
    if (profile.annex_iii_category != AnnexIIICategory.NOT_HIGH_RISK
            and not profile.post_market_monitoring):
        gaps.append(ComplianceGap(
            framework="EU AI Act",
            article="Art.72",
            issue="No post-market monitoring for high-risk AI outputs",
            severity="high",
            deadline="2026-08-02",
            fix="Implement: accuracy drift detection, protected-attribute bias metrics "
                "(for credit scoring: age, gender, nationality), output distribution tracking, "
                "quarterly review with documented findings"
        ))
    
    # InsurTech: Solvency II
    if (profile.feeds_solvency2_internal_model
            and profile.annex_iii_category == AnnexIIICategory.CAT6C_INSURANCE_PRICING):
        gaps.append(ComplianceGap(
            framework="Solvency II",
            article="Art.120-126 + EU AI Act Art.9",
            issue="AI pricing model feeding Solvency II internal model requires "
                  "dual validation: use test + back-testing (Solvency II) AND "
                  "Art.9(7) pre-market testing (EU AI Act)",
            severity="high",
            deadline="2026-08-02 for EU AI Act layer; Solvency II ongoing",
            fix="Align validation documentation. Use Solvency II back-testing evidence "
                "to partially satisfy EU AI Act Art.9(7) testing record requirements. "
                "Document explicitly in Annex IV technical documentation."
        ))
    
    # InsurTech: IDD
    if profile.used_for_idd_distribution:
        gaps.append(ComplianceGap(
            framework="IDD",
            article="Art.17 + EU AI Act Art.14",
            issue="AI-assisted insurance distribution must satisfy IDD Art.17 "
                  "best-interests obligation AND EU AI Act Art.14 human oversight",
            severity="medium",
            deadline="2026-08-02 for EU AI Act layer; IDD ongoing",
            fix="Human oversight implementation (Art.14) simultaneously satisfies IDD "
                "Art.17 governance obligation. Document dual compliance in operator "
                "training materials and oversight procedure."
        ))
    
    return gaps

# Example: InsurTech credit scoring + Solvency II internal model
profile = AISystemProfile(
    name="InsurPricer AI v2.4",
    sector=FinancialSector.INSURANCE_UNDERTAKING,
    role=AISystemRole.BOTH,
    annex_iii_category=AnnexIIICategory.CAT6C_INSURANCE_PRICING,
    feeds_solvency2_internal_model=True,
    used_for_idd_distribution=True,
    is_critical_function=True,
    in_dora_ict_register=True,
    has_ai_act_tech_doc=False,    # Gap
    has_human_oversight=False,    # Gap
    has_unified_risk_register=False,  # Gap
    incident_response_dual_track=False,  # Gap
    post_market_monitoring=True
)

gaps = assess_compliance(profile)
critical = [g for g in gaps if g.severity == "critical"]
print(f"Critical gaps: {len(critical)} | Total: {len(gaps)}")
for g in gaps:
    print(f"  [{g.severity.upper()}] {g.framework} {g.article}: {g.issue[:60]}...")
    print(f"    Deadline: {g.deadline}")

30-Step Developer Checklist: EU AI Act + DORA + InsurTech

Part A — Scope and Classification (Steps 1-6)

1. DORA scope confirmation: Verify the financial entity (yours or your client's) falls under DORA Art.2(2). If microenterprise (Art.16), document simplified-framework obligations explicitly.

2. EU AI Act scope confirmation: Confirm your AI system is placed on the EU market or used within the EU. Confirm you are a provider (builds the system), deployer (operates it), or both.

3. Annex III classification: Apply EU AI Act Art.6(2) + Annex III. For FinTech/InsurTech: Category 6(b) (credit scoring), Category 6(c) (insurance pricing), Category 2 (critical infrastructure AI in payment networks). Not high-risk if purely fraud detection (explicitly excluded from Cat.6(b)).

4. Prohibited practices check: Confirm the AI system does not use prohibited techniques (Art.5): subliminal manipulation, social scoring by public authorities, real-time remote biometric identification in public spaces, exploitation of vulnerabilities of specific groups.

5. DORA ICT criticality classification: Determine whether the AI system supports a Critical or Important Function (Art.3(22)) — any function whose disruption would materially impair financial soundness, operational continuity, or compliance obligations. DORA enhanced requirements (TLPT, contract provisions) apply to CIF-supporting systems.

6. InsurTech: Solvency II internal model check: If the AI system's output feeds into Solvency Capital Requirement calculations, confirm the use test, statistical quality standards, and validation requirements under Solvency II Pillar II are documented alongside EU AI Act Art.9 requirements.

Part B — Risk Management Foundation (Steps 7-12)

7. Unified risk register creation: Create a risk register with two explicitly separated taxonomies: (a) DORA ICT risks — availability, integrity, confidentiality, auditability; (b) EU AI Act AI risks — output accuracy, bias against protected attributes, misuse scenarios, drift over time.

8. DORA Art.8 ICT asset registration: Register AI system in the ICT asset register with: system name, version, hosting environment, business function supported, criticality classification, dependency on ICT TPSPs (AI API providers, model hosting infrastructure).

9. EU AI Act Art.9(2)(a)-(b) risk identification: Document known and foreseeable risks for the specific AI use case. For credit scoring: bias against age/gender/nationality protected attributes; for insurance pricing: proxy discrimination through postal code or occupation; for payment AI: adversarial manipulation and model poisoning.

10. DORA protection controls (Art.9): Verify ICT security controls covering the AI system: access management for model endpoints, encryption of inference logs, patch management for AI framework dependencies, physical protection of inference infrastructure.

11. DORA detection controls (Art.10): Implement monitoring that detects anomalous AI system behaviour as ICT events: latency spikes (availability), unexpected output distribution shifts (integrity), unauthorised API access (confidentiality).

12. EU AI Act Art.9(4) design-level controls: Implement controls through design: input validation to reject adversarial inputs, output confidence thresholds that gate high-stakes decisions, model version control with rollback capability, training data governance with protected attribute handling.

Part C — Technical Documentation and Conformity (Steps 13-18)

13. Annex IV technical documentation: Prepare full Annex IV documentation covering all eight elements: general description and intended purpose, design and development process, monitoring/testing/validation with results, training data description with data governance, human oversight measures, accuracy and robustness metrics, cybersecurity measures, EU declaration of conformity reference.

14. DORA Art.28 TPSP registration: If the AI system is provided by a third-party vendor (API, cloud AI platform), register the provider in the ICT third-party service provider register (Art.28(3)) with: service description, criticality, contractual arrangement reference, annual due diligence record.

15. DORA Art.30 contract review: Verify the AI vendor contract includes mandatory DORA Art.30 provisions: service level description with measurable performance targets, data location (EU-hosted for financial data), audit rights for both the financial entity and competent authorities, business continuity obligations, exit plan and data portability requirements.

16. EU AI Act Art.25 deployer obligations (if using third-party AI): Document: instructions-for-use compliance, fundamental rights impact assessment (Art.26(2) if required), operator training on the specific system, incident notification procedure to the provider.

17. CTPP designation monitoring: Check the European Supervisory Authorities' published Critical TPSP register. If your AI vendor is designated as a CTPP, integrate Lead Overseer oversight recommendations into your own risk assessment update cycle (DORA Art.31(5)).

18. EU AI database registration: Register the high-risk AI system with the EU AI database (Art.49) before first deployment. Prepare EU declaration of conformity (Art.47) referencing applicable harmonised standards and conformity assessment procedure used.

Part D — Incident Response and Monitoring (Steps 19-24)

19. Dual incident classification procedure: Build a written decision tree executed at the start of every incident: (a) Apply DORA Art.17 + RTS thresholds — is this a major ICT-related incident? (b) Apply EU AI Act Art.3(49) criteria — did this cause death, serious harm, fundamental rights breach, or critical infrastructure disruption? Both assessments run in parallel, not sequentially.

20. DORA 4-hour notification capability: Establish 24/7 capability to reach the national competent authority within 4 hours of classifying a major incident. Designate an incident notification owner with authority to send DORA Art.19 initial notification without executive approval delays.

21. EU AI Act 15-day serious incident track: Build parallel notification procedure: if the incident triggers Art.3(49) serious incident criteria, initiate contact with the national market surveillance authority and prepare the Art.73 notification within 15 working days. Maintain a parallel incident record for the MSA separate from the DORA incident log.

22. EU AI Act Art.72 post-market monitoring: Implement continuous post-market monitoring covering: prediction accuracy per segment (detect drift), protected attribute disparate impact metrics (detect bias emergence), output distribution monitoring (detect data shift), quarterly compliance review with documented findings retained under Art.12 logging requirements.

23. DORA annual ICT testing (Art.26(1)): Include the AI system in the annual ICT testing programme. Tests must cover AI-specific operational scenarios: model API unavailability (failover procedure), corrupted model output detection, adversarial input resilience, inference infrastructure failure modes.

24. DORA TLPT inclusion (Art.26(2)): If the AI system supports a Critical or Important Function and the financial entity qualifies for Threat-Led Penetration Testing obligations, include the AI system in the TIBER-EU-methodology TLPT scope every 3 years. AI-specific threat scenarios: adversarial prompt injection, model inversion attacks, API credential compromise.

Part E — Infrastructure and Go-Live (Steps 25-30)

25. EU-sovereign infrastructure verification: Confirm inference infrastructure, model storage, training data, and audit logs are hosted on EU-sovereign infrastructure — physically in the EU, operated by an entity under EU jurisdiction, with no US-parent-company CLOUD Act exposure. DORA Art.30(2)(e) data location provisions and EU AI Act Art.70 audit log confidentiality both require this for financial AI processing personal data.

26. InsurTech: IDD Art.17 human oversight alignment: If the AI system supports insurance distribution decisions, confirm the EU AI Act Art.14 human oversight implementation (step 18 in Part C) is documented as simultaneously satisfying IDD Art.17 best-interests governance obligation. Single documentation, dual compliance benefit.

27. Operator competence training (Art.14(4)(c)): Train all operators designated to oversee high-risk AI outputs. Training must cover: what the system does, what failure modes look like, how to identify anomalous outputs, when and how to override, escalation path. Maintain training records; refresh on material model update.

28. Human oversight override test: Before go-live, test the override capability with a controlled scenario: trigger a high-confidence AI output that is deliberately wrong; verify the operator can identify, override, and escalate without friction. Document test result in technical documentation.

29. Pre-market compliance gate: Before first deployment, verify: (a) Annex IV technical documentation complete and reviewed; (b) EU AI database registration submitted; (c) ICT asset register updated; (d) TPSP register updated; (e) DORA Art.30 contract provisions confirmed; (f) incident response dual-track tested; (g) human oversight live and trained.

30. Post-deployment review schedule: Set calendar entries: DORA annual ICT test (Arts.26(1)) — 12 months from go-live; EU AI Act post-market monitoring quarterly review — 3 months from go-live; DORA TPSP annual due diligence (Art.28(4)) — 12 months from provider onboarding; CTPP designation list check — quarterly; EU AI Act material change assessment (Art.6) — triggered by any model update changing performance metrics by more than 10%.

The Infrastructure Layer: EU-Sovereign Hosting for Dual Compliance

Both DORA and the EU AI Act converge on an infrastructure requirement that many FinTech and InsurTech developers miss until the audit.

DORA Art.30(2)(e) requires ICT contracts with third-party service providers to specify data location. For AI systems, "data" includes inference logs, model outputs, audit trails, and incident records — all of which DORA requires to be retained and accessible to competent authorities.

EU AI Act Art.70 gives competent authorities power to access technical documentation and logs during market surveillance. When those logs are stored on infrastructure operated by a US-parent company or subject to US jurisdiction, they are potentially accessible to US federal law enforcement under the CLOUD Act — independent of EU confidentiality protections or the EU AI Act's data protection obligations.

The practical consequence: a FinTech storing credit-scoring AI audit logs on AWS Frankfurt (operated by Amazon.com Inc., a US entity) has documentation that is simultaneously required to be confidential under EU AI Act Art.70 and potentially subject to CLOUD Act compelled disclosure without notification to the financial entity or the EU competent authority.

EU-native infrastructure eliminates this conflict. sota.io runs on Hetzner Germany and Amsterdam — EU-incorporated, no US parent, no CLOUD Act exposure. Financial entities deploying AI inference services, audit log storage, and post-market monitoring pipelines on sota.io satisfy DORA Art.30(2)(e) data location requirements and EU AI Act Art.70 confidentiality protections with a single infrastructure choice.

Summary

FinTech and InsurTech developers building AI systems face three categories of dual-regime obligation before August 2, 2026:

Risk management: EU AI Act Art.9 and DORA ICT Risk Management Framework (Arts.6-14) are parallel requirements, not alternatives. Maintain a unified risk register with explicitly separated ICT and AI-specific risk taxonomies. Solvency II adds a third validation layer for InsurTech models feeding capital calculations.

Third-party AI: DORA Art.28-30 governs operational resilience of AI API providers. EU AI Act Art.25 governs appropriate use of third-party high-risk AI. Both apply simultaneously for every AI API dependency. DORA Art.30 contract terms and EU AI Act Art.25 documentation requirements are complementary checklists, not alternatives.

Incident response: DORA's 4-hour initial notification deadline (Art.19(4)(a)) governs the combined response cadence for dual incidents. EU AI Act Art.73's 15-working-day window requires a parallel notification track to a different competent authority. Build the dual decision tree before the incident, not during.

The Python pipeline and 30-step checklist above give development teams a structured framework for executing dual compliance before the August 2026 deadline.

See Also

• EU AI Act + DORA: Dual Compliance for Financial Sector AI Systems — Complementary guide covering the strategic dual-compliance framework, Python DORAAIActComplianceChecker, and 25-item checklist for banking, insurance, and investment firms
• EU AI Act InsurTech: Insurance AI Developer Compliance Guide 2026 — Deep dive into InsurTech-specific obligations: Annex III 5(c), DORA ICT third-party risk, IDD distribution AI, Solvency II model governance
• EU AI Act FinTech: Credit Scoring and Loan Decision Developer Compliance 2026 — FinTech-specific guide: Annex III Category 6(b) credit scoring, Art.14 human oversight for automated credit decisions, DORA intersection