Model lifecycle governance under ISO 42001

Phase 1: Data Sourcing and the Risk of Poor Foundations

Governance begins long before the first line of training code is written. In the context of ISO 42001, the data sourcing phase is the most critical point for risk injection. If your training data is poisoned, stale, or legally precarious, the model it produces is a liability regardless of how sophisticated your architecture is. You must establish a formal verification process for dataset selection that aligns with your organisational risk appetite.

I often see firms treat data prep as a purely technical task for data scientists, yet ISO 42001 demands accountability. This means creating a 'Data Manifest' for every model. This document should detail the lineage of the data, any transformations applied, and a justification for why this specific dataset is appropriate for the intended use case. This isn't just about privacy; it is about ensuring the model's output is reliable and representative.

• Documented data provenance: Where did the set come from?
• Bias assessment: Quantitative checks for historical imbalances in the data.
• Legal basis for processing: GDPR/UK GDPR compliance for training datasets.
• Pre-processing transparency: Documentation of cleaning, labelling, and augmentation.

Phase 2: Development, Training, and Verification

The development phase is where 'Shadow AI' often thrives, with developers experimenting locally without oversight. To comply with Clause 8 of ISO 42001, you must bring these activities into a controlled environment. This involves setting 'stage-gates' where a model cannot move from training to validation without meeting predefined performance and safety metrics. This is not about slowing people down, but about establishing a repeatable, defensible process.

Verification and validation (V&V) are the twin pillars here. Verification asks if you built the model correctly (e.g., does the code run as expected?), while validation asks if you built the right model (e.g., does it solve the problem safely?). In an ISO 42001 audit, you will be expected to show the test results that justify your decision to move a model into production. If you cannot produce a test report, you do not have a governed model.

• Design Specification: Documenting the choice of architecture (e.g., Transformer, CNN).
• Validation Split: Clear separation of training, validation, and test sets.
• Hyperparameter Logging: Recording the configurations that led to the best-performing version.
• Bias Mitigation: Active testing for disparate impact during the training runs.

Phase 3: Deployment and the Transparency Requirement

Deployment is the moment of greatest risk transition. Under ISO 42001, moving a model to production requires more than a CI/CD pipeline; it requires a formal handover. This handover should include a 'Model Card' or a transparency report that summarizes the model's intent, performance limits, and known weaknesses. This ensures that the operations team actually understands what they are supporting and what the 'guardrails' look like.

You must also consider the system context. A model does not exist in a vacuum; it is part of an AI System (the 'S' in AIMS). This means governing the inputs, the API wrappers, and the human interfaces. If your model is being used to make decisions about people—such as in recruitment or lending—your deployment phase must include a human-in-the-loop (HITL) review process to meet ethical and regulatory expectations.

• Risk-based deployment: Canary releases or A/B testing as a standard.
• Environment isolation: Ensuring the production AI environment is distinct from training.
• User guidance: Providing clear documentation on how the model should be interacted with.
• System Integration: Testing how the AI interacts with existing legacy software.

Phase 4: Continuous Monitoring and Drift Management

The 'set and forget' mentality is the enemy of ISO 42001 compliance. AI models are dynamic; they degrade as the world changes, a phenomenon known as model drift. Your management system must include a robust monitoring framework that tracks performance in real-time. This isn't just about 'uptime'—it is about 'predictive accuracy' and 'safety thresholds'. If accuracy drops by more than a defined percentage, it should trigger an automatic investigation.

Feedback loops are equally vital. You need a mechanism for users to report 'hallucinations' or errors. In our practice, we recommend an AI-specific incident log. This allows you to differentiate between a standard IT outage and an AI failure. The latter requires a different response, often involving the data science team to determine if the model needs retuning or if the underlying data distribution has fundamentally shifted.

• Drift Detection: Automated alerts when input data changes significantly from training data.
• Log Retention: Keeping a history of inputs and outputs for forensic audit.
• Incident Response: A dedicated playbook for when an AI produces harmful or hallucinatory content.
• Periodic Re-evaluation: A scheduled deep-dive (e.g., every 6 months) into model efficacy.

Phase 5: Retirement and Decommissioning with Purpose

Most organisations forget the end of the lifecycle, but ISO 42001 does not. Decommissioning a model is as sensitive as deploying one. If you retire a model that was integrated into a larger business process without a proper transition plan, you create operational risk. You must document the 'Why' behind the retirement—whether it was due to obsolescence, cost, or a discovered safety flaw that could not be mitigated.

Finally, ensure that the removal of a model doesn't leave 'ghost' data behind. This involves a clean-up of associated datasets, API keys, and compute resources. From a GRC perspective, the goal is to close the loop. An archived model should be preserved in a state where it can be audited if a legal query arises regarding a decision it made three years ago. This 'forensic readiness' is a hallmark of a mature AIMS.

• Decommissioning triggers: Defining when a model is no longer fit for purpose.
• Data retention/deletion: How to handle the data used or generated by the retiring model.
• Transition planning: Ensuring users aren't left without an alternative when a model is pulled.
• Archiving: Saving weights and logs for 5-7 years for legal and regulatory evidence.

Frequently asked questions