EU AI Act Post-Market Monitoring: The Complete SaaS Developer Checklist for August 2026

Post #1611 in the sota.io EU AI Act Post-Market Monitoring Operations Series

The EU AI Act's August 2, 2026 deadline for high-risk AI systems is 54 days away. If your system falls under Annex III (credit scoring, biometric identification, critical infrastructure, education, employment, benefits administration, law enforcement, migration, justice), you need operational post-market monitoring in place before day one.

This is the finale of our five-part Post-Market Monitoring series. We've covered the PMS plan structure (Art.72), MLOps implementation with drift detection and alert thresholds, bias monitoring and fairness metrics, and the Art.73 incident escalation pipeline. This post distills everything into a 40-point checklist you can work through today.

The series:

• Post #1: Art.72 PMS Plan — Required Metrics & Review Cycles
• Post #2: MLOps Implementation — Drift Detection & Alert Thresholds
• Post #3: Bias Monitoring — Fairness Metrics & Demographic Tracking
• Post #4: Art.73 Escalation Pipeline — When PMS Findings Become Mandatory Reports
• Post #5 (this post): Complete Developer Checklist

Part 1: PMS Plan Documentation (Art.72) — 8 Points

A Post-Market Monitoring system starts with a documented plan. This plan must exist before you place the system on the market.

Checkpoint 1 — PMS Plan Document exists You have a formal Post-Market Monitoring Plan document. It is version-controlled and referenced in your Annex IV technical documentation. It is not a section of another document — it stands alone.

Checkpoint 2 — Proportionality statement Your PMS plan opens with a proportionality statement explaining why the monitoring approach is appropriate for your system's risk level and use case. Art.72(1) requires the plan to be proportionate to the nature of the AI technology and the risks posed.

Checkpoint 3 — Data collection scope defined The plan specifies exactly what data will be collected: input features, prediction outputs, confidence scores, feedback signals, demographic attributes (where applicable and proportionate), and operational metadata. "We collect performance data" is not sufficient.

Checkpoint 4 — Performance indicators documented You have defined quantitative performance indicators with baseline values and acceptable ranges. These are the same metrics your Art.9 risk management system identified as relevant to the risks your system poses.

Checkpoint 5 — Review cycle schedule Your plan specifies review cadences: continuous automated monitoring, weekly dashboards, monthly KPI reviews, and at minimum annual comprehensive assessments. Art.72(4) requires ongoing data gathering and analysis.

Checkpoint 6 — Corrective action triggers For each performance indicator, you have defined the threshold at which corrective action is triggered. "Performance degrades" is not a trigger — "accuracy falls below 0.82 measured on rolling 7-day window" is.

Checkpoint 7 — Art.9 linkage documented Your PMS plan explicitly references which risk management system entries (from Art.9) each monitoring metric is designed to detect. The risk management system and the monitoring system are not independent silos.

Checkpoint 8 — Plan signed and version-controlled The current PMS plan has a version number, an effective date, a review date, and a sign-off from whoever is accountable for AI compliance in your organization. Old versions are retained for audit.

Part 2: MLOps Implementation — 8 Points

Having a plan is not enough. Art.72 requires an operational monitoring system. These checkpoints verify implementation.

Checkpoint 9 — Prediction logging active Every inference request is logged with: timestamp, input hash (not raw PII), output, confidence score, and deployment version. Logs are stored in EU jurisdiction. Retention period covers the system's operational lifetime plus any statutory period.

Checkpoint 10 — Data drift detection running You have automated drift detection comparing the statistical distribution of current inputs against your training distribution baseline. PSI (Population Stability Index) or KS test are common implementations. Alerts fire when PSI exceeds 0.2 or equivalent threshold.

Checkpoint 11 — Performance degradation detection You track your primary performance metric (accuracy, F1, AUC-ROC, or whatever is appropriate) on a rolling window. You have defined the window size and the degradation threshold that triggers an alert.

Checkpoint 12 — Concept drift indicators configured Beyond data drift (input distribution shift), you monitor for concept drift (relationship between inputs and outputs shifting). This typically requires ground truth labels or proxy signals — you have defined how you obtain these.

Checkpoint 13 — Alert routing configured Monitoring alerts do not just write to a log file. They route to a system where humans are notified and responses are tracked. Alert fatigue management is in place — you know how many alerts are firing per week.

Checkpoint 14 — Retraining trigger defined You have a documented criterion for triggering model retraining. This is connected to your monitoring thresholds, not an ad-hoc decision. Retraining is logged with the reason it was triggered.

Checkpoint 15 — Model version tracking Every deployed model version has a unique identifier. Monitoring metrics are tracked per version. When you retrain and redeploy, you can compare performance across versions against the same baseline.

Checkpoint 16 — Monitoring infrastructure in EU jurisdiction Your monitoring data — logs, metrics, dashboards, alerting configuration — is stored and processed within the EU. If you use a US-hosted observability platform (DataDog, New Relic, Splunk), this data is reachable under the CLOUD Act. Art.12 record-keeping obligations require audit trail integrity that a US-jurisdiction subpoena can compromise.

Part 3: Bias Monitoring — 6 Points

For high-risk AI systems in domains affecting individuals (credit, employment, benefits, law enforcement, education), Art.72 monitoring must include fairness and bias dimensions.

Checkpoint 17 — Protected attributes identified You have documented which demographic attributes are legally relevant for your use case. This is jurisdiction-specific — GDPR Art.9 special categories, relevant national anti-discrimination law, and sector-specific guidance all apply.

Checkpoint 18 — Fairness metrics selected and baselined You have selected appropriate fairness metrics (demographic parity, equalized odds, calibration by group, or others as justified) and established baseline values from your validation data. The choice of metric is justified in your risk management documentation.

Checkpoint 19 — Disaggregated performance tracking active You track your primary performance metrics disaggregated by relevant demographic groups. You can answer the question: "What is the false positive rate for group X versus group Y in production right now?"

Checkpoint 20 — Bias alert thresholds set You have defined thresholds for acceptable disparity between groups. When actual disparity exceeds threshold, an alert fires — the same alert routing as Checkpoint 13. "We check for bias in annual reviews" does not satisfy Art.72.

Checkpoint 21 — Bias incident escalation path documented You have defined at what level of detected bias a finding escalates from internal PMS action to potential Art.73 serious incident consideration. A significant unexpected disparity affecting a protected group in a high-risk domain is a candidate serious incident.

Checkpoint 22 — Fairness data jurisdiction secured Disaggregated data tracking demographic performance is particularly sensitive under GDPR. This data is stored with appropriate access controls, data minimization applied, and within EU jurisdiction.

Part 4: Art.73 Escalation Pipeline — 8 Points

Post-market monitoring creates findings. Some findings require mandatory reporting to national market surveillance authorities under Art.73. These checkpoints verify your escalation pipeline.

Checkpoint 23 — Serious incident definition documented Your team has read Art.73 and Art.3(49) and has a documented definition of what constitutes a "serious incident" for your specific system and use case. This definition is not generic — it reflects your system's actual failure modes.

Checkpoint 24 — Internal escalation criteria defined You have a decision matrix that maps monitoring finding severity to internal escalation tiers: (1) log and monitor, (2) internal review and corrective action, (3) potential serious incident — escalate to compliance, (4) confirmed serious incident — initiate Art.73 reporting.

Checkpoint 25 — 2-day preliminary report capability For incidents involving risk to health, safety, or fundamental rights, Art.73 requires a preliminary report to the national market surveillance authority within 2 calendar days of becoming aware. You have verified you can produce and submit a compliant preliminary report within this window. You know which authority to notify for each EU member state where you operate.

Checkpoint 26 — 10-day intermediate report capability Art.73 requires an intermediate report within 10 calendar days detailing what happened, immediate mitigation actions taken, and ongoing investigation status. You have a template and a process.

Checkpoint 27 — 15-day final report capability The final report is due within 15 calendar days and must include root cause analysis, permanent corrective measures, and updated risk assessment. You have verified you can complete this within the deadline.

Checkpoint 28 — Notification authority registry maintained You have a current list of the national market surveillance authorities in every EU member state where your high-risk AI system is deployed, along with their reporting contact information and any member-state-specific additional requirements.

Checkpoint 29 — Incident logging system in place Every potential serious incident is logged from the moment it is identified. The log records: when it was identified, who identified it, what the finding was, what tier it was classified as, what actions were taken, and when/if it escalated to Art.73 reporting.

Checkpoint 30 — Incident response rehearsed You have conducted at least one tabletop exercise simulating a serious incident scenario. Your team knows the escalation path, who makes the classification decision, and how to produce the regulatory report. "We'll figure it out when it happens" is not a compliant incident response capability.

Part 5: Infrastructure and Jurisdiction — 6 Points

EU AI Act compliance is not just about your model — it is about where your data and logs live.

Checkpoint 31 — Training data jurisdiction documented Your technical documentation (Annex IV, Art.10) specifies where your training data was stored and processed. If it crossed US jurisdiction during preprocessing or storage (S3, Snowflake, Databricks on AWS), this is documented and risk-assessed.

Checkpoint 32 — Inference infrastructure jurisdiction documented Your deployed model runs on infrastructure whose jurisdiction is documented. For EU market surveillance cooperation under Art.74, market surveillance authorities need to be able to access relevant information. If your inference infrastructure is on AWS US-East, this access path is through US-jurisdiction systems.

Checkpoint 33 — Monitoring data jurisdiction documented Where are your Art.72 monitoring logs stored? Where do your drift detection calculations run? Where is your alerting data? If the answer involves any US-headquartered cloud provider, the CLOUD Act applies to that data regardless of server location.

Checkpoint 34 — Audit trail integrity verifiable Your monitoring logs are tamper-evident. You can demonstrate to a market surveillance authority that your Art.72 monitoring records have not been altered. Log integrity mechanisms (append-only storage, hash chains, or equivalent) are documented.

Checkpoint 35 — Data retention policy covering AI Act period The EU AI Act does not specify a single retention period — Art.12 requires records to be kept for the AI system's operational lifetime, and Art.73 incident reports must be retained as part of your technical documentation. Your data retention policy reflects these requirements.

Checkpoint 36 — Subprocessor chain documented Your Annex IV technical documentation includes a list of relevant subprocessors involved in your AI system's operation: cloud providers, observability tools, data annotation vendors, third-party model providers. For each: name, jurisdiction, role, and what data they process.

Part 6: Organizational Readiness — 6 Points

Technical systems are not sufficient without organizational capability.

Checkpoint 37 — Compliance owner named There is a named individual in your organization who is accountable for EU AI Act Art.72 compliance. This person knows they are accountable, has the authority to take corrective action, and is the escalation point for monitoring findings.

Checkpoint 38 — Team training current Everyone who operates your AI system or works with its monitoring data understands their obligations under Art.72 and Art.73. Training is documented. "I told them at an all-hands once" is not documented training.

Checkpoint 39 — Board or leadership briefed Your leadership understands that serious incident under Art.73 requires regulatory reporting within 2 calendar days. When an incident happens at 3am on a Saturday, the escalation path to the person who can authorize regulatory notification does not depend on one person being available.

Checkpoint 40 — PMS plan review scheduled Your PMS plan has a next review date on the calendar. Art.72 requires the plan to remain appropriate as the system evolves. When you retrain the model, update the system, or observe sustained performance changes, you trigger a plan review.

The August 2026 Deadline: What Happens on Day One

On August 2, 2026, national market surveillance authorities begin active enforcement of high-risk AI obligations. This is not a soft launch — the AI Act has been in force since August 2024, with a two-year transition for high-risk system obligations.

Enforcement begins with documentation review. Market surveillance authorities will request: your Annex IV technical documentation, your Art.9 risk management system records, and your Art.72 PMS plan. If your PMS plan does not exist or is clearly theoretical (no operational monitoring, no alert thresholds, no escalation path), this is the first finding.

The second enforcement vector is incident reports. If your system produces a serious incident after August 2 and you fail to file within the 2/10/15-day windows, this is a direct Art.73 violation — fines up to 3% of global annual turnover or €15 million.

The third enforcement vector is market surveillance access. Art.74 requires you to cooperate with market surveillance authorities when they request information. If your monitoring data is on US-jurisdiction infrastructure, this cooperation may conflict with your CLOUD Act exposure. EU authorities want EU-jurisdiction records; US authorities can compel US-jurisdiction systems.

Infrastructure Decision: Where Your Monitoring Lives

The infrastructure checkpoints (31–36) reflect a compliance reality that many EU SaaS developers discover late: compliance is not just what your code does — it is where your code and data run.

The CLOUD Act (18 U.S.C. § 2713) requires US-based cloud providers to disclose data to US government agencies regardless of where servers are physically located. AWS Frankfurt, Azure Netherlands, and GCP Belgium are all subject to this. Your Art.12 audit trail, your Art.72 monitoring logs, and your Art.73 incident records — if stored on US-headquartered infrastructure — are reachable by US legal process in ways that may conflict with your EU compliance obligations.

Running your AI system and its monitoring stack on EU-native infrastructure (no US parent, no CLOUD Act exposure) eliminates this tension. sota.io runs on Hetzner Germany — EU jurisdiction, no US parent, your Art.72 logs stay in EU jurisdiction by default.

Checklist Summary

Part 1 — PMS Plan Documentation: ☐1 ☐2 ☐3 ☐4 ☐5 ☐6 ☐7 ☐8

Part 2 — MLOps Implementation: ☐9 ☐10 ☐11 ☐12 ☐13 ☐14 ☐15 ☐16

Part 3 — Bias Monitoring: ☐17 ☐18 ☐19 ☐20 ☐21 ☐22

Part 4 — Art.73 Escalation Pipeline: ☐23 ☐24 ☐25 ☐26 ☐27 ☐28 ☐29 ☐30

Part 5 — Infrastructure and Jurisdiction: ☐31 ☐32 ☐33 ☐34 ☐35 ☐36

Part 6 — Organizational Readiness: ☐37 ☐38 ☐39 ☐40

Target score for August 2 readiness: 35+ of 40, with all Part 4 (Art.73) checkpoints green.

See Also

• EU AI Act Art.72 PMS Plan: Developer's Guide to High-Risk AI Monitoring Requirements
• EU AI Act MLOps Implementation: Drift Detection & Alert Thresholds
• EU AI Act Bias Monitoring: Fairness Metrics in Production
• EU AI Act Art.73: When PMS Findings Become Mandatory Incident Reports
• EU AI Act Infrastructure Compliance: EU Hosting Checklist for Developers