AAIA lesson 6: AI development lifecycle

An AI solution moves through requirements, design, development and training, testing and validation, deployment, operation and monitoring, and retirement, and each stage should produce a record that an auditor can examine. Unlike conventional software, an AI lifecycle loops: monitoring can send the system back to retraining or redesign. This lesson covers subtopic 2B, AI Solution Development Methodologies and Lifecycle. Supporting tasks add three angles: evaluate the lifecycle from design to decommissioning (inputs and outputs included) for compliance and risk, check that requirements fit the enterprise architecture, and check that algorithms and models stay aligned with business objectives, policies and procedures.

Stages and checkpoints

The figure pairs every stage with one question. Reading left to right:

Gates are the glue. A gate is a point at which a named person or body decides whether the work may proceed, based on defined criteria. The audit test is whether the gate has ever said no, or at least attached conditions. Gates whose approval is purely formal do not control risk.

MLOps in audit terms

MLOps applies engineering discipline to machine learning: versioned data and code, automated pipelines, a model registry, controlled promotion between environments and monitoring in production (see MLOps basics). For an auditor its value is evidence. A registry that records which dataset, code and parameters produced each model version, who approved promotion, and what the validation results were turns an assertion into something checkable. Without it, reproducing a model or explaining a past decision may be impossible.

Documentation and model cards

A model card is a short structured document describing a model: intended use, out-of-scope uses, training data summary, evaluation results including by group, known limitations and maintenance contacts. Related documents include data sheets for datasets and system documentation for technical readers. Their audit value is threefold: they force the builder to state intended use, they give deployers and oversight bodies what they need to use the system properly, and they provide a baseline for later change. For a purchased model, the equivalent is the provider’s documentation, which should be read critically and supplemented with the organisation’s own testing.

A card that is written once and never updated is a minor finding in itself, because it describes a version that no longer exists.

Worked example: a document-review assistant

A services firm of 250 people (a different organisation) builds an assistant that classifies incoming contracts by risk. A lifecycle audit reads as follows.

• Requirements. A one-line request in a ticket; no performance target. The auditor records that the system cannot later be shown to be “good enough”.
• Design. A hosted model is chosen, with no recorded alternatives and no assessment of the provider.
• Test. Developers tried 20 contracts and were satisfied. There is no agreed threshold or test set kept separate.
• Deploy. The developer who built it released it directly.
• Operate. Nobody reviews outputs, and no model card exists.

Individually each gap looks small. Together they mean no one can demonstrate that the system works, who authorised it, or when to stop relying on it. The recommendation is a proportionate set of gates: documented requirements with thresholds, a sample test with a held-out set, release authorisation separate from development, and a monitoring owner. A low-impact tool needs lighter gates than a credit model, but not none.

Easy to confuse

• Verification versus validation. Verification asks whether the system was built as specified; validation asks whether it meets the real need. Lesson 8 returns to this.
• Model card versus policy. A card describes one model; a policy governs all.
• Data sheet versus model card. A data sheet documents a dataset (motivation, composition, collection, recommended uses); a model card documents a trained model (intended use, evaluation, limits).

Key points

• Every lifecycle stage should leave a record, and the lifecycle loops back from monitoring.
• Gates matter only if they can say no or impose conditions.
• A model registry provides the traceability that makes evidence possible.
• Model cards state intended use, limitations and evaluation, and must be kept current.
• Retirement includes data and dependency handling, not only the shutdown.

Check yourself

The exam-focused summary is on the AI operations recap.