Article 11 gets the headlines because technical documentation is tangible: pages, diagrams, sign-offs. Article 72 — post-market monitoring — is quieter but equally binding for many high-risk deployments: it is where compliance meets production reality. Regulators are not only asking what you documented before go-live; they want evidence that you watched the system behave and reacted when the world changed.

What Article 72 Requires (Conceptually)

For high-risk AI systems, the Act expects a systematic process to collect and analyse performance data after the system is placed on the market or put into service. The goal is to verify continuous conformity, detect emerging risks, and feed improvements back into governance.

In practice, that implies:

  • Defined monitoring responsibilities — Who owns monitoring, who reviews signals, and who can stop or constrain a system?
  • Operational data — Inputs, outputs, and context sufficient to detect drift, misuse, and unexpected failure modes — within the limits of privacy law and your retention policy.
  • Feedback loops — When monitoring finds an issue, there is a path to incident handling, documentation updates, and — where needed — regulatory notification.

The exact division between provider and deployer still matters (see provider vs deployer); deployers often hold the richest operational picture even when the provider maintains the core model.

From Legal Text to Runbooks

Translate Article 72 into artefacts your organisation can defend:

  1. Monitoring plan — Scope (which systems), metrics (quality, bias proxies where applicable, latency, error rates), sampling, and review cadence.
  2. Change detection — Triggers for “material change” that require re-classification or documentation refresh — new data sources, new geographies, new decision thresholds.
  3. Incident pathway — Severity levels, internal escalation, and alignment with serious-incident reporting rules where they apply.
  4. Evidence store — Immutable or versioned logs, linked to the system’s Annex IV record and documentation version history.

If you cannot produce these under stress, you do not yet have post-market monitoring — you have a dashboard.

Common Mid-Market Gaps

  • SaaS black boxes — Vendors expose APIs but not enough telemetry; deployers must negotiate logging exports or proxy metrics.
  • Shadow AI — Teams adopt tools outside IT; monitoring plans never cover them. Start from a full inventory before tuning metrics.
  • Documentation rot — Monitoring finds a drift event, but nobody updates Annex IV. Tie monitoring tickets to documentation change control.

How Aikraft Fits

Aikraft’s monitoring module is designed around this operational layer: connect signals from your stack where possible, centralise incidents, and surface regulatory updates that force a re-review of classified systems. It does not replace legal interpretation — it gives compliance and engineering a shared system of record for what happened after go-live.

Next Steps

  • Classify systems that are already in production, not only net-new projects.
  • Align monitoring metrics to the decisions your organisation actually automates or recommends.
  • Re-read your provider contracts for data-sharing and incident cooperation — you will need both for a credible Article 72 story.

For a dated view of enforcement timing, see our August 2026 deadline guide. When you are ready to implement, start with Setting up compliance monitoring.

Back to Blog