7.1 Control Objective A.6: AI System Life Cycle
Key Takeaways
A.6 has nine controls in two subgroups, not seven controls in a flat A.6.1–A.6.7 sequence.
A.6.1.2 and A.6.1.3 address objectives and processes for responsible development.
A.6.2.2–A.6.2.8 cover requirements, design documentation, verification and validation, deployment, operation, technical documentation, and event logs.
The controls specify outcomes and documentation; canary releases, model cards, red teams, and independent sign-off are examples rather than universal mandates.
Lifecycle thinking includes post-deployment validation, re-evaluation, and retirement, even though the Annex A control structure is not itself a list of lifecycle stages.
Annex A.6: AI system life cycle
A.6 is the largest Annex A group, with nine controls. It has two nested subgroups, which is why its numbering looks different. A flat list called A.6.1 through A.6.7 is incorrect and omits important controls.
A.6.1 Management guidance for development
The first subgroup ensures the organization identifies objectives and implements processes for responsible design and development.
A.6.1.2 Objectives for responsible development
The organization identifies and documents objectives that guide responsible development and integrates measures to achieve them into the development lifecycle.
Objectives can address safety, security, privacy, fairness, transparency, robustness, maintainability, accessibility, or other context-relevant outcomes. The standard does not prescribe one fixed list or metric.
A.6.1.3 Processes for responsible design and development
The organization defines and documents specific processes for responsible AI system design and development.
Processes can include requirements management, data work, design review, coding, configuration, verification, validation, impact assessment, change control, and approval. Exact activities depend on whether the organization develops a model, integrates components, fine-tunes a service, or supplies a complete system.
A.6.2 AI system life cycle
The second subgroup defines criteria and requirements for lifecycle stages.
A.6.2.2 Requirements and specification
The organization specifies and documents requirements for new AI systems or material enhancements to existing systems.
Requirements can include purpose, intended use, users, inputs and outputs, performance, interfaces, constraints, applicable obligations, human interaction, safety, security, privacy, data, monitoring, and retirement. “Material enhancement” matters: a significant change should not bypass requirements merely because a system already exists.
A.6.2.3 Documentation of design and development
The organization documents AI system design and development based on organizational objectives, documented requirements, and specification criteria.
Useful documentation can cover architecture, components, decisions, data flows, dependencies, limitations, and traceability. The control does not universally require one model-card format or public source code.
A.6.2.4 Verification and validation
The organization defines and documents verification and validation measures and specifies criteria for their use.
Verification checks conformance to specified requirements. Validation checks suitability for intended use or application. Measures can include functional testing, performance evaluation, subgroup analysis, robustness tests, domain review, security testing, usability work, or field evaluation.
Independent review can reduce conflicts in high-consequence contexts, but this control does not state that all testing must be performed by a team completely separate from developers. Objectivity, competence, risk, and applicable requirements inform the design.
A.6.2.5 Deployment
The organization documents a deployment plan and ensures appropriate requirements are met before deployment.
A plan can cover readiness criteria, approvals, configuration, training, data migration, user communication, rollback, monitoring, and handover. Canary, shadow, or blue-green release can be useful techniques; none is universally mandated.
A.6.2.6 Operation and monitoring
The organization defines and documents elements needed for ongoing operation. At minimum, the control points to system and performance monitoring, repairs, updates, and support.
Monitoring should follow requirements and risks. It can include service health, prediction performance, data shifts, incidents, complaints, overrides, or impact indicators. A model can remain stable; drift is a possibility to monitor, not an inevitable law.
A.6.2.7 Technical documentation
The organization determines technical documentation needed for relevant categories of interested parties and provides it in an appropriate form.
Auditors, users, partners, customers, and supervisory authorities can need different information. The control is not limited to “internal” documentation. Appropriate form can reflect technical literacy, confidentiality, accessibility, and applicable reporting duties.
A.6.2.8 Event logs
The organization determines lifecycle phases at which event-log record keeping should be enabled, at minimum while the AI system is in use.
Log content depends on purpose and risk. It can cover versions, events, user actions, inputs or derived references, outputs, errors, overrides, changes, and security events, subject to privacy, retention, and security constraints. Logging every raw input forever is not automatically appropriate.
Lifecycle versus control numbering
The A.6 controls are governance controls, not an eight-stage lifecycle list. For broader process thinking, ISO/IEC 5338 includes inception, design and development, verification and validation, deployment, operation and monitoring, continual validation, re-evaluation, and retirement.
A.6 supports those activities without assigning one control to each stage. For example, technical documentation and logging can span multiple stages.
Example traceability
A hospital develops a diagnostic-support model:
- responsible-development objectives include clinically appropriate performance and safe human interaction;
- processes define design, data review, validation, and change control;
- requirements identify intended use, clinician users, validated imaging conditions, and fallback;
- design documentation records components and data flows;
- V&V criteria include clinical and subgroup performance;
- deployment planning covers configuration, training, and rollback;
- operation defines monitoring, repair, update, and support;
- technical documentation is tailored to clinicians, IT staff, and regulators; and
- event logging supports traceability and incident review.
No one tool makes this compliant. The selected controls must work together and be justified in the SoA.
Memory map
A.6.1.2 objectives; A.6.1.3 processes; then A.6.2.2 requirements, .3 design documentation, .4 V&V, .5 deployment, .6 operation, .7 technical documentation, and .8 event logs.
Tip
If an option says “A.6.7 model cards” or omits event logging, it is using an inaccurate control map.
How many controls does A.6 contain?
Seven
Eight
Nine
Ten
Which control addresses recording event logs?
A.7.5
A.6.2.5
A.6.1.3
A.6.2.8
What does A.6.2.4 require?
Defined and documented verification and validation measures with criteria for use
A specific red-team vendor
Blue-green deployment for all systems
Public release of test datasets
Sections you finish are checked off in the contents.