ISO 42001 AI Life-Cycle Controls: Connect Direction, Delivery and Use

Choose the life-cycle view that matches your role

An organisation may develop a complete system, integrate an external model, configure a purchased application or use a supplier's service. Its role affects the decisions it can make and the evidence it needs from others. A customer cannot simply manufacture missing supplier evaluation evidence, while a developer cannot assume that a customer's operating context is identical to its own test environment.

Map the relevant activities and interfaces before choosing detailed controls. Include where requirements are established, how data and components are obtained, who evaluates the system, who approves deployment and who owns operation and change. If an activity sits outside the organisation, identify the relationship and information needed to govern the dependency. Outsourcing changes the interface; it does not make the dependency disappear.

Use the map to identify important transitions. Evidence may be lost when a project moves into service, when a supplier releases a new version or when a system is adopted for another purpose. These transitions are often where assumptions become invisible. The life-cycle view should make them explicit enough for the next decision-maker to assess.

Keep direction distinct from delivery evidence

The management group contains objectives for responsible development and processes for responsible design and development. Objectives establish what responsible development should achieve in context. Processes establish how the work will be organised so that those objectives can influence requirements, evaluation and decisions.

The delivery group contains requirements and specification, design documentation, verification and validation, deployment, operation and monitoring, technical documentation and event logs. Each supplies a different part of the evidence chain. A strong statement of objectives does not replace representative evaluation; a successful test does not establish that the organisation has defined an acceptable intended use.

Keep these distinctions when reviewing readiness. Ask whether objectives have influenced the requirements and whether evaluation can test those requirements in the relevant context. Where a result is outside an agreed condition, determine how the operating process will recognise and respond to it. This creates a traceable relationship without demanding that every decision be copied into every document.

Illustrative software example: an external model in a new service

A software business builds a document-analysis service using an externally supplied model. The supplier reports useful general capabilities, but the software business intends to use it for a narrower customer workflow with particular document types and consequences of error. The business begins by defining the purpose and responsible-development objectives for that workflow, including how users should understand and review the output.

Requirements then identify what the service must do and under what conditions. Design decisions explain the selected components and how information moves through them. Evaluation uses cases relevant to the intended workflow rather than relying only on a public benchmark. Deployment arrangements identify approval, operating information and how the service can be supported. The supplier's evidence contributes, but the business evaluates its relevance to the integrated service.

After launch, a supplier update changes behaviour on a document category. The operational owner can trace the affected assumptions, evaluation evidence and customer information. The change is assessed through the organisation's established processes. This connection matters more than whether the original project used a particular delivery framework: the organisation can understand what changed and decide what evidence is needed next.

Illustrative construction example: moving an AI tool between projects

A construction consultancy uses an AI tool to help review project documentation for possible inconsistencies. An initial project establishes a limited use with qualified reviewers. Another project team wants to use the same tool across different document structures and contractual arrangements. Reusing the software does not automatically mean that the original use assumptions still hold.

The organisation compares the new purpose, inputs, review responsibilities and consequences of missed or misleading indications. It determines what requirements and evaluation need updating before the new deployment. Technical and user information explains the limits and the role of competent review. The tool supports a defined workflow; it does not provide independent assurance that designs or contractual documents are acceptable.

During operation, reviewers report recurring limitations. Those observations feed back into requirements, evaluation and the decision about continued use. This closes the life-cycle loop. A purely project-centred approach might treat release as the end of governance and leave the receiving team with no effective route to influence the system.

Make evidence travel across handovers

A handover should give the receiving owner enough information to operate within the evaluated conditions and identify relevant change. Useful information may include intended use, limitations, significant dependencies, evaluation results, unresolved issues, responsibilities and support arrangements. The exact package should match the system and recipient; a large technical archive is not automatically a usable operational handover.

Different recipients need different views. A developer may need detailed design and test information. A service owner may need operating assumptions and response arrangements. A user may need clear instructions and limitations. A customer may need agreed information about its responsibilities. Connect technical documentation with user information rather than sending every audience the same material.

Event logs can contribute evidence about what happened, but they are only useful when the relevant events, context, access and retention have been considered. More logging is not automatically better governance. Link logging decisions to operational needs and applicable obligations, avoiding uncontrolled collection of sensitive information merely because storage is available.

Treat change as a new decision about existing assumptions

AI systems can change through models, data, configuration, components, operating conditions or intended use. Not every change has the same significance. Define how people identify changes that may affect risk, impacts, requirements or evaluation validity. Then connect them to appropriate reassessment, treatment and approval processes.

Change control should be able to respond to evidence from operation. A decline in performance, a new concern or an unexpected use may show that an assumption is no longer reliable even if no code changed. Conversely, a minor technical change may not require repeating every previous activity. The decision should be justified by its relevance, rather than by an automatic all-or-nothing rule.

Use the management-system processes in clause 8 and clause 9 to connect operational control, assessment and performance evaluation. Annex A.6 is part of that wider system, not a separate development certification scheme.

Common gaps in an apparently mature life cycle

Frequent gaps include requirements that cannot be evaluated, evaluations disconnected from intended use, release approval without an operational owner and monitoring that produces metrics nobody can act on. Another is assuming that a third-party component carries all the assurance needed for the completed system. An integration can introduce new effects and dependencies even when the component itself is well documented.

A practical review follows one important requirement from its origin through design, evaluation, deployment and operation. Then follow one operational issue backwards to the people who can change the system. These two paths reveal whether the life cycle works as a connected process. They are suggested review methods, not additional mandatory ISO records.

Individual controls in this theme

Why connected life-cycle control matters for AI

Most AI problems that surface in operation began as small gaps earlier on: a requirement that was vague, a design reason nobody wrote down, a test that did not resemble real use, a release approved without checking the destination. The controls in this theme join the stages together so that each decision carries forward the reasons and evidence behind it. The business benefit is fewer surprises after release, less rework and a team that can explain why a system behaves as it does. It also helps when responsibilities are split across suppliers, customers and internal groups, because each can see what the next party needs. For an auditor, it shows whether the organisation manages AI as a continuous activity with owned decisions, or as a series of projects that end at delivery.