The AI system life cycle in ISO 42001: what Annex A.6 asks of you at each stage

Of all the Annex A domains in ISO/IEC 42001, A.6 sits closest to the development work itself. Where the policy (A.2) and roles (A.3) are about the organisation, A.6 follows the AI system: from the objectives you set before development starts to the event logs you keep once the system is live. Teams that have been building models for years often have many of these steps in place informally. The standard asks for something different: that you can show, for each stage, how you do it and why. This article walks through the A.6 controls in life cycle order, in plain terms and with the nonconformities we encounter most often as auditors.

Before any code exists: objectives and design processes (A.6.1.2 and A.6.1.3)

The life cycle does not start with the first line of code. Control A.6.1.2 asks for documented objectives for responsible development, and they need to be measurable. "We develop AI responsibly" is an intention, not an objective. A usable objective reads, for example: every model that affects individuals passes a bias test on predefined characteristics before deployment, with documented acceptance criteria. These objectives should align with the AI policy, be communicated to the development teams and be tracked, for instance through a dashboard or periodic reporting.

Control A.6.1.3 then asks for a documented process for responsible design. In practice this means the design phase has a set of fixed steps: an ethical screening at the start, translating fairness requirements into concrete design criteria, determining the level of explainability needed and designing human oversight (human-in-the-loop or human-on-the-loop). The nonconformity we see most often here: the ethical review happens only after the system has been built, and oversight mechanisms are retrofitted afterwards. That rarely works well. Whoever decides after the build that a human should be able to intervene tends to discover the architecture was never designed for it.

Documenting requirements (A.6.2.2)

For every new AI system, and for every material change, the standard asks for documented requirements. The pitfall is that requirements cover only the functional and technical side: what the system should do, how fast and how accurately. An auditor checks whether there are also requirements on fairness (which metric, which threshold), explainability, human oversight and data quality, and whether the outcomes of the AI risk assessment (6.1.2) and the impact assessment (6.1.4) show up in the requirements. Traceability is the key word: for every requirement it should be clear where it came from. A risk assessment that identifies a bias risk while the system requirements say nothing about it is a classic finding.

Documenting the design (A.6.2.3)

Design documentation answers two questions: what was chosen and why. Think of the model architecture and the rationale for choosing it, the structure of the data pipeline, the training approach and the evaluation methodology. In many organisations the design exists only in the code and in the heads of the developers. That backfires with staff turnover and at every audit. The standard also expects the documentation to evolve with the system: a design document describing the situation from two retraining cycles ago does not count as current.

Verification and validation (A.6.2.4)

Testing before deployment is more than checking whether the model is accurate. The standard asks for defined verification and validation measures with criteria set in advance. In a mature setup that includes functional tests, performance tests, fairness tests per defined group, robustness tests with edge cases and adversarial input, and safety tests within set boundaries. Two points deserve attention. First, independence: for higher-risk systems, validation should not sit with the same team that built the model. Second, pass and fail criteria: without predefined thresholds, the deployment decision becomes a matter of gut feeling. And if the system changes materially, validation has to be repeated.

Deployment (A.6.2.5)

For deployment the standard asks for a documented plan and a check that the conditions have been met. In practical terms this means a pre-deployment checklist: is the risk assessment current, has the impact assessment been completed, has validation passed, is the documentation (model card, data sheet) in place, is monitoring configured and has the rollback procedure been tested? Who is allowed to approve must be defined. The nonconformity we encounter here is predictable: any developer can deploy to production, with no gate. Staged rollouts (canary releases, shadow mode next to the old model) considerably reduce the risk of a new model version, and a tested rollback lets you revert to the previous version within minutes.

Operation and monitoring (A.6.2.6)

After deployment the real work starts. The standard asks you to define the elements needed for ongoing operation, including monitoring, maintenance, updates and support. Monitoring that only measures uptime and error rates misses what matters with AI: drift. Data drift (the input changes), model drift (performance degrades) and concept drift (the reality the model was trained on shifts) stay invisible without detection mechanisms until users start complaining. Mature monitoring also tracks fairness metrics over time and the rate at which humans override the system's output. Just as important as measuring is the feedback loop: persistent drift has to lead somewhere, such as retraining, a fresh risk assessment or, in the extreme case, retiring the system.

Technical documentation for interested parties (A.6.2.7)

Control A.6.2.7 asks you to determine what technical documentation each category of interested parties needs: users, partners, supervisory authorities. The two best-known forms are the model card (purpose, architecture, training data, performance, limitations, fairness evaluations and intended use of the model) and the data sheet (origin, collection method, processing steps and known limitations of a dataset). For high-risk AI systems under the EU AI Act this connects directly to the technical documentation obligations there; setting up A.6.2.7 properly lays that foundation at the same time. Version control and a central repository are not luxuries: documentation scattered across personal drives carries little weight in an audit.

Logging (A.6.2.8)

The last control in the chain asks for event logging, at minimum while the system is in use. Good AI logging records per decision: the input, the output, the model version used, the confidence score and any human overrides. The test we apply as auditors is simple: can you reconstruct how a specific decision from three months ago came about? Infrastructure logs (access, errors) do not answer that question. Logs also need protection against tampering and a retention period that matches the applicable regulation; for high-risk systems under the EU AI Act, specific requirements apply.

The common thread

A.6 comes down to one requirement: that the life cycle of your AI systems consists of defined steps with evidence, rather than the good habits of your best developers. The internal audit module of the Secure Audit platform contains, for each A.6 control, the criterion, the interview questions an auditor asks, an example of a good implementation and the documents you want to have ready. It lets you test your own life cycle before the certification body does. Get in touch for a no-obligation conversation.