EU AI Act Post-Market Monitoring on Azure
How to operationalise EU AI Act post-market monitoring on Azure — logging, model drift detection, and serious-incident reporting duties for high-risk AI.
The EU AI Act's headline obligations — conformity assessment, technical documentation, the CE mark — happen before a high-risk system reaches the market. But the obligation that consumes the most engineering effort over a system's life starts the day after go-live: post-market monitoring. From 2 August 2026, providers of Annex III high-risk AI systems must run a documented monitoring system, keep lifetime logs, and report serious incidents on tight statutory deadlines.
This is an operations problem, not a paperwork problem. Below is how we at CC Conceptualise build post-market monitoring for high-risk AI on Azure — what to log, how to detect drift, and how to wire the incident-reporting machinery so a 15-day clock never catches you flat-footed.
TL;DR / Key takeaways
- Post-market monitoring is mandatory and continuous for Annex III high-risk AI from 2 August 2026 — a documented system, not an annual review.
- Lifetime logging is a legal requirement: events must be recorded automatically and retained (generally at least six months) to support traceability and incident investigation.
- Serious incidents must be reported to the market surveillance authority without undue delay — within 15 days at the outside, 10 days for a death, and 2 days for widespread infringements or critical-infrastructure disruption.
- Model drift is your silent compliance killer: it erodes the accuracy and robustness you certified, so detecting and acting on it is effectively obligatory.
- Azure gives you the building blocks — Azure Monitor, Azure ML model monitoring, AI Foundry evaluations, Purview — but none are compliant by default; configuration to the Act is the work.
What the Act actually demands after go-live
Three obligations dominate the post-market phase. They interlock, and treating them in isolation is the most common mistake we see.
| Obligation | What it requires | Primary Azure building block |
|---|---|---|
| Post-market monitoring (Art. 72) | A documented, proactive system that collects and analyses performance data across the lifetime, checks continued conformity, and feeds the risk management process | Azure ML model monitoring, AI Foundry evaluations, Azure Monitor |
| Automatic logging (Art. 12, 19) | Events recorded automatically over the lifetime to a degree appropriate to purpose; logs kept under provider control, generally ≥6 months | Azure Monitor, Log Analytics, immutable storage |
| Serious incident reporting (Art. 73) | Report to the market surveillance authority on a causal link; staged deadlines down to 2 days | Incident workflow built on Azure Monitor alerts + a tracked response process |
The connective tissue is your risk management system and technical documentation. Monitoring output is not an end in itself — it must flow back into the risk file, and material changes can trigger a fresh conformity assessment. If you are still scoping which of your systems are in this regime, start with our Annex III high-risk classification guide before building any of this.
Logging: the foundation everything else stands on
Article 12 requires high-risk systems to log events automatically across their lifetime. The Act is deliberately purpose-relative — it does not hand you a schema — so you must derive what to log from your system's risks and intended use. In practice, a defensible high-risk log captures:
- The reference period of each use and the input data (or a privacy-preserving reference to it).
- The system version and model version behind every decision, so you can reconstruct exactly what produced an output.
- The output, confidence, and any human override — who intervened, when, and what they changed.
- Operational events — failures, fallbacks, content-safety triggers, threshold breaches.
How we build this on Azure
Route application and inference telemetry through Azure Monitor into a dedicated Log Analytics workspace, with diagnostic settings exporting to immutable (WORM) blob storage for the retention period. Two things matter for compliance that teams routinely miss:
- Tamper-evidence. Logs that prove conformity must themselves be trustworthy. Use immutability policies and tight RBAC so the people operating the model cannot quietly rewrite its history.
- Retention. The Act expects an appropriate period, generally at least six months unless sectoral law (or your own incident-investigation needs) demands longer. Set this explicitly; do not inherit a default 30-day workspace retention and assume you are covered.
One pattern we deploy repeatedly: a correlation ID minted at the API gateway and threaded through every log, so a single serious-incident investigation can stitch inference, oversight, and infrastructure events into one timeline in minutes rather than days.
Drift: the risk the Act never names but always means
"Drift" appears nowhere in the AI Act. Yet the accuracy, robustness, and continued-conformity requirements make drift detection effectively mandatory. A high-risk credit or triage model that was conformant at placement can silently degrade as the world moves underneath it — and the moment its real-world accuracy falls below the threshold in your technical documentation, you are non-conformant, monitoring or not.
There are three kinds worth instrumenting:
- Data drift — the input distribution shifts away from your training/reference data.
- Prediction (concept) drift — the relationship between inputs and the correct output changes.
- Data-quality drift — nulls, schema changes, or upstream pipeline faults corrupt inputs.
Drift monitoring on Azure ML
Azure Machine Learning model monitoring computes drift, data-quality, and prediction-drift signals against a baseline you define from your production reference dataset. The collection layer (model data collector) captures inputs and outputs at inference; scheduled monitors compute metrics and raise alerts.
| Signal | What it catches | Recommended action threshold |
|---|---|---|
| Data drift | Input distribution shift | Alert at a tuned statistical threshold; investigate before it reaches the accuracy floor |
| Prediction drift | Output distribution / concept shift | Alert and trigger a labelled-data accuracy check |
| Data quality | Nulls, out-of-range, schema breaks | Hard alert; consider auto-fallback to a safe default |
| Ground-truth accuracy | True performance vs. documented threshold | The compliance line — breach means potential non-conformity |
The compliance discipline most teams miss: tie your drift thresholds to the metrics in your technical documentation, not to convenient defaults. If your conformity case claims 92% precision, your monitoring must alert before production precision approaches that floor — and the alert must reach a human with authority to act.
Wiring drift and logging into human oversight
Article 14 human oversight is not a checkbox; it is the actor your monitoring must empower. A drift alert that lands in an unread channel is a finding you can be held to but did not act on. We connect threshold breaches directly to an on-call rota with documented authority to pause, roll back, or override the system, and — critically — we log those interventions back into the same trail. That closed loop is what turns telemetry into defensible governance. For the broader control set this sits inside, see our conformity assessment guide.
Serious incident reporting: know the clocks before you need them
Article 73 is where post-market monitoring meets the regulator. A serious incident is one that directly or indirectly leads to death or serious harm to health, serious and irreversible disruption of critical infrastructure, a breach of EU fundamental-rights obligations, or serious harm to property or the environment.
Once you establish a causal link (or a reasonably likely one) between your system and the incident, the reporting clock runs:
| Scenario | Deadline after establishing the link |
|---|---|
| General serious incident | Without undue delay, at most 15 days |
| Death of a person | At most 10 days |
| Widespread infringement or serious critical-infrastructure disruption | At most 2 days |
Two days is brutally short if the first time anyone discusses "who decides this is serious?" is during the incident. Decide in advance, in writing:
- Who triages an alert into a candidate incident.
- Who performs the causal-link assessment and on what evidence (this is where your correlation-ID logging earns its keep).
- Who is authorised to file with the relevant market surveillance authority, and the contact path.
- How the 2 / 10 / 15-day clocks are tracked so the right deadline applies to the right incident class.
We treat this as a runbook with a rehearsed tabletop, not a policy PDF. The penalties make the stakes concrete: high-risk non-compliance can reach EUR 15M or 3% of global turnover, and prohibited practices EUR 35M or 7%.
Making it auditable: ISO/IEC 42001
All of the above is more defensible inside a management system. ISO/IEC 42001, the AI management-system standard, provides the governance scaffolding — roles, monitoring processes, incident handling, continual improvement — that maps cleanly onto the Act's post-market and risk-management duties. It does not replace the legal obligations, but it makes them repeatable and audit-ready, and it gives your CISO a recognisable structure rather than a bespoke spreadsheet.
A 6-step rollout sequence
For teams standing this up now ahead of the August 2026 deadline, this is the order we recommend:
- Derive monitoring signals from the risk file — turn documented thresholds into measurable metrics and alerts.
- Enable lifetime logging — Azure Monitor + Log Analytics, immutable retention ≥6 months, correlation IDs end to end.
- Deploy drift and quality monitors — Azure ML model monitoring against a production baseline.
- Connect alerts to human oversight — empowered on-call, logged interventions.
- Stand up the incident path — triage, causal-link assessment, and the 2 / 10 / 15-day reporting runbook.
- Close the loop into risk management — fixed-cadence review, documentation updates, re-assessment triggers.
If August 2026 is on your horizon, our readiness checklist sequences the wider programme around this monitoring core.
FAQ
What does post-market monitoring require under the EU AI Act?
Providers of high-risk AI systems must run a documented, proactive monitoring system that collects and analyses performance data across the system's lifetime. It checks continued conformity, surfaces drift and emerging risks, and feeds findings back into the risk management process. These obligations apply from 2 August 2026 for Annex III high-risk systems.
What logging does the EU AI Act mandate for high-risk AI?
High-risk AI systems must automatically record events (logs) over their lifetime to a degree appropriate to their purpose. Logs must support traceability, post-market monitoring, and incident investigation. Providers must keep logs under their control for an appropriate period, generally at least six months unless other law requires longer.
When must I report an AI Act serious incident, and by when?
A serious incident is one causing death or serious harm to health, serious and irreversible disruption of critical infrastructure, breach of fundamental-rights obligations, or serious harm to property or the environment. Providers must report to the relevant market surveillance authority immediately after establishing a causal link, and no later than 15 days; tighter deadlines apply for deaths (10 days) and widespread infringements or critical-infrastructure cases (2 days).
How is model drift relevant to AI Act compliance?
Drift is not named in the Act, but undetected accuracy, data, or concept drift is a direct route to losing the conformity you certified at market placement. Post-market monitoring and the accuracy, robustness, and human-oversight requirements effectively oblige you to detect and react to drift before it produces harm or non-conformity.
Which Azure services support EU AI Act monitoring and logging?
Azure Monitor and Log Analytics handle event logging and retention; Azure Machine Learning model monitoring and data collection cover drift, data quality, and performance signals; Azure AI Foundry provides evaluation and content-safety telemetry. Microsoft Purview supports lineage and records management. None are compliant out of the box — they are building blocks you must configure to the Act's requirements.
Does ISO/IEC 42001 help with post-market monitoring?
Yes. ISO/IEC 42001, the AI management-system standard, gives you the governance scaffolding — roles, monitoring processes, continual improvement, and incident handling — that maps cleanly onto the Act's post-market monitoring and risk-management duties. It does not replace the legal obligations but makes them auditable and repeatable.
Post-market monitoring is where AI Act compliance stops being a document and becomes an operating discipline. If you are designing — or pressure-testing — the logging, drift, and incident architecture for a high-risk system on Azure, our AI & Data Platform engineering team can help you build it to the standard that survives an audit.
Topics