Search every question across sub-FAQs

Repeat ISO risk assessments at planned intervals and when significant changes are proposed or occur; repeat impact assessments at planned intervals or when significant changes are proposed. Revisit legal classification when intended purpose, functionality, integration, operator role, branding, market, affected population, decision influence, profiling, Annex coverage, product law, guidance, or application date changes.

A name or trademark change, substantial modification, or changed intended purpose can make a distributor, importer, deployer, or other party the provider of a high-risk system under Article 25. Review before the change is released, not only after an incident.

Keep the AIMS reassessment date and the legal-classification review date separately visible because the triggers, approvers, evidence tests, and consequences differ. If either analysis changes, update controls, technical documentation, instructions, registration, conformity-assessment planning, monitoring, and customer or supplier allocations as applicable.

Use the risk and impact assessments to decide whether oversight is needed, at which lifecycle stages, and for which decisions. A low-consequence drafting tool may use sampling and user correction, while an AI recommendation affecting employment, credit, safety, or access to services may need review before action, defined challenge criteria, and authority to stop use. These are examples; the documented impact, risk, instructions, and applicable law control the design.

Define the decision boundary in operational terms: which outputs or signals the person sees, what information and explanation are available, what the reviewer must verify, the time allowed, required competence, workload limits, override or stop authority, escalation route, backup coverage, and what happens to the output and affected person after intervention. State which decisions remain automated and which belong to another role.

Test the arrangement in realistic conditions. A recorded approval does not show effective oversight if the reviewer lacks time, relevant information, training, system access, independence, or authority, or if the interface encourages automation bias and makes challenge impractical. Test normal cases, ambiguous cases, known failure modes, out-of-range inputs, unavailable reviewers, and safe-stop or fallback paths.

Where the EU AI Act applies, Article 14 requires high-risk systems to be designed for effective oversight and enables assigned persons, as appropriate, to understand limitations, detect anomalies, interpret outputs, disregard or override them, and intervene or stop the system. Article 26 requires deployers to assign oversight to natural persons with necessary competence, training, authority, and support. For specified remote biometric identification, Article 14(5) generally requires separate verification by at least two qualified persons, subject to its law-enforcement, migration, border-control, and asylum exception.

Evidence should show why oversight was selected and whether it works. Keep the risk and impact rationale, role and decision-boundary definitions, current instructions and known limitations, competence criteria and records, interface and procedure tests, staffing and workload assumptions, sampled decisions, challenge and agreement rates where meaningful, overrides, reversals, stops, escalations, response times, monitoring results, complaints, incidents, and corrective actions.

For each sample, preserve the system and version, input or case reference where lawful, output or signal reviewed, information available to the reviewer, action, reason, timing, escalation, final outcome, and follow-up. Protect personal and confidential information and apply the relevant retention rule; oversight is not a reason to keep every prompt or decision indefinitely.

A system or process owner should maintain the oversight design, interfaces, staffing, and resources. Named reviewers perform the control and need documented competence and authority. Designated management approves the treatment plan and residual AI risk; a reviewer should not be made the residual-risk owner merely because that person performs the control.

Product, safety, privacy, security, employment, legal, accessibility, or operational owners should approve requirements within their authority. For supplier systems, allocate who provides instructions and limitations, who configures oversight features, who trains reviewers, who receives performance or incident reports, and who can require correction or suspend use.

Where EU high-risk duties apply, the provider designs and documents the oversight measures and the deployer assigns suitable natural persons and organises their support. Contract wording may allocate work and information, but it cannot remove either party's statutory duties.

Review oversight at planned intervals and when intended purpose, users, affected population, automation level, interface, system instructions, performance, impacts, incidents, workload, staffing, supplier, connected tools, or applicable duties change. Reassess before a recommendation becomes an automated action or a low-consequence use begins affecting people materially.

Use decision samples, overrides, missed escalations, complaints, incidents, reviewer feedback, workload, latency, and monitoring results to decide whether the control remains effective. A falling override rate can show better system performance or growing over-reliance; investigate the cause before treating the metric as improvement.

For EU high-risk systems, align review 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 and 2 August 2027 for 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. Other laws, provider instructions, or organisational controls can require oversight earlier.

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.

Build the AIMS responsibility map from the actual lifecycle. Record who specifies, develops, supplies, integrates, configures, validates, deploys, operates, monitors, supports, changes, and retires the AI system; who provides data, models, tools, and infrastructure; who gives users instructions; and who acts on limitations, complaints, incidents, or corrections. Include shared and externally performed work instead of treating outsourced activity as outside the AIMS.

Run the EU AI Act role test separately for each system and transaction. A provider develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts the system into service under its own name or trademark. A deployer uses an AI system under its authority in a professional activity, excluding personal non-professional use. Importers, distributors, product manufacturers, authorised representatives, and affected persons are separate categories. These definitions do not map automatically to AIMS job titles or contract labels.

Confirm territorial scope before assigning EU duties. Article 2 covers providers placing systems or general-purpose AI models on the Union market, deployers established or located in the Union, and third-country providers and deployers where system output is used in the Union, plus specified supply-chain actors. Conditional exclusions include military, defence and national-security uses, sole-purpose scientific research and development, pre-market research and testing other than real-world testing, purely personal non-professional use, and some free and open-source releases.

Recheck Article 25 before rebranding or changing a high-risk system. A distributor, importer, deployer, or other party becomes the provider for the high-risk system if it puts its name or trademark on it, makes a substantial modification while it remains high-risk, or changes the intended purpose of a non-high-risk system so it becomes high-risk. Product manufacturers also become providers in the specified Annex I safety-component circumstances.

Keep a system inventory and responsibility matrix tied to the actual lifecycle, plus supplier and customer agreements, intended-purpose and branding records, system instructions and limitations, technical-documentation access, data and model dependencies, change notices, acceptance records, monitoring ownership, incident routes, correction rights, retention, exit arrangements, and unresolved gaps.

For each EU role conclusion, retain the system and version, actor and legal entity, activity, market and location facts, name or trademark, intended purpose, who developed or commissioned development, who controls use, relevant Article 2 scope or exclusion, Article 3 definition, Article 25 analysis, effective date, approver, and reassessment trigger.

For high-risk systems, written agreements with component or service suppliers should specify the information, capabilities, technical access, and assistance needed for the provider to comply, subject to the Article 25(4) scope and open-source exception. The agreement supports compliance but does not change who meets the statutory definition.

Assign internal accountability to a process or system owner who can operate and correct the relationship. Legal owners determine statutory roles, procurement manages supplier commitments, technical and operational owners verify integration and monitoring, and governance resolves unallocated or conflicting responsibilities.

A contract can allocate work, information, access, assistance, and remedies, but it cannot rewrite a statutory definition. Record any gap between the contractual allocation, actual conduct, and legal role, then escalate it before deployment or material change.

For EU high-risk systems, the provider owns provider obligations, while the deployer must follow instructions, assign suitable human oversight, control relevant input data where applicable, monitor use, retain automatically generated logs under its control for at least six months unless other applicable Union or national law provides otherwise, make specified notifications, and cooperate with authorities. The exact duties depend on the role, system, use, and applicable exceptions.

Review allocation when the system, model, service terms, supplier, customer use, branding, integration, intended purpose, territory, contract, technical access, monitoring access, or incident route changes. Review before a white-label release, material integration, new market, new intended use, or modification goes live.

Record the effective date and evidence for each allocation, then update agreements, instructions, access to records, monitoring, change notification, incident communication, and escalation routes together when facts change.

Align statutory readiness with the applicable AI Act date and the legal text then in force. The published AI Act sets 2 August 2026 for Annex III provider and deployer obligations 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. Chapter V obligations began applying on 2 August 2025, while Article 111 gives providers of general-purpose AI models placed on the market before that date until 2 August 2027 to comply. Article 111 also has separate transition rules for existing high-risk systems. ISO/IEC 42001 and other laws or contracts can require responsibility allocation earlier.

Follow the Clause 6.1.3 sequence for each assessed risk: select a treatment option; determine every necessary control; compare that set with Annex A to check for omissions; consider relevant Annex A controls and Annex B implementation guidance; add different or additional controls where needed; produce the statement of applicability; formulate the treatment plan; and obtain designated-management approval of the plan and residual AI risk.

Annex A is normative as a reference control set within ISO/IEC 42001, but not every listed control applies to every organisation or system. Annex B is normative implementation guidance, although the organisation does not have to document or justify the inclusion or exclusion of that guidance in the statement of applicability. The risk assessment, chosen treatment, objectives, and applicable external requirements determine the actual control set; a team may need controls beyond Annex A.

Use system-specific examples to test the reasoning. A supplied AI service can require supplier documentation, intended-use instructions, logging, monitoring, and incident routes. A model trained internally can also require data acquisition, quality, provenance, preparation, verification, release, and change controls. An AI tool affecting people can require impact assessment, accessible user information, adverse-impact reporting, and meaningful human oversight. These examples are not a universal checklist.

The statement of applicability must contain the necessary controls and justify their inclusion and exclusion. An exclusion can be justified when a control is not necessary under the risk assessment or an applicable external requirement does not require it or provides an exception. The statement is not permission to omit a control that the selected treatment or an external requirement makes necessary.

Evidence should show design, implementation, operation, and effectiveness: the risk assessment, treatment decision, statement of applicability, control description, scope, owner, procedure or technical configuration, implementation record, sampled transactions or logs, monitoring method and result, exceptions, residual-risk approval, findings, corrective actions, and review date.

A reviewer should be able to trace from an AI objective and assessed risk to the selected control, its implementation, current operating samples, effectiveness result, exception handling, and residual-risk decision. A policy, screenshot, vendor claim, or control title by itself rarely shows the full chain.

Match the evidence to the control. Supplier controls can use due-diligence records, contract requirements, documentation received, change notices, service reviews, and correction requests. Data controls can use acquisition approvals, provenance, quality criteria and results, lineage, and preparation records. Human-oversight controls can use competence evidence, interface tests, sampled interventions, escalations, and workload measures.