ISO 42001 Annex A.6.1.3: Define Responsible AI Design and Development Processes

What control A.6.1.3 requires in practice

Control A.6.1.3 asks the organisation to define and document the specific processes it uses for the responsible design and development of an AI system. The control is about how the work is done and how decisions are made along the way, rather than the objectives themselves, which belong to A.6.1.2. Annex B, offered as guidance, lists matters a process may address: the life-cycle stages used, testing requirements and means, human oversight requirements and tools, the stages at which impact assessment takes place, expectations for training data, the expertise or training developers need, release criteria, approvals and sign-offs, change control, usability and controllability, and engagement with interested parties. It adds that processes depend on the functionality and technology involved, and that the organisation may specify its own life-cycle stages. The outcome is a defined, documented way of working that developers actually follow.

Preserve the decisions through iteration

Annex B.6.1.3 discusses lifecycle stages, testing, oversight, impact assessment, data expectations, expertise, release decisions and change control. This guidance is required consideration under clause 6.1.3(e), with tailoring allowed by B.1. The organisation can define lifecycle stages that fit its work.

As an original process-design method, identify the decisions that should not disappear during rapid iteration. A team may need to confirm the intended use, evaluate a changed dataset or obtain an authorised release decision. Explain what evidence informs each decision and how an unresolved issue is handled.

Why defined AI development processes matter

Without a defined process, responsible development depends on individuals remembering the right questions at the right moment. That works until a team is busy, a new member joins or a feature changes late in a release. A documented process makes expectations visible: when an impact view is needed, what data may be used, who approves release and what happens to a change. This reduces rework and disputes, since developers know the rules in advance. It also gives the organisation evidence for clients who ask how their system was built, and helps managers compare projects consistently. Where development is partly outsourced, a defined process is a basis for specifying what suppliers must do.

How to implement control A.6.1.3

Describe the process at the level of decisions, so it survives rapid iteration and different technologies. The process should fit the way your teams actually work, whether that is formal stage gates or short iterations, so involve developers when describing it.

1. Decide which life-cycle stages your work follows, or adopt a recognised model and adapt it.
2. List the decisions that must not disappear during iteration, such as confirming intended use and approving release.
3. For each decision, say what evidence informs it and who has authority to take it.
4. Define testing and human oversight expectations, and the stage at which an impact assessment is triggered, so nobody has to guess.
5. Set rules for training data, including permitted sources, approved suppliers and labelling expectations.
6. Add change control so a late feature that alters the use prompts a fresh look at the earlier decisions.
7. Check the process on a live project and adjust steps that teams routinely bypass.

Illustrative software example: a late feature changes the use

Illustrative construction example: domain input arrives too late

A construction consultancy develops an AI tool to classify progress images. Domain engineers see the prototype only after technical testing is complete. They identify that important categories depend on site context the images do not contain.

The organisation adjusts its process so relevant domain knowledge informs requirements, data and evaluation earlier. This can prevent avoidable rework and unsupported conclusions. The control does not prescribe the exact workshop or gate; it requires a defined process suited to responsible design and development.

Integrate oversight and evaluation

Where human oversight contributes to treatment, development should make it feasible. Consider what information a reviewer receives, when intervention is possible and whether the interface supports the intended decision. A policy statement cannot compensate for a product that hides the evidence needed for review.

Testing and evaluation should connect with specified requirements and intended conditions. The verification and validation control develops those arrangements, while impact assessment informs consequences and relevant stages.

Define how exceptions and changes move

A process needs a usable route when evidence is incomplete or a criterion is not met. Identify who can decide whether further work, restriction or a different approach is appropriate. Avoid a release process where an unresolved concern can only be ignored or escalated indefinitely.

Document the process at a level that supports consistent work. Existing software or product-development arrangements can provide a foundation, but examine where AI introduces different dependencies and evidence needs. Renaming an existing procedure is not the same as checking its adequacy.

Evidence and failure patterns