ISO 42001 Annex A.6.2.3: Preserve the Reasoning Behind AI Design
ISO 42001 control A.6.2.3 concerns documenting AI design and development in relation to organisational objectives, requirements and specification criteria. The record should explain what was designed and why. Without that reasoning, a later team may change a feature without recognising the condition that made the original decision acceptable.
What control A.6.2.3 requires in practice
Control A.6.2.3 asks the organisation to document the design and development of an AI system, grounding the record in its organisational objectives, documented requirements and specification criteria. The point is to show how the finished system relates to what was intended. Annex B, which is guidance, lists the kinds of design choice that may need recording: the choice of machine learning approach, algorithm and model type, how the model is trained and what data quality is assumed, how models are evaluated and refined, the hardware and software involved, security threats considered over the life cycle, such as data poisoning, model stealing or model inversion, how outputs are presented, how people interact with the system, and interoperability and portability. It accepts that design and development iterate, but expects documentation to be maintained and a final architecture description to exist.
Document choices that affect the result
Annex B.6.2.3 discusses choices about models, data, evaluation, components, security, interfaces and human interaction. It recognises iteration and the value of maintained stage documentation and a final architecture account. The guidance must be considered under clause 6.1.3(e), while B.1 allows implementation appropriate to the organisation.
A practical record focuses on consequential choices and their basis. Explain alternatives considered where they help a later reader understand a limitation or trade-off. Do not create a narrative of every minor experiment if it obscures the decisions that affect requirements and risk.
Why recording AI design reasoning matters
Design decisions often exist only in the heads of the people who made them. When those people move on, the organisation loses the reasons behind the system's behaviour and may undo a safeguard without realising it. A design record lets later teams change a component knowing what it was there to do. It speeds investigation after an incident, supports evidence for clients and auditors that requirements were actually met and helps new staff become productive without reconstructing history. It also makes security thinking visible: threats considered at design stage can be checked again when the system is modified. The cost is modest when the record focuses on consequential choices rather than every experiment.
How to implement control A.6.2.3
Record the choices that shaped behaviour, together with their reasons, and keep the record alongside the system. Proportion again helps: a short, accurate record maintained through the work is better than a long retrospective document written after the system has already shipped.
- Link the design record to the requirements and objectives it responds to, so the reader can see exactly what each choice served.
- Capture consequential decisions on model approach, data assumptions, components, interfaces and human interaction, with the reason for each.
- Note alternatives considered where they explain a limitation or trade-off a later reader might otherwise question.
- Record security threats considered in design and the measures chosen in response.
- Keep stage documentation through iterations and produce a final architecture description when the design settles.
- Define who maintains the record, and require updates when a change alters a recorded decision.
- Check periodically that a new team member can understand why the system behaves as it does.
Illustrative software example: a warning disappears during redesign
A software team designs an AI assistant to show source material beside a generated answer because reviewers need that material to check technical claims. A later interface redesign removes the source view to simplify the screen.
If the original design rationale is retained and linked to the review requirement, the redesign team can recognise the effect on the control. A screenshot of the old interface alone may not explain why the element mattered. The record supports assessment of the change rather than prohibit redesign indefinitely.
Illustrative manufacturing example: the model choice depends on data
A manufacturer selects an inspection approach after examining the available image data and the operating environment. A later team inherits the code but not the assumptions about lighting and product variants used during development.
The design documentation should connect the choice with those conditions and relevant evaluation. When a new product variant is introduced, the team can identify which assumptions need reconsideration. A repository containing model files does not necessarily preserve the business and technical reasoning behind them.
Maintain a coherent account through iteration
Development can involve many versions and experiments. Keep enough stage information to understand material changes and the basis of the deployed configuration. Distinguish rejected approaches from the design actually released.
The final architecture description should help relevant readers understand components and interfaces. Its format can vary. A user organisation purchasing a service may rely on appropriate supplier information and its own integration documentation rather than pretend to possess undisclosed internal model design details.
Link design with requirements and evaluation
The requirements and specification provide the basis for design decisions. Verification and validation provide evidence about whether the resulting system meets the relevant criteria and intended conditions. Useful documentation keeps these connections visible.
Include relevant security and human-interaction considerations without turning the design record into an unrelated threat catalogue. If a choice changes how a reviewer can intervene or what information a user sees, explain its significance for the system's operation and assessment.
Evidence and common mistakes
The control calls for documented design and development. Evidence may include rationale, architecture descriptions, controlled decisions and links to specifications and evaluation. Test whether a competent colleague can explain a significant design choice without relying entirely on the original developer.
Common weaknesses include keeping only the final model file, documenting decisions after release from memory and mixing current and obsolete diagrams. Another is treating commercial confidentiality as a reason to omit all integration information. Protect sensitive detail while preserving what authorised people need to assess and operate the system.
Frequently asked questions
Is source code enough design documentation?
It can be important evidence, but may not explain objectives, assumptions, interfaces or the reasoning behind choices. Provide the information needed for those purposes.
Must every experiment be retained forever?
No universal rule is stated here. Preserve relevant design evidence and follow applicable information-control and retention requirements.
Can supplier documentation contribute?
Yes. Assess its relevance and limits, and document your own integration and use decisions rather than claim visibility you do not have.
Preserve the rationale behind a consequential AI design choice
Ask Sterling to review an AI design evidence trail. Scoped support can connect requirements, documentation and Effivity ISO & GRC automation software. Documented Information Management develops useful control principles. Return to the lifecycle theme or the library hub.