A.6.2.3 AI system design and development documentation

What A.6.2.3 asks an AI team to document about its design and development

A.6.2.3 asks the organization to document how its AI system was designed and developed, measured against its own objectives, its documented requirements and its specification criteria. In practice, the auditor expects one traceable record that links what the system was meant to do to the architecture, model choices, training approach and design decisions that were made to get there. If an audit, a customer questionnaire or an internal governance review asks how the system was built, this record is the answer, and it has to exist before the question arrives. The risk this control addresses is a build that nobody can later trace or justify. A team picks a model family, sets a training configuration, drops a feature or accepts a trade-off between accuracy and fairness, and the reasoning lives only in someone's memory. When the system later produces an unexpected result, or a regulator asks why a design choice was made, the organization cannot show whether the decision followed its requirements or was improvised under deadline.

The difficulty is usually scattered evidence. Design reasoning sits in chat threads, notebook cells, pull request comments and tickets that were closed without a summary, and no single place says which decision answered which requirement. Start by naming the owner of the design record and deciding where it lives, then require each significant decision to name the requirement it serves, the alternatives considered and the person who approved it. Confirm with your auditor or certification body how they expect the record to be structured, since ISO/IEC 42001 does not prescribe a format. A practical check is to pick one production model and ask whether someone outside the team can reconstruct, from the record alone, why its architecture and training approach were chosen and what changed between versions. If the answer requires interviewing the original engineers, the record is incomplete. Version-controlled wiki pages and protected repositories can hold this material, as long as reviews and approvals are recorded alongside the decisions they support.

Which AI systems, teams and third parties fall under the design record

The design record for A.6.2.3 is only as complete as its scope. Before anyone writes a design note, the organization must decide which AI systems the AI management system covers, how bought and adapted models are treated, and which teams and suppliers feed the record. These decisions follow the statement of applicability under clause 6.1.3, which the organization owns and must confirm with its certification body.

AI systems inside the AIMS boundary

List every AI system the organization builds, deploys or operates within the management system scope, including internal tools, customer-facing features and decision-support models. Record each system's name, owner, purpose and environment so that each one has a design record to point to. An assessor will usually pick a system from production and ask for its record, so a system missing from the inventory is a visible gap. Confirm the boundary wording with the certification body before work starts, because the scope statement sets what gets audited.

Built, fine-tuned or bought models

Decide how each model type is treated: models trained in-house, open-weight models adapted through fine-tuning or retrieval, and third-party APIs called without modification. Design decisions differ for each, so the record should state which parts the organization designed and which it inherited. A fine-tuned model usually needs its own training approach and data choices documented, while a purchased API needs the integration design and the reasons for choosing it. Ask the certification body how it expects each category to be recorded.

Third-party components in the record

Record every external component the system depends on, such as foundation models, vector databases, hosted inference, libraries and datasets obtained from suppliers. For each one, note the version or model identifier, the supplier, the design reason for using it and the known limits that shaped the architecture. Gaps here are common when teams swap a model provider without updating the design note. Cross-check this list against procurement records and the supplier controls under the third-party clauses of Annex A.

Product teams and requirements owners

Product managers usually own the objectives and documented requirements that the design must trace back to, so they must sign off the link between a stated purpose and the architecture chosen. Without that input, the record describes what was built but not why it meets the objectives. Name a single accountable owner for each system's design record and confirm that product changes trigger an update to it.

Data science and platform engineering

Data scientists document model selection, training approach, evaluation choices and the reasons behind design trade-offs. Platform engineers document the hosting architecture, environments, pipelines and infrastructure decisions that the model runs on. Both groups write the technical content of the record, so their entries should use the same system identifier and version labels. Ask who reviews each entry and how disagreements between the two groups are resolved and recorded.

Security and risk review

Security engineers contribute threat-relevant design choices, such as access boundaries, secret handling, isolation between tenants and the resilience measures built into the architecture. Risk owners confirm that the design addresses the risks identified in the organization's risk and impact assessments. Their sign-off shows that security considerations were part of the design rather than added after release. Confirm with the certification body whether the security review is recorded in the design file or cross-referenced to a separate security document.

Why the internal design record is not the same as A.6.2.7 technical documentation

The internal design record under A.6.2.3 and the technical documentation under A.6.2.7 can draw on the same architecture facts, but they answer different questions for different readers. A.6.2.3 asks the organization to document how the AI system was designed and developed against its objectives, documented requirements and specification criteria. A.6.2.7 asks the organization to decide what documentation each category of interested party needs, such as users, partners and supervisory authorities, and to provide it in a suitable form, including limits and residual risks. The internal record is for the people who built and govern the system. The external documentation is for people who must rely on it without seeing the build.

The same facts usually feed both: the model architecture, the components and data sources, the training approach, the evaluation results and the intended purpose. The difference is in what each document keeps. The internal record should keep the reasoning behind each design decision, the alternatives considered and rejected, the trade-offs accepted, and the open risks the team has not closed. External documents often omit exactly these items because they are written to inform, not to explain how the team got there. For illustrative purposes, a team that chose a smaller model for latency reasons should record the rejected larger model, the measured gap and the residual risk, even if the external sheet only states the model in use.

Confirm this split with your assessor before you build the two documents, because the wording of A.6.2.3 and A.6.2.7 in the standard and the guidance in its Annex B, which you should obtain from ISO, sets the boundary your auditor will test. A practical check: pick one design decision and ask whether the internal record explains why it was made, what was rejected and what remains open, and whether the external document states the limits that follow from it. Version control and change history help here, since each change to a design decision should be traceable to a date, an author and a reason.

How an assessor tests the design and development record

This table walks through the test steps an assessor typically follows for A.6.2.3, the evidence each step asks for, and the findings that most often appear. Read it as a checklist for preparing records before a certification body samples your AI systems. The main takeaway is that the design record must trace from stated objectives to design decisions and stay current through every release.

Test step	What the assessor checks	Evidence requested	Common finding
Select AI systems from the inventory	Whether the sample covers systems in scope of the AI management system, drawn from the organization's own AI inventory and not only the flagship product	AI system inventory, scope statement and the statement of applicability entry for A.6.2.3	Inventory omits systems built in-house or added through features, so they are never tested
Trace objectives to requirements	Whether the stated objectives and documented requirements for each sampled system are identifiable and agreed	Objectives record, requirements specification and approval records with dates and owners	Objectives are generic and cannot be matched to any requirement
Trace requirements to design decisions	Whether each material requirement is linked to an architecture or design decision that addresses it	Design documents, architecture diagrams and a traceability matrix or equivalent cross-reference	Requirements exist but never link to a design decision
Check model choices and rationale	Whether the selected model type, provider or version and key parameters are recorded with a reason for the choice	Model selection record, evaluation notes comparing alternatives and sign-off by the accountable owner	Model chosen without recorded rationale or alternatives considered
Check the training approach	Whether the data sources, training method, configuration and key assumptions are documented as they were used	Training run records, configuration files, data lineage references and design notes dated during development	Training approach described only in a slide deck or from memory
Confirm records were written during development	Whether design records predate release and reflect decisions as they were made	Document creation dates, commit history, wiki revision history and approval timestamps	Records written or back-filled after release, with no contemporaneous history
Confirm records stay current through releases	Whether changes to design or training after a release are reflected in the record and approved	Version history showing who changed what and when, change tickets and re-approval records	Design changed in code or configuration but the document still describes the earlier version
Confirm the organization's own review	Whether the owner reviewed the design record against its objectives before the system went forward	Review minutes, sign-offs and any internal audit findings on the design record	No evidence that anyone other than the author reviewed the record

Building the design record step by step

The sequence turns the objectives and requirements for an AI system into a single, dated design record that an assessor can trace from intent to build decisions. Each step has a named output, so the record stays current as the system changes.

Assign one owner per design record
Name one accountable owner for each AI system's design record, normally the product or engineering lead who can answer for architecture and model decisions. The owner decides who contributes sections, such as data science, security and privacy, and who must review them. Done means a record header lists the system name, the owner, the contributors and the date the record was opened. Ownership should appear in the organization's AI roles and responsibilities, so an assessor can match the record to a named person.
Link objectives and requirements to a template
Copy the documented AI objectives and the approved requirements for the system into a standard design record template. Each design section should point back to the requirement it serves, such as performance, security, fairness or transparency targets. Done means every requirement in the approved specification has at least one place in the template where a design decision will be recorded, and any gaps are flagged for the owner. The template itself is the first artifact an assessor will ask to see.
Capture architecture and model choices as they occur
Record the system architecture, the model or models considered, the training approach and the data sources as each is decided, not reconstructed later. Include the alternatives considered and the reason one was chosen, along with known limits. Engineers can draft entries in the repository alongside the code, which keeps the record close to the work. Done means the architecture diagram, model selection notes and training approach sections are populated for the current build, with each entry dated.
Keep a dated decision log
Maintain a decision log that captures each significant design choice, who made it, when, and which objective or requirement it affects. Decisions that change scope, accept a known risk or depart from the original specification need their own entries. Done means the log can be read on its own and reconstructs why the system is built as it is. The log is distinct from the summary sections, so an assessor can test whether decisions were made deliberately and by the right people.
Require sign-off at defined design gates
Set the gates at which the design must be reviewed and approved before work continues, such as after architecture selection, before training starts and before the system moves to verification. Approvers should be the roles defined in the organization's governance, and each approval should record the reviewer, the date and the version approved. Done means every gate has a signed or recorded approval entry, and no gate is marked complete without one. The organization sets the gates and approvers, so confirm them against its own AI governance policy.
Version and store each record revision
Store the design record in a version-controlled repository or wiki so that every change is kept with its date and author, and earlier versions can be compared or restored. Tag the version approved at each gate so the approved design can be matched to the system that was later verified and deployed. Done means an assessor can open any approved version and see what changed, when and by whom. Access should be limited to the roles that need to edit or approve the record, and the repository's own permission model should be documented.

Evidence that passes for AI design and development documentation

A.6.2.3 asks for a design and development record that traces back to objectives, documented requirements and specification criteria. The artifacts below are the ones an assessor will usually ask to see, and each one only holds up if it is updated as the system changes rather than rewritten before an audit. Treat them as a set: each artifact should point to the others.

Design record per AI system

A single, versioned design record for each AI system describes its architecture, components, data flows, integration points and intended operating context. The assessor will check that the record matches the system as deployed, not the system as first planned. Keep it in a controlled wiki or repository and require a change request to alter any architecture section. Confirm that each record names an owner and states which requirements it implements.

Dated decision log with rationale

A decision log records each significant design choice, such as a model family, a retrieval approach or a rejected alternative, with a date, the decision owner and the reason it was made. Assessors use it to test whether design decisions trace to documented objectives and risks. Add an entry whenever a change request or release gate alters a design choice, so the log grows with the system instead of being reconstructed later.

Model and training approach records

These records describe the model selected, its provenance and license, how it was adapted or trained, the data sets used at a high level, and the hyperparameters or configuration that shaped the result. Assessors look for enough detail that a second team could reproduce or challenge the design. Pin each record to the model version and training run it describes, and update it when a model is retrained, fine-tuned or swapped.

Requirements-to-design traceability

A traceability matrix links each documented requirement and specification criterion to the design element that addresses it, and to the verification activity that tests it. Assessors use it to find requirements with no design owner or design elements with no stated purpose. Generate or review the matrix at each release gate, and flag any requirement whose design link changed since the last approved version.

Approval and sign-off entries

Approval entries record who reviewed each design version, what they approved, the date and any conditions attached. Assessors check that approvers had the competence and authority to accept the design, and that unapproved designs were not released. Enforce approval in the workflow itself, for example through protected branches that require a named reviewer before merge, so the sign-off cannot be skipped under deadline pressure.

Version history and change control

Version history shows every change to the design documents, what changed, when, by whom and why, and allows an assessor to compare any two versions. Tie each version to a change request and a release identifier so the history matches what ran in production. Schedule reviews around change events rather than a yearly refresh, and confirm that rollbacks are recorded as changes too.

Open-source tools that keep design records under version control

A.6.2.3 asks for a documented record of how an AI system was designed and built. The tools below can hold that record, show who changed it and when, and tie code back to recorded decisions. None of them makes the design record complete or compliant on its own; the organization still decides what must be documented.

Protected branches in GitLab

GitLab Community Edition (MIT) lets maintainers restrict which roles can push or merge to a branch. Setting push access to no one blocks direct pushes, and force pushes stay disabled unless explicitly allowed. For A.6.2.3, this turns design-affecting code and configuration changes into reviewed merge requests, so the commit history shows who approved each design change. Confirm that your self-hosted tier and merge request approval settings meet your reviewer and separation-of-duties requirements.

Version history in XWiki

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. Reviewers can compare any two versions and roll back to an earlier one. For A.6.2.3, this gives a dated trail for architecture descriptions, model selection rationale and design decisions, so an assessor can see how the record evolved. Confirm that rollback is governed by a process, since restoring an old version must not erase the record of a decision.

Role-based permissions in BookStack

BookStack (MIT) assigns abilities through roles, and those permissions can be overridden at the shelf, book, chapter or page level. For A.6.2.3, this lets the organization decide who may edit design records for each AI system while others only read them. Editors can be limited to the design owners named in the project's records. Confirm that your role model separates authors from approvers and that page-level overrides are reviewed, since a single exception can widen access without notice.

Code scanning with Semgrep Community Edition

Semgrep Community Edition (LGPL-2.1-only) scans code in languages including Python, Go, Java, JavaScript, TypeScript and Terraform, using community or custom rules. It can run in CI/CD pipelines to scan repositories continuously. For A.6.2.3, scan results recorded per pipeline run can support evidence that implemented code matches the recorded design, such as approved model-serving components or prohibited libraries. Semgrep does not verify design intent, so custom rules must be written from the documented design decisions. Confirm the language coverage for your stack and the license terms that apply to your use.

What documenting AI design costs in effort, tooling and assessment

This table breaks down the cost components of documenting AI system design and development under A.6.2.3, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to see where internal effort will land before you bring in outside help.

Cost component	Who carries the cost	One-time or recurring	What drives it
Tooling and licenses	Organization or implementation partner	One-time setup, then recurring hosting	The supplied open-source tools (GitLab Community Edition, XWiki, BookStack, Semgrep Community Edition) carry no license spend under their stated licenses, so cost sits in hosting, backups and administration time
Design record templates and traceability setup	Engineering lead with implementation partner support if scoped	One-time	Number of AI system types, whether requirements link to design decisions, and how many repositories and wikis must be connected
Migration of past design records	Engineering and data science teams	One-time	Age and completeness of existing design notes, model cards and architecture diagrams, and whether they live in email, slides or unversioned files
Engineering and data science time to write and maintain records	Internal teams, or partner staff if contracted	Recurring, per release and per model change	Frequency of model retraining, number of model changes, and how much design content is captured as a by-product of normal work
Governance time for design approvals	Internal AI governance owner and approvers	Recurring, per approval gate	Number of approval gates, whether approvers use a standard review checklist, and how many systems share the same approvers
Evidence upkeep between audits	Compliance lead and system owners	Recurring, periodic review	Review cadence set in the organization's own procedures, staff turnover, and changes to third-party components or model providers
External review or testing	Independent reviewer or testing firm, if commissioned	Recurring per review cycle	Scope of the design review, whether security testing of the design is included, and the number of high-impact systems in scope
Auditor sampling effort	Organization pays the certification body or auditor, and staff time to respond	Recurring per audit cycle	Number of AI systems the auditor samples, how quickly records can be produced, and how well records trace to requirements
Third-party and supplier components	Organization, plus supplier documentation effort	Recurring	Number of third-party models, APIs or datasets whose design details must be documented, and what the supplier provides in writing

Who owns the design record, what a partner prepares and what the auditor tests

Your team owns the substance of the design record. Control A.6.2.3 asks the organization to document how the AI system was designed and developed against its own objectives, documented requirements and specification criteria, so the objectives, the design decisions and the approvals must come from people accountable for the system. A partner can structure the record, but it cannot decide why a model was chosen, which trade-offs were accepted or whether the system met its requirements.

Objectives and requirements: Confirm the objectives and requirements the design is measured against, as set under A.6.2.2 and A.6.1.2.
Design decisions: Record architecture, model choices, training approach and the reasons for each, in your own words.
Approvals: Name the approvers, their dates and what they signed off, including any decision to proceed.
Content accuracy: Review every entry for correctness before it is treated as the record of truth.
Ownership: Assign a named owner for each design artifact and for keeping the record current.

Before any assessment, check that every design decision in the record has a named owner and a recorded approval that your staff can explain without the partner present.

Questions buyers ask about A.6.2.3 before hiring outside help

How much effort does the design record take for a single AI system?

The effort depends on how much design and development history the system already has and how many people made its decisions. A record covers the objectives the system serves, the documented requirements it was built against, the architecture, the model choices, the training approach and the design decisions behind each of them. A single system with a stable architecture and a small team usually needs a shorter first pass than a system that has changed models several times or that depends on third-party components. The main drivers are how many design decisions were never written down, how many of them need to be reconstructed from tickets, commits and meeting notes, and how often the system has been materially changed. Ask any provider to break the estimate into discovery, reconstruction, template build and ongoing upkeep, so you can see which part is one-time and which recurs.

Can our team write the A.6.2.3 record without an outside partner?

Yes, an internal team can write the record if it has the engineering knowledge to explain the design and the governance time to review it. The standard does not require a consultant, and the organization owns its controls. The practical question is whether the people who made the design decisions can commit time to documenting them, and whether someone outside the build team can challenge the record before an assessor sees it. Teams that struggle usually lack a template, a review step, or a place where records are version controlled. An outside partner can help with those mechanics, such as setting up a repository, drafting templates and running a gap check, but the decisions recorded must still be the organization's own.

What does the work need from engineering and governance staff?

Engineering staff need to supply the facts: the architecture, the model and data choices, the training or configuration approach, and the trade-offs considered at each step. Governance staff need to confirm that each design decision traces back to a documented objective and requirement, and that the record is reviewed and approved under the organization's own process. In practice this means named owners for the design record, a reviewer outside the delivery team, and a rule that material design changes update the record before release. Without those roles the record tends to describe the system as it was built at one moment and then drift away from it.

How long does it take to build the first design records?

No duration can be stated here without knowing the system, its history and the scope agreed for the work. The most reliable answer comes from a written scope that lists the systems covered, the records to be produced, the sources to be reconstructed and the review steps. Ask for the schedule to show when engineering input is needed, because that input is usually the slowest part. Compare any timeline against your own plan for the assessment, including when the auditor expects to see the records. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the schedule should come from that document rather than from a general estimate.

Can a partner build the record and still stay independent of the auditor?

Yes, provided the roles are kept separate. An implementation partner can prepare systems, documentation and evidence, but only an independent auditor or certification body issues a report or certificate. Under ISO/IEC 42001, certification is granted by an external certification body, and ISO itself does not certify organizations. The same firm should not design the controls, prepare the evidence and then conclude that the controls work. Confirm with the certification body, before engaging anyone, whether it has any conflict-of-interest rules about who may prepare the records. Keep the written record of who wrote what, so an assessor can see that the organization owns the design decisions.

How does A.6.2.3 differ from A.6.2.7?

A.6.2.3 is the internal design and development record, while A.6.2.7 is the technical documentation given to interested parties such as users, partners and supervisory authorities. A.6.2.3 explains why the system was built the way it was, based on its objectives, documented requirements and specification criteria. A.6.2.7 decides what each audience needs to know and provides it in a suitable form, including limits and residual risks. The internal record can feed the external documentation, but the two serve different readers and should be reviewed separately. Mixing them usually leaves engineers with user-facing documents that omit design reasoning, or customers with internal notes they cannot use.

Which tools can keep the design record under version control?

Several open-source tools can hold the record with an audit trail. A repository platform such as GitLab Community Edition can keep design documents with protected branches, so that only named roles can merge changes and direct pushes are blocked. A wiki such as XWiki records every change to a page, showing what changed, when and by whom, and allows comparing and rolling back versions. BookStack assigns permissions by role and can override them at the shelf, book, chapter or page level. The right choice depends on whether engineers already work in a repository and on how reviews are run. Confirm each tool's capabilities against the version you deploy, because the features described here come from current documentation.

How DeployOpen scopes, implements and prepares design evidence for A.6.2.3

DeployOpen helps organizations set up the systems where AI design and development records are written, reviewed and kept, so the evidence for A.6.2.3 is traceable from the start. The organization owns its design decisions and its AI management system, and an independent auditor or certification body decides whether the control is met.

How we scope

Written scope names which AI systems, teams and repositories the design record covers for A.6.2.3.
Scope states which design artifacts are in and out, such as architecture, model choices, training approach and design decisions.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.

How we build

We configure a self-hosted wiki with version history so design decisions carry an author, a date and a comparable revision trail.
We set protected branches in GitLab Community Edition so design-related changes go through review before they are merged.
We add Semgrep scans to CI/CD pipelines and set role-based access in BookStack so reviewers approve records they are responsible for.

How we hand over

Handover includes a documented design record template mapped to the organization's stated objectives and specification criteria.
We provide access and permission documentation so the organization can show who could create, change and approve each design record.
The organization receives runbooks and a list of open items, and decides which records to show to its independent auditor.

How we support

Support covers upgrades, backups and access reviews for the wiki, repository and scanning tools used for design evidence.
Retainers can include periodic reviews of design records against the organization's requirements, with findings reported to its internal owner.
Organizations should confirm with their auditor which design records and retention periods the assessment will expect before setup.

A.6.2.3 Documentation of AI system design and development