ISO 42001 Annex A.6.2.5: Plan AI Deployment Before Release

What control A.6.2.5 requires in practice

Control A.6.2.5 asks the organisation to document a deployment plan and to make sure appropriate requirements are met before the system is deployed. It has two parts: a plan, and a check that readiness conditions are satisfied. Annex B, which is guidance, draws attention to the fact that systems are often developed in one environment and deployed in another, for example built on premises and deployed in the cloud, and that these differences belong in the plan. It also notes that components such as software and a model may be deployed separately. The organisation is expected to have release criteria, which may include verification and validation measures that must be passed, performance targets, user testing and management approvals, and the plan should reflect the perspectives of, and impacts on, interested parties.

Examine the destination environment

Annex B.6.2.5 considers differences between development and deployment environments, independently deployed components, release criteria and relevant interested-party impacts. Its guidance must be considered under clause 6.1.3(e), with tailored implementation permitted by B.1.

A practical plan identifies what will be deployed, where and under which conditions. Consider dependencies that made evaluation successful and whether they exist in operation. A test environment with different resources, data or reviewer access may not represent the deployment context.

Why AI deployment planning matters

Many AI incidents occur not because the model was poor but because the system that went live was not the one that was tested. Different data, resources, configuration or user access can change behaviour entirely. A deployment plan makes the organisation compare the destination with the evaluation conditions, agree who has authority to release and prepare those affected. The result is fewer failed launches, less emergency rework and clearer accountability for the decision to go live. For clients, an orderly deployment with defined criteria is evidence of a mature service. For the organisation, it makes rollback and communication easier, because they were considered before anything went wrong.

How to implement control A.6.2.5

Treat deployment as a decision with conditions, not a technical event, and test the plan against the destination. Where a supplier controls part of the deployment, agree in advance what you will be told about changes, so your plan remains accurate after release.

1. Describe what will be deployed, including each component that can change independently, and where it will run.
2. List differences between development, evaluation and operating environments, and judge which could change results.
3. Define release criteria drawn from evaluation outcomes, performance targets, user testing and required approvals.
4. Name who may authorise release and what evidence they will see before deciding.
5. Plan for the people affected, including training, communication and arrangements for those who rely on outputs in their daily work.
6. Prepare how the deployment can be paused or reversed if the system behaves unexpectedly, and who may decide that.
7. Record the outcome of the readiness check before go-live, including any accepted conditions.

Illustrative software example: the model and application are released separately

Illustrative manufacturing example: operating conditions differ from the pilot

A manufacturer evaluates an AI inspection aid in a controlled area with experienced staff. It plans deployment on a busy line with different lighting and temporary operators. The pilot result is useful evidence but does not automatically support that configuration.

The plan examines relevant environment and competence differences before release. It connects evaluation, operating instructions and support with the intended deployment. If the conditions cannot be met, the organisation needs an appropriate decision about resources, scope or timing rather than assume the pilot approval covers the gap.

Make release criteria meaningful

Criteria can include relevant evaluation results, user preparation and authorised approvals. These are implementation considerations from the guidance, not one mandatory checklist for every system. Choose criteria that address the actual requirements and treatment decisions.

A criterion should provide a usable basis for deciding readiness. “Testing completed” may say little if important failures remain unresolved. Identify how exceptions are evaluated and who can decide, while preserving the evidence and limits of any conditional release.

Include the people affected by deployment

Consider whether users and other relevant parties have the information and resources needed for the changed service. A new interface or output can alter how people interpret a result. Deployment should connect with user information and appropriate communication.

Support and operating ownership should also be ready. A development team may be available during the pilot but absent after release. The plan needs to account for the organisation's actual ongoing arrangement rather than rely on informal goodwill.

Evidence and common mistakes