8.1 A.6 AI System Life Cycle — Design, Development, Verification

8.1 A.6 AI System Life Cycle — Design, Development, Verification

Auditor focus: Annex A.6 (AI system life cycle) asks whether the organization governs AI systems as managed products across their life—not as one-off data-science experiments. In this section you audit the front half: life cycle framework, requirements, design, development, and verification/validation. Deployment and logging follow in 8.2.

---

Control objective of A.6 (life cycle)

The A.6 control objective is to ensure AI systems are developed, verified, validated, deployed, operated, and retired under defined processes that manage AI-specific risks (data dependence, non-determinism, drift, human-oversight failure, opaque change). A.6 implements Clause 8 operational control and Clause 6 risk treatment for the system engineering path. It complements A.5 (impact assessment), A.7 (data for AI), and A.8–A.10 (transparency, use, third parties).

A.6 is the largest objective in Annex A with nine controls, split across two subclauses: A.6.1 Management guidance for AI system development (two controls) and A.6.2 AI system life cycle (seven controls).

Numbering warning. Annex A subclauses ending in .1 are objective statements, not controls. There is no A.6.1.1, no A.6.2.1, and no A.6.2.9 — controls start at .2. Third-party summaries routinely invent them, and exam items quote real IDs, so a fabricated number costs the mark. Note also that verification and validation are a single control (A.6.2.4), not two, and that retirement / decommissioning has no dedicated Annex A control (see Section 8.2).

Organizations may map stages to ISO/IEC 5338:2023 AI system life cycle processes or to internal MLOps/SDLC. Auditors do not mandate a brand name; they test defined stages, entry/exit criteria, roles, and records.

---

Development objectives and life cycle framework (A.6.1.2–A.6.1.3)

Strong evidence: approved AI life cycle procedure or standard; stage gates (concept → design → build → V&V → release → operate → retire); RACI for product, ML, risk, security, legal; inventory linking each in-scope system to its current stage; exceptions managed and time-bound.

Weak evidence: “We use Agile/Scrum”; a generic software SDLC with no AI gates (evaluation data freeze, fairness tests, impact assessment completion, model card); shadow models in production outside the framework.

Sampling: Select 2–4 systems (prefer high residual risk from risk/impact assessments). Confirm each is assigned a stage, owner, and gate history. One production system with no lifecycle record is stronger negative evidence than a perfect template never applied.

---

AI system requirements and specification (A.6.2.2)

Before design and training become uncontrolled science projects, the organization should specify:

• Intended purpose and operational context (users, environment, decision type).
• Boundaries and prohibited uses (out-of-scope tasks the model must not drive).
• Performance and quality criteria (metrics, thresholds, acceptance bands).
• Constraints (latency, cost, privacy, human-in-the-loop requirements, regulatory class if claimed).
• Links to Clause 6.1 risks and Clause 6.1.4 / A.5 impact assessment conclusions where applicable.

Auditor probe: For one high-risk system, obtain the requirements baseline used at last major release. Trace one claimed metric (e.g., false-negative rate) through design decision → test plan → result. Broken chain = nonconformity against life cycle control, even if a model exists.

---

Design and development documentation (A.6.2.3)

Design choices (A.6.2.3, driven by the A.6.1.3 process)

Design should incorporate responsible AI by design: safety and robustness choices, fairness considerations, privacy-preserving architecture, explainability proportionate to risk, and human oversight design (when humans must confirm, override, or monitor).

Look for documented design choices and trade-offs—not only neural architecture diagrams. Examples: why a two-stage model with human review for low-confidence scores; why certain features were excluded as proxies; fallback to rule-based or manual path; rate limits and abuse controls for generative systems.

Development records (A.6.2.3)

Development controls typically include:

• Source and model version control (code, configs, weights or registry IDs).
• Reproducible training pipelines (environment, seeds, data snapshot IDs).
• Secure development practices (secrets, dependency management, access to training infra).
• Peer review / change control for model-affecting changes.
• Segregation of duties: developers do not solely approve their own production release (links A.3.2 roles and responsibilities with the A.6.2.4 verification and A.6.2.5 deployment gates).

---

Verification and validation (A.6.2.4)

Proportionate depth: High-impact decisioning systems warrant adversarial/OOD stress tests, slice performance, regression vs prior model, and documented residual risks. Low-risk internal classifiers need less ceremony but still need defined criteria and retained results.

Human oversight design evidence: acceptance tests that exercise override paths; UI/workflow showing human responsibility; criteria for when automation may not decide alone. Oversight that exists only as a policy sentence without design or test fails both A.6 design and later operational controls.

---

Documentation of design choices

Auditors need attributable records: model cards or equivalent technical docs; design reviews; decision records for fairness/safety trade-offs; linkage from impact assessment to design mitigations. Documentation need not be verbose marketing—it must allow reconstruction of what was decided, why, and against which requirements.

Cross-control: Incomplete design docs often cascade into A.8 transparency gaps and weak Clause 7.5 documented information. Raise the primary finding where the requirement fails most clearly (usually A.6 life cycle + SoA implementation description).

---

Auditor sampling playbook (front-half A.6)

1. SoA — Confirm A.6 controls applicable; read implementation description.
2. Inventory + risk tier — Sample high-risk first.
3. Requirements — Intended use, metrics, prohibited uses.
4. Traceability matrix (or reconstruct one): requirement → design → code/model version → test case → result → release approval.
5. V&V package — Test plan, datasets used (IDs), results, sign-offs, independence of validation where claimed.
6. Human oversight — Designed, tested, not only promised.
7. Exceptions — Hotfixes that skipped gates; how compensated.

Scenario: Hiring-screen model in production. Product brief says “assist recruiters.” Actual workflow auto-rejects below threshold with no human review. Impact assessment assumed assistive use. Finding path: requirements and intended-use mismatch (A.6.2.2), design documentation and oversight (A.6.2.3), validation against real use (A.6.2.4), and likely A.5 / 6.1.4 impact assessment not updated. Prefer multi-control analysis; severity driven by harm potential.

Exam trap: Confusing verification with validation, or accepting “we use GitHub” as a complete life cycle framework. Another trap: treating A.6 as optional “best practice” when the SoA includes it—normative Annex A controls selected in the SoA must be implemented and auditable.