EU AI Act Art.74: Market Surveillance Authority Powers — Developer Guide (2026)

EU AI Act Article 74 establishes the investigative and enforcement powers that national market surveillance authorities (MSAs) hold over providers, deployers, and importers of high-risk AI systems. Where Art.73 defines what providers must report to MSAs, Art.74 defines what MSAs can demand in return — and the reach of those demands is substantial. An MSA with a reasonable suspicion that a high-risk AI system poses a risk may require physical access to premises, access to source code and training data, production of all Annex IV technical documentation, and suspension of the system pending investigation — all without advance judicial authorization in most member state transpositions.

For developers, Art.74 defines the threat model on the regulatory side: what a competent authority can compel you to produce, on what timeline, and with what enforcement backstop if you refuse. Art.74 is not merely a governance article — it is the legal mechanism that transforms Art.21 (provider cooperation obligations), Art.12 (logging requirements), Art.17 (quality management system documentation), and Art.73 (serious incident reporting) from paper obligations into enforceable ones. Understanding Art.74's scope before a system goes live shapes architecture decisions about where documentation is stored, which cloud provider hosts the inference infrastructure, and how quickly a provider can produce a compliance package under investigative pressure.

This guide covers Art.74(1)–(10) in full, the MSA investigation pipeline from Art.73 report to enforcement outcome, the Art.74 × Art.21 cooperation intersection, the Art.74 × Art.79 investigation procedure timeline, CLOUD Act jurisdiction risk when MSA demands access to data on US-hosted infrastructure, Python implementation for MSACooperationHandler and MSAInvestigationRequest, and the 40-item Art.74 compliance checklist.

Art.74 became applicable on 2 August 2026 as part of the Chapter IX market surveillance framework. From that date, any high-risk AI system on the EU market is subject to MSA oversight under Art.74 powers.

Art.74 at a Glance

Art.74(1): MSA Legal Basis and Powers Foundation

Art.74(1) establishes that MSAs exercise the powers granted under national market surveillance law (typically implementing Regulation (EU) 2019/1020 on market surveillance and compliance of products) as supplemented by the AI Act's specific provisions. This dual-layer structure means the powers available to any specific MSA depend on how the member state has transposed both the general market surveillance framework and the AI Act.

National MSA Designations

Developer obligation at Art.74(1): Know which national MSA has jurisdiction over your AI system before it goes live. For cross-border deployments (e.g., SaaS platforms serving 10 EU member states), the MSA of the member state where the provider's EU establishment is located typically leads coordination — but the AI system is subject to investigation by any MSA in any member state where it is deployed.

The Art.74(1) baseline is not theoretical. Germany's BNetzA has already published AI oversight guidelines. France's CNIL (data protection) and ARCOM (algorithmic systems) have overlapping jurisdiction for AI systems that process personal data. Developers deploying into the EU market without knowing their primary MSA are creating a governance gap that Art.74 investigations will expose immediately.

Art.74(2): MSA Access Rights — What They Can Demand

Art.74(2) defines the core investigative access rights of MSAs. These rights are the most architecturally significant provision of Art.74 for developers because they define what the regulatory perimeter looks like from the inside.

Art.74(2)(a): Documentation Access

MSAs may require production of:

• All Annex IV technical documentation (15+ mandatory components)
• QMS documentation under Art.17 (process controls, change management, testing logs)
• Post-market monitoring data and PMM plan (Art.72)
• Incident logs and Art.73 reports with supporting evidence
• Conformity assessment documentation (Art.43) and Declaration of Conformity (Art.48)
• EUAIDB registration details (Art.71)

Timeline: MSAs typically establish a response deadline in the investigation request — commonly 10 working days for non-urgent documentation requests, though Art.74(9) allows immediate demands for imminent serious risk situations.

Art.74(2)(b): Algorithm and Source Code Access

MSAs may require access to:

• Algorithms (model architecture, inference logic, decision pathways)
• Training data used to develop the system
• Test sets used to validate accuracy and robustness (Art.15)
• Source code when necessary to assess whether the AI system functions as documented

This provision is the one that most directly implicates infrastructure decisions. Algorithm access means:

1. The MSA can inspect whether the deployed model matches the technical documentation
2. The MSA can verify the accuracy, robustness, and bias evaluation results
3. The MSA can assess whether logging systems (Art.12) actually capture what the documentation claims they capture

Art.74(2)(c): Physical Access

MSAs may conduct on-site inspections of:

• Data centers hosting inference infrastructure
• Developer premises where the AI system is developed or maintained
• Deployer premises where the system operates in production

Physical access is the most intrusive power and typically requires coordination with law enforcement in most member state legal systems. However, it is a legally available power — not a theoretical one.

Art.74(3): MSA Enforcement Powers

When an MSA finds, through investigation, that a high-risk AI system poses a risk to health, safety, or fundamental rights, Art.74(3) grants a graduated enforcement toolkit:

Graduated Enforcement Ladder

The enforcement ladder is not necessarily sequential. An MSA with evidence of an imminent serious risk under Art.74(9) can impose immediate provisional measures — suspension, restriction, or recall — without first following the corrective action notice procedure. The provisional measure can be imposed first; the full investigation procedure under Art.79 follows.

Developer Response Requirements Under Art.74(3)

When an MSA issues a corrective action notice:

1. Acknowledge receipt within the MSA's stated deadline (failure to acknowledge triggers Art.74(8) non-cooperation exposure)
2. Designate an MSA response lead — a named contact with technical authority to commit to corrective actions
3. Provide a corrective action plan with timeline — the MSA sets the deadline, but the plan's credibility affects whether provisional measures are added
4. Update technical documentation (Annex IV) to reflect the corrective actions taken
5. Notify deployers of any changes that affect the AI system they operate under Art.30(5) cooperation obligation

Art.74(4): Multi-Authority Coordination

Art.74(4) requires MSAs to coordinate their investigations with other national competent authorities when an AI system falls within the scope of multiple regulatory regimes. This is the provision that creates multi-authority exposure for a single AI system.

Common Multi-Authority Scenarios

Developer implication: A single investigation under Art.74 can result in coordinated enforcement from multiple national authorities simultaneously. An AI healthcare triage system under investigation by the health MSA can trigger simultaneous GDPR investigation by the data protection authority under Art.74(4) coordination. The provider faces parallel compliance obligations, parallel documentation production, and potentially parallel fines under separate legal regimes.

This multi-authority coordination is also why the CLOUD Act jurisdiction risk matters at Art.74 — it is not only the primary MSA that may demand access to data stored on US cloud infrastructure. A coordinated investigation involving the data protection authority compounds the jurisdiction complexity.

Art.74(5)–(6): AI Office Powers for GPAI Models

Arts.74(5) and (6) establish that the AI Office (rather than national MSAs) holds primary investigative authority over GPAI models with systemic risk (Art.51 classification). This creates a separate, parallel investigation track.

AI Office vs. National MSA — GPAI Developers

A GPAI model provider whose model is integrated into a high-risk AI system deployed by third-party developers faces dual investigative exposure: the national MSA investigating the high-risk AI system (Art.74(1)–(4)) AND the AI Office investigating the GPAI model itself (Art.74(5)–(6)). Art.73(3) already establishes that serious incidents involving GPAI components must be dual-reported — Art.74 establishes the dual investigation architecture that follows those reports.

Art.74(7): Cross-EU Enforcement Notification

When an MSA takes enforcement action under Art.74(3) — particularly use restriction, suspension, or withdrawal — Art.74(7) requires notification to:

• The Commission (via RAPEX/ICSMS notification system)
• All other MSAs in EU member states

This notification triggers a cross-EU market consequence from a single national MSA action. If Germany's BNetzA orders market withdrawal of a high-risk AI system for serious risk, that notification reaches French, Dutch, Polish, and all other EU MSAs simultaneously. Each receiving MSA must then assess whether to take equivalent protective measures in its own territory.

Practical developer consequence: An Art.74(7) notification effectively means a single MSA enforcement decision can result in coordinated market withdrawal across the entire EU single market within days. A provider cannot rely on "fighting it out" in one member state while continuing operations in others — the notification mechanism makes that strategy unavailable.

Art.74(8): Cooperation Obligation

Art.74(8) states that providers, deployers, and importers must cooperate fully with MSA investigations and must not obstruct, impede, or fail to respond to lawful demands. Non-cooperation is independently sanctionable under Art.74(10).

Non-cooperation includes:

• Failing to respond to documentation requests within the specified deadline
• Providing incomplete or misleading documentation
• Refusing physical access when lawfully ordered
• Destroying or altering documentation after an investigation has commenced
• Delaying provision of source code or algorithm access

Art.99(5) fines for non-cooperation: Up to €15 million or 3% of total worldwide annual turnover (whichever is higher) — the same penalty scale as non-conformity fines, applied separately for each instance of non-cooperation. Non-cooperation in the context of an active investigation can trigger fines that compound with underlying non-conformity fines.

Art.74(9): Immediate Provisional Measures

Art.74(9) grants MSAs the power to impose immediate provisional measures when a high-risk AI system presents an imminent serious risk that cannot await the standard investigation procedure. This is the emergency shutdown provision of the AI Act.

Imminent Serious Risk — MSA Assessment Criteria

An MSA assessing whether Art.74(9) applies evaluates:

1. Imminence: Is harm occurring now or about to occur? (Not merely possible at some future point)
2. Severity: Does the risk involve death, serious health harm, fundamental rights violation, or critical infrastructure disruption?
3. Causal link: Is the AI system the plausible cause of the risk (even if not yet proven)?
4. Urgency: Would waiting for the standard procedure result in harm that cannot be prevented or remedied?

Art.74(9) provisional measures are time-limited. They must be followed by the full Art.79 investigation procedure. If the investigation clears the system, provisional measures must be lifted. If the investigation confirms the risk, Art.74(3) enforcement measures follow the provisional period.

Developer Incident Response for Art.74(9) Scenarios

Art.74(9) Provisional Measure Received
│
├── Hour 0–4: Legal counsel engagement
│   └── Confirm MSA authority, measure scope, and appeal rights
│
├── Hour 4–24: Technical triage
│   └── Preserve all logs, documentation, model artifacts
│   └── DO NOT alter any AI system configuration pending investigation
│   └── Notify deployers under Art.30(5) obligation
│
├── Day 1–3: Response package preparation
│   └── Annex IV documentation production
│   └── Incident log extraction (Art.12)
│   └── QMS documentation (Art.17)
│   └── Statement of technical position
│
├── Day 3–10: MSA engagement
│   └── Formal response to MSA with compliance package
│   └── Request for Art.79 investigation timeline
│
└── Day 10+: Art.79 investigation procedure
    └── Full investigation with technical assessments
    └── Corrective action plan if non-conformity found

Art.74 × Art.21: Cooperation Obligations — The Two-Sided Obligation

Art.21 and Art.74 are the two sides of the same obligation. Art.21 defines what providers must do when MSAs exercise their powers. Art.74 defines what MSAs can demand. Understanding both together defines the full legal relationship.

Architecture implication: Art.21 compliance is not a documentation exercise — it requires that the technical architecture can actually fulfill the cooperation obligation when an Art.74 investigation demand arrives. This means:

1. Documentation is producible within 10 working days — Annex IV documents must be maintained in current, accessible state, not reconstructed from memory after an investigation begins
2. Algorithm access is feasible — if inference infrastructure is managed by a third-party cloud provider under a contract that does not permit source code disclosure to third parties, Art.21 compliance is architecturally compromised
3. Training data is accessible — if training data is stored on ephemeral infrastructure that is cleaned after training, Art.74(2)(b) demands cannot be met
4. Logging is audit-ready — Art.12 logs must be exportable and interpretable by MSA investigators who are not familiar with your internal systems

Art.74 × Art.73: Investigation Trigger

The most frequent trigger for Art.74 investigations is a serious incident report under Art.73. The investigation pipeline from Art.73 report to Art.74 enforcement follows a defined structure:

Art.73 Serious Incident Report Filed by Provider
│
├── MSA Receives Report (Art.73(1))
│   └── MSA assesses whether Art.74 investigation warranted
│
├── MSA Opens Art.74 Investigation
│   └── Documentation request (Art.74(2)(a))
│   └── Algorithm access request (Art.74(2)(b)) if causation unclear
│   └── Physical access if source of harm needs on-site assessment
│
├── MSA Determines Outcome
│   ├── No conformity issue → investigation closed, provider notified
│   ├── Conformity issue, correctable → Art.74(3) corrective action notice
│   ├── Serious risk confirmed → Art.74(3) restriction/suspension/withdrawal
│   └── Imminent serious risk → Art.74(9) provisional measures (can precede investigation)
│
├── MSA Notifies Commission and Other MSAs (Art.74(7))
│   └── RAPEX/ICSMS notification
│   └── Other MSAs assess equivalent measures
│
└── Provider Compliance and Follow-Up
    └── Art.73(5) follow-up report with root cause and corrective actions
    └── Art.79 full investigation procedure for formal findings

The critical developer insight is that an Art.73 preliminary report — which does not require root cause analysis — starts the Art.74 investigation clock. The MSA does not wait for the Art.73(5) follow-up report to begin exercising Art.74 powers. A provider that files an Art.73 preliminary report should treat the Art.74 documentation production obligation as simultaneously active.

Art.74 × Art.79: MSA Investigation Procedure

Art.79 defines the investigation procedure that MSAs must follow when exercising Art.74 powers. Together, Art.74 (powers) and Art.79 (procedure) define the complete MSA investigation framework.

Art.79 investigation timeline: The AI Act does not mandate a specific investigation completion deadline. However, Art.79 combined with Art.74(9) provisional measures creates a structural incentive: if an MSA cannot complete the investigation within a reasonable period, provisional measures (if any) remain in effect, making extended investigations commercially costly for providers.

CLOUD Act × Art.74: Jurisdiction Risk

Art.74's access rights create a specific CLOUD Act jurisdiction problem when a provider's technical infrastructure — source code repositories, training data, inference infrastructure, documentation — is hosted on US cloud providers subject to the CLOUD Act (18 U.S.C. § 2713).

The Dual-Compellability Architecture

When an MSA opens an Art.74 investigation and demands access to data stored on US-cloud infrastructure, the provider faces three simultaneous obligations:

1. EU MSA cooperation (Art.74 + Art.21): Disclose immediately when lawfully demanded
2. GDPR Art.48: International data transfer to a foreign authority requires a GDPR-compliant legal basis — a demand from an EU MSA satisfies this; a parallel US government demand does not
3. CLOUD Act: The US government can independently compel the cloud provider to produce the same data under a CLOUD Act order

The conflict: GDPR Art.48 restricts compliance with foreign court orders for personal data transfers. A provider that stores training data (containing personal data) on a US cloud provider faces a scenario where the US government can compel production of data that the provider cannot voluntarily transfer without violating GDPR. The EU MSA is compelled to cooperate simultaneously.

EU-native infrastructure resolution: A provider that stores all Art.74-relevant data (documentation, source code, training data, logs) on EU-native infrastructure — hosted by an EU-incorporated cloud provider with no US presence — eliminates the CLOUD Act compellability entirely. The EU MSA's Art.74 demand is the only legal order that applies. This is the single-regime advantage: one legal order, one disclosure decision, no conflict.

US Cloud Infrastructure          EU-Native Infrastructure
──────────────────────           ────────────────────────
Art.74 MSA demand ──────┐        Art.74 MSA demand ──────┐
CLOUD Act order  ──────┤        (no CLOUD Act)            │
                         ↓                                 ↓
                Provider caught                    Single legal order
                  in conflict                      Full MSA cooperation
                  GDPR Art.48                      GDPR compliant
                  vs. CLOUD Act                    No conflict

Python Implementation

MSA Cooperation Infrastructure

from __future__ import annotations
from dataclasses import dataclass, field
from datetime import date, timedelta
from enum import Enum
from typing import Literal


class MSAAccessType(Enum):
    DOCUMENTATION = "documentation"       # Annex IV, QMS, PMM
    ALGORITHM = "algorithm"               # model architecture, inference logic
    SOURCE_CODE = "source_code"           # full source code review
    TRAINING_DATA = "training_data"       # dataset access
    ON_PREMISES = "on_premises"           # physical site inspection
    LOGGING_SYSTEM = "logging_system"     # Art.12 audit logs


class MSAInvestigationStatus(Enum):
    RECEIVED = "received"
    ACKNOWLEDGED = "acknowledged"
    RESPONSE_PREPARED = "response_prepared"
    SUBMITTED = "submitted"
    MSA_ASSESSMENT = "msa_assessment"
    PROVISIONAL_MEASURE = "provisional_measure"
    CORRECTIVE_ACTION = "corrective_action"
    CLOSED_NO_FINDING = "closed_no_finding"
    ENFORCEMENT_ACTIVE = "enforcement_active"


@dataclass
class MSAInvestigationRequest:
    request_id: str
    msa_authority: str                          # e.g., "DE-BNetzA", "FR-ARCOM"
    received_date: date
    access_types: list[MSAAccessType]
    response_deadline_days: int                 # working days from received_date
    is_provisional_measure: bool = False        # Art.74(9) emergency measure
    triggering_incident_ref: str | None = None  # Art.73 incident report ID
    is_art79_formal_investigation: bool = False

    @property
    def response_deadline_date(self) -> date:
        """Calculate absolute deadline (counting working days)."""
        current = self.received_date
        remaining = self.response_deadline_days
        while remaining > 0:
            current += timedelta(days=1)
            if current.weekday() < 5:  # Monday–Friday
                remaining -= 1
        return current

    @property
    def is_overdue(self) -> bool:
        return date.today() > self.response_deadline_date

    def requires_source_code_access(self) -> bool:
        return MSAAccessType.SOURCE_CODE in self.access_types

    def requires_training_data_access(self) -> bool:
        return MSAAccessType.TRAINING_DATA in self.access_types

    def requires_algorithm_access(self) -> bool:
        return (
            MSAAccessType.ALGORITHM in self.access_types
            or self.requires_source_code_access()
        )


@dataclass
class CompliancePackage:
    """Structured response package for Art.74 MSA investigation."""
    request_id: str
    preparation_date: date
    annex_iv_documents: list[str] = field(default_factory=list)
    qms_documents: list[str] = field(default_factory=list)
    pmm_plan_reference: str | None = None
    art12_log_extract: str | None = None
    conformity_assessment_ref: str | None = None
    declaration_of_conformity_ref: str | None = None
    euaidb_registration_number: str | None = None
    art73_incident_reports: list[str] = field(default_factory=list)

    def is_complete_for_documentation_request(self) -> bool:
        """Verify all mandatory Annex IV documentation is present."""
        mandatory = [
            bool(self.annex_iv_documents),
            bool(self.qms_documents),
            self.conformity_assessment_ref is not None,
            self.declaration_of_conformity_ref is not None,
            self.euaidb_registration_number is not None,
        ]
        return all(mandatory)

    def completeness_gaps(self) -> list[str]:
        gaps = []
        if not self.annex_iv_documents:
            gaps.append("Annex IV technical documentation missing")
        if not self.qms_documents:
            gaps.append("QMS documentation (Art.17) missing")
        if not self.conformity_assessment_ref:
            gaps.append("Conformity assessment reference missing")
        if not self.declaration_of_conformity_ref:
            gaps.append("Declaration of Conformity (Art.48) missing")
        if not self.euaidb_registration_number:
            gaps.append("EUAIDB registration number (Art.71) missing")
        if not self.pmm_plan_reference:
            gaps.append("PMM plan (Art.72) reference missing")
        return gaps


@dataclass
class MSACooperationHandler:
    """
    Manages the Art.74 MSA cooperation lifecycle.
    Implements Art.21 provider cooperation obligation.
    """
    system_id: str
    national_msa: str
    response_lead_name: str
    response_lead_email: str
    infrastructure_jurisdiction: Literal["eu_native", "us_cloud", "mixed"]

    def assess_cloud_act_risk(
        self, request: MSAInvestigationRequest
    ) -> dict[str, str | bool]:
        """
        Assess CLOUD Act dual-compellability risk for MSA request.
        Critical for Art.74(2)(b) demands (algorithm, training data, source code).
        """
        high_risk_types = {
            MSAAccessType.SOURCE_CODE,
            MSAAccessType.TRAINING_DATA,
            MSAAccessType.ALGORITHM,
        }
        involves_sensitive = bool(
            high_risk_types & set(request.access_types)
        )

        if self.infrastructure_jurisdiction == "eu_native":
            return {
                "cloud_act_risk": False,
                "gdpr_art48_issue": False,
                "jurisdiction": "EU-only — single legal order applies",
                "recommendation": "Cooperate directly with MSA under Art.21",
            }
        elif self.infrastructure_jurisdiction == "us_cloud" and involves_sensitive:
            return {
                "cloud_act_risk": True,
                "gdpr_art48_issue": True,
                "jurisdiction": "Dual-compellability: EU MSA + US CLOUD Act possible",
                "recommendation": (
                    "Engage legal counsel before disclosure. "
                    "Assess GDPR Art.48 for personal data in training sets. "
                    "Consider migrating sensitive assets to EU-native infrastructure."
                ),
            }
        else:
            return {
                "cloud_act_risk": True,
                "gdpr_art48_issue": involves_sensitive,
                "jurisdiction": "Mixed — partial CLOUD Act exposure",
                "recommendation": (
                    "Audit which specific assets are on US infrastructure "
                    "before producing requested items."
                ),
            }

    def prepare_response_package(
        self, request: MSAInvestigationRequest
    ) -> CompliancePackage:
        """
        Build Art.21 compliance response package for Art.74 request.
        Returns package with completeness gaps listed for remediation.
        """
        package = CompliancePackage(
            request_id=request.request_id,
            preparation_date=date.today(),
        )
        # Populate from document management system (implementation-specific)
        return package

    def is_art74_9_provisional_measure(
        self, request: MSAInvestigationRequest
    ) -> bool:
        return request.is_provisional_measure

    def calculate_non_cooperation_fine_exposure(
        self, annual_worldwide_turnover: float
    ) -> dict[str, float]:
        """Art.99(5): Non-cooperation fine = max(€15M, 3% of global turnover)."""
        return {
            "fixed_maximum": 15_000_000.0,
            "turnover_based": annual_worldwide_turnover * 0.03,
            "applicable_fine": max(
                15_000_000.0, annual_worldwide_turnover * 0.03
            ),
        }

Art.74 Compliance Checklist — 40 Items

Pre-Deployment (Before EU Market Placement)

• 1. Identified primary national MSA for each EU member state where system is deployed
• 2. Designated named MSA response lead with technical authority and legal mandate
• 3. Annex IV technical documentation maintained in current, accessible state (not reconstruction-dependent)
• 4. QMS documentation (Art.17) audit-ready for immediate MSA production
• 5. Art.12 logging system configured for MSA-interpretable log export
• 6. Art.72 PMM plan current and accessible as Annex IV Section 6 document
• 7. Art.71 EUAIDB registration number obtained and documented in Annex IV
• 8. Declaration of Conformity (Art.48) and CE marking documentation accessible
• 9. Assessed infrastructure jurisdiction: EU-native vs. US-cloud vs. mixed
• 10. CLOUD Act risk assessment completed for Art.74(2)(b) access scenarios

Art.74(2): Access Readiness

• 11. Annex IV documentation production workflow tested (can deliver in ≤10 working days)
• 12. Algorithm documentation accurate and matches deployed model (not outdated architecture docs)
• 13. Training data access procedure documented (data location, access mechanism, legal basis for MSA disclosure)
• 14. Source code access procedure defined (MSA access via controlled review environment, not open credential sharing)
• 15. Physical access coordination procedure defined for on-site inspection scenario
• 16. Incident log export procedure tested (Art.12 records accessible without developer intervention)
• 17. Art.73 incident reports archive accessible (all historical reports, including follow-up reports)
• 18. Notified body certificates and conformity assessment documents accessible

Art.74(3): Enforcement Response Readiness

• 19. Corrective action response procedure defined (acknowledgment → plan → execution → documentation update)
• 20. Use restriction suspension protocol defined (who authorizes, which systems are affected, deployer notification)
• 21. Emergency shutdown capability documented for Art.74(9) provisional measure scenarios
• 22. Deployer notification procedure ready (Art.30(5) — inform deployers of MSA-ordered changes)
• 23. Legal counsel on retainer familiar with AI Act enforcement procedure
• 24. Internal escalation chain defined (developer → legal → executive → board for Art.74(9) scenarios)
• 25. Art.99(5) non-cooperation fine exposure calculated and risk-accepted by governance body

Art.74(4)–(6): Multi-Authority and GPAI Preparation

• 26. Multi-authority map completed (GDPR authority, sectoral authority, AI Act MSA for each deployment context)
• 27. GPAI component used? Art.74(5)–(6) AI Office cooperation obligation assessed
• 28. GPAI provider contract includes Art.21/Art.74 cooperation rights (can AI Office contact GPAI provider directly?)
• 29. Dual investigation protocol defined: national MSA + AI Office simultaneous investigation response
• 30. Data protection authority coordination assessed for AI systems processing personal data

Art.74(7)–(8): Cross-EU and Cooperation Obligations

• 31. Art.74(7) notification impact assessed: if one MSA enforces, all EU MSAs are notified
• 32. Multi-market response plan: can provider respond to coordinated multi-MSA investigation?
• 33. Non-obstruction checklist: investigation preservation order ready (no documentation destruction/modification)
• 34. Art.74(8) training: technical staff aware that failing to cooperate triggers independent fine
• 35. Documentation version control: Annex IV changes tracked so MSA can see historical state at any past date

Art.74(9): Provisional Measures Scenario

• 36. Art.74(9) recognition criteria defined for operations team (how to identify MSA provisional measure)
• 37. 4-hour legal escalation procedure for Art.74(9) receipt documented
• 38. Evidence preservation (no config changes, no log deletion) procedure for Art.74(9) active period
• 39. Art.79 investigation timeline request procedure documented (formally request investigation start date)
• 40. Appeal rights under national administrative law assessed and documented in incident response plan

Art.74 × Art.82: MSA Notifications to Commission

When an MSA takes enforcement action under Art.74(3) or (9), Art.82 requires the MSA to notify the Commission with:

• Identity of the provider and AI system
• Nature of the non-conformity or risk
• Measures taken and their justification
• Results of any testing and technical assessment

Developer consequence: An Art.82 notification is a public enforcement record. Commission publications of Art.82 notifications are expected to become publicly accessible under EU transparency requirements. A provider subject to an Art.74 enforcement action and subsequent Art.82 notification faces reputational exposure that extends beyond the direct compliance cost.

The Art.82 notification also triggers cross-EU protective measure consideration by all other MSAs — making Art.82 the mechanism by which a single-country enforcement action becomes a pan-EU market consequence (as described under Art.74(7)).

See Also

• EU AI Act Art.73: Serious Incident Reporting — Developer Guide — What providers report to MSAs that triggers Art.74 investigations
• EU AI Act Art.72: Post-Market Monitoring Plan — Developer Guide — PMM data that MSAs may demand under Art.74(2)
• EU AI Act Art.71: EU AI Database — Developer Guide — EUAIDB registration number required in MSA compliance packages
• EU AI Act Conformity Assessment — Developer Guide — Conformity assessment documentation that MSAs access under Art.74
• EU NIS2 + AI Act: Critical Infrastructure Double Compliance — MSA coordination with NIS2 authorities under Art.74(4)