Change management for AI systems: ISO 42001 clauses 6.3 and 8.1

A classic change process assumes code. Something gets modified, someone approves it, it goes to production and the release is recorded. For AI systems that assumption no longer holds. A model can start behaving differently without a single line of code changing: because it was retrained on more recent data, because a threshold was adjusted, or because the supplier of the underlying model rolled out a new version. ISO/IEC 42001 touches this subject in two places, and organisations that look at only one of them run into the other during the audit.

Two kinds of change, two clauses

Clause 6.3 covers changes to the management system itself. When you determine that the AIMS needs to change, you carry that change out in a planned way. You consider the purpose of the change and its potential consequences, the integrity of the system as a whole, the resources required, and any reallocation of responsibilities and authorities.

Clause 8.1 covers execution. You plan and control the processes needed to meet the AIMS requirements, establish criteria for those processes, control them against those criteria, and keep documented information demonstrating they were carried out as planned. Changes to AI systems in production sit here: retraining, a different data source, a different deployment environment, an adjusted prompt or a new model version from the supplier.

What differs from ordinary change management

For traditional applications the triggers for change are well understood and there is usually a working change management process around them. AI systems add triggers that process never anticipated.

The first is retraining. The model is retrained on the last few months of data, accuracy stays flat or improves slightly, and nobody sees cause for a change request. That the error distribution across subgroups has shifted only becomes visible if someone measures for it. The second is the external model version. If you run against a supplier model through an API, you receive updates you did not plan and sometimes do not see. The third is configuration: a threshold, a system prompt or a filter someone adjusts on a Tuesday afternoon because the outputs were too strict. Technically that is not a release. For the behaviour of the system it is.

Setting criteria: when is something a change

This is the heart of clause 8.1. You document when you retrain, when a drift alert is escalated, when a system is decommissioned, and which changes require the risk assessment to be redone. Without those criteria, every decision becomes a matter of interpretation after the fact, and that is exactly what an auditor records as a nonconformity.

A workable split uses three categories. Changes that can alter model behaviour, such as retraining, a new data source or a new model version, require risk reassessment and retesting before production. Changes that touch the application but not the model, such as a revised user interface, follow the regular process. Changes limited to infrastructure are logged. Write that split down and keep it short enough that teams actually use it.

Changes to the AIMS itself

Clause 6.3 gets overlooked because the system itself rarely changes. It happens more often than people think: extending the scope to generative AI, adapting governance processes to new regulation, or redistributing AI teams after an acquisition. In each case the standard expects prior thought about the purpose, the consequences for existing controls, the resources required and who is responsible for what afterwards.

In practice that means a short change proposal, approval by the AI governance function or top management before the change takes effect, and an evaluation afterwards of whether the intended effect was achieved. Reacting to new legislation without a structured transition plan is one of the nonconformities auditors record under this clause.

What an auditor asks for

Pick an AI system in production and follow one change end to end. Which version runs now, and which ran three months ago? Which experiment underpins the current version, and where are the results? Who approved the change, and on what basis? Was it tested before going live, and what was the rollback plan? And the question that yields the most: was the risk assessment updated after that change, or does it still describe the previous model version?

If an organisation answers that sequence readily, the process is sound. If the answer stops at a ticket reference with no substance behind it, AI change management exists in name only.

Updates you do not plan yourself

Outsourced AI deserves separate attention. A supplier updating their model is effectively changing your system. Arrange three things contractually: advance notice of version changes, the option to stay on a specific version or receive a transition period, and a test environment where you can assess the new version before it lands in your production process. Outsourced AI processes kept outside your own governance is one of the standing nonconformities under clause 8.1.

Where the evidence sits

For the audit you need the change management procedure for AI systems, the criteria for retraining, escalation and decommissioning, experiment logs and deployment records, approval records, the updated responsibility matrix after organisational changes, and post-implementation reviews. For the AIMS itself, add the change proposals with impact analysis and the approvals.

Nonconformities auditors record regularly

Models are retrained and redeployed without formal change control. Documented criteria are missing for the decisions that matter, such as when to retrain or when to escalate on drift. Operational records such as experiment logs and deployment records are absent or incomplete, so it cannot be shown that processes ran as planned. Development processes differ per team with no common standard. And on the clause 6.3 side: changes to the AIMS are made ad hoc, without impact assessment and without recording the roles that shifted.

Do not build a separate AI change process alongside the one you already run. Add one question to the form teams already fill in: can this change alter the behaviour of the model? If yes, risk reassessment and retesting follow. That is a smaller intervention than a second process, and it keeps the decision with the people actually making the change.