sota.io
2026-05-30·5 min read·sota.io Team

EU AI Act Provider Sprint Finale 2026: Art.15, Art.17 & Art.72 — Complete High-Risk AI Compliance Stack

Post #5/5 — EU AI Act Provider Sprint 2026. Deadline: 2 August 2026.

EU AI Act Provider Sprint Finale 2026: Art.15 Accuracy, Art.17 QMS, Art.72 Post-Market Monitoring — Complete Compliance Stack

Five weeks before August 2026, providers of high-risk AI systems face their final sprint to full compliance. This concluding post in our EU AI Act Provider Sprint Series covers the three remaining pillars: Art.15 (accuracy, robustness, and cybersecurity), Art.17 (quality management system), and Art.72 (post-market monitoring). Then we consolidate all provider obligations into a master 50-item checklist.

If you've been following this series, you now have documented systems for risk management (Art.9), data governance (Art.10), technical documentation (Art.11), and transparency obligations to deployers (Art.13). Art.15, Art.17, and Art.72 complete the picture.

Why These Three Articles Matter Most at Deadline

Art.15, Art.17, and Art.72 are the operational backbone of high-risk AI compliance — not one-time documentation tasks but ongoing processes that must continue indefinitely after your system goes live.

Together, they form a compliance flywheel: design → measure → monitor → improve → re-measure.

Art.15: Accuracy, Robustness, and Cybersecurity

What Art.15 Requires

Art.15 mandates that high-risk AI systems achieve "appropriate levels" of accuracy, robustness, and cybersecurity throughout their lifecycle. The word "appropriate" is deliberate — the standard scales with the risk level and intended use. A medical diagnosis AI faces a higher accuracy bar than an HR screening tool, but both must document their performance targets and demonstrate they meet them.

Accuracy: Your system must produce correct outputs for its intended purpose. Art.15 does not prescribe a minimum accuracy figure — it requires you to:

  1. Define accuracy metrics relevant to your use case (precision, recall, F1-score, AUC, calibration error, etc.)
  2. Establish target thresholds before deployment
  3. Test against representative datasets that reflect real-world deployment conditions
  4. Document accuracy for each intended use category
  5. Disclose accuracy metrics and known limitations to deployers (via the Art.13 information package)

Robustness: Your system must behave consistently when inputs deviate from ideal conditions. Art.15 covers three robustness dimensions:

For robustness testing, providers typically use:

Cybersecurity: This is where Art.15 breaks new ground compared to traditional software security requirements. It specifically calls out adversarial attacks — attempts to manipulate AI systems through crafted inputs.

Art.15 cybersecurity requirements include:

  1. Adversarial robustness: The system must be designed to resist attempts to exploit vulnerabilities through adversarial examples, data poisoning, or model extraction
  2. Access controls: Unauthorized parties must not be able to alter system behavior, training data, or model parameters
  3. Security by design: Cybersecurity must be considered from system architecture through deployment, not bolted on afterward
  4. Incident detection: Mechanisms to detect and respond to security compromises must be in place

Art.15 Implementation Roadmap

Phase 1 — Define Performance Targets (Weeks 1-2)

Create an Art.15 Performance Specification document covering:

Art.15 Performance Specification — [System Name]
────────────────────────────────────────────────
Use Case:            [description]
Risk Category:       [Annex III classification]
Target Population:   [who this system serves]

ACCURACY METRICS
Primary metric:      [e.g., balanced accuracy ≥ 0.87]
Secondary metrics:   [e.g., false positive rate ≤ 0.08]
Test dataset:        [size, composition, date of assembly]
Known limitations:   [e.g., degraded performance on [subgroup]]

ROBUSTNESS THRESHOLDS
Input noise:         [max degradation under X% corrupted inputs]
Distribution shift:  [monitoring trigger threshold]
Failure mode:        [graceful degradation policy]

CYBERSECURITY CONTROLS
Adversarial testing: [methodology, tools, last test date]
Access control:      [who can modify model/data/config]
Incident response:   [detection → notification → remediation SLAs]

Phase 2 — Testing and Validation (Weeks 3-5)

Phase 3 — Monitoring Architecture (Weeks 6-8)

Art.15 and the SME Exemption

For SMEs and startups, Art.15 compliance can be proportionate. You don't need a separate adversarial testing team if you:

Art.17: Quality Management System

The QMS Concept

A Quality Management System is not a document — it's a set of interconnected policies, procedures, and processes that ensure your high-risk AI system is built, deployed, and maintained to a consistent standard. Art.17 requires every provider to have one, documented and implemented.

The practical analogy: ISO 9001 quality management, adapted for AI. If ISO 27001 governs information security processes, Art.17 governs AI compliance processes.

What an Art.17 QMS Must Cover

Art.17 specifies the minimum scope of your QMS:

1. Regulatory compliance strategy A documented statement of how you comply with the EU AI Act, including which conformity assessment route you take (self-assessment via Annex VI, or third-party via Annex VII for certain high-risk categories).

2. Design and development procedures Documented processes for:

3. Supplier and third-party management If your high-risk AI system incorporates third-party components (pre-trained models, datasets, APIs), your QMS must document:

4. Post-market monitoring procedures How you systematically collect, analyze, and act on performance data from deployed systems (feeding Art.72).

5. Record-keeping and documentation control Where documents are stored, who has access, how long records are retained, and how you handle version control for compliance artifacts.

6. Serious incident reporting procedures Internal escalation paths and notification timelines for serious incidents (connecting to Art.73 for operators, and Art.20 corrective action and duty of information obligations for providers).

7. Corrective action processes When your monitoring identifies a compliance gap, Art.17 requires a documented process for investigating root cause, implementing fixes, re-validating, and communicating to affected deployers.

8. Management responsibility Someone in your organization must own the QMS. Document who is responsible for AI compliance (a named role or function, not just "legal").

QMS Implementation Guide

Minimal viable QMS for startups (3 documents):

Many startups panic when they read "quality management system." In practice, an SME-proportionate QMS can start with three core documents:

Document 1: AI Compliance Policy A 2-4 page statement covering your compliance strategy, the scope of your high-risk AI systems, roles and responsibilities, and how you manage the Art.9-Art.15 requirements. Reference your Art.11 Technical Documentation Package.

Document 2: Development and Validation Procedures A step-by-step checklist for every model release — data quality checks (Art.10), accuracy benchmarks (Art.15), documentation update (Art.11), deployer notification (Art.13). This turns compliance into a repeatable workflow.

Document 3: Post-Market Monitoring and Incident Response Plan How you collect performance data after deployment (Art.72), what thresholds trigger review, and what happens when something goes wrong. Covers your Art.18 corrective action obligations.

Full QMS for regulated use cases (6-8 documents):

For Annex III use cases that require third-party conformity assessment (biometric identification, critical infrastructure, certain employment/education systems), your QMS should be audit-ready:

  1. AI Compliance Policy + Management Responsibility Matrix
  2. Risk Management Procedures (Art.9)
  3. Data Governance Procedures (Art.10)
  4. Development, Training, and Validation Procedures (Art.15)
  5. Technical Documentation Control Procedure (Art.11)
  6. Deployer Communication and Transparency Procedure (Art.13)
  7. Post-Market Monitoring and Incident Response Procedure (Art.72, Art.73)
  8. Supplier/Third-Party Management Procedure

QMS version control: Every QMS document needs a version number, effective date, approval signature (or equivalent digital record), and a change log. When you update the system substantially (model retrain, new use case), update your QMS documents and re-run your conformity assessment review.

QMS and Conformity Assessment

Art.17 is inseparable from conformity assessment. When you complete your self-assessment (for most Annex III categories under Art.43 Annex VI), you sign a Declaration of Conformity attesting that your QMS exists and that your system meets Art.9-Art.15. If a market surveillance authority audits you, the QMS is the first document they request.

Art.72: Post-Market Monitoring System

Why Post-Market Monitoring Is Different from Pre-Deployment Testing

Art.15 testing happens before deployment. Art.72 monitoring happens after. The distinction matters because real-world AI system behavior often diverges from pre-deployment test results:

Art.72 requires providers to systematically capture this real-world experience and feed it back into the compliance lifecycle.

Art.72 Post-Market Monitoring Plan

Every provider must establish a post-market monitoring (PMM) plan — a documented strategy for collecting and analyzing performance data from deployed systems. Your PMM plan must be proportionate to the nature and risk of the system.

Minimum PMM plan components:

1. Monitoring objectives What specifically are you monitoring? List your Art.15 accuracy metrics, the robustness indicators from your performance specification, and any use-case-specific safety signals.

2. Data collection methods How will you collect performance data from deployed systems? Options include:

3. Monitoring frequency and triggers When do you review? Art.72 requires "proactive" monitoring — not waiting for complaints. Define:

4. Analysis and escalation procedures When monitoring reveals a concern:

5. Feedback loop to Art.9 risk management Art.72 findings must feed into your Art.9 risk register. When monitoring identifies a new risk that wasn't anticipated at design time, update the risk register, assess severity, and implement mitigations under your Art.20 corrective action process.

6. Record-keeping All PMM activities must be documented: what was monitored, what was found, what actions were taken. These records must be available to market surveillance authorities on request.

PMM for SaaS Providers: Practical Architecture

If you're a SaaS provider whose high-risk AI system is used by multiple deployers, your PMM architecture typically looks like this:

SaaS Provider PMM Architecture
────────────────────────────────
Deployer A ──┐
Deployer B ──┼──→ Feedback API ──→ Monitoring Dashboard ──→ PMM Review Team
Deployer C ──┘           │                                         │
                         ↓                                         ↓
                  Data Store                               Art.9 Risk Register
                  (predictions +                          Art.17 QMS Corrective Actions
                   outcomes where                         Art.18 Provider Notifications
                   available)

Key implementation decisions:

Opt-in vs. mandatory logging: Under GDPR, you cannot log personal data for PMM purposes without a lawful basis. Options include: consent (deployer agreement terms), legitimate interests assessment, or contractual necessity. Structure your Art.13 information package to inform deployers that their usage data feeds your PMM obligations.

Outcome feedback: The hardest part of PMM is getting ground-truth outcomes. If your AI makes a hiring recommendation, you rarely learn whether the hire was successful. Design PMM to work with available proxies: deployer override rates (how often do deployers override the AI?), complaint rates, escalation rates.

Drift detection: Implement statistical drift detection (population stability index, Jensen-Shannon divergence, or similar) on input feature distributions. Drift in inputs predicts degradation before it shows up in outcome metrics.

PMM and the August 2026 Deadline

Your PMM plan must exist before your system goes into production at compliance deadline. You don't need six months of monitoring data on 2 August 2026 — you need the plan, the data collection infrastructure, and evidence that it's operating.

Master Provider Compliance Checklist — All 50 Items

This checklist consolidates all provider obligations across the EU AI Act Provider Sprint series (Art.9, Art.10, Art.11, Art.13, Art.15, Art.17, Art.72). Use it as your August 2026 readiness gate.

Art.9 — Risk Management System (covered in Post #1)

Art.10 — Data and Data Governance (covered in Post #2)

Art.11 — Technical Documentation (covered in Post #3)

Art.13 — Transparency and Deployer Information (covered in Post #4)

Art.15 — Accuracy, Robustness, and Cybersecurity

Art.17 — Quality Management System

Art.72 — Post-Market Monitoring

The Provider Compliance Flywheel

All five posts in this series describe components of a single system. Here's how they connect:

     Art.9 Risk Management
            │
            ↓ informs
     Art.10 Data Governance ──────────────────────┐
            │                                      │
            ↓ produces                             │
     Art.11 Technical Documentation ◄─────────────┤
            │                                      │
            ↓ informs                              │
     Art.13 Deployer Information ◄─────────────────┤
            │                                      │
            ↓ defines standards                    │
     Art.15 Accuracy/Robustness/Security            │
            │                                      │
            ↓ governs all                          │
     Art.17 Quality Management System              │
            │                                      │
            ↓ monitors                             │
     Art.72 Post-Market Monitoring ────────────────┘
            │
            └──→ findings feed back into Art.9 ↑

This is not a compliance checklist you complete once. It's a lifecycle management system you operate continuously.

Putting It Together: The August 2026 Sprint Plan

With 63 days until the August 2026 deadline (2 August 2026), here's a realistic sprint for a high-risk AI provider that has partially addressed these obligations:

Weeks 1-2: Assessment

Weeks 3-5: Documentation Sprint

Weeks 6-8: Implementation and Validation

Final 2 weeks: Conformity Assessment

EU Deployment and the Sovereignty Dimension

Meeting EU AI Act obligations is not only about legal compliance — it's about market access. EU deployers (including government bodies, financial institutions, healthcare providers) will increasingly require proof of Art.9-Art.17 compliance before onboarding high-risk AI systems. Your QMS and PMM plan become commercial assets: demonstrable evidence of trustworthy AI.

For providers building on EU infrastructure — where your training data, model weights, and inference endpoints remain in EU jurisdictions — the compliance narrative extends naturally to data sovereignty. Deployers face their own obligations (see the EU AI Act Deployer Sprint) and look for providers who reduce their compliance burden. Deploying on an EU-native stack eliminates one class of deployer concern entirely.

Series Summary: EU AI Act Provider Sprint 2026

This series covered the full provider compliance stack for high-risk AI systems under the EU AI Act:

  1. Art.9: Risk Management System — The four lifecycle phases, risk categories, 25-item implementation checklist
  2. Art.10: Data Governance — 8-domain data practices, bias examination, special categories, 20-item checklist
  3. Art.11: Technical Documentation — Annex IV requirements, document architecture, version control
  4. Art.13: Transparency to Deployers — Instructions for Use, 10 categories, substantial change protocol
  5. Art.15 + Art.17 + Art.72 (this post) — Performance standards, QMS, post-market monitoring, 50-item master checklist

The August 2026 deadline is not the end of the story — it's when ongoing compliance operations begin. Providers who treat these obligations as a one-time sprint will find themselves non-compliant within 12 months. Providers who build the compliance flywheel have systems that self-correct.

See Also

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Join the waitlistView pricing