ISO 42001 Annex A.6.2.6: Operate and Monitor AI Systems After Deployment

What control A.6.2.6 requires in practice

Control A.6.2.6 asks the organisation to define and document what is needed to keep an AI system running after deployment. At a minimum the control names monitoring of the system and its performance, repairs, updates and support. Annex B, which is guidance, develops each. Monitoring covers general errors and failures, whether the system performs as expected on production data and whether commitments to customers and legal requirements continue to be met; where a system keeps learning, performance should be watched, and performance can also shift through drift in data even without learning, which may signal a need for retraining. Repair and update processes should cover affected components, schedules and information for users. Support should consider how users find help and report incidents. The guidance also raises misuse beyond design, and security threats specific to AI.

Monitor the result that matters in operation

Annex B.6.2.6 discusses performance on production data, changing conditions, repair and update processes, support and relevant security considerations. It notes that performance can change even without continuous learning. Organisations must consider the guidance under clause 6.1.3(e), with tailored implementation allowed by B.1.

Choose criteria appropriate to the task and interested-party needs. Availability and response time can matter, but they may not reveal whether outputs remain suitable for the decision. A system that responds quickly with misleading information is not adequately understood through uptime alone.

Why operating and monitoring AI matters

An AI system is not finished at release. The data it sees changes, users find new ways to use it and suppliers update the components beneath it, so quality can erode without any error message. Defined operation and monitoring give the organisation an early view of this decline, so it can repair or retrain before customers notice. They also set clear expectations for support and for communicating changes, which protects client relationships. Without them, responsibility for a degrading system is often unclear, and the first sign of trouble is a complaint. Documented operating arrangements are also what an auditor or buyer looks for to judge whether a system is managed rather than merely delivered.

How to implement control A.6.2.6

Choose measures that show whether outputs remain suitable, not only whether the service is running. Where a supplier runs the system, clarify what monitoring information you will receive, because your responsibility for outcomes does not disappear with the contract.

1. List the operating activities needed: monitoring, repair, updates and user support, with an owner for each.
2. Select performance measures that reflect the task and the needs of interested parties, besides availability and speed, and agree acceptable values.
3. Decide how production data will be reviewed for drift or changed use, and what level triggers action.
4. Define repair and update procedures, including how affected users are informed.
5. Set up support routes so users can find help and report incidents, and keep a record of what is raised.
6. Watch for use outside the intended purpose, and decide how such use is assessed.
7. Identify security threats particular to your AI approach, and include them in routine review.

Illustrative IT example: vocabulary changes while the model does not

Illustrative manufacturing example: support ownership is unclear

A manufacturer uses an AI inspection aid whose uncertain outputs increase on one production line. Operations contacts IT, IT contacts the equipment supplier and the supplier says the issue concerns local image conditions. Meanwhile, staff improvise a workaround.

Documented support arrangements should explain how issues are investigated across the relevant parties and who can decide operating conditions. The organisation examines the evidence and responsibilities instead of allowing the case to circulate indefinitely. A service contact number alone is not a complete support process.

Connect monitoring with repair and update decisions

Define how errors and failures receive attention, how relevant components are updated and how affected users learn what changed. Changes in function or intended use need appropriate assessment, not merely a technical release note.

Where continuous learning occurs, examine how ongoing changes are monitored against design goals and intended operation. Where it does not occur, data or context can still shift. The organisation should understand which situation applies rather than use “AI learns over time” as a vague explanation for every difference.

Make metrics and evaluation methods suitable

The guidance discusses choosing metrics according to the task, understanding their relationships and using relevant domain knowledge. It does not impose one F1 score, accuracy percentage or error threshold on every system. Consider the significance of different errors and the conditions represented by the evidence.

Evaluation methods should reflect operation closely enough to support useful conclusions. Comparing with relevant non-AI practice may provide context, but should not become an excuse for an unsupported claim. A small test set or a supplier average needs appropriate limits.

Control changed and unintended use

Monitoring may reveal that people use the system for purposes not anticipated in its design. Examine the appropriateness of that use through the relevant processes. A work-around can change the consequence of an output even when the software configuration remains stable.

Connect operation with intended use, risk reassessment and event logs. These links help evidence reach the people able to respond.

Evidence and common failures