ISO/IEC 42001 FAQ Post Market Monitoring

For AIMS operational monitoring, define each question, measure, method, data source, population, system version, period, owner, review cadence, and threshold before collecting results. Monitor AIMS performance and control effectiveness as well as relevant system behaviour and impacts. Route each threshold to a named action such as risk or impact reassessment, incident handling, supplier escalation, correction, restricted use, rollback, or retirement.

Choose measures that fit the task and consequence. Examples include false-positive and false-negative rates for classification, unresolved-task rates for an assistant, unsafe tool executions for an agent, performance across relevant groups, complaint trends, override timeliness, data or concept drift, and supplier-service changes. A single global accuracy score can hide the error type, population, or operating condition that matters.

If the organisation is an EU AI Act provider of a high-risk AI system, Article 72 separately requires a documented post-market monitoring system proportionate to the technology and risks. It must actively and systematically collect, document, and analyse relevant performance data throughout the system's lifetime and support evaluation of continuing compliance. The plan belongs in the technical documentation and can use relevant deployer data or other sources. Existing sector systems can incorporate the required elements in the cases and conditions stated in Article 72(4).

Article 73 reporting for a serious incident is a separate process. Providers report to the market-surveillance authority where the incident occurred immediately after establishing a causal link or reasonable likelihood and no later than 15 days after awareness. The outside limit is two days for a widespread infringement or serious irreversible critical-infrastructure disruption and 10 days after awareness when a death is involved and causation is established or suspected. An incomplete initial report may be followed by a complete report when needed for timeliness.

AIMS evidence should show the full route from measure to action. Keep monitoring objectives, operational definitions, methods, data-quality and representativeness checks, evaluation periods, baselines and thresholds, dashboards, review records, complaints, adverse-impact reports, incidents, event logs, overrides, supplier notices, threshold breaches, risk and impact reassessments, decisions, corrections, and effectiveness checks.

Preserve enough context to show which system and component versions, intended use, population, environment, data window, metric calculation, limitations, and period each conclusion covers. Record missing data and blind spots explicitly; an empty incident log does not prove that no incidents occurred if users lacked a reporting route.

For an EU Article 72 record, keep the provider role analysis, high-risk classification, lifetime plan, data sources, deployer information route, interaction with other AI systems where relevant, analysis method, continuous-compliance conclusion, technical-documentation version, corrective or preventive decisions, and any integration with an existing sector plan.

Assign system and control owners for collection and first response, a competent evaluator for analysis, risk owners for treatment decisions, and management-review, incident, supplier, and corrective-action authorities for escalation. State who can restrict or stop the system.

For supplier systems, allocate who receives provider notices, who supplies operating data or complaints, who investigates shared failures, and who can require correction or suspend the service. Determine the separate EU AI Act operator role before assigning statutory post-market monitoring or reporting duties.

Under the EU AI Act, the high-risk system provider owns the Article 72 system and plan. Deployers monitor use according to the instructions and, where relevant, inform the provider; Article 26 also requires prompt notification and, when use in accordance with the instructions may present a risk within the meaning of Article 79(1), suspension. Contractual reporting routes should support those duties without being treated as a substitute for them.

Review monitoring design at planned intervals and when objectives, intended purpose, system or model version, deployment context, affected population, production data, suppliers, connected systems, impacts, thresholds, incidents, or applicable duties change. Also review a measure when it no longer detects the risk or outcome it was chosen to represent.

When a threshold is crossed, preserve the result, analysis, decision, action, and effectiveness check. Route the finding to risk or impact reassessment, incident handling, management review, supplier action, rollback, or corrective action as appropriate. Do not reset the baseline until the reason and approval are documented.

For high-risk systems under the EU AI Act, align the legal process with the applicable Article 6 route and the legal text then in force. The published AI Act sets 2 August 2026 for Annex III obligations, including Articles 72 and 73, and 2 August 2027 for corresponding Article 6(1) product-route obligations. The Council gave final approval to the Digital Omnibus on AI on 29 June 2026; the adopted amendment moves those dates to 2 December 2027 and 2 August 2028 respectively, but it must still be published in the Official Journal and enter into force. Article 111 contains separate transition rules for systems already placed on the market or put into service. Existing sector reporting duties and ISO controls may apply earlier and remain separate.