FAQEU AI Act

EU AI Act How do you monitor AI after release?

High-risk AI providers must monitor their systems after release. Article 72 requires a documented monitoring system and plan to check continued compliance throughout the system's lifetime.

Collect performance data, relevant deployer feedback, complaints and incidents. Connect the findings to risk review, corrective action and reporting.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 21, 2026
Overview

A tracks how a high-risk AI system performs after release. The provider owns the Article 72 system and plan. Collect, document and analyse relevant lifetime performance data, including deployer data where relevant, to assess continued compliance and decide on corrective or preventive action.

Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

What monitoring does Article 72 require?

Providers must establish and document monitoring proportionate to the system's technology and risks. Actively and systematically collect, record and analyse relevant performance data throughout its lifetime.

Keep the post-market monitoring plan in the Annex IV technical documentation. The 2026 amendment replaces the earlier implementing-act mechanism with Commission guidance and a template, due by 2 September 2027. It was published on 24 July 2026 and entered into force on 27 July. Until the guidance is available, you can use your own or a vendor's form to organise evidence; identify it as that form.

For high-risk systems already covered by Section A of Annex I product legislation, Article 72 allows the provider to integrate equivalent AI Act elements into an existing sectoral post-market system and plan. The same integration option applies to Annex III point 5 systems placed on the market or put into service by financial institutions subject to Union financial-services governance rules.

  • Define the monitored high-risk AI system, intended purpose, deployed versions, integrations, and known interaction points with other AI systems.
  • Specify which performance, safety, fundamental-rights, robustness, cybersecurity, anomaly, complaint, and incident signals are collected after deployment.
  • Explain how deployer feedback and other external sources are triaged, documented, analysed, and fed into risk management and technical documentation updates.
  • Link monitoring outputs to Article 20 corrective action and Article 73 serious-incident reporting so risk signals do not stop at product support.
  • Keep the monitoring plan with the technical documentation and update the lifecycle change record when provider-made changes affect the system.

What should the monitoring process do?

Keep a documented monitoring system and plan. Collect and analyse relevant lifetime performance data and deployer feedback where relevant. Check continued compliance with Chapter III Section 2 and route risk signals to corrective action or serious-incident reporting when the legal triggers are met. The provider owns this Article 72 process.

When does Article 72 apply?

Article 72 remains on the AI Act's general application date of 2 August 2026. Regulation (EU) 2026/1744 separately moves Chapter III Sections 1 to 3 to 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I high-risk systems. Providers should record which provisions apply to the specific system and date instead of treating every high-risk obligation as having one start date.

Question 2

How should feedback, incidents and corrective action connect?

Deployers monitor use according to the provider's instructions and, where relevant, inform providers under Article 72. They supply important evidence even though the provider owns the plan.

If instructed use may create an Article 79(1) risk to health, safety or fundamental rights, the deployer must suspend use and inform the provider or distributor and relevant market surveillance authority without undue delay. For a , immediately inform the provider first, then the importer or distributor and relevant authorities. If the provider cannot be reached, apply Article 73 with the necessary role adjustments. The notification duty excludes sensitive operational data of law-enforcement deployers.

Give ordinary feedback, nonconformity, risks and serious incidents separate handling routes. Under Article 20, a provider that considers or has reason to consider a high-risk system nonconforming must immediately bring it into conformity, withdraw it, disable it or recall it, as appropriate.

  • Deployer feedback intake: capture the system, version, use context, instruction-for-use step, observed output, affected persons or groups, operator action, and available logs.
  • Risk escalation: if the deployer reports an Article 79(1)-type risk, record the suspension status, market-surveillance authority notice, and provider response owner.
  • Serious-incident escalation: link the record to Article 73 reporting analysis, causal-link assessment, authority routing, investigation, risk assessment, and corrective action.
  • Corrective action: document whether the provider brought the system into conformity, disabled it, withdrew it, recalled it, or informed distributors, deployers, authorised representatives, or importers.
  • Log handling: use Article 12 and Article 19 provider logs and Article 26 deployer-controlled logs to reconstruct the event, but check privacy, sector, and law-enforcement limits before requesting or transferring data.
Question 3

What records should the provider keep?

Keep the plan, signals collected, analysis, decisions and documentation updates together. A reviewer should be able to see why a signal did or did not lead to corrective action, a conformity update or an incident report.

Annex IV requires a description of relevant lifecycle changes and the performance-evaluation system, including the Article 72 plan. Keep the change history with the monitoring records.

  • Monitoring plan: scope, data sources, feedback channels, signal categories, review frequency, escalation routes and responsible people.
  • Signal records: complaints, anomalies, performance drift, bias or discrimination indicators, cybersecurity issues, human-oversight failures, misuse patterns, and interaction issues with other AI systems.
  • Log evidence: provider-controlled automatically generated logs, deployer-controlled logs when shared lawfully, retention basis, access controls, and integrity checks.
  • Decision records: root-cause analysis, continued-compliance assessment, serious-incident determination, corrective-action decision, and authority communication status.
  • Lifecycle records: versions, configuration changes, model or data changes, intended-purpose changes, integration changes, and any substantial-modification or new conformity-assessment trigger considered.
Question 4

When should you review the plan again?

Review the plan when the deployed system no longer matches its instructions, documentation or risk assumptions. Check changes to purpose, classification, performance, affected groups, oversight, logs, integrations and controls.

Review responsibility too. A distributor, importer, deployer or other party can become the provider by rebranding a high-risk system, substantially modifying one while it remains high-risk, or changing a non-high-risk system's purpose so it becomes high-risk. Record the applicable Article 25 trigger and any contractual allocation for rebranding.

  • New or changed intended purpose, user population, deployment context, country rollout, or affected group.
  • to a high-risk AI system after placement on the market or putting into service.
  • Integration with another AI system, model, data source, workflow, or product that changes performance or risk assumptions.
  • Observed performance drift, repeated anomalies, serious-incident indicators, or unresolved deployer feedback.
  • Changes to logs, human oversight, instructions for use, cybersecurity controls, or maintenance processes that affect traceability or safe operation.
Primary sources

References and citations

eur-lex.europa.eu5 citations
Referenced sections
  • Primary legal text for provider post-market monitoring under Article 72, deployer escalation under Article 26, logging under Articles 12 and 19, corrective action under Article 20, serious incidents under Article 73, and lifecycle documentation in Annex IV.
  • Primary legal text for Article 72 provider post-market monitoring systems, monitoring plans, and Annex IV technical-documentation links.
  • Primary legal text for Articles 12, 19, 20, 26, 72, and 73 on logs, deployer monitoring, corrective action, post-market monitoring, and serious incidents.
Show 2 more
  • Primary legal text for Annex IV technical documentation, including lifecycle changes and the Article 72 post-market performance-evaluation system.
  • Primary legal text for Article 25 value-chain responsibility changes, Article 43 substantial-modification conformity assessment, and Annex IV lifecycle-change documentation.
"Post-market monitoring by providers and post-market monitoring plan"
More quoted passages
"Providers shall establish and document a post-market monitoring system"
"facilitating the post-market monitoring referred to in Article 72"
"relevant changes made by the provider to the system"
"a new conformity assessment procedure"
ai-act-service-desk.ec.europa.eu2 citations
Referenced sections
  • Official AI Act Service Desk article page for provider corrective actions and duty of information after nonconformity.
  • Official AI Act Service Desk article page for provider corrective actions and duty of information.
"Corrective actions and duty of information"
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission policy page for official AI Act context and the risk-based regulatory framework.
  • Commission policy page for official EU AI Act context and the risk-based framework used by the page.
"The AI Act is the first-ever comprehensive legal framework on AI worldwide."
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission reporting-template page for serious incidents involving GPAI models with systemic risk; useful for keeping GPAI incident routing distinct from Article 73 high-risk AI system routing.
  • Commission page for serious-incident reporting resources for GPAI models with systemic risk; included to distinguish that GPAI reporting route from high-risk AI system Article 73 handling.
"serious incidents involving general-purpose AI models"
eur-lex.europa.eu
Referenced sections
  • Binding amendment published on 24 July 2026, entering into force on 27 July 2026, which replaces Article 72(3)'s implementing-act mechanism with Commission guidance, including a post-market monitoring plan template, due by 2 September 2027.
"including a template"
Show all related guides (34)

When must you disclose AI use? | EU AI Act

Check AI interaction notices, technical content marking, biometric notices, deepfake and text disclosures, exceptions, accessibility and deadlines.

When must you report a serious incident? | EU AI Act

Check serious-incident outcomes, reporting roles, 15-, 10- and two-day deadlines, authority recipients, corrective action and the separate model route.

Who needs a rights impact assessment? | EU AI Act

Check who needs an Article 27 fundamental rights impact assessment, what it must cover, and how privacy assessments, notification and registration fit.

Common questions, clear answers | EU AI Act

Clear answers on AI Act scope, risk categories, provider and user duties, general-purpose models, disclosures, rights, assessments and deadlines.

EU AI Act deadlines and compliance calendar

Find the AI Act deadline for your system or model. Check high-risk dates, transparency duties, older-model transitions and the evidence to prepare.

EU AI Act fundamental rights impact assessments

Check who needs an Article 27 fundamental rights impact assessment, what it must contain and how DPIA reuse, notification and registration work.

EU AI Act GPAI model evidence checklist

Collect model documentation, integration information, copyright records and training summaries. Add testing, incident and security records for systemic risk.

EU AI Act monitoring and serious incidents

Set up high-risk AI monitoring, identify serious incidents and check reporting deadlines, recipients, deployer escalation and corrective action.

EU AI Act penalties and fines

Check the AI Act fine tiers, smaller-organisation caps, GPAI provider fines and the facts authorities consider when deciding a penalty.

EU AI Act serious incident reporting steps

Check serious-incident harm, preserve evidence and choose the reporting deadline and recipient for high-risk AI systems and systemic-risk GPAI models.

EU AI Act timeline and phased deadlines

See which AI Act rules apply now and what comes next. Check high-risk dates, older-model transitions and the difference between legal and standards dates.

EU AI Act vs ISO/IEC 42001

Compare AI Act legal duties with ISO/IEC 42001 management-system requirements. See which records can be reused and what certification does and does not cover.

EU AI Act vs NIST AI RMF

Compare AI Act legal duties with the voluntary NIST AI RMF. Map risk records to specific requirements and identify legal steps that need separate evidence.

EU AI Act: Check whether the Act applies

Use five checks to establish AI Act scope, exclusions, your role, risk categories and evidence for the decision.

EU AI Act: Choose a high-risk assessment route

Choose between provider-run internal control, notified-body assessment and a product-law procedure before release.

EU AI Act: Classify a tool before approval

Classify an AI tool or model before purchase or release. Check EU scope, prohibited uses, high-risk rules, transparency and GPAI duties.

EU AI Act: Compliance checklist

Check each AI tool, decide which duties apply, and give every action an owner and evidence link.

EU AI Act: Conformity assessment

Some high-risk systems use a provider-run assessment. Others need an authorised independent assessor or a product-law assessment.

EU AI Act: Does it apply to you?

Check whether the AI Act applies to your system or model, identify your provider or deployer role, and keep evidence for the decision.

EU AI Act: Duties for general-purpose AI models

Check GPAI provider duties for documentation, integrator information, copyright and training summaries, plus extra requirements for systemic-risk models.

EU AI Act: High-risk requirements

High-risk providers must meet system requirements before supply. Deployers must use and monitor the system under the provider's instructions.

EU AI Act: High-risk system checklist

Check the system's risk controls, data, documentation, logs, instructions, human oversight and testing before release.

EU AI Act: Is your use case high-risk?

Find high-risk AI examples in recruitment, banking, education, healthcare, public services and products. Check Article 6 conditions and exceptions.

EU AI Act: Plan your compliance work

Build a compliance plan for each AI tool: your role, the duties that apply, the evidence needed and the person responsible.

EU AI Act: Standards and quality management

Use EN 18286:2026 to organise provider quality-management procedures and keep evidence that they work for each high-risk system.

EU AI Act: Technical file and evidence templates

Build the technical file and provider records for a high-risk AI system, with owners and evidence links for each field.

EU AI Act: When must you disclose AI?

Check Article 50 chatbot notices, synthetic-output marking, biometric notices, deepfake disclosures and public-interest text exceptions.

EU AI Act: Which AI uses are banned?

Check Article 5 prohibited AI practices, the narrow exceptions, evidence to retain and the new content prohibitions from 2 December 2026.