EU AI Act Art.72 Post-Market Monitoring: Closing the QMS Feedback Loop

Post #4 in the sota.io EU AI Act Quality Management System Series

You built your Art.17 Quality Management System. You documented your Art.9 risk assessments. You wrote the Annex IV technical documentation. Now your high-risk AI system is in production — and Art.72 is where the compliance work actually begins.

Article 72 of the EU AI Act requires every high-risk AI provider to implement a post-market monitoring system that collects, documents, and acts on data about how the system performs in real-world conditions. But Art.72 is not a standalone obligation bolted on after deployment. It is the feedback mechanism that makes your entire QMS self-correcting — the close of the loop that Art.9, Art.11, and Art.17 opened.

This guide explains how to build that feedback loop: what Art.72 requires, how monitoring data flows back into your QMS, and what national competent authorities will inspect when they invoke their Art.74 powers after August 2, 2026.

The Feedback Loop Architecture

Before diving into specifics, it helps to see the full QMS feedback loop this series has been building:

Art.9 Risk Assessment  →  Art.17 QMS  →  Art.11 Technical Documentation
        ↑                                            ↓
Art.72 Monitoring  ←  Art.21 Corrective Actions  ←  Deployment
        ↓
Art.73 Incident Reports  →  Art.74 NCA Market Surveillance

Your QMS is a closed-loop control system. Art.72 monitoring is the sensor layer — it detects when reality diverges from your pre-deployment assumptions. When it does, the data flows back through corrective actions (Art.21) into your Art.9 risk assessment and Art.17 QMS procedures. The loop closes.

If you treat Art.72 as a separate post-deployment checklist rather than an integral part of your QMS, you will have two disconnected compliance artefacts instead of one coherent system. NCAs inspecting under Art.74 are specifically trained to look for this disconnection.

What Art.72 Actually Requires

Article 72 requires providers of high-risk AI systems to establish a post-market monitoring system that is proportionate to the nature of the AI technology and its risks. The monitoring system must:

1. Actively collect data on the performance of the high-risk AI system during its operational lifetime
2. Identify and analyse any malfunctions, near-misses, serious incidents, and unintended outputs
3. Trigger updates to the risk management system when monitoring reveals new or changed risks
4. Feed the technical documentation updates required under Art.11 when the system changes materially
5. Generate the evidence base for incident reports under Art.73 when serious incidents occur

The regulation requires that your post-market monitoring plan be part of your technical documentation from the outset — not written retrospectively after deployment.

The Monitoring Plan Requirement

Your post-market monitoring plan (required as part of Annex IV technical documentation) must specify:

• Data sources: What data will you collect? From where? At what frequency?
• Performance metrics: Which KPIs indicate the system is performing within acceptable bounds?
• Deviation thresholds: What constitutes a meaningful deviation from expected performance?
• Escalation triggers: At what threshold does a deviation become a reportable serious incident under Art.73?
• Review cadence: How often will monitoring data be formally reviewed and fed back into the QMS?

# Example monitoring plan specification
class PostMarketMonitoringPlan:
    data_sources = [
        DataSource(
            name="production_inference_logs",
            frequency="real-time",
            retention_days=365,
            fields=["input_hash", "output_confidence", "human_override", "outcome_label"]
        ),
        DataSource(
            name="deployer_feedback_api",
            frequency="event-driven",
            retention_days=365,
            fields=["incident_type", "severity", "affected_users", "system_context"]
        ),
        DataSource(
            name="quarterly_performance_review",
            frequency="90_days",
            retention_days=730,
            fields=["accuracy_delta", "bias_metrics", "drift_indicators", "nca_reportable"]
        ),
    ]

    deviation_thresholds = DeviationThresholds(
        accuracy_drop_pct=0.05,          # 5% accuracy drop → trigger investigation
        false_positive_rate_change=0.10, # 10% FPR change → trigger QMS review
        human_override_rate_change=0.15, # 15% override rate spike → trigger root cause
    )

    escalation_triggers = EscalationTriggers(
        serious_incident_threshold=SeverityLevel.DEATH_OR_SERIOUS_INJURY,
        # Art.73: 2 days (widespread/critical-infra), 10 days (death), 15 days (other serious)
        nca_report_deadline_days=2,      # use shortest window for triage classification
        corrective_action_deadline_days=30,
    )

Connecting Art.72 to Your Art.9 Risk Assessment

The most critical — and most commonly missed — connection is between Art.72 monitoring data and your Art.9 risk management system.

Art.9 requires an iterative risk management process. It is not a one-time pre-deployment assessment. The regulation explicitly requires that the risk management process "take into account" new data that emerges from operation of the system.

This means your Art.72 monitoring outputs must be formally piped back into your Art.9 risk register. In practice:

Risk Register Update Triggers

class RiskRegisterUpdateTrigger:
    """Defines when monitoring data must trigger an Art.9 risk register update."""
    
    def evaluate_monitoring_event(self, event: MonitoringEvent) -> RiskUpdateAction:
        
        # Mandatory triggers — require immediate risk register review
        if event.severity >= SeverityLevel.SERIOUS_INCIDENT:
            return RiskUpdateAction(
                action="IMMEDIATE_RISK_REGISTER_REVIEW",
                scope="full_risk_assessment",
                deadline_days=7,
                notifies=["qms_owner", "nca_liaison"],
                triggers_art73=True
            )
        
        # Drift triggers — require risk register update at next review cycle
        if event.type == EventType.PERFORMANCE_DRIFT:
            if event.drift_magnitude > self.SIGNIFICANT_DRIFT_THRESHOLD:
                return RiskUpdateAction(
                    action="SCHEDULE_RISK_REGISTER_UPDATE",
                    scope="affected_risk_categories",
                    deadline_days=30,
                    notifies=["qms_owner"]
                )
        
        # Pattern triggers — require risk register review when patterns emerge
        if event.type == EventType.NEAR_MISS_PATTERN:
            if event.pattern_count >= self.PATTERN_THRESHOLD:
                return RiskUpdateAction(
                    action="INVESTIGATE_AND_UPDATE",
                    scope="relevant_risk_entries",
                    deadline_days=14,
                    notifies=["qms_owner", "safety_function_lead"]
                )
        
        return RiskUpdateAction(action="LOG_ONLY")

When monitoring triggers a risk register update, the update must:

1. Reference the specific monitoring event that triggered it
2. Document how the new data changes the risk assessment
3. Specify what control measures have been added, modified, or removed
4. Update the corresponding section of your Annex IV technical documentation
5. Record who authorised the change and when

This audit trail — from monitoring event to risk register update to technical documentation revision — is the evidence chain NCAs will trace during Art.74 inspections.

Connecting Art.72 to Your Art.17 QMS Procedures

Article 17 requires your QMS to include procedures for "examining, testing, and validating" the system throughout its lifecycle. Post-deployment monitoring is where those procedures are exercised.

The eight mandatory QMS elements from Art.17 each have a monitoring dimension:

The QMS is only "complete" when all eight elements have a live connection to post-market monitoring. A QMS that functions only on paper — with no monitoring data actually flowing back into it — will not satisfy Art.17 under regulatory scrutiny.

Connecting Art.72 to Technical Documentation (Art.11)

Your Annex IV technical documentation is not a static artefact filed at launch. Art.11 requires it to be updated when the system undergoes a "substantial modification" — and Art.72 monitoring is what reveals when modifications are needed.

The monitoring-to-documentation pipeline:

class TechnicalDocumentationUpdate:
    """Triggered by Art.72 monitoring when documentation currency check fires."""
    
    DOCUMENTATION_CURRENCY_CHECK_DAYS = 90  # Maximum age before mandatory review
    
    def check_documentation_currency(
        self, 
        monitoring_period_summary: MonitoringPeriodSummary
    ) -> DocumentationCurrencyResult:
        
        issues = []
        
        # Check if performance has drifted outside documented ranges
        for metric in monitoring_period_summary.performance_metrics:
            if metric.current_value not in metric.documented_range:
                issues.append(DocumentationGap(
                    section="Performance Characteristics (Annex IV §3)",
                    gap=f"{metric.name}: documented range {metric.documented_range}, "
                        f"actual {metric.current_value}",
                    severity="HIGH" if metric.deviation_pct > 0.10 else "MEDIUM"
                ))
        
        # Check if new risk controls have been added but not documented
        for control in monitoring_period_summary.new_controls_deployed:
            if not control.in_technical_documentation:
                issues.append(DocumentationGap(
                    section="Risk Management Measures (Annex IV §6)",
                    gap=f"Undocumented control: {control.name}",
                    severity="HIGH"
                ))
        
        # Check if intended use has changed based on deployer feedback
        if monitoring_period_summary.use_case_drift_detected:
            issues.append(DocumentationGap(
                section="Intended Purpose (Annex IV §1)",
                gap="Use case drift detected in deployer feedback",
                severity="CRITICAL"
            ))
        
        return DocumentationCurrencyResult(issues=issues, requires_update=len(issues) > 0)

When the documentation currency check returns issues, your QMS procedures must specify:

• Who is responsible for updating the technical documentation
• What review and sign-off process applies
• How the updated documentation is communicated to deployers affected by the change
• Whether the update constitutes a "substantial modification" that triggers a new conformity assessment under Art.43

Incident Escalation: From Art.72 to Art.73

The most consequential monitoring output is the escalation of serious incidents to national competent authorities under Art.73.

Article 73 requires providers to report serious incidents to the market surveillance authority of the Member State where the incident occurred. "Serious incident" means any incident or malfunction that leads or might lead to death, serious injury, or other serious negative effects on health, safety, property, or fundamental rights.

The Art.72→Art.73 escalation pipeline:

class IncidentEscalationPipeline:
    
    def process_monitoring_event(self, event: MonitoringEvent) -> IncidentAction:
        
        severity = self.classify_incident(event)
        
        if severity == IncidentSeverity.SERIOUS:
            # Art.73 reporting obligation triggered
            # Timeline: immediate awareness → initial report to NCA
            initial_report_deadline = event.awareness_timestamp + timedelta(hours=72)
            
            return IncidentAction(
                action="SERIOUS_INCIDENT_REPORT",
                report_to="national_market_surveillance_authority",
                initial_report_deadline=initial_report_deadline,
                # Art.73 requires: description, affected users, immediate actions taken
                initial_report_fields=[
                    "incident_description",
                    "affected_member_state",
                    "estimated_affected_users",
                    "immediate_safety_measures_taken",
                    "investigation_status"
                ],
                follow_up_required=True,
                triggers_art74_inspection_possible=True
            )
        
        elif severity == IncidentSeverity.NEAR_MISS:
            # Not reportable under Art.73, but must feed risk register
            return IncidentAction(
                action="INTERNAL_INVESTIGATION",
                feeds_risk_register=True,
                deadline_days=14
            )
        
        else:
            return IncidentAction(
                action="LOG_AND_TREND",
                feeds_performance_review=True
            )
    
    def classify_incident(self, event: MonitoringEvent) -> IncidentSeverity:
        """Art.73 serious incident classification logic."""
        
        # Death or serious bodily injury — always serious
        if event.outcome in [Outcome.DEATH, Outcome.SERIOUS_BODILY_INJURY]:
            return IncidentSeverity.SERIOUS
        
        # Serious disruption to critical infrastructure — always serious
        if event.affected_system_type == SystemType.CRITICAL_INFRASTRUCTURE:
            if event.disruption_level >= DisruptionLevel.SIGNIFICANT:
                return IncidentSeverity.SERIOUS
        
        # Violation of fundamental rights — always serious
        if event.fundamental_rights_violation_possible:
            return IncidentSeverity.SERIOUS
        
        # Property damage above threshold — may be serious
        if event.property_damage_eur and event.property_damage_eur > self.MATERIAL_DAMAGE_THRESHOLD:
            return IncidentSeverity.SERIOUS
        
        return IncidentSeverity.ROUTINE

Art.73 reporting deadlines run from the moment the provider becomes aware of the serious incident — not from when the monitoring system first detected it. The deadlines are tiered by severity: 2 days for incidents affecting critical infrastructure or widespread harm, 10 days where the incident leads to death, and 15 days for other serious incidents. This means your incident detection pipeline must be fast enough to allow for awareness, classification, and report preparation within the shortest applicable window (2 days for the most severe cases).

What NCAs Inspect Under Art.74

Article 74 gives national competent authorities broad powers to inspect your post-market monitoring system. When an NCA issues an inspection notice or conducts a market surveillance audit, they will typically request:

Documentation:

• Your Art.72 post-market monitoring plan (must exist in technical documentation from launch)
• Monitoring logs for the inspection period (Art.12 record-keeping obligations apply)
• Risk register update history showing how monitoring events were acted upon
• Any Art.73 incident reports filed during the inspection period
• Evidence that monitoring data was formally reviewed at the cadence specified in your plan

System Access:

• Demonstration that your monitoring infrastructure is operational
• Sample of monitoring outputs with evidence of review and action
• Audit trail from monitoring event to corrective action (Art.21)
• Evidence that technical documentation was updated when monitoring required it

Personnel:

• Interviews with the person responsible for your QMS (Art.17 requires you to designate one)
• Explanation of how monitoring findings are escalated internally
• Evidence that deployers were informed of material changes

The most common finding in early Art.74 inspections: monitoring exists in principle but the feedback loop to the QMS is not documented. Logs are collected but not formally reviewed. The risk register was not updated after events that should have triggered it. The technical documentation was not revised despite material performance drift.

Building the Monitoring Infrastructure

For SaaS providers, the practical monitoring infrastructure has three tiers:

Tier 1: Real-Time Alerting

# Grafana/Prometheus alerting rules for Art.72 compliance
groups:
  - name: eu_ai_act_art72_monitoring
    rules:
      # Accuracy drift alert
      - alert: HighRiskAIAccuracyDrift
        expr: |
          (
            ai_model_accuracy_7d_rolling - ai_model_accuracy_baseline
          ) / ai_model_accuracy_baseline < -0.05
        for: 1h
        labels:
          severity: warning
          eu_ai_act_article: art72
          qms_trigger: risk_register_review
        annotations:
          summary: "High-risk AI system accuracy drift exceeds 5% threshold"
          description: "Art.72 monitoring: accuracy drift {{ $value | humanizePercentage }} vs baseline. QMS risk register review required within 30 days."
          runbook_url: "https://your-runbook/art72-accuracy-drift"

      # Human override rate spike
      - alert: HumanOverrideRateSpike
        expr: |
          (
            ai_human_override_rate_7d_rolling - ai_human_override_rate_baseline
          ) / ai_human_override_rate_baseline > 0.15
        for: 2h
        labels:
          severity: warning
          eu_ai_act_article: art72
          qms_trigger: art14_oversight_verification
        annotations:
          summary: "Human oversight override rate exceeds 15% baseline change"
          description: "Art.72 monitoring: override rate change {{ $value | humanizePercentage }}. Art.14 human oversight effectiveness review required."

      # Serious incident candidate
      - alert: SeriousIncidentCandidate
        expr: ai_incident_severity_score >= 8
        for: 0m
        labels:
          severity: critical
          eu_ai_act_article: art72_art73
          qms_trigger: immediate_escalation
        annotations:
          summary: "Potential Art.73 serious incident detected"
          description: "Art.73 NCA reporting window may apply (2 days critical-infra, 10 days death, 15 days other). Incident ID: {{ $labels.incident_id }}. Immediate investigation required."

Tier 2: Periodic Performance Review

Your Art.17 QMS must specify a formal periodic review cadence for monitoring data — typically quarterly. Each review should produce a written record that:

• Summarises the period's monitoring data against documented performance ranges
• Records any risk register updates triggered by monitoring findings
• Documents any technical documentation revisions made
• Confirms that the monitoring plan remains adequate for the current risk profile
• Identifies any changes to the monitoring plan required for the next period

This review record is both a QMS output (Art.17) and a monitoring log (Art.12).

Tier 3: Deployer Feedback Integration

For SaaS providers, your deployers operate the high-risk AI system and observe its real-world performance. Art.26 requires deployers to report serious incidents and malfunctions to providers. Your monitoring infrastructure must include a channel for receiving and processing that feedback.

class DeployerFeedbackProcessor:
    """Processes Art.26 deployer incident reports into Art.72 monitoring data."""
    
    def process_deployer_report(self, report: DeployerReport) -> MonitoringEvent:
        event = MonitoringEvent(
            source="deployer_report",
            deployer_id=report.deployer_id,
            incident_description=report.description,
            affected_users=report.affected_users,
            member_state=report.deployer_member_state,
            timestamp=report.report_timestamp,
        )
        
        # Run through serious incident classification (Art.73 trigger check)
        severity = self.incident_classifier.classify(event)
        event.severity = severity
        
        # If serious: initiate Art.73 reporting process
        if severity == IncidentSeverity.SERIOUS:
            self.art73_reporter.initiate_report(event)
        
        # Always: feed into risk register evaluation pipeline
        self.risk_register_updater.evaluate(event)
        
        # Always: log for Art.12 record-keeping
        self.monitoring_log.record(event)
        
        return event

The QMS Completeness Test

Before you file your technical documentation and declare your system ready for the August 2, 2026 enforcement date, apply this Art.72 completeness test to your QMS:

Art.72 QMS Feedback Loop Completeness Check
─────────────────────────────────────────────────────────────────

MONITORING PLAN
□ Written post-market monitoring plan exists in technical documentation
□ Plan specifies data sources, collection frequency, retention periods
□ Performance baselines are documented (what "normal" looks like)
□ Deviation thresholds are defined and justified
□ Review cadence is specified (recommend: quarterly minimum)
□ Deployer feedback channel is defined and operational

FEEDBACK CONNECTIONS
□ Monitoring → Art.9: risk register update triggers are defined and documented
□ Monitoring → Art.17: QMS review procedures include monitoring data review
□ Monitoring → Art.11: documentation currency check process exists
□ Monitoring → Art.21: corrective action escalation paths are mapped
□ Monitoring → Art.73: serious incident classification logic is documented
□ Monitoring → Deployers: material change notification process exists

INFRASTRUCTURE
□ Tier 1 (real-time): automated alerting for deviation threshold breaches
□ Tier 2 (periodic): formal quarterly review process with written output
□ Tier 3 (deployer): Art.26 feedback channel with processing pipeline
□ Art.12 record-keeping: all monitoring logs retained ≥10 years for high-risk AI

AUDIT READINESS
□ NCA information request response time: can produce monitoring plan in <24h
□ Monitoring log retrieval: can produce specific period logs within 2 business days
□ Risk register update history: audit trail exists from monitoring event to update
□ Art.73 history: all serious incident reports filed and accessible
□ QMS review records: formal periodic reviews documented and signed off

Summary: Art.72 as the Living Proof of Your QMS

Your Quality Management System under Art.17 is designed to ensure that your high-risk AI system performs as intended throughout its operational lifetime. Art.72 is how you prove it does.

Without post-market monitoring, your QMS is a set of pre-deployment assertions. With it, your QMS becomes a self-correcting system that adapts to real-world performance data — which is exactly what Art.9's iterative risk management requirement demands.

The feedback loop this QMS series has traced — Art.9 risk assessment → Art.17 management system → Art.11 documentation → Art.72 monitoring → back to Art.9 — is not a compliance formality. It is the architecture that makes a high-risk AI system safe to operate at scale.

Post #5 of this series will close the loop on audit readiness: how to prepare your complete QMS documentation package for NCA inspection, including the evidence assembly process, the conformity assessment connection, and the August 2, 2026 go/no-go checklist.

The EU AI Act Quality Management System Series:

• Post #1: EU AI Act Art.17 Quality Management System: A Developer's Implementation Guide
• Post #2: Art.11 Technical Documentation as QMS Output
• Post #3: EU AI Act Art.9 Risk Management System: Integrating with Your QMS
• Post #4: Art.72 Post-Market Monitoring: Closing the QMS Feedback Loop (this post)
• Post #5: QMS Audit Readiness: The Complete NCA Inspection Package