Home / Requirement record / A.6.2.3
A.6.2.3
Documentation of AI system design and development
Document the AI system's design and development, grounded in the organization's objectives, the documented requirements and the specification criteria. The artefact behind the answer is design records covering ML approach, algorithm and model type, training approach and data quality, evaluation and refinement, hardware and software, AI-specific security threats, output interface, human interaction and interoperability. For documentation of ai system design and development the evidence sits at the gate it belongs to.
- What it asks
- Document the AI system's design and development, grounded in the organization's objectives, the documented requirements and the specification criteria.
- Where generative AI changes the answer
- Design documentation has to record the model version, the system prompt and the corpus, or the behaviour cannot be reproduced later.
- Who it binds
- The AI system owner and the delivery team at each life cycle gate. For A.6.2.3 the named role is the owner of design records covering ML approach, algorithm and model type, training approach and data quality, evaluation and refinement, hardware and software, AI-specific security threats, output interface, human interaction and interoperability.
- Evidence an auditor normally samples
- Design records covering ML approach, algorithm and model type, training approach and data quality, evaluation and refinement, hardware and software, AI-specific security threats, output interface, human interaction and interoperability
- Final system architecture documentation
- The test you can run
- Ask for design records covering ML approach, algorithm and model type, training approach and data quality, evaluation and refinement, hardware and software, AI-specific security threats, output interface, human interaction and interoperability and for its last review date; an artefact nobody can date is paperwork rather than a control.
- Common failures
- AI-specific threats such as data poisoning, model inversion and model theft not considered
- No final architecture documentation
- Before the draft publishes
- For A.6.2.3, walk the use through the life cycle gates and record which gate has no evidence behind it. That gap is what an auditor will ask about first. The first artefact to produce is design records covering ML approach, algorithm and model type, training approach and data quality, evaluation and refinement, hardware and software, AI-specific security threats, output interface, human interaction and interoperability.
- Where this sits against the draft
- The draft's published scope names controls for the risks it identifies, and A.6.2.3 (documentation of ai system design and development) is the published ISO/IEC 42001 control closest to that work. The draft does not replace it, and an audit still tests it against the evidence listed here.