EU AI Act Art.72 Post-Market Monitoring: Building the System NCAs Will Inspect in 2026

Post #1498 in the sota.io EU AI Compliance Series — EU-AI-ACT-MARKET-SURVEILLANCE-OPS-2026 #2/5

Your Art.74 inspection starts before the NCA knocks on the door. National competent authorities reviewing high-risk AI systems under EU AI Act market surveillance are explicitly checking whether your Art.72 post-market monitoring system is operational, documented, and producing evidence. A monitoring system that exists only on paper — or that generates data you cannot retrieve within NCA timelines — fails the inspection regardless of your AI system's actual performance.

This guide covers what Art.72 requires, how NCAs verify compliance during Art.74 market surveillance, the evidence trail you must maintain, and the operational gaps that trigger corrective action.

What Art.72 Actually Requires

Art.72 of the EU AI Act (Regulation (EU) 2024/1689) imposes a post-market monitoring obligation on providers of high-risk AI systems. The obligation has three components:

1. A post-market monitoring plan — documented before market placement, integrated into your Art.11 technical documentation and Art.9 risk management system.

2. Active data collection — gathering, documenting, and analysing data on the performance of high-risk AI systems throughout their operational lifetime.

3. Incident escalation — feeding serious incidents and near-misses into the Art.73 reporting pipeline.

The plan is not a one-time document. Art.72 requires you to update it when performance data reveals new risk patterns, when the system is substantially modified, or when NCA findings indicate gaps.

What NCAs Check During Art.74 Market Surveillance

Under Art.74, national competent authorities have the power to access your technical documentation, source code, datasets, and operational records. When an NCA initiates market surveillance of a high-risk AI system, it will specifically examine your Art.72 compliance through several lenses:

1. Does a post-market monitoring plan exist?

The NCA will request your Art.11 technical documentation package. Within it, the post-market monitoring plan must appear as a named section. Inspectors look for:

• Data sources identified (deployment logs, user feedback, error rates, drift metrics)
• Collection frequency and retention periods specified
• Responsible personnel or function named
• Update cadence documented

A vague reference to "ongoing monitoring" is not a plan. NCAs expect a structured document with timelines, metrics, and ownership.

2. Is the system actually collecting data?

The plan must be operational. NCAs request evidence of actual monitoring activity: log files, dashboards, periodic reports, or anomaly alerts covering the period since market placement. If your high-risk AI system has been deployed for six months but you can only produce three weeks of monitoring data, the inspection will identify this gap.

Key data categories NCAs expect to find collected:

• Performance drift — is the model performing within the parameters validated during conformity assessment (Art.43)?
• Error rate trends — are false positive / false negative rates stable or degrading?
• Edge case encounters — when has the system encountered inputs outside its training distribution?
• User feedback — has any deployer reported unexpected outputs under Art.26?
• Near-miss events — situations where system output could have caused harm but did not

3. Is the system integrated with Art.73 incident reporting?

NCAs cross-reference your Art.72 monitoring records against your Art.73 serious incident reports. If your monitoring data shows anomalies that should have triggered Art.73 reporting (death, serious harm, or significant rights violation) but no incident report exists, the NCA will treat this as a compliance failure on both Art.72 and Art.73 simultaneously.

The Art.73 reporting timelines are strict:

• 2 days for serious incidents involving critical infrastructure or widespread harm
• 10 days for incidents involving death
• 15 days for other serious incidents

Your monitoring system must be able to detect and escalate within these windows — which means near-real-time alerting for serious incident triggers, not weekly batch analysis.

4. Can you produce Art.72 evidence on NCA timelines?

Art.74 gives NCAs the power to compel documentation within specified periods. Your monitoring system must be queryable on demand. If your monitoring data lives in a CLOUD Act-jurisdiction storage system (AWS S3, Azure Blob, Google Cloud Storage), NCA investigators from the data-sovereignty angle face a jurisdictional complexity: the storage provider is technically subject to US government disclosure requests, which creates evidence-chain integrity questions under cross-border enforcement.

EU-native monitoring infrastructure — running on Hetzner, Scaleway, OVHcloud, or a managed PaaS like sota.io — eliminates this complexity. Your monitoring data sits under EU law, period.

Building the Post-Market Monitoring System

A compliant Art.72 post-market monitoring system for a high-risk AI application has five operational layers:

Layer 1: Input/Output Logging

Every inference by your high-risk AI system must be logged with sufficient detail to reconstruct the decision context. Minimum logging payload:

• Timestamp (UTC)
• Input vector hash (not raw input — to protect data subjects under GDPR Art.5(1)(e))
• Model version identifier
• Output class or value
• Confidence score
• Processing node / environment identifier

Retention: Art.72 does not specify a minimum, but Art.11 technical documentation retention is 10 years post-market. Align your monitoring data retention to this.

Layer 2: Performance Metric Computation

Raw logs are not monitoring. Your system must compute derived metrics on a defined schedule:

• Accuracy drift vs. conformity-assessment baseline
• Distribution shift on input features
• False positive / false negative rate trends per deployment context
• Latency anomalies (can indicate data-quality problems upstream)

Compute frequency: daily for production systems; real-time alerting for incidents.

Layer 3: Threshold-Based Alerting

Define numeric thresholds for each metric that trigger internal alerts. Thresholds must be:

• Documented in your post-market monitoring plan
• Calibrated against your Art.9 risk management system (higher-risk use cases → tighter thresholds)
• Reviewed when the model is updated or when deployment context changes

Breach of a threshold triggers Layer 4.

Layer 4: Incident Classification and Escalation

Alert breaches are classified by severity:

• Level 1 — Near-miss: Performance degraded but no harm occurred. Document, investigate, update monitoring plan.
• Level 2 — Significant deviation: Output caused or could have caused material harm to a user. Escalate to legal/compliance within 24h. Assess Art.73 reporting obligation.
• Level 3 — Serious incident: Death, serious injury, or significant rights violation. Art.73 report to NCA within statutory window. Consider market withdrawal pending investigation.

Layer 5: Periodic Monitoring Reports

Generate a formal monitoring report at minimum quarterly. The report must:

• Summarise metric trends over the period
• Document all Level 1-3 events and their resolution
• Confirm the monitoring plan remains fit-for-purpose or propose updates
• Be signed off by the person responsible for the quality management system (Art.17)

These reports are primary evidence during an NCA inspection. A provider that cannot produce quarterly monitoring reports for the prior 12 months will struggle to demonstrate Art.72 compliance.

Common Art.72 Gaps That Trigger NCA Corrective Action

Based on the pattern of NCA enforcement expectations expressed in EU AI Act implementation guidance, these are the most common Art.72 gaps inspectors identify:

Gap 1: Plan exists, system does not

The monitoring plan was written for the conformity assessment (Art.43) but never operationalised. Logs are not collected. No dashboards exist. This is the most common gap and results in the most serious NCA findings.

Fix: Treat the post-market monitoring plan as engineering infrastructure, not a document artifact. Build it into your CI/CD pipeline and deploy it alongside the AI model.

Gap 2: Data collected, but not analysable on demand

Logs exist in CloudWatch, Datadog, or Splunk — but there is no way to produce an NCA-ready report showing specific metric trends over a defined period. The data is there; the query interface is not.

Fix: Build two artifacts: raw logs (for completeness) and pre-computed metric reports (for NCA retrieval). Run nightly report generation. Archive reports for 10 years.

Gap 3: No integration with Art.73 pipeline

Monitoring identifies anomalies, but there is no formal escalation path to the Art.73 reporting workflow. An internal ticket is opened; no one checks whether it crosses the serious incident threshold.

Fix: Add an explicit Art.73 check step to your Level 2+ escalation procedure. The question "Does this meet the Art.73 serious incident definition?" must be answered and documented within your escalation SLA.

Gap 4: Monitoring plan not updated after model changes

The original plan was compliant, but the model was fine-tuned, retrained, or updated without updating the monitoring thresholds to match the new version's performance profile. The old thresholds do not catch new failure modes.

Fix: Make post-market monitoring plan review a mandatory step in your model update approval workflow.

Gap 5: Third-country storage undermines evidence integrity

Monitoring data is stored in a CLOUD Act-jurisdiction system. In a cross-border NCA investigation, data sovereignty questions arise about whether the monitoring evidence can be subpoenaed by non-EU authorities — and whether that constitutes an unauthorised data transfer under GDPR.

Fix: Route monitoring data to EU-jurisdiction storage from the start. Retro-migrating monitoring infrastructure after an NCA visit is expensive and disruptive.

Art.72 and the Art.9 Risk Management System

Your Art.72 post-market monitoring system feeds your Art.9 risk management system — they are not independent. The relationship:

• Art.9 risk management system identifies risks and defines control measures during development
• Art.72 post-market monitoring collects evidence on whether those controls are working in production
• When monitoring reveals a control is ineffective, Art.9 requires you to update the risk assessment and the control set
• The updated risk assessment flows back into your Art.11 technical documentation

NCAs examining a high-risk AI system expect to see this feedback loop documented. A risk management system that shows no updates since initial deployment — despite months of post-market monitoring data — signals to inspectors that the loop is broken.

Integration with Art.26 Deployer Feedback

Under Art.26, deployers of high-risk AI systems have obligations to monitor the system's use and report relevant information to providers. Your Art.72 post-market monitoring system should have a defined intake process for Art.26 deployer feedback:

• A documented channel for deployers to submit performance observations
• A triage process that classifies deployer reports by risk level
• An SLA for responding to deployer reports that indicate potential Art.73 triggers
• Evidence that deployer feedback has been considered in monitoring plan updates

NCAs examining deployer-reported incidents will also request evidence that the provider's Art.72 system received and acted on the reports.

August 2026 Readiness Checklist

With the August 2, 2026 EU AI Act deadline approaching, here is the Art.72 inspection-readiness checklist for high-risk AI providers:

Documentation

• Post-market monitoring plan documented and version-controlled
• Plan referenced in Art.11 technical documentation package
• Plan updated after each model version release
• Responsible persons named and aware of obligations
• Retention policy documented (minimum 10 years)

Operational

• Input/output logging active for all high-risk AI deployments
• Performance metrics computed on defined schedule
• Threshold alerts configured and tested
• Art.73 escalation pathway documented and linked to monitoring alerts
• Art.26 deployer feedback intake process operational

Evidence

• Monitoring reports generated at least quarterly since deployment
• All Level 1+ events documented with resolution
• Evidence accessible on demand in EU-jurisdiction storage
• Audit trail complete and tamper-evident
• Last Art.9 risk management system update reflects current monitoring findings

NCA Readiness

• Monitoring data can be exported within 48h of NCA request
• Person responsible for Art.72 compliance named in quality management system (Art.17)
• Protocol in place for NCA access to monitoring infrastructure during Art.74 inspection

Storing Monitoring Data on EU-Native Infrastructure

Art.72 data includes sensitive performance records about AI systems affecting natural persons. Under GDPR, this data must be handled with appropriate technical and organisational measures. If your monitoring data traverses or rests in CLOUD Act-jurisdiction infrastructure, you face a structural contradiction: evidence generated to demonstrate EU AI Act compliance sits in a system where US government access is legally possible without the knowledge of the EU controller.

EU-native managed PaaS — running entirely within Hetzner Germany or equivalent EU jurisdiction — eliminates this contradiction. Your monitoring logs, metric databases, and periodic reports stay under EU law. When NCAs request access during Art.74 market surveillance, there are no cross-jurisdictional complications.

sota.io is EU-native managed PaaS: no US parent, no CLOUD Act exposure, Hetzner Germany infrastructure. Git-deploy your monitoring stack the same way you deploy your AI application, and your Art.72 evidence stays EU-sovereign.

Next in the MARKET-SURVEILLANCE-OPS-2026 Series

• Post #1499: EU AI Act Art.73 Serious Incident Reporting Operations: Timelines, Evidence Packages, and NCA Communication Protocols
• Post #1500: NCA Corrective Action Response: What to Do When Market Surveillance Finds Non-Compliance
• Post #1501: MARKET-SURVEILLANCE-OPS-2026 Finale: Complete NCA Inspection Readiness Toolkit for High-Risk AI Providers