EU AI Act Art.79: Procedure for AI Systems Presenting Risk at National Level — Developer Guide (2026)

EU AI Act Article 79 defines the formal investigation and corrective action procedure that market surveillance authorities (MSAs) follow when an AI system is believed to present a risk to health, safety, or fundamental rights — regardless of whether that system is non-compliant. Art.79 is the procedural complement to Art.74's enforcement powers: Art.74 grants MSAs the right to investigate and demand documentation; Art.79 prescribes the formal sequence those investigations must follow, including provider hearing rights, corrective measure requirements, and cross-border notification obligations.

The Art.79 procedure matters to developers because it defines the procedural boundary between preliminary MSA scrutiny and formal enforcement action. A high-risk AI system can be subject to Art.74(2) documentation demands and Art.74(9) provisional measures before an Art.79 formal investigation is initiated. Once an MSA opens a formal Art.79 evaluation, the timeline and obligations become more structured: the provider must be given a hearing, corrective measure orders must specify legal basis and appeal rights, and the Commission and other Member States must be notified if measures are taken — triggering the possibility of EU-level harmonisation under Art.80.

Understanding Art.79 also clarifies the Art.79 vs Art.82 procedural fork: Art.79 applies when an AI system presents a risk (whether compliant or not); Art.82 applies when an AI system is non-compliant (whether or not it currently causes harm). A developer building a technically-defective QMS under Art.17 faces Art.82 non-compliance procedure. A developer whose compliant AI system causes an unforeseen serious incident faces Art.79 risk procedure. These are parallel tracks with distinct obligations and different cross-border escalation paths.

This guide covers Art.79(1)–(7) in full, the Art.79 × Art.74 investigative powers overlap, the Art.79 → Art.80 Union escalation trigger, Art.81 compliant-but-risky systems, Art.79 × Art.82 procedural fork analysis, Art.79 × Art.70 confidentiality during investigation, CLOUD Act jurisdiction risk for investigation-demanded data on US infrastructure, Python implementation for AISystemRiskEvaluationRequest and RiskInvestigationResponse, and the 40-item Art.79 developer compliance checklist.

Art.79 became applicable on 2 August 2026 as part of the Chapter IX market surveillance enforcement framework.

Art.79 at a Glance

Art.79(1): Triggering the Formal Evaluation

Art.79(1) gives the MSA the right to initiate a formal evaluation of an AI system where it has reasonable grounds to consider that the system presents a risk to health, safety, or fundamental rights. This reasonable grounds standard is lower than a finding of non-compliance — an MSA can open an Art.79 evaluation based on:

• A serious incident report submitted under Art.73 indicating a pattern of harm
• Third-party complaint or alert by a notified body, deployer, or affected party
• Market surveillance intelligence from other Member States via Art.79(5) notifications
• Proactive monitoring results indicating concerning performance metrics
• Scientific Panel (Art.66) assessment flagging systemic risk indicators in a GPAI component

The Art.79(1) evaluation is distinct from Art.74(2) document demands. An MSA may issue Art.74(2)(a) documentation demands before opening an Art.79 evaluation — the document review may then inform whether Art.79 grounds exist. Once Art.79 is formally initiated, the investigation becomes structured by the Art.79 procedural requirements.

Art.79(1) Cooperation Obligation

During an Art.79 evaluation, the provider, deployer, and any other relevant operators must cooperate with the MSA. This cooperation obligation extends Art.21's general cooperation requirements into the formal investigation context:

Providers who obstruct an Art.79 evaluation are subject to Art.99(5) fines up to €15 million or 3% of global annual turnover — the non-cooperation penalty applies to Art.79 obstruction as well as Art.74(10) obstruction.

Art.79(2): Corrective Measures, Withdrawal, and Recall

Where an Art.79 evaluation confirms either non-compliance with this Regulation or a risk to health, safety, or fundamental rights, the MSA is empowered to require one or more of the following:

The Art.79(2) Corrective Measure Hierarchy

Art.79(2) Confirmed Risk or Non-Compliance
├── Level 1: Corrective Action (default)
│   ├── Fix non-compliance within specified period
│   ├── Implement additional risk mitigation measures
│   └── Provide updated documentation / QMS amendments
│
├── Level 2: Use Restriction
│   ├── Restrict deployment to specific use contexts
│   ├── Restrict deployment geography within Member State
│   └── Require deployer notification / user disclosure update
│
├── Level 3: Market Withdrawal
│   ├── Remove system from the market (cease new placements)
│   ├── Notify downstream deployers
│   └── Coordinate with EUAIDB registration (Art.71 status update)
│
└── Level 4: Recall
    ├── Remove already-deployed instances
    ├── Notify affected end users
    └── Cooperate with affected deployers on transition

The MSA selects the measure proportionate to the severity of risk. A temporary accuracy degradation discovered through Art.72 PMM that creates manageable risk may result in a corrective action order. An AI system deployed in a medical context that produces systematically harmful outputs may trigger recall.

Mandatory Content of Art.79(2) Corrective Measure Orders

Art.79(2) specifies that corrective measure orders must include:

1. Legal basis — specific provision(s) of the EU AI Act or associated Annex that the system violates or that grounds the risk finding
2. Timeline for compliance — a reasonable period commensurate with the nature and severity of the risk
3. Right to a hearing — the provider must have the opportunity to respond before final measures take effect (except for provisional measures under Art.74(9))
4. Appeal procedures — available judicial or administrative remedies, competent courts, and appeal deadlines under national law

This four-element requirement is a due process floor. Providers who receive Art.79(2) corrective measure orders without all four elements can challenge the procedural validity of the order in national administrative courts.

Art.79(3): National Competent Authority Notification

When an MSA takes measures under Art.79(2), it must inform the national competent authority (NCA) — the body designated under Art.74(1) that supervises market surveillance in that member state. In several EU member states, the MSA and the NCA are the same body (e.g., Germany's BNetzA for digital services AI). In sectoral contexts, they are distinct: a healthcare MSA taking Art.79(2) action against a medical AI system informs the NCA, which in turn coordinates with the health ministry.

NCA notification matters to developers because the NCA may:

• Escalate findings to the European AI Board under Art.65 for horizontal consistency review
• Share findings with other NCAs under Art.78(2) for coordinated surveillance in similar sectors
• Trigger Art.80 Union safeguard review if the measure has potential EU-wide implications

Art.79(4): Proactive Risk Notification by Operators

Art.79(4) creates a proactive obligation for providers, deployers, distributors, and importers: they must immediately notify the MSA if they become aware that an AI system they are involved with presents a risk to health, safety, or fundamental rights — without waiting for MSA initiation.

This is distinct from Art.73 serious incident reporting (which triggers after a specific incident occurs). Art.79(4) applies to systemic risk awareness that may not (yet) have resulted in a specific incident:

Art.79(4) Notification Content Requirements

An Art.79(4) proactive risk notification should include:

@dataclass
class ProactiveRiskNotification:
    """Art.79(4) proactive risk notification to national MSA."""
    
    ai_system_euaidb_id: str            # Art.71 registration number
    notifying_party_role: str           # "provider" | "deployer" | "distributor"
    risk_description: str               # Nature of identified risk
    affected_persons_category: str      # Health / Safety / Fundamental Rights
    affected_scope: str                 # Estimated number of affected persons/deployments
    risk_detection_method: str          # PMM / external research / internal audit
    detection_date: date                # When operator became aware
    interim_measures_taken: list[str]   # Any immediate mitigations already implemented
    proposed_corrective_actions: list[str]  # Suggested remedies
    evidence_package_location: str      # Where Annex IV + PMM data is available for MSA

Art.79(5): Cross-Border Notification to Commission and Member States

When an MSA takes measures under Art.79(2), it must immediately notify:

• The European Commission
• All other Member States — via the RAPEX/ICSMS notification system used for general product safety

This cross-border notification has two significant consequences for providers:

Consequence 1: EU-Wide Market Impact An Art.79(2) measure taken by a single national MSA (e.g., the German BNetzA) becomes visible to every other Member State MSA. If a provider's AI system is used across 12 EU member states, a German Art.79(2) corrective action order may prompt the French, Dutch, and Swedish MSAs to open their own Art.79(1) evaluations under the same reasonable grounds now documented by Germany's findings.

Consequence 2: Commission Review Trigger (Art.79(6)) The Art.79(5) notification triggers the Art.79(6) Commission consultation process, in which the Commission may decide the national measure is or is not justified. This means a single MSA measure can escalate to Commission-level review affecting the entire EU market.

Art.79(5) Notification Chain

Provider/Deployer becomes aware of risk
        ↓
Art.79(4): Proactive notification to national MSA
        ↓ (or Art.73 incident report triggers MSA initiation)
Art.79(1): MSA opens formal evaluation
        ↓
Art.74(2): MSA demands documentation/access during evaluation
        ↓
Art.79(2): MSA confirms risk → issues corrective measure order
        ↓
Art.79(3): MSA informs National Competent Authority
        ↓
Art.79(5): MSA notifies Commission + all Member States (RAPEX/ICSMS)
        ↓
Art.79(6): Commission consults Member States + operators → justified or unjustified
        ↓                          ↓
Art.79(7a): Unjustified          Art.79(7b): Justified
→ Member State withdraws         → Other MSAs may adopt comparable measures
  the measure                    → Art.80 Union safeguard if EU-wide action needed

Art.79(6) and (7): Commission Decision and EU-Wide Harmonisation

After receiving Art.79(5) notification, the Commission enters consultation with:

• The Member State MSA that took the measure
• Other Member States
• The relevant operator (provider, deployer, or both)

The Commission's decision determines the EU-wide fate of the national measure:

Art.79(7) Justified Decision: The Commission determines the national measure is justified. Other Member States are informed and may take comparable measures against the same AI system in their jurisdiction. This effectively converts a national enforcement action into a coordinated EU-wide enforcement response — without requiring a separate Art.80 Union safeguard procedure.

Art.79(7) Unjustified Decision: The Commission determines the national measure is not justified (e.g., the MSA applied an incorrect risk standard, or the risk assessment methodology was flawed). The Member State must withdraw the measure. The provider's Art.79(3) appeal right provides a parallel pathway to challenge the measure nationally while the Commission review proceeds.

Art.79 vs Art.82: The Critical Procedural Fork

The most important developer-facing distinction in Chapter IX is the fork between Art.79 (risk procedure) and Art.82 (formal non-compliance procedure):

The Practical Scenario: A clinical decision support AI system produces an unexopected pattern of harmful recommendations (root cause: training data drift). The Art.73 incident report triggers an MSA Art.79(1) evaluation (risk procedure). During the evaluation, the MSA discovers the Art.72 PMM plan failed to include the drift detection metrics required by Art.72(3)(b). This non-compliance — separate from the risk — triggers an Art.82 formal non-compliance procedure running in parallel with the Art.79 risk procedure.

Developers should plan for the possibility that a single incident triggers both Art.79 and Art.82 simultaneously, requiring coordinated responses under different procedural frameworks.

Art.79 × Art.81: Compliant Systems That Present Risk

Art.81 addresses the scenario where an AI system is fully compliant with all EU AI Act requirements but nonetheless presents a risk to health, safety, or fundamental rights. This can occur when:

• Compliance requirements prove insufficient for an edge case not anticipated in the legislation
• A new class of harm emerges not covered by existing high-risk AI categories
• An AI system operates in novel deployment context changing its risk profile despite unchanged technical parameters

Art.81 outcomes may include:

1. Commission adopting delegated acts to amend Annex requirements
2. MSA coordinating with notified bodies to revise conformity assessment scope
3. Art.9 risk management system mandatory update to address the newly-identified risk

For developers: Art.81 means that achieving full EU AI Act compliance does not create an absolute safe harbour against Art.79 investigations. A system whose conformity assessment was accurate at deployment time can be subject to Art.79 evaluation if post-market monitoring reveals risk that was not present or foreseeable at the time of assessment.

Art.79 × Art.70: Confidentiality During Investigation

Art.70 establishes confidentiality obligations for MSAs, notified bodies, and Commission officials regarding information obtained during AI Act procedures. Art.79 investigations fall within Art.70's scope:

Art.70(3) Exception: Confidentiality protections do not apply where disclosure is necessary to protect the health or safety of persons. An MSA investigating an imminent serious risk under Art.79 may disclose otherwise-confidential information where the public health rationale justifies it. Providers cannot rely on Art.70 trade secret protection to prevent disclosure of risk-relevant information in imminent harm scenarios.

CLOUD Act × Art.79: Jurisdiction Risk for Investigation Data

Art.79 investigations generate and consume large volumes of documentation: Annex IV technical files, QMS records, PMM data, Art.12 logs, incident reports, corrective action correspondence. Where this data is stored on US-hosted cloud infrastructure (AWS, Azure, GCP, Oracle Cloud US regions), it is potentially subject to US Department of Justice orders under the CLOUD Act — simultaneously with EU MSA access demands under Art.79.

The Dual Compellability Problem for Art.79 Investigation Data

EU-Native Infrastructure Resolution: Hosting Annex IV documentation, Art.12 logs, QMS records, PMM data, and development infrastructure on EU-native PaaS infrastructure (processing and storing data exclusively in EU member state jurisdictions) eliminates the CLOUD Act overlap. The MSA's Art.79 investigation proceeds under EU law as the single governing jurisdiction; US DOJ orders targeting EU-sovereign data have no operational pathway.

Python Implementation: Art.79 Investigation Response

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

class InvestigationTrigger(Enum):
    ARTICLE_73_INCIDENT_REPORT = "art73_incident_report"
    ARTICLE_74_DOCUMENT_DEMAND = "art74_document_demand_led_to_art79"
    ARTICLE_79_4_PROACTIVE_NOTIFICATION = "art79_4_operator_proactive"
    THIRD_PARTY_COMPLAINT = "third_party_complaint"
    MSA_OWN_INITIATIVE = "msa_own_initiative"
    OTHER_MSA_NOTIFICATION = "art79_5_cross_border_information"

class Art79MeasureType(Enum):
    CORRECTIVE_ACTION = "corrective_action"
    USE_RESTRICTION = "use_restriction"
    MARKET_WITHDRAWAL = "market_withdrawal"
    RECALL = "recall"
    NO_MEASURE_REQUIRED = "no_measure"

@dataclass
class AISystemRiskEvaluationRequest:
    """Represents an Art.79(1) formal MSA evaluation initiation."""
    
    msa_reference_number: str
    msa_country: str                    # ISO 3166-1 alpha-2 (DE, FR, NL...)
    ai_system_euaidb_id: str            # Art.71 EUAIDB registration ID
    trigger: InvestigationTrigger
    trigger_reference: str              # Art.73 report ID, Art.74 demand ref, etc.
    initiation_date: date
    evaluation_scope: list[str]         # Which requirements are under evaluation
    documentation_deadline: date        # When provider must supply docs
    hearing_date: Optional[date]        # Art.79(2): right to hearing before measure
    
    def response_deadline(self) -> date:
        """Calculate provider response deadline (typically 10-15 working days)."""
        working_days = 10
        current = self.initiation_date
        counted = 0
        while counted < working_days:
            current = current + timedelta(days=1)
            if current.weekday() < 5:  # Mon-Fri
                counted += 1
        return current
    
    def is_provisional_measure_parallel(self) -> bool:
        """Art.74(9) provisional measures may run parallel to Art.79 evaluation."""
        urgent_triggers = [
            InvestigationTrigger.ARTICLE_73_INCIDENT_REPORT,
        ]
        return self.trigger in urgent_triggers
    
    def requires_art82_parallel(self) -> bool:
        """Returns True if evaluation scope suggests non-compliance alongside risk."""
        compliance_requirements = [
            "art9_risk_management", "art11_technical_documentation",
            "art12_logging", "art13_transparency", "art14_human_oversight",
            "art15_robustness", "art17_qms", "art72_pmm_plan"
        ]
        return any(req in self.evaluation_scope for req in compliance_requirements)


@dataclass
class RiskInvestigationResponse:
    """Provider's formal response to an Art.79(1) evaluation request."""
    
    msa_reference_number: str
    provider_response_date: date
    euaidb_registration_id: str
    
    # Documentation package
    annex_iv_current_version: str
    art12_log_export_location: str      # EU-hosted, not US cloud
    qms_documentation_location: str     # EU-hosted, not US cloud
    pmm_plan_location: str
    
    # Risk assessment response
    provider_risk_assessment: str       # Provider's own assessment of alleged risk
    interim_mitigations_implemented: list[str]
    proposed_corrective_actions: list[str]
    estimated_corrective_timeline: str  # In calendar days
    
    # Hearing exercise
    hearing_requested: bool = True      # Always request hearing — Art.79(2)
    hearing_statement: str = ""
    
    # Infrastructure declaration
    infrastructure_jurisdiction: str = "EU_NATIVE"
    
    def hearing_exercise_statement(self) -> str:
        return (
            f"Provider exercises the right to a hearing pursuant to Art.79(2) of "
            f"Regulation (EU) 2024/1689 (EU AI Act) in connection with MSA reference "
            f"{self.msa_reference_number}. Provider requests written hearing within "
            f"[5 working days] before any corrective measure becomes binding."
        )
    
    def cloud_act_risk_level(self) -> str:
        """Assess CLOUD Act dual-compellability risk for investigation data."""
        if self.infrastructure_jurisdiction == "EU_NATIVE":
            return "NONE — Investigation data exclusively in EU jurisdiction"
        elif self.infrastructure_jurisdiction == "EU_SOVEREIGN_CLOUD":
            return "LOW — EU contractual sovereignty framework; verify CLOUD Act carve-out"
        elif self.infrastructure_jurisdiction == "US_CLOUD":
            return "HIGH — Art.12 logs / Annex IV on US cloud subject to CLOUD Act § 2713"
        else:
            return "MIXED — Partial CLOUD Act exposure; audit per-data-category"
    
    def art79_to_art82_exposure(self) -> str:
        """Assess whether Art.79 investigation may trigger Art.82 parallel procedure."""
        return (
            "If MSA evaluation finds both risk (Art.79 trigger) and non-compliance "
            "(Art.82 trigger), provider should prepare for parallel procedures under "
            "both Art.79 and Art.82. Corrective measures under Art.79(2) and compliance "
            "requirements under Art.82(2) may have different timelines and legal bases. "
            "Engage legal counsel for both tracks simultaneously."
        )

Art.79 Investigation Timeline: Developer Response Runbook

When an MSA initiates an Art.79 formal evaluation, providers have a structured but time-constrained window to respond:

Art.79 × Art.74(9): Provisional Measures During Investigation

While an Art.79(1) evaluation is underway, the MSA retains the right to impose Art.74(9) provisional measures if it determines that an imminent serious risk exists that cannot wait for the completion of the Art.79 investigation procedure.

Provisional measures under Art.74(9) do not require the same procedural safeguards as Art.79(2) corrective measures — they are temporary emergency orders designed to prevent immediate harm. However, once imposed, they run parallel to the Art.79 formal evaluation, which will eventually result in either:

• Confirming and making the provisional measure permanent (corrective action/withdrawal/recall)
• Withdrawing the provisional measure if the Art.79 evaluation finds no sustained risk

Developers who receive Art.74(9) provisional measures should immediately open Art.79(1) response preparation even if no formal Art.79 initiation has been served — provisional measures almost always precede formal Art.79 evaluation initiation.

Art.79 40-Item Developer Compliance Checklist

Pre-Investigation Preparedness (Items 1-10)

• 1. Art.71 EUAIDB registration number documented and current in all systems
• 2. Annex IV technical documentation current, version-controlled, EU-hosted
• 3. Art.12 log export procedure tested: can produce structured export within 24 hours
• 4. QMS documentation (Art.17) audit-ready for MSA physical review
• 5. Art.72 PMM plan current and linked to Art.9 risk management feedback loop
• 6. Art.73 incident reporting protocol established and staff trained
• 7. Legal counsel pre-identified for AI Act enforcement response
• 8. Investigation response lead (technical + legal) designated in advance
• 9. MSA contact information for lead member state deployment jurisdiction identified
• 10. Art.74(2)(a) documentation assembly procedure tested with <48-hour rehearsal

Art.79(1) Evaluation Response (Items 11-20)

• 11. Art.79(1) initiation notice review procedure established (scope identification)
• 12. Art.79(1) cooperation obligation understood: evaluate who must participate
• 13. Deployer notification procedure ready if deployer's Art.79(4) trigger identified
• 14. Cross-function evaluation team assembled (technical + compliance + legal + exec)
• 15. Documentation package compiled per MSA scope within response deadline
• 16. Art.79(2) hearing request drafted and ready to file within Day 5 of initiation
• 17. Provider risk assessment prepared (Art.79(1) rebuttal or confirmation)
• 18. Interim mitigations identified and implemented before hearing
• 19. Art.79 vs Art.82 fork analysis completed (is this risk-only or also non-compliance?)
• 20. CLOUD Act infrastructure assessment completed for investigation data

Art.79(2) Corrective Measure Response (Items 21-30)

• 21. Art.79(2) measure received: review for all 4 mandatory elements
• 22. Legal basis stated and correct? (Verify MSA cited accurate AI Act provision)
• 23. Timeline stated and reasonable? (Challenge if disproportionate to risk)
• 24. Hearing right explicitly stated? (Challenge if absent)
• 25. Appeal procedure stated? (Verify correct national court/administrative body)
• 26. If corrective action ordered: implementation plan within specified timeline
• 27. If market withdrawal ordered: downstream deployer notification plan ready
• 28. If recall ordered: affected user notification procedure activated
• 29. Art.72 PMM plan updated to reflect root cause of risk finding
• 30. EUAIDB (Art.71) registration updated if system status changes

Art.79(4)-(7) Cross-Border and Commission Procedures (Items 31-40)

• 31. Art.79(4) proactive risk notification procedure established for PMM-detected risks
• 32. Art.79(5) cross-border consequence understood: other MSAs may initiate evaluations
• 33. Multi-jurisdiction deployment map maintained (which MSAs may receive Art.79(5) notification)
• 34. Art.79(6) Commission consultation participation procedure established
• 35. Provider input to Art.79(6) Commission consultation prepared if requested
• 36. Art.80 Union safeguard procedure understood: escalation pathway if Art.79(7) justified EU-wide
• 37. Art.81 compliant-but-risky scenario mapped in Art.72 PMM contingency planning
• 38. Art.70 confidentiality confirmed for investigation data disclosed to MSA
• 39. Art.99(5) non-cooperation fine exposure minimised: cooperation protocol embedded in team training
• 40. Post-investigation lessons-learned: Art.72 PMM updated, Art.9 risk register updated

See Also

• EU AI Act Art.74: Market Surveillance Authority Powers — Developer Guide
• EU AI Act Art.73: Serious Incident Reporting for High-Risk AI Systems
• EU AI Act Art.72: Post-Market Monitoring Plan for High-Risk AI Systems
• EU AI Act Art.75: Market Surveillance of General-Purpose AI Models
• EU AI Act Art.21: Cooperation with Competent Authorities — Developer Guide