EU AI Act Art.20 Corrective Actions: Non-Conformity Obligations, Immediate Withdrawal and Recall Triggers, Market Surveillance Notification, and Art.20 × Art.73 × Art.17 × Art.72 Integration (2026)

Article 20 of the EU AI Act closes a critical loop in the high-risk AI compliance architecture: it answers the question of what happens when a provider discovers — or has reason to believe — that a high-risk AI system they have placed on the market or put into service does not conform to the Regulation. The answer is a three-part obligation: take immediate corrective action, inform the supply chain, and — where the non-conformity creates a risk — notify the national competent authorities and any involved notified bodies.

Art.20 is not about preventing non-conformity. Prevention belongs to Art.17 (Quality Management System), Art.9 (Risk Management System), and the conformity assessment procedures in Chapter V. Art.20 is the reactive obligation — the mechanism the Regulation provides for handling discovered non-conformity after a high-risk AI system is already operational in the market.

The placement of Art.20 within Section 2 of Chapter III (Provider Obligations, Art.16-27) immediately after Art.19 (automatically generated logs) and before Art.21 (cooperation with competent authorities) is architecturally significant. Art.19 logs create the evidentiary record that reveals non-conformity. Art.20 governs the response to that revelation. Art.21 governs the ongoing relationship with authorities that the Art.20 notification triggers. The three articles form a discovery-response-cooperation sequence that is central to the Act's enforcement model.

The Legal Architecture of Art.20

Art.20(1) — Corrective Actions:

Providers of high-risk AI systems which consider or have reason to consider that a high-risk AI system that they have placed on the market or put into service is not in conformity with this Regulation shall immediately take the necessary corrective actions to bring that system into conformity, to withdraw it or to recall it, as appropriate, and shall inform the distributors of the high-risk AI system concerned and, where applicable, the deployers accordingly.

Four elements require careful parsing.

"Consider or have reason to consider" sets a low evidential threshold. The obligation does not require certainty of non-conformity — it requires only that the provider considers, or has reason to consider, that the system may be non-conforming. This is a constructive knowledge standard. A provider who receives post-market monitoring data indicating that an AI system's actual accuracy substantially deviates from the accuracy reported in the technical documentation under Art.11 has "reason to consider" that the system is non-conforming, even before conducting a formal internal investigation confirming the deviation.

The practical implication is significant: providers cannot defer Art.20 obligations until non-conformity is formally established through an internal investigation or notified body review. The trigger is much earlier — the point at which a reasonable provider would have reason to consider non-conformity as a possibility.

"Not in conformity with this Regulation" encompasses non-conformity with any provision of the Regulation applicable to the high-risk AI system. This includes non-conformity with: the transparency requirements of Art.13, the human oversight requirements of Art.14, the accuracy and robustness requirements of Art.15, the technical documentation requirements of Art.11, the conformity assessment requirements of Chapter V, and any harmonised standard that was relied upon for the conformity assessment. Non-conformity is not limited to safety failures — a system that has ceased to meet the logging requirements of Art.12 or the post-market monitoring requirements of Art.72 is also non-conforming for Art.20 purposes.

"Immediately" is not defined in Art.20 with a specific timeframe. Unlike Art.73, which establishes explicit notification timelines for serious incidents (72 hours for life-threatening incidents, 15 days for others), Art.20 uses the unqualified "immediately." In product safety law, "immediately" generally means without unreasonable delay — that is, as soon as the corrective action is practicable given the nature of the non-conformity and the necessary response.

"To bring that system into conformity, to withdraw it or to recall it, as appropriate" establishes a hierarchy of corrective responses. Bringing into conformity is the preferred response where technically feasible — updating the system to address the non-conformity, re-conducting affected conformity assessment steps, and ensuring the corrected system meets all applicable requirements. Withdrawal (preventing further distribution or use) is appropriate where conformity cannot be rapidly achieved and continued use creates unacceptable risk. Recall (actively recovering systems already placed in use) is the most disruptive option, reserved for situations where withdrawal alone is insufficient because systems already deployed pose ongoing risk.

Art.20(2) — Risk Notification:

Where the high-risk AI system presents a risk within the meaning of Art.79(1), the provider shall immediately inform the national competent authorities of the Member States in which it has made the system available and, where applicable, the notified body that issued a certificate for the high-risk AI system in accordance with Art.44, in particular of the non-conformity and of any corrective actions taken.

Art.20(2) elevates the Art.20 corrective action obligation into a regulatory notification obligation where the non-conformity creates a qualifying risk. The reference to Art.79(1) is the key criterion.

The Art.79(1) Risk Threshold

Art.79(1) defines the risk threshold that triggers market surveillance authority intervention:

Where national authorities or the Commission have sufficient reason to consider that a high-risk AI system presents a risk to the health or safety of persons or to compliance with obligations under Union or national law protecting fundamental rights, they shall carry out an evaluation of the AI system concerned.

For Art.20(2) purposes, the relevant element of Art.79(1) is the criterion that a system "presents a risk to the health or safety of persons or to compliance with obligations under Union or national law protecting fundamental rights."

Two risk categories qualify:

Health and safety risks: A high-risk AI system that generates incorrect outputs in a medical diagnostic context, an employment screening context where incorrect outputs affect livelihoods, or a safety component context where incorrect outputs could lead to physical harm. The risk does not need to have materialised — a system presenting a theoretical but credible risk to health or safety triggers Art.20(2).

Fundamental rights risks: A high-risk AI system that operates in a manner that discriminates on grounds protected under the EU Charter of Fundamental Rights, that enables surveillance in violation of Art.7 or Art.8 Charter rights, or that generates decisions affecting Art.41 right to good administration without the transparency required by Art.13. The category is broad and includes privacy, non-discrimination, and procedural rights.

The practical threshold question for providers: what internal standard determines whether a discovered non-conformity "presents a risk" within Art.79(1)? The answer requires a risk assessment against the Art.79(1) criteria, documented in the QMS under Art.17. A non-conformity that affects only technical metadata (an out-of-date field in the technical documentation) without affecting system outputs does not obviously present an Art.79(1) risk. A non-conformity that causes the system to output incorrect classifications in a high-stakes context almost certainly does.

What Constitutes Non-Conformity: Practical Taxonomy

Non-conformity under the EU AI Act for Art.20 purposes can arise from multiple sources. The following taxonomy is not exhaustive but covers the principal pathways through which operational AI systems can become non-conforming after initial market placement:

The common thread across these scenarios is that non-conformity is typically discovered through the operational evidence that Art.19 logs and Art.72 post-market monitoring are designed to generate. This is the closed-loop architecture of Chapter III: Art.17 (QMS) builds in preventive controls, Art.72 generates operational evidence, Art.19 preserves that evidence, and Art.20 governs the corrective response when the evidence reveals non-conformity.

The Supply Chain Notification Chain

Art.20(1) requires providers to inform distributors and, where applicable, deployers when corrective actions are taken. The notification chain operates as follows:

Provider → Distributor: Providers must immediately inform all distributors of the affected high-risk AI system. The distributor's obligation, upon receiving this notification, is defined in Art.24: distributors who have reason to believe a high-risk AI system they have distributed is not in conformity must ensure corrective measures are taken and cooperate with the provider and competent authorities. The Art.20(1) provider notification activates the Art.24 distributor obligation.

Provider → Deployer: The "where applicable" qualification in Art.20(1) reflects the practical reality that providers may not have direct contractual relationships with all deployers of their systems (particularly where distribution is multilevel). Where the provider has a direct relationship with deployers — as is common in SaaS and API-based AI deployment models — the notification obligation is direct and immediate. Where deployers are downstream of distributors, the distributor's Art.24 obligation activates the communication channel.

Deployer obligations upon notification: Deployers who receive an Art.20(1) notification from a provider or distributor must assess the impact of the non-conformity on their specific deployment, consider whether continued use of the system is appropriate given the non-conformity, and cooperate with the provider on any corrective measures.

Art.20 × Art.73: Corrective Actions and Serious Incident Reporting

Art.73 (formerly Art.62 in the Council's draft) establishes a separate, parallel obligation to report serious incidents to market surveillance authorities. Understanding the relationship between Art.20 corrective actions and Art.73 serious incident reporting is essential for compliance architecture.

Art.73 scope: Providers and deployers of high-risk AI systems must report to market surveillance authorities any serious incidents. A serious incident is defined as an incident or malfunction of a high-risk AI system that has directly led to, or may reasonably be expected to have contributed to, a death of a person or serious harm to a person's health, to damage to property, or to a serious breach of fundamental rights obligations or to serious damage to critical infrastructure. The definition requires an incident or malfunction that has already occurred or imminently may occur — not merely a potential future risk arising from non-conformity.

The Art.20 / Art.73 intersection: An Art.20 corrective action event and an Art.73 serious incident report may arise from the same underlying facts but represent different obligations:

The practical implication is that Art.20 corrective action obligations can arise without Art.73 serious incident reporting being required — a provider who discovers a conformity gap through proactive monitoring before any harm occurs must still take Art.20 corrective action and notify under Art.20(2) if there is an Art.79(1) risk, but does not have an Art.73 reporting obligation.

Conversely, a serious incident under Art.73 may arise without a conformity gap — a hardware failure in the deployment environment that causes an AI system to produce harmful outputs does not necessarily make the AI system itself non-conforming, but does require Art.73 reporting.

Art.73 Notification Timelines:

Art.73 establishes specific timelines that Art.20 does not. For serious incidents:

• Deaths or life-threatening situations: notification within 72 hours
• Other serious incidents: notification within 15 days
• Annual summaries (for less severe incidents): submitted to the competent authority annually

Where an Art.20 corrective action scenario escalates to an Art.73 serious incident, the Art.73 timelines govern the notification to market surveillance authorities, and the Art.20 "immediately" standard governs the corrective actions themselves.

Art.20 × Art.17 QMS Integration: CAPA Process

Art.17 requires providers to implement a Quality Management System covering, among other elements, processes for reporting serious incidents and non-conformities. Art.17(1)(n) specifically requires the QMS to include "post-market monitoring in accordance with Art.72" and Art.17(1)(o) requires "cooperation with national competent authorities."

In QMS terminology, the Art.20 mechanism maps directly to a Corrective and Preventive Action (CAPA) process:

Corrective Action (Art.20 direct): Addressing the specific non-conformity — fixing the AI system, withdrawing it, or recalling it — and notifying the supply chain and authorities.

Preventive Action (Art.17 QMS): Investigating the root cause of the non-conformity to prevent recurrence. A non-conformity that triggered Art.20 obligations should feed back into the Art.17 QMS as input for risk management system updates (Art.9), technical documentation revision (Art.11), and post-market monitoring plan updates (Art.72).

The CAPA loop for Art.20 compliance:

Detection (Art.19 logs, Art.72 monitoring, external report)
    ↓
Non-Conformity Assessment (does this trigger Art.20?)
    ↓
Risk Assessment (does this trigger Art.20(2) notification?)
    ↓
Corrective Action (conform, withdraw, or recall)
    ↓
Supply Chain Notification (Art.20(1): distributors + deployers)
    ↓
Authority Notification if required (Art.20(2): NCA + notified body)
    ↓
Root Cause Analysis (Art.17 QMS CAPA)
    ↓
Preventive Measures (updated Art.9 risk management, Art.72 monitoring)
    ↓
Documentation (Art.18 retention of corrective action records)

Art.18 is directly relevant here: corrective action records — the decision to take Art.20 action, the corrective measures implemented, the notifications sent — are part of the technical documentation that Art.18 requires providers to retain for 10 years from the last date of placing on the market.

Art.20 × Art.72 Post-Market Monitoring: The Detection Feed

Art.72 requires providers to establish and document a post-market monitoring (PMM) plan as part of their QMS. The PMM plan must be proportionate to the nature of the AI system and its risks, and must include procedures for collecting and reviewing data on the AI system's performance in real-world operation.

The Art.72 PMM system is the primary operational detection mechanism for Art.20 non-conformity triggers. Specifically, Art.72(4) requires that when post-market monitoring data reveals that the AI system does not comply with the Regulation or that its performance has substantially deviated from the intended purpose, the provider must immediately take corrective actions — explicitly cross-referencing Art.20.

This cross-reference makes Art.72 and Art.20 inseparable in practice: a PMM plan that does not have a defined escalation path to Art.20 corrective actions is structurally incomplete. The PMM plan must specify:

1. What deviation from expected performance metrics triggers an Art.20 review
2. Who within the provider organisation has authority to initiate Art.20 corrective actions
3. What documentation must be generated when Art.20 is triggered
4. How Art.20(2) notifications are assembled and transmitted to national competent authorities

Python CorrectiveActionManager Implementation

The following implementation provides a structured workflow for managing Art.20 obligations, integrating with supply chain notification, risk assessment, and regulatory reporting:

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


class CorrectiveActionType(Enum):
    BRING_INTO_CONFORMITY = "bring_into_conformity"
    WITHDRAWAL = "withdrawal"
    RECALL = "recall"


class RiskLevel(Enum):
    NO_ART79_RISK = "no_art79_risk"       # Art.20(2) not triggered
    ART79_HEALTH_SAFETY = "art79_health_safety"   # Art.20(2) triggered
    ART79_FUNDAMENTAL_RIGHTS = "art79_fundamental_rights"  # Art.20(2) triggered
    ART73_SERIOUS_INCIDENT = "art73_serious_incident"  # Art.20(2) + Art.73 triggered


class NotificationStatus(Enum):
    PENDING = "pending"
    SENT = "sent"
    ACKNOWLEDGED = "acknowledged"
    OVERDUE = "overdue"


@dataclass
class NonConformityEvent:
    event_id: str
    system_id: str
    detected_at: datetime
    detected_by: str  # internal_audit, pmt_monitoring, external_report, deployer_report
    description: str
    risk_level: RiskLevel
    corrective_action_type: CorrectiveActionType
    member_states_affected: list[str] = field(default_factory=list)
    notified_body_id: Optional[str] = None
    corrective_action_initiated_at: Optional[datetime] = None
    resolved_at: Optional[datetime] = None

    def to_record(self) -> dict:
        return {
            "event_id": self.event_id,
            "system_id": self.system_id,
            "detected_at": self.detected_at.isoformat(),
            "detected_by": self.detected_by,
            "description": self.description,
            "risk_level": self.risk_level.value,
            "corrective_action_type": self.corrective_action_type.value,
            "member_states_affected": self.member_states_affected,
            "notified_body_id": self.notified_body_id,
            "corrective_action_initiated_at": (
                self.corrective_action_initiated_at.isoformat()
                if self.corrective_action_initiated_at else None
            ),
            "resolved_at": self.resolved_at.isoformat() if self.resolved_at else None,
            "integrity_hash": self._compute_hash(),
        }

    def _compute_hash(self) -> str:
        content = f"{self.event_id}{self.system_id}{self.detected_at.isoformat()}{self.description}"
        return hashlib.sha256(content.encode()).hexdigest()


class CorrectiveActionManager:
    """
    Art.20 EU AI Act corrective action workflow manager.
    Manages non-conformity detection, risk assessment, corrective action
    initiation, supply chain notification, and authority notification.
    """

    # Art.73 notification timelines (hours)
    ART73_LIFE_THREATENING_DEADLINE_H = 72
    ART73_OTHER_SERIOUS_DEADLINE_H = 360  # 15 days

    def __init__(self, system_id: str, provider_name: str):
        self.system_id = system_id
        self.provider_name = provider_name
        self.events: list[NonConformityEvent] = []
        self.notification_log: list[dict] = []

    def assess_risk_level(
        self,
        description: str,
        potential_harm: str,
        affected_persons_count: Optional[int] = None,
        involves_fundamental_rights: bool = False,
        involves_health_safety: bool = False,
        incident_occurred: bool = False,
    ) -> RiskLevel:
        """
        Assess whether the non-conformity triggers Art.20(2) notification
        and/or Art.73 serious incident reporting.
        """
        if incident_occurred and (involves_health_safety or involves_fundamental_rights):
            return RiskLevel.ART73_SERIOUS_INCIDENT

        if involves_health_safety:
            return RiskLevel.ART79_HEALTH_SAFETY

        if involves_fundamental_rights:
            return RiskLevel.ART79_FUNDAMENTAL_RIGHTS

        return RiskLevel.NO_ART79_RISK

    def select_corrective_action(
        self,
        risk_level: RiskLevel,
        can_fix_immediately: bool,
        systems_in_deployment: int,
    ) -> CorrectiveActionType:
        """
        Select the appropriate corrective action type based on risk and
        feasibility of immediate conformity restoration.
        """
        if can_fix_immediately:
            return CorrectiveActionType.BRING_INTO_CONFORMITY

        if risk_level in (
            RiskLevel.ART79_HEALTH_SAFETY,
            RiskLevel.ART73_SERIOUS_INCIDENT,
        ) and systems_in_deployment > 0:
            # High risk, cannot fix immediately — recall
            return CorrectiveActionType.RECALL

        # Cannot fix immediately but lower risk — withdrawal
        return CorrectiveActionType.WITHDRAWAL

    def register_non_conformity(
        self,
        description: str,
        detected_by: str,
        risk_level: RiskLevel,
        corrective_action_type: CorrectiveActionType,
        member_states_affected: list[str],
        notified_body_id: Optional[str] = None,
    ) -> NonConformityEvent:
        """
        Register a non-conformity event and initiate Art.20 workflow.
        """
        event = NonConformityEvent(
            event_id=self._generate_event_id(),
            system_id=self.system_id,
            detected_at=datetime.utcnow(),
            detected_by=detected_by,
            description=description,
            risk_level=risk_level,
            corrective_action_type=corrective_action_type,
            member_states_affected=member_states_affected,
            notified_body_id=notified_body_id,
            corrective_action_initiated_at=datetime.utcnow(),
        )

        self.events.append(event)
        self._initiate_notification_workflow(event)
        return event

    def _initiate_notification_workflow(self, event: NonConformityEvent) -> None:
        """Determine and schedule required notifications."""
        notifications = []

        # Art.20(1): Always notify supply chain
        notifications.append({
            "type": "supply_chain",
            "recipients": ["distributors", "deployers"],
            "deadline": event.detected_at,  # immediately
            "status": NotificationStatus.PENDING.value,
            "legal_basis": "Art.20(1)",
        })

        # Art.20(2): Notify authorities if Art.79(1) risk
        if event.risk_level != RiskLevel.NO_ART79_RISK:
            for ms in event.member_states_affected:
                notifications.append({
                    "type": "national_competent_authority",
                    "recipient": f"NCA_{ms}",
                    "deadline": event.detected_at,  # immediately
                    "status": NotificationStatus.PENDING.value,
                    "legal_basis": "Art.20(2)",
                })

            if event.notified_body_id:
                notifications.append({
                    "type": "notified_body",
                    "recipient": event.notified_body_id,
                    "deadline": event.detected_at,
                    "status": NotificationStatus.PENDING.value,
                    "legal_basis": "Art.20(2)",
                })

        # Art.73: Serious incident reporting if applicable
        if event.risk_level == RiskLevel.ART73_SERIOUS_INCIDENT:
            # Determine timeline: 72h for life-threatening, 15d for others
            art73_deadline = event.detected_at + timedelta(
                hours=self.ART73_LIFE_THREATENING_DEADLINE_H
            )
            for ms in event.member_states_affected:
                notifications.append({
                    "type": "art73_serious_incident",
                    "recipient": f"MSA_{ms}",
                    "deadline": art73_deadline.isoformat(),
                    "status": NotificationStatus.PENDING.value,
                    "legal_basis": "Art.73",
                })

        self.notification_log.extend(notifications)

    def get_compliance_status(self) -> dict:
        """Return current Art.20 compliance status across all events."""
        return {
            "system_id": self.system_id,
            "provider": self.provider_name,
            "total_events": len(self.events),
            "open_events": sum(1 for e in self.events if not e.resolved_at),
            "pending_notifications": sum(
                1 for n in self.notification_log
                if n["status"] == NotificationStatus.PENDING.value
            ),
            "overdue_notifications": sum(
                1 for n in self.notification_log
                if n["status"] == NotificationStatus.OVERDUE.value
            ),
            "generated_at": datetime.utcnow().isoformat(),
        }

    def _generate_event_id(self) -> str:
        timestamp = datetime.utcnow().strftime("%Y%m%d%H%M%S%f")
        return f"CA-{self.system_id[:8].upper()}-{timestamp}"

Implementation Checklist: Art.20 Compliance

Provider Obligations (Art.20)

• 1. Non-conformity detection procedures defined — QMS (Art.17) includes explicit criteria for what constitutes a non-conformity triggering Art.20 review
• 2. Constructive knowledge standard applied — Art.20 triggers on "reason to consider," not confirmed non-conformity; PMM data reviewed against this threshold
• 3. Art.79(1) risk assessment process established — Documented procedure for assessing whether discovered non-conformity presents a health/safety or fundamental rights risk
• 4. Corrective action selection criteria documented — Policy specifying when to bring into conformity, withdraw, or recall, based on risk level and feasibility
• 5. "Immediately" interpreted and operationalised — Internal SLA defined for Art.20 corrective action initiation from discovery (e.g., within 24 hours of risk assessment)
• 6. Distributor notification template prepared — Art.20(1) notification package for distributors: non-conformity description, affected system versions, corrective actions taken
• 7. Deployer notification template prepared — Parallel template for direct deployer relationships, including guidance on interim use restrictions if applicable
• 8. National competent authority notification procedure — For each Member State of availability: authority name, notification portal/email, required information fields for Art.20(2)
• 9. Notified body notification procedure — If certificate issued: notified body notification procedure for Art.20(2) scenarios
• 10. Art.73 escalation path defined — Procedure for escalating Art.20 events that involve serious incidents to Art.73 reporting, with 72-hour and 15-day timelines tracked

QMS Integration (Art.17 × Art.20)

• 11. CAPA process includes Art.20 corrective actions — QMS CAPA workflow covers Art.20 events from detection through resolution and root cause analysis
• 12. PMM plan includes Art.20 escalation thresholds — Art.72 post-market monitoring plan specifies what performance deviations trigger Art.20 review
• 13. Art.20 records created for all events — Each Art.20 trigger documented with: detection date, evidence, risk assessment, corrective action taken, notifications sent
• 14. Art.18 retention applied to Art.20 records — Corrective action records retained for 10 years per Art.18 documentation keeping requirements
• 15. Root cause analysis completed for each Art.20 event — Preventive measures implemented and documented in QMS following each corrective action

System and Operational

• 16. Corrective action authority designated — Named role within provider organisation with authority to initiate Art.20 corrective actions (withdrawal, recall) without further escalation
• 17. Supply chain contacts maintained — Current contact list for all distributors and direct deployers, updated at each supply chain change
• 18. Monitoring alerts configured — PMM monitoring system generates alerts when Art.20-triggering thresholds are breached
• 19. Withdrawal and recall procedures tested — Tabletop exercise or simulation confirming that withdrawal/recall can be executed within defined timelines
• 20. Cooperation obligations documented — Art.21 cooperation with competent authorities integrated into Art.20 workflow: authority requests for information have defined internal response procedures

Art.20 in the Broader Compliance Architecture

Art.20 does not operate in isolation. Its position in the compliance architecture is best understood as the reactive complement to the preventive and monitoring obligations that precede it:

Prevention layer: Art.9 (risk management), Art.17 (QMS), conformity assessment (Chapter V) — these obligations are designed to prevent non-conformity from arising in the first place. They create the baseline that Art.20 applies when prevention fails.

Detection layer: Art.72 (post-market monitoring), Art.19 (log retention), Art.13 (transparency, enabling deployers and users to identify anomalies) — these obligations generate the evidence that reveals non-conformity after deployment.

Response layer: Art.20 (corrective actions), Art.73 (serious incident reporting), Art.21 (cooperation with authorities) — these obligations govern what providers must do when non-conformity is detected.

Enforcement layer: Art.79 (market surveillance), Art.74 (access rights), Art.99-101 (penalties) — these provisions give competent authorities the power to investigate non-conformity and impose consequences where Art.20 obligations were not met.

The Article 20 obligation is ultimately the mechanism by which the EU AI Act creates accountability for what happens after a high-risk AI system leaves the provider's control. It represents a recognition that conformity at the point of market placement is necessary but not sufficient: the Regulation requires providers to maintain active responsibility for the conformity of their systems throughout their operational lifetime, respond immediately when that conformity is in question, and bring national authorities into the picture when the stakes warrant it.

For providers who implement the full Art.17 QMS, Art.72 post-market monitoring, and Art.19 log retention obligations correctly, Art.20 compliance is largely an operational consequence of those upstream systems — the detection infrastructure that generates Art.20 triggers is already in place, and the corrective action and notification workflows integrate naturally into the CAPA processes that a well-implemented QMS already requires. The compliance cost of Art.20 is therefore mostly front-loaded into the preventive and monitoring infrastructure, with the reactive Art.20 workflow representing the payoff of that investment.

See Also:

• EU AI Act Art.17: Quality Management System Implementation
• EU AI Act Art.19: Automatically Generated Logs
• EU AI Act Art.21: Cooperation with Competent Authorities
• EU AI Act Art.72: Post-Market Monitoring System