2026-06-10·5 min read·sota.io Team

EU AI Act Art.16 Post-Placement Provider Obligations: Corrective Actions, NCA Cooperation & Post-Market Monitoring 2026

Post #2 in the sota.io EU AI Act Art.16 Provider Obligations Series

EU AI Act Art.16 post-placement obligations loop: corrective actions, NCA cooperation and post-market monitoring cycle for high-risk AI providers

Most high-risk AI provider compliance programmes focus on the pre-deployment checklist: technical documentation, quality management system, conformity assessment, CE marking, EU database registration. Complete those, place the system on the market, move on to the next sprint. The compliance work is done.

This framing is wrong. Article 16 of Regulation (EU) 2024/1689 imposes a second cluster of obligations that activate only after your system is deployed and running in production. These are the post-placement obligations, and they impose continuous legal duties that run for the operational lifetime of the system. Missing them does not produce a pre-deployment audit finding — it produces a serious incident report, a regulatory investigation, or an enforcement notice after something goes wrong in production.

With 53 days remaining before the August 2, 2026 enforcement deadline, this post breaks down the full post-placement cluster under Art.16: the corrective action duty under Art.20, the cooperation obligations under Art.21, the user information duty under Art.13, and the post-market monitoring requirement under Art.72. Each section includes concrete implementation guidance you can start building today.

The Post-Placement Obligations in Art.16

Article 16 maps 11 distinct provider obligations across the letter designations (a) through (k). The first five — compliance with Arts.9–15, quality management system, technical documentation, record-keeping, and conformity assessment — are predominantly pre-deployment obligations. The remaining six are either continuous or triggered by post-deployment events:

Art.16 Obligation	Implementing Article	Pre- or Post-Placement
(g) Corrective actions	Art.20	Post-placement (triggered)
(h) Cooperation with market surveillance	Art.21	Post-placement (triggered)
(i) Inform deployers and users	Art.13	Continuous
(j) Post-market monitoring	Art.72	Continuous
(k) Serious incident reporting	Art.73	Post-placement (triggered)
(f) Registration in EU database	Art.49	Pre-placement (one-time + update)

This post covers obligations (g) through (j). Serious incident reporting under Art.73 was covered in detail in the EU AI Act Art.73 Incident Detection Automation post in this series.

Art.16(g) + Art.20: Corrective Actions and the Duty of Information

What Art.20 Requires

Article 20 establishes a three-part corrective action obligation for providers who consider, or have reason to consider, that a high-risk AI system they have placed on the market or put into service is not in conformity with the EU AI Act.

Part 1 — Immediate corrective action. The provider must take all necessary corrective action to bring the system into conformity, to withdraw it, or to recall it, as appropriate. The regulation does not prescribe a fixed timeline for this step, but the phrase "immediately take the necessary corrective measures" in Art.20(1) establishes an urgency standard. For a cloud-delivered AI system, "corrective action" typically means one of: disabling the non-conforming feature, deploying a conforming patch, restricting access for affected deployers, or suspending service.

Part 2 — Inform competent authorities. If the non-conformity presents a risk to health, safety, or fundamental rights, the provider must inform the market surveillance authorities of the member states in which they made the system available. The information must include: the nature of the non-conformity, the corrective action taken, and whether the non-conformity has been corrected. This notification obligation mirrors the product safety notification obligations many hardware manufacturers already comply with.

Part 3 — Inform deployers. The provider must also inform the deployers to whom they have supplied the system of the non-conformity and the corrective measures taken. This is distinct from the Art.21 NCA cooperation obligation — deployer notification runs in parallel.

The Triggering Threshold

Art.20 activates when the provider "considers or has reason to consider" non-conformity. This is an objective standard: if a reasonable provider in your position would conclude there is a non-conformity issue, the obligation applies even if you have not yet made a definitive determination. Waiting for certainty before triggering the corrective action protocol is not a defensible compliance position.

In practice, the triggering events for an Art.20 assessment should include:

A serious incident report under Art.73 (automatic trigger — if a serious incident occurred, non-conformity is plausible)
A market surveillance authority request for documentation under Art.21
Internal monitoring detecting that system accuracy, robustness, or fairness metrics have degraded below the thresholds documented in your Annex IV risk management plan
A deployer complaint that the system is producing outcomes inconsistent with the use case constraints in the instructions for use
A third-party security finding affecting the Art.15 cybersecurity requirements

Building the Corrective Action Assessment Workflow

The practical implementation of Art.20 compliance is a three-stage workflow: detection, assessment, and response.

# corrective_action_trigger.py
# Runs as part of post-market monitoring pipeline — see Art.72 section below

from enum import Enum
from dataclasses import dataclass
from typing import Optional
import logging

class NonConformityType(Enum):
    ACCURACY_DEGRADATION = "accuracy_degradation"
    ROBUSTNESS_FAILURE = "robustness_failure"
    TRANSPARENCY_GAP = "transparency_gap"
    HUMAN_OVERSIGHT_BYPASS = "human_oversight_bypass"
    DATA_GOVERNANCE_BREACH = "data_governance_breach"
    CYBERSECURITY_INCIDENT = "cybersecurity_incident"
    SERIOUS_INCIDENT = "serious_incident"  # Art.73 trigger — auto-escalates

@dataclass
class NonConformitySignal:
    signal_type: NonConformityType
    description: str
    metric_key: Optional[str]
    metric_value: Optional[float]
    threshold: Optional[float]
    source: str  # "monitoring", "deployer_report", "nca_inquiry", "internal_audit"
    timestamp: str

@dataclass
class CorrectiveActionAssessment:
    signal: NonConformitySignal
    risk_to_health_safety_fundamental_rights: bool  # Art.20(1) trigger for NCA notification
    immediate_action_required: bool
    proposed_corrective_action: str
    deployers_to_notify: list[str]
    nca_member_states: list[str]  # populated if risk_to_health_safety_fundamental_rights=True
    assessment_timestamp: str

def assess_non_conformity_signal(signal: NonConformitySignal) -> CorrectiveActionAssessment:
    """
    Art.20 corrective action assessment.
    Returns assessment with notification obligations.
    """
    # Serious incidents always present risk to health/safety/fundamental rights
    risk_flag = signal.signal_type == NonConformityType.SERIOUS_INCIDENT
    
    # Accuracy degradation beyond threshold in HR/healthcare domain = fundamental rights risk
    if signal.signal_type == NonConformityType.ACCURACY_DEGRADATION:
        if signal.metric_value and signal.threshold:
            degradation_pct = (signal.threshold - signal.metric_value) / signal.threshold
            risk_flag = degradation_pct > 0.15  # >15% degradation below documented threshold
    
    # Human oversight bypass in any domain = fundamental rights risk
    if signal.signal_type == NonConformityType.HUMAN_OVERSIGHT_BYPASS:
        risk_flag = True
    
    return CorrectiveActionAssessment(
        signal=signal,
        risk_to_health_safety_fundamental_rights=risk_flag,
        immediate_action_required=risk_flag or signal.signal_type == NonConformityType.SERIOUS_INCIDENT,
        proposed_corrective_action=_determine_corrective_action(signal),
        deployers_to_notify=_get_affected_deployers(signal),
        nca_member_states=_get_deployment_member_states() if risk_flag else [],
        assessment_timestamp=_utc_now()
    )

def _determine_corrective_action(signal: NonConformitySignal) -> str:
    actions = {
        NonConformityType.ACCURACY_DEGRADATION: "Disable affected model version; roll back to last conforming version; update monitoring thresholds",
        NonConformityType.ROBUSTNESS_FAILURE: "Restrict input domain; apply input validation patch; schedule model robustness retest",
        NonConformityType.TRANSPARENCY_GAP: "Update instructions for use; notify deployers of revised guidance; update Art.13 documentation",
        NonConformityType.HUMAN_OVERSIGHT_BYPASS: "Immediately disable feature; mandatory human review reinstatement; full Art.14 re-audit",
        NonConformityType.CYBERSECURITY_INCIDENT: "Apply security patch; rotate credentials; NCA notification; Art.73 incident report if serious",
        NonConformityType.SERIOUS_INCIDENT: "Disable implicated feature; Art.73 NCA notification within 2 days; deployer notification",
    }
    return actions.get(signal.signal_type, "Manual review required")

What the Corrective Action Record Must Contain

Art.20 does not specify a documentation format, but prudent practice — and what market surveillance authorities will request under Art.21 — means your corrective action record should document:

The triggering signal and date detected
Whether a risk to health, safety, or fundamental rights was assessed and the reasoning
The corrective action taken and the date completed
Which deployers were notified and when
Which NCA member states were notified and when (if applicable)
The outcome: was conformity restored, or was the system withdrawn?

Store these records with the same retention policy as your Art.12 operational logs — accessible for NCA inspection on demand.

Art.16(h) + Art.21: Cooperation with National Competent Authorities

The Scope of Art.21 Cooperation Duties

Article 21 requires providers to supply competent authorities, upon reasoned request, with all the information and documentation necessary to demonstrate conformity of the high-risk AI system with the requirements of Chapter III Section 2. The cooperation duty covers three specific areas:

Documentation access. NCAs can request the complete Annex IV technical documentation, the Art.17 QMS documentation, the Art.12 operational logs for a specified period, the Art.73 serious incident records, and the Art.20 corrective action records. The word "demonstrate conformity" sets the standard: you must be able to present this documentation in a way that an authority can verify your claims.

Physical and technical access. Art.74 (market surveillance powers) supplements Art.21 by giving NCAs the right to access the AI system itself — including testing it, reviewing its training data, and inspecting its monitoring infrastructure. Art.21 cooperation means facilitating that access, not obstructing it.

Access to personnel. NCAs can require interviews with the technical and compliance staff responsible for the system. This is a standard product safety investigation power.

Building the NCA Regulatory Access Package

The most effective way to satisfy Art.21 cooperation obligations is to maintain a pre-packaged regulatory access bundle that can be handed to an NCA within 24–48 hours of a request. This is distinct from your Annex IV Technical Documentation (which documents conformity) — it is an access package that lets an authority navigate your compliance artefacts efficiently.

The regulatory access package should contain:

regulatory-access-package/
├── README.md                    # How to read this package; system overview; contact info
├── 01-technical-documentation/  # Annex IV complete file (latest version)
│   ├── annex-iv-v{version}.pdf
│   └── version-history.md
├── 02-qms-documentation/        # Art.17 QMS manual and procedure records
│   ├── qms-manual.pdf
│   └── recent-reviews/
├── 03-risk-management/          # Art.9 RMS: current risk register, mitigation evidence
│   └── risk-register-current.json
├── 04-operational-logs/         # Art.12 logs for the requested period
│   └── generate-log-export.sh   # Script to export logs for specified date range
├── 05-conformity-assessment/    # Art.43 conformity assessment record, DoC, CE marking
│   ├── declaration-of-conformity.pdf
│   └── conformity-assessment-record.pdf
├── 06-post-market-monitoring/   # Art.72 monitoring reports and alert records
│   └── monitoring-reports/
├── 07-corrective-actions/       # Art.20 corrective action records
│   └── ca-records/
├── 08-incident-records/         # Art.73 serious incident reports
│   └── incident-reports/
└── 09-eu-database-registration/ # Art.49 registration confirmation and EU database entry
    └── eu-database-entry.pdf

Key principle: every document in the package should have a creation timestamp, a version number, and a named responsible person. NCAs are experienced at identifying documentation assembled after the fact — timestamped audit trails are more credible than polished PDFs.

The Art.74 Inspection Right

Art.74(6) gives NCAs the right to conduct inspections at the provider's premises, including accessing development and testing environments. For a cloud-native AI provider on EU infrastructure, "premises" includes your production deployment environment. Providers who host on non-EU infrastructure face a structural complication: the NCA's Art.74 physical access right runs into jurisdictional limits when the infrastructure is outside the EU.

This is a practical argument for EU-hosted infrastructure. An NCA from Germany or France can exercise its Art.74 inspection right against a system running on Hetzner Germany as a routine administrative matter. The same NCA exercising the same right against a system running on AWS us-east-1 requires international legal coordination that may not produce results within the NCA's operational timeline.

Art.16(i) + Art.13: Keeping Users Informed Through the Lifecycle

When Art.13 Documentation Must Be Updated

Article 13 requires providers to ensure that high-risk AI systems are transparent — specifically, that they come with instructions for use in digital or physical form that enable deployers to understand the system's capabilities, limitations, accuracy performance, and intended deployment conditions.

The update obligation under Art.13 runs continuously. Any of the following events requires a documentation update and notification to deployers:

A new version of the system with changed capabilities or limitations
A change in the intended purpose (including expansion to new Annex III domains)
A corrective action that changes the system's behaviour or use constraints
New accuracy or robustness data from post-market monitoring that changes the parameters deployers should use
New guidance from the EU AI Office or relevant NCA on applicable requirements

The practical implementation: maintain a CHANGELOG.md alongside your instructions for use, versioned with each system release. Every deployer who has integrated your system should receive automated notification when the instructions for use are updated. This is a release-communications practice most SaaS teams already implement — it becomes a regulatory obligation under Art.13.

# .github/workflows/deployer-notification.yml
# Triggered on release of a new system version

name: Deployer Notification — Art.13 Update

on:
  release:
    types: [published]

jobs:
  notify-deployers:
    runs-on: ubuntu-latest
    steps:
      - name: Check for instructions-for-use changes
        id: check_ifu_changes
        run: |
          # Compare instructions-for-use/ between this release and previous
          PREV_TAG=$(git describe --abbrev=0 --tags HEAD~1 2>/dev/null || echo "")
          if [ -n "$PREV_TAG" ]; then
            CHANGED=$(git diff $PREV_TAG HEAD --name-only -- docs/instructions-for-use/ | wc -l)
            echo "changed=$CHANGED" >> $GITHUB_OUTPUT
          else
            echo "changed=1" >> $GITHUB_OUTPUT
          fi
      
      - name: Send deployer notification
        if: steps.check_ifu_changes.outputs.changed != '0'
        env:
          DEPLOYER_NOTIFICATION_WEBHOOK: ${{ secrets.DEPLOYER_NOTIFICATION_WEBHOOK }}
        run: |
          curl -X POST "$DEPLOYER_NOTIFICATION_WEBHOOK" \
            -H "Content-Type: application/json" \
            -d '{
              "event": "instructions_for_use_updated",
              "system_version": "${{ github.event.release.tag_name }}",
              "release_notes_url": "${{ github.event.release.html_url }}",
              "instructions_for_use_url": "https://docs.yoursystem.eu/instructions-for-use",
              "art13_compliance_note": "This notification is provided pursuant to EU AI Act Art.13 and Art.16(i). Updated instructions for use are available at the URL above.",
              "change_summary": "${{ github.event.release.body }}"
            }'
      
      - name: Log notification to Art.12 audit trail
        if: steps.check_ifu_changes.outputs.changed != '0'
        run: |
          # Record in Art.12 operational log that deployer notification was sent
          echo "{\"event\": \"art13_deployer_notification\", \"version\": \"${{ github.event.release.tag_name }}\", \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"}" >> audit-log/art13-notifications.jsonl

Art.16(j) + Art.72: Post-Market Monitoring as a Legal Requirement

What Art.72 Requires

Article 72 establishes the post-market monitoring obligation for providers of high-risk AI systems placed on the EU market. The obligation has three components:

Component 1 — A post-market monitoring plan. The plan must be documented as part of the Annex IV technical documentation (Section 8). It must specify: the monitoring indicators, the data collection mechanisms, the alert thresholds that trigger action, the feedback loop back to the Art.9 risk management system, and the connection to the Art.73 serious incident reporting pipeline.

Component 2 — Active data collection. The provider must actively collect and review relevant data about the performance of the system after deployment. The standard is not passive: "actively" means your monitoring infrastructure must be designed to surface problems, not just record them.

Component 3 — The feedback loop. Art.72(3) specifies that post-market monitoring must feed back into the risk management system under Art.9. This is the continuous compliance loop: monitoring detects a performance issue → Art.9 risk management is updated → Annex IV documentation is revised → if non-conformity is identified, Art.20 corrective actions are triggered.

The Minimum Viable Monitoring Stack

For a cloud-native high-risk AI system, a compliant Art.72 monitoring implementation requires at minimum:

Model performance tracking. Track accuracy, precision, recall, and F1 against your documented performance benchmarks from Section 6 of the Annex IV. Any degradation beyond the thresholds documented in your Art.9 risk management plan triggers the Art.20 assessment workflow.

Fairness and bias monitoring. For systems in Annex III domains where algorithmic discrimination is a documented risk — employment, education, essential services — track performance disaggregated by protected characteristics. The EU AI Act does not specify a statistical fairness metric, but your Art.9 risk management plan should document which metrics apply to your use case.

Human oversight event logging. Art.14 requires that designated operators can understand, override, and interrupt the system. Your monitoring must track how often human oversight functions are invoked, whether overrides correlate with higher accuracy, and whether the oversight mechanism is accessible to the deployers who need it.

Distribution shift detection. The most common cause of accuracy degradation for production ML systems is drift between training data distribution and production data distribution. Implement input distribution monitoring using Population Stability Index or similar statistics, and set alert thresholds that trigger an Art.9 risk review when significant drift is detected.

# art72_monitoring_loop.py
# Core post-market monitoring implementation for Art.72 compliance

import json
import time
from datetime import datetime, timezone
from pathlib import Path

class Art72Monitor:
    def __init__(self, system_id: str, annex_iv_thresholds: dict):
        self.system_id = system_id
        self.thresholds = annex_iv_thresholds  # From Section 6 of Annex IV
        self.art20_assessor = CorrectiveActionTrigger()  # See Art.20 section above
        self.log_path = Path("monitoring-records") / system_id
        self.log_path.mkdir(parents=True, exist_ok=True)
    
    def run_monitoring_cycle(self, metrics: dict) -> dict:
        """
        Execute one Art.72 monitoring cycle.
        Returns monitoring record including any triggered Art.20 assessments.
        """
        record = {
            "system_id": self.system_id,
            "timestamp": datetime.now(timezone.utc).isoformat(),
            "metrics": metrics,
            "threshold_checks": [],
            "art20_triggers": [],
            "art9_update_required": False
        }
        
        # Check each metric against Annex IV documented thresholds
        for metric_key, threshold in self.thresholds.items():
            if metric_key in metrics:
                current_value = metrics[metric_key]
                breach = self._check_threshold_breach(metric_key, current_value, threshold)
                record["threshold_checks"].append({
                    "metric": metric_key,
                    "current": current_value,
                    "threshold": threshold,
                    "status": "BREACH" if breach else "OK"
                })
                
                if breach:
                    # Trigger Art.20 corrective action assessment
                    signal = NonConformitySignal(
                        signal_type=NonConformityType.ACCURACY_DEGRADATION,
                        description=f"Metric {metric_key} breached Annex IV threshold",
                        metric_key=metric_key,
                        metric_value=current_value,
                        threshold=threshold,
                        source="monitoring",
                        timestamp=record["timestamp"]
                    )
                    assessment = self.art20_assessor.assess(signal)
                    record["art20_triggers"].append(assessment.__dict__)
                    record["art9_update_required"] = True
        
        # Write to Art.12 compliant audit log
        log_file = self.log_path / f"{datetime.now(timezone.utc).strftime('%Y-%m')}.jsonl"
        with open(log_file, "a") as f:
            f.write(json.dumps(record) + "\n")
        
        return record
    
    def _check_threshold_breach(
        self, 
        metric_key: str, 
        current_value: float, 
        threshold: dict
    ) -> bool:
        """Check if metric breaches its documented Annex IV threshold."""
        threshold_type = threshold.get("type", "minimum")
        threshold_value = threshold.get("value")
        
        if threshold_type == "minimum":
            return current_value < threshold_value
        elif threshold_type == "maximum":
            return current_value > threshold_value
        elif threshold_type == "range":
            return not (threshold["low"] <= current_value <= threshold["high"])
        
        return False


# Configuration — values come from your Annex IV Section 6 documentation
ANNEX_IV_THRESHOLDS = {
    "accuracy": {"type": "minimum", "value": 0.92},      # 92% minimum accuracy
    "recall_protected_class_a": {"type": "minimum", "value": 0.90},
    "recall_protected_class_b": {"type": "minimum", "value": 0.90},
    "false_positive_rate": {"type": "maximum", "value": 0.08},
    "population_stability_index": {"type": "maximum", "value": 0.20},  # >0.20 = significant drift
}

monitor = Art72Monitor("high-risk-hr-screening-v2", ANNEX_IV_THRESHOLDS)

Art.72 Monitoring Periods and Data Retention

Art.72 does not specify minimum monitoring periods, but Art.12 operational log retention requirements and Art.20 corrective action documentation requirements together imply that monitoring records must be retained for at least as long as the system is deployed and for a reasonable period after withdrawal. Best practice for systems in employment and healthcare domains — where discrimination claims can surface years after deployment — is a minimum 5-year retention policy for monitoring records.

The EU AI Office is expected to publish sector-specific technical guidance on Art.72 monitoring requirements before the August 2026 deadline. Monitor the EU AI Office's guidelines pages for updates.

The Post-Placement Compliance Loop: Integrating Art.20, Art.21, Art.72, and Art.73

The four post-placement obligations do not operate independently. They form a legal compliance loop:

Art.72 Post-Market Monitoring
         │
         │ detects performance issue or distribution shift
         ▼
Art.20 Corrective Action Assessment
         │
         │ is there risk to health/safety/fundamental rights?
         ├─── YES ──► Art.73 Serious Incident Report to NCA (within 2 days)
         │            + Art.21 Cooperation Package prepared
         │            + Deployers notified
         │
         ├─── NO + non-conformity confirmed ──► Corrective action taken
         │                                     + Deployers notified
         │                                     + Art.12 log updated
         │
         └─── NO + no non-conformity ──► Monitoring record filed
                                         Art.12 log updated
                                         Return to Art.72 monitoring
         
Art.21 NCA Cooperation
         │
         │ triggered by NCA request or as part of Art.73 notification
         ▼
Regulatory Access Package assembled and provided
Continued monitoring resumes
Art.9 Risk Management System updated with findings
Return to Art.72 monitoring

Every iteration of this loop is a documented event that belongs in your Art.12 audit trail. The loop runs continuously for the operational lifetime of the system.

Art.16 Post-Placement Compliance Checklist

Use this checklist to verify your post-placement obligations are operational before the August 2, 2026 deadline:

Art.20 Corrective Actions

Triggering thresholds defined in Art.9 risk management plan and documented in Annex IV Section 8
Corrective action assessment workflow implemented and tested
Risk-to-health/safety assessment logic documented
Deployer notification mechanism built and tested
NCA notification template prepared for each EU member state of deployment
Corrective action records retained in Art.12 compliant log

Art.21 NCA Cooperation

Regulatory access package assembled and versioned
Package includes: Annex IV, QMS, operational logs, conformity assessment, incident records
Log export script tested (can generate clean export within 24h)
Named regulatory contact designated and documented
Package can be provided to NCA within 48 hours of request

Art.13 User Information (Continuous)

Instructions for use versioned alongside system releases
Automated deployer notification on instructions-for-use update
Art.12 log records each deployer notification event
Update triggers documented: new version, accuracy change, corrective action, NCA guidance

Art.72 Post-Market Monitoring

Monitoring indicators defined in Annex IV Section 8
Monitoring infrastructure deployed and generating records
Alert thresholds configured and match Annex IV documentation
Monitoring records feed into Art.9 risk management system (feedback loop documented)
Data retention policy set (minimum: duration of deployment + 5 years recommended)
Monitoring reports generated on defined schedule

Infrastructure Note: Why Post-Placement Monitoring Benefits from EU-Native Hosting

Post-market monitoring for an Art.16 compliant high-risk AI system generates substantial operational data: model performance metrics, input distribution statistics, override event logs, and corrective action records. This data has two regulatory properties:

First, it falls within the Art.12 record-keeping obligation — it is regulated data that must be preserved and accessible to NCAs.

Second, it can itself contain personal data. Monitoring a hiring AI system means monitoring decisions about identified individuals. Under GDPR, that data must be stored in EU jurisdiction. Under the EU AI Act's relationship with GDPR (recital 9), providers must ensure their monitoring infrastructure does not create GDPR exposure through cross-border transfer.

A provider running post-market monitoring on EU-native infrastructure (Hetzner Germany, OVHcloud, Scaleway) satisfies both requirements natively. The same monitoring pipeline on AWS or GCP — even in an EU region — retains US CLOUD Act exposure for the monitoring records, which are precisely the records NCAs will request under Art.21.

sota.io's managed PaaS runs entirely on Hetzner Germany with no US-parent data exposure, making it a natural foundation for Art.72 monitoring infrastructure that satisfies both the EU AI Act record-keeping requirements and GDPR jurisdiction constraints.

What's Next in This Series

This is Post 2 of 5 in the EU AI Act Art.16 Provider Obligations series:

Post 1: Art.16 Complete Developer Compliance Guide — all 11 Art.16 obligations mapped
Post 2 (this post): Post-placement obligations — Art.20, Art.21, Art.13, Art.72
Post 3 (next): Art.16(e)+(f)+(g) — Conformity Assessment, EU Declaration of Conformity, and CE Marking workflow
Post 4: Art.16 obligations for SaaS providers: multi-tenant architectures, role boundaries, and the deployer notification chain
Post 5 (finale): Complete Art.16 Provider Compliance Checklist and 53-day implementation roadmap

The August 2, 2026 deadline for all high-risk AI obligations is 53 days away. For most organisations, post-placement monitoring infrastructure takes the longest to build because it requires integrating across model serving, data pipelines, alerting, and documentation systems. If you are just starting, start here.

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 waitlist View pricing