EU AI Act Art.61 Further Innovation Support Measures — Developer Guide (2026)

EU AI Act Articles 57–60 establish the core sandbox framework, real-world testing pathways, personal data processing rules, and SME-specific support. Article 61 completes this innovation support architecture by creating a broader obligation on member state competent authorities and the Commission to provide innovation infrastructure that extends beyond any single legal mechanism.

Where Art.57 gives developers a controlled testing environment and Art.60 gives SMEs priority queue access, Art.61 addresses the surrounding ecosystem: testing facilities, digital infrastructure, coaching services, coordination between national AI authorities, and the administrative structures through which the EU's innovation support commitments become operational.

For developers, Art.61 matters most when your team has exhausted what Art.57 sandboxes and Art.60 SME benefits offer — or when you need infrastructure that a sandbox does not provide: large-scale compute, sector-specific testing datasets, physical hardware environments, or inter-authority coordination for cross-border deployment.

Art.61 became applicable on 2 August 2025 as part of Chapter VI (Measures in Support of Innovation) of the EU AI Act (Regulation (EU) 2024/1689).

Art.61 in the Chapter VI Framework

Art.61 is deliberately broader than the preceding articles. It does not create a specific compliance procedure or application process. Instead, it establishes institutional obligations — things member state authorities and the Commission must have in place to support innovation across the AI Act's scope. Developers access Art.61 benefits by engaging with the institutions those obligations create.

What Art.61 Establishes

Core Obligations

Art.61 requires member state competent authorities, in coordination with the European AI Office, to:

1. Provide regulatory coaching and guidance to operators developing AI systems beyond what sandbox admission formally provides
2. Facilitate access to EU Testing and Experimentation Facilities (TEFs) established under the Digital Europe Programme
3. Coordinate with Digital Innovation Hubs (DIHs) to extend AI Act compliance support to operators who are not in formal sandboxes
4. Enable access to the AI-on-Demand Platform for providers needing computational resources for AI development and testing
5. Support standardisation activities relevant to Chapter III high-risk AI requirements
6. Foster cross-border cooperation between national competent authorities for providers operating across multiple member states

The Art.61 vs Art.57 Distinction

Art.57 creates a formal legal relationship: provider applies, authority admits, sandbox terms govern the development. Art.61 creates an informal support ecosystem that operators can access without formal admission or binding legal frameworks.

EU Testing and Experimentation Facilities (TEFs)

The most concrete Art.61 benefit for most developers is access to EU Testing and Experimentation Facilities (TEFs) — sector-specific testing infrastructure established under the Digital Europe Programme (Regulation (EU) 2021/694).

TEFs provide physical and digital infrastructure that AI developers cannot replicate internally: real-world test environments, curated datasets, hardware emulators, sector-specific simulators, and access to domain experts. They are not regulatory sandboxes — TEF use does not give you the supervised development status that Art.57 provides. What TEFs provide is technical infrastructure.

EU TEF Network (2025)

Each TEF provides:

• Curated sector datasets — real-world data collected under appropriate legal bases, available for AI training and validation
• Physical test environments — lab space, hardware emulators, simulation platforms
• Domain expertise — sector specialists who can validate AI system outputs against real-world use cases
• Pre-compliance assessment — informal review of AI system design against sector-specific requirements before formal conformity assessment

Accessing TEFs Under Art.61

TEF access is coordinated through national Digital Europe programme contacts. The access process varies by TEF:

1. Expression of Interest — most TEFs use an open call process, not continuous admission
2. Technical Review — TEF evaluates whether your use case fits their infrastructure
3. Resource Allocation — compute time, lab access, dataset licensing negotiated per project
4. NDA and data agreements — sector datasets typically require data access agreements; negotiating these takes 2–6 weeks
5. Results ownership — clarify upfront who owns TEF outputs; most TEFs use joint publication provisions for research outputs

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

class TEFSector(Enum):
    HEALTH = "health"
    AGRI_FOOD = "agri_food"
    MANUFACTURING = "manufacturing"
    SMART_CITIES = "smart_cities"
    HUMAN_ROBOT = "human_robot"

class TEFAccessStatus(Enum):
    IDENTIFYING = "identifying"
    EOI_SUBMITTED = "eoi_submitted"
    TECHNICAL_REVIEW = "technical_review"
    NDA_NEGOTIATION = "nda_negotiation"
    ACTIVE = "active"
    COMPLETED = "completed"
    REJECTED = "rejected"

@dataclass
class TEFAccessRecord:
    """Track Art.61 access to EU Testing and Experimentation Facility."""
    tef_name: str
    sector: TEFSector
    use_case: str
    ai_system_description: str
    eoi_submitted: Optional[date] = None
    eoi_reference: Optional[str] = None
    technical_review_outcome: Optional[str] = None
    nda_signed: Optional[date] = None
    access_start: Optional[date] = None
    access_end: Optional[date] = None
    datasets_accessed: List[str] = field(default_factory=list)
    outputs_produced: List[str] = field(default_factory=list)
    output_ownership: Optional[str] = None
    status: TEFAccessStatus = TEFAccessStatus.IDENTIFYING
    notes: str = ""

    def is_active(self) -> bool:
        return self.status == TEFAccessStatus.ACTIVE

    def outputs_on_eu_infrastructure(self) -> bool:
        """Check whether TEF outputs are stored on EU infrastructure — CLOUD Act risk."""
        # TEF infrastructure is EU-based by Digital Europe mandate
        # Risk arises if developer EXPORTS outputs to US cloud services
        return True  # TEF itself is EU-based; developer pipeline may vary

    def cloud_act_exposure_summary(self) -> str:
        if not self.outputs_produced:
            return "No outputs yet — monitor when outputs are generated."
        return (
            f"TEF outputs ({len(self.outputs_produced)} items) were produced on EU TEF infrastructure. "
            f"If exported to US cloud (AWS/Azure/GCP), CLOUD Act jurisdiction applies to model weights, "
            f"training logs, and intermediate artifacts. Retain on EU-sovereign infrastructure."
        )

Digital Innovation Hubs (DIHs) Under Art.61

Digital Innovation Hubs are a pre-existing EU ecosystem that Art.61 formally integrates into the AI Act support framework. DIHs are single-entry-point organisations that connect businesses — especially SMEs — with technical expertise, testing facilities, financing, and skills. Over 200 DIHs are accredited under the Digital Europe Programme, with specialisations in AI, cybersecurity, high-performance computing, and sector verticals.

What DIHs Provide Under Art.61

Finding the Right DIH

DIHs are geographically distributed and sector-specialised. The European Digital Innovation Hub catalogue is maintained by the Commission at the Smart Specialisation Platform:

@dataclass
class DIHEngagement:
    """Track Digital Innovation Hub engagement under Art.61."""
    dih_name: str
    dih_country: str
    dih_specialisation: List[str]  # e.g. ["AI", "healthcare", "manufacturing"]
    contact_date: date
    services_requested: List[str]
    services_received: List[str] = field(default_factory=list)
    tef_referral_received: bool = False
    funding_advice_received: bool = False
    pre_conformity_assessment: bool = False
    assessment_findings: Optional[str] = None
    engagement_status: str = "initial_contact"
    next_steps: List[str] = field(default_factory=list)
    notes: str = ""

    def art_61_benefit_summary(self) -> str:
        benefits = []
        if self.pre_conformity_assessment:
            benefits.append("Pre-conformity assessment (reduces Art.43 preparation cost)")
        if self.tef_referral_received:
            benefits.append("TEF access referral (Art.61 testing infrastructure)")
        if self.funding_advice_received:
            benefits.append("Funding guidance (Digital Europe/Horizon access)")
        if not benefits:
            return "No Art.61 benefits claimed yet."
        return "Art.61 benefits via DIH: " + "; ".join(benefits)

DIH vs Sandbox: When to Use Which

AI-on-Demand Platform

The AI-on-Demand Platform (AIOD) is a European AI public infrastructure initiative that provides:

• AI assets catalogue — open datasets, pre-trained models, tools, benchmarks
• Shared compute access — access to European HPC infrastructure via the EuroHPC initiative
• Developer environments — pre-configured development environments for AI experimentation
• Research partnerships — connection with European AI research community

Art.61 creates an obligation for the Commission to ensure that AI Act innovation support is coordinated with the AIOD platform. For developers, this means access to curated European datasets with appropriate legal bases, and shared compute for development phases that precede or run alongside Art.57 sandbox activity.

CLOUD Act Implications for AI-on-Demand

AIOD infrastructure is operated on European HPC facilities (LUMI in Finland, LEONARDO in Italy, MARE NOSTRUM in Spain). These are not subject to CLOUD Act jurisdiction — unlike AWS, Azure, or GCP operated by US parent companies.

However, developers accessing AIOD may still export data or model weights to US-operated cloud services in their development pipeline:

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

class InfrastructureJurisdiction(Enum):
    EU_SOVEREIGN = "eu_sovereign"          # AIOD, TEF, national HPC
    US_CLOUD = "us_cloud"                  # AWS, Azure, GCP
    MIXED = "mixed"                        # Multi-cloud pipeline
    UNKNOWN = "unknown"

@dataclass
class Art61InfrastructureAssessment:
    """Assess CLOUD Act exposure in Art.61 innovation support infrastructure."""
    project_name: str
    ai_system_description: str

    # Infrastructure components
    development_infra: InfrastructureJurisdiction = InfrastructureJurisdiction.UNKNOWN
    training_infra: InfrastructureJurisdiction = InfrastructureJurisdiction.UNKNOWN
    tef_outputs_stored: InfrastructureJurisdiction = InfrastructureJurisdiction.UNKNOWN
    model_weights_stored: InfrastructureJurisdiction = InfrastructureJurisdiction.UNKNOWN
    training_data_stored: InfrastructureJurisdiction = InfrastructureJurisdiction.UNKNOWN
    cicd_pipeline: InfrastructureJurisdiction = InfrastructureJurisdiction.UNKNOWN

    # Art.59 scope (if personal data involved)
    personal_data_in_pipeline: bool = False
    personal_data_jurisdiction: InfrastructureJurisdiction = InfrastructureJurisdiction.UNKNOWN

    notes: str = ""

    def has_cloud_act_exposure(self) -> bool:
        us_jurisdictions = [
            self.development_infra,
            self.training_infra,
            self.tef_outputs_stored,
            self.model_weights_stored,
            self.training_data_stored,
            self.cicd_pipeline,
        ]
        return InfrastructureJurisdiction.US_CLOUD in us_jurisdictions or \
               InfrastructureJurisdiction.MIXED in us_jurisdictions

    def cloud_act_risk_items(self) -> List[str]:
        risks = []
        if self.development_infra == InfrastructureJurisdiction.US_CLOUD:
            risks.append("Development environment: US cloud — CLOUD Act compellability on dev logs")
        if self.training_infra == InfrastructureJurisdiction.US_CLOUD:
            risks.append("Training infrastructure: US cloud — CLOUD Act compellability on training runs")
        if self.tef_outputs_stored == InfrastructureJurisdiction.US_CLOUD:
            risks.append("TEF outputs: US cloud — CLOUD Act risk on validated test results")
        if self.model_weights_stored == InfrastructureJurisdiction.US_CLOUD:
            risks.append("Model weights: US cloud — CLOUD Act compellability on trained model")
        if self.training_data_stored == InfrastructureJurisdiction.US_CLOUD:
            risks.append("Training data: US cloud — CLOUD Act compellability on sector datasets")
        if self.personal_data_in_pipeline and \
           self.personal_data_jurisdiction == InfrastructureJurisdiction.US_CLOUD:
            risks.append("Personal data: US cloud — CLOUD Act + GDPR Art.59(1)(f) violation risk")
        return risks

    def remediation_path(self) -> str:
        if not self.has_cloud_act_exposure():
            return "No CLOUD Act exposure identified. Current infrastructure acceptable."
        items = self.cloud_act_risk_items()
        return (
            f"CLOUD Act exposure in {len(items)} pipeline component(s). "
            f"Migrate to EU-sovereign infrastructure: LUMI (HPC), local EuroHPC allocation, "
            f"or sota.io for deployment/CI components."
        )

Regulatory Coaching Under Art.61

One of the least-publicised Art.61 mechanisms is the obligation on national competent authorities to provide regulatory coaching sessions — structured meetings where developers can present their AI system design to authority representatives before filing formal compliance documentation.

What Coaching Provides

• Scope clarification — is your system high-risk under Annex III? Competent authority opinion (not binding, but practically influential)
• Obligation mapping — which Arts.9–15 obligations apply to your specific use case
• Documentation review — informal review of draft technical documentation before formal submission
• Conformity assessment pathway — guidance on whether self-declaration or third-party assessment is required for your system

Coaching vs Sandbox vs Guidance Channel

Coaching sessions typically require:

@dataclass
class RegulatoryCoachingSession:
    """Track Art.61 regulatory coaching session with national competent authority."""
    authority_name: str
    authority_country: str
    session_date: Optional[date] = None
    session_request_date: Optional[date] = None

    # Pre-session materials
    ai_system_overview: str = ""
    annex_iii_classification_question: str = ""
    specific_questions: List[str] = field(default_factory=list)

    # Session outcomes
    scope_opinion: Optional[str] = None
    high_risk_opinion: Optional[str] = None  # "likely" / "unlikely" / "unclear"
    obligations_identified: List[str] = field(default_factory=list)
    documentation_feedback: Optional[str] = None
    conformity_assessment_pathway: Optional[str] = None

    # Follow-up
    authority_reference: Optional[str] = None
    follow_up_actions: List[str] = field(default_factory=list)
    coaching_notes: str = ""

    def session_prepared(self) -> bool:
        """Check if minimum materials are ready for coaching session."""
        return bool(
            self.ai_system_overview and
            self.annex_iii_classification_question and
            self.specific_questions
        )

    def high_risk_likely(self) -> bool:
        return self.high_risk_opinion == "likely"

Art.61 and Cross-Border Coordination

Many EU AI systems are deployed across multiple member states. Art.61 creates obligations for cross-border coordination between national competent authorities — relevant when:

• Your system is developed in Germany but deployed in France, Poland, and the Netherlands
• You have received sandbox admission in one member state and want to operate in others
• Your Art.58 real-world testing plan spans multiple jurisdictions

Multi-Member State Art.61 Support

Art.61 coordination does not create a single-entry-point for multi-jurisdiction development. In practice, it means:

1. Lead authority concept — the competent authority of the member state where development primarily occurs is typically the lead contact
2. Art.62 AI Office coordination — for cross-border matters, the EU AI Office acts as coordinator between national authorities
3. Mutual recognition of coaching outputs — informal coaching opinions from one authority may be referenced when seeking guidance from another (not legally binding, but practically useful to demonstrate good-faith engagement)

@dataclass
class MultiMemberStateCoordination:
    """Track Art.61 coordination for cross-border AI development."""
    project_name: str
    lead_authority_country: str
    deployment_countries: List[str]
    development_country: str

    # Authority contacts
    authority_contacts: dict = field(default_factory=dict)  # country -> contact details
    lead_coaching_session: Optional[RegulatoryCoachingSession] = None
    additional_authority_queries: List[dict] = field(default_factory=list)

    # EU AI Office coordination
    eu_ai_office_contacted: bool = False
    eu_ai_office_reference: Optional[str] = None

    notes: str = ""

    def countries_without_authority_contact(self) -> List[str]:
        """Identify deployment countries without authority contact established."""
        return [c for c in self.deployment_countries
                if c not in self.authority_contacts]

    def coordination_summary(self) -> str:
        covered = len(self.authority_contacts)
        total = len(self.deployment_countries)
        return (
            f"Cross-border coordination: {covered}/{total} deployment countries "
            f"with authority contact. Lead authority: {self.lead_authority_country}. "
            f"EU AI Office engaged: {'Yes' if self.eu_ai_office_contacted else 'No'}."
        )

Art.61 and the EU AI Strategy Infrastructure

Art.61 cannot be read in isolation from the broader EU AI strategy. The Commission's AI Strategy (COM(2018)795), AI Action Plan (2024), and Digital Europe Programme all create infrastructure that Art.61 formally incorporates into the regulatory support framework.

Key Infrastructure Links

Interaction with Art.57 Sandbox

Art.61 and Art.57 are complementary, not alternatives:

1. Before sandbox: Use Art.61 mechanisms (DIH pre-assessment, regulatory coaching) to determine whether sandbox admission is appropriate and what to put in the sandbox plan
2. During sandbox: Use Art.61 TEF access to supplement the sandbox environment with compute and datasets your sandbox agreement doesn't provide
3. After sandbox: Use Art.61 DIH services for post-sandbox compliance support during commercialisation

@dataclass
class Art61JourneyTracker:
    """Track Art.61 support mechanisms across the AI development lifecycle."""
    project_name: str
    ai_system_description: str
    target_deployment_date: Optional[date] = None

    # Pre-sandbox phase
    dih_engagement: Optional[DIHEngagement] = None
    coaching_sessions: List[RegulatoryCoachingSession] = field(default_factory=list)
    sandbox_decision: Optional[str] = None  # "apply" / "skip" / "undecided"

    # Development phase
    tef_access: Optional[TEFAccessRecord] = None
    aiod_platform_used: bool = False
    eurohpc_allocation: Optional[str] = None

    # Deployment phase
    post_sandbox_dih_support: bool = False
    cross_border_coordination: Optional[MultiMemberStateCoordination] = None
    infrastructure_assessment: Optional[Art61InfrastructureAssessment] = None

    notes: str = ""

    def art_61_benefits_claimed(self) -> List[str]:
        benefits = []
        if self.dih_engagement:
            benefits.append(f"DIH engagement: {self.dih_engagement.dih_name}")
        if self.coaching_sessions:
            benefits.append(f"Regulatory coaching: {len(self.coaching_sessions)} session(s)")
        if self.tef_access:
            benefits.append(f"TEF access: {self.tef_access.tef_name}")
        if self.aiod_platform_used:
            benefits.append("AI-on-Demand Platform: used for compute/datasets")
        if self.eurohpc_allocation:
            benefits.append(f"EuroHPC allocation: {self.eurohpc_allocation}")
        if self.cross_border_coordination:
            benefits.append("Cross-border authority coordination: engaged")
        return benefits

    def readiness_for_market(self) -> bool:
        """Check whether Art.61 mechanisms have been adequately used."""
        has_coaching = len(self.coaching_sessions) > 0
        has_technical_support = self.tef_access is not None or self.aiod_platform_used
        has_cloud_act_assessment = self.infrastructure_assessment is not None
        return has_coaching and has_technical_support and has_cloud_act_assessment

CLOUD Act Implications for Art.61 Infrastructure

Art.61 creates access to EU-funded infrastructure — TEFs, AIOD platform, EuroHPC — which is EU-based and not subject to CLOUD Act jurisdiction. However, developer pipelines often mix EU Art.61 infrastructure with US cloud services for convenience.

The critical risk point: outputs from TEF testing (validation results, model performance data, curated sector datasets) represent commercially sensitive intellectual property. If stored on US cloud infrastructure:

• US CLOUD Act (18 U.S.C. § 2713) enables compelled disclosure to US law enforcement
• EU GDPR Art.59(1)(f) is violated if TEF datasets included personal data processed under sandbox conditions
• Competitive intelligence value of TEF outputs makes US cloud storage a strategic risk, not just a compliance risk

Recommended Infrastructure Architecture

Development (AIOD / EuroHPC) → Training (EuroHPC allocation) → Validation (TEF)
        ↓                               ↓                           ↓
  EU-sovereign IDE              EU-sovereign compute          EU-sovereign storage
        ↓
  CI/CD on EU PaaS (e.g., sota.io)
        ↓
  Deployment on EU infrastructure

Each pipeline stage should be assessed using Art61InfrastructureAssessment.cloud_act_risk_items() before production deployment.

Common Mistakes Under Art.61

1. Treating Art.61 as a Compliance Obligation

Mistake: Developer believes they must formally comply with Art.61 requirements. Reality: Art.61 creates obligations on authorities, not providers. Developers access Art.61 benefits voluntarily. There is no Art.61 compliance obligation on your side — only the opportunity to access the infrastructure it mandates.

2. Skipping DIH Pre-Assessment

Mistake: Developer goes straight to formal conformity assessment (Art.43) without seeking informal DIH pre-assessment. Reality: DIH pre-conformity assessments are free or low-cost, typically faster than formal assessment, and can identify compliance gaps before spending significant resources on Art.43 procedures. DIH assessment does not replace Art.43 but can substantially reduce preparation time.

3. Assuming TEF Admission Is Automatic

Mistake: Developer assumes TEF access is available on demand. Reality: TEFs operate on call-based admission cycles. Most TEF calls are open 1–2 times per year. Planning TEF access requires identifying the relevant call 6–12 months in advance and preparing an expression of interest that demonstrates clear use of TEF-specific capabilities (not generic compute requests).

4. Exporting TEF Outputs to US Cloud

Mistake: Developer uses TEF for sector-specific testing but stores validated models and results in AWS/Azure for convenience. Reality: If TEF outputs include personal data processed under Art.59 conditions, exporting to US cloud violates Art.59(1)(f). Even without personal data, TEF outputs may represent competitive intellectual property exposed to CLOUD Act compellability. Use EU-sovereign infrastructure for TEF output storage.

5. Not Documenting Art.61 Engagement

Mistake: Developer engages with DIHs and coaching sessions but does not retain records of the engagement. Reality: Records of Art.61 engagement (coaching session outcomes, DIH pre-assessment findings, TEF access agreements) are valuable evidence of good-faith compliance effort. In the event of a market surveillance investigation, documented Art.61 engagement demonstrates that the developer sought and followed authoritative guidance before commercialisation.

Art.61 Compliance Checklist

Phase 1: Initial Assessment (Before Development)

• Identify the national Digital Innovation Hub(s) relevant to your AI sector and country
• Request a DIH initial consultation to assess AI Act scope applicability
• Request a regulatory coaching session with the national competent authority if Annex III classification is unclear
• Determine whether TEF access is relevant (sector-specific testing datasets needed, physical simulation required)
• Identify the relevant TEF and its next open call schedule
• Register on the AI-on-Demand Platform for asset catalogue access and compute information
• Map your deployment countries and identify competent authority contacts for each

Phase 2: Development Phase

• Engage DIH for pre-conformity assessment of AI system design against Arts.9–15
• Submit TEF expression of interest (if relevant, matching call timeline)
• Request Art.60 guidance channel access if SME (parallel to Art.61 coaching)
• Establish regulatory coaching session record (outcome documented)
• Assess infrastructure jurisdiction using Art61InfrastructureAssessment
• Identify all CLOUD Act exposure points in development pipeline
• Migrate TEF-associated outputs to EU-sovereign storage
• Document all Art.61 engagement activities with dates and outcomes

Phase 3: TEF Engagement (If Applicable)

• TEF expression of interest submitted within open call window
• Technical review passed — TEF access confirmed
• Data access agreement signed (sector datasets)
• NDA and output ownership terms agreed before testing begins
• TEF outputs stored on EU-sovereign infrastructure
• TEF validation results documented in Art.11 technical documentation
• TEF contact person named in technical documentation

Phase 4: Multi-Member State Coordination

• Lead competent authority identified for multi-jurisdiction deployment
• Authority contacts established in all deployment countries
• EU AI Office contacted if cross-border issues arise (Art.62 coordination)
• Coaching opinions referenced in authority queries to other member states
• Cross-border coordination documented in deployment plan

Phase 5: Post-Development Documentation

• Art.61 benefit record compiled (coaching sessions, DIH services, TEF outputs)
• Infrastructure assessment completed — CLOUD Act exposures remediated
• Art.61 engagement records retained alongside Art.11 technical documentation
• DIH post-commercialisation support engaged (compliance support during deployment)
• TEF access record referenced in conformity assessment documentation

System Infrastructure

• Development environment: EU-sovereign (AIOD, EuroHPC, national HPC, or EU PaaS)
• Training infrastructure: EU-sovereign (no US cloud for TEF-associated training runs)
• Model weights: EU-sovereign storage (no AWS S3, Azure Blob, GCP Storage)
• TEF outputs: EU-sovereign storage (TEF-produced validation data, test results)
• CI/CD pipeline: EU-sovereign (no GitHub Actions run on US infrastructure for regulated output)
• Deployment: EU-sovereign (GDPR Art.59(1)(f) satisfied, CLOUD Act exposure eliminated)

Art.61 is part of the EU AI Act's Chapter VI innovation support framework. For related mechanisms, see our developer guides on Art.57 AI Regulatory Sandboxes, Art.60 SME and Startup Measures, and our EU AI Act Hosting Compliance guide for infrastructure decisions under the CLOUD Act exposure framework.