ISO 42001 Clause 4.4: Connect the Processes of the AIMS
ISO 42001 clause 4.4 requires the organisation to establish, implement, maintain, improve and document its AI management system, including the necessary processes and their interactions. It asks for a functioning system. A policy, risk register and audit plan can each look reasonable while leaving the decisions between them unresolved.
What clause 4.4 requires in practice
Clause 4.4 is short but carries the idea of the whole standard. The organisation must set up, run, maintain and document an AI management system, and keep improving it. That system includes the processes it needs and the interactions between them, built in line with the standard's requirements.
Each verb matters. Establishing and implementing means the arrangements exist and are used. Maintaining and continually improving means they stay current and get better as evidence arrives. Documenting means the system, including its processes and their interactions, can be understood by others. The standard does not prescribe a manual, a number of procedures or a software platform. What it expects is a connected system in which context, requirements, planning, operation, evaluation and improvement feed each other, rather than a set of unrelated policies. The word interactions is the test: information and decisions must travel between processes without losing their conditions.
Follow the hand-offs
A practical way to design the system is to follow a proposed AI use. Someone describes its purpose, relevant people contribute context, assessments inform treatment, authorised management approves decisions, and operating teams receive conditions they can apply. Monitoring and concerns then feed reassessment, review and improvement. This is an illustrative decision path, not a prescribed sequence of forms.
For each hand-off, identify what information the next person needs and what happens if it is incomplete. A process owner who receives only a final approval status may not know about an important supplier limitation. The interaction needs to preserve the decision's conditions as well as its outcome.
Why a connected system matters to the business
Many organisations hold sound individual documents, such as a policy, a risk register and an audit plan, yet still approve AI uses carelessly because nothing links them. A connected system means an approval granted for one purpose carries its conditions to the teams who implement it, supplier changes reach the people who assess them, and audit findings return to planning. The business gains faster, more confident decisions and fewer incidents that arise from gaps between teams. It also gains audit resilience, since auditors follow decisions across processes and find consistent evidence. Finally, an integrated system can reuse existing quality, security or procurement arrangements instead of creating a costly parallel bureaucracy.
How to implement clause 4.4
Design the system around the path a proposed AI use takes through the business. Sterling teams often begin by mapping that path on one real case and then generalising.
- Pick a recent proposal for an AI use and list each hand-off, from request through assessment, approval, operation and review.
- For every hand-off, record what information the next person needs, including the conditions attached to any approval.
- Check which existing processes, such as procurement, release management or information security, can carry these hand-offs, and reuse them where suitable.
- Write concise process descriptions that show owners, inputs, outputs and links, in a format your people will actually read.
- Test an exception, such as an absent reviewer or a late supplier notice, and repair the route if no authorised response appears.
- Assign responsibility for maintaining the system and feed monitoring results and audit findings back into the descriptions, so that the documented system keeps pace with what people really do.
- Confirm with a short walkthrough that a new colleague could follow the route without help from the original designer.
Evidence an auditor expects for clause 4.4
An auditor wants to see that the system exists on paper and in practice, and that its parts connect.
- Process descriptions or equivalent documented information that show the needed processes and how they interact.
- Decision records for real AI uses showing assessment, approval and the conditions passed to operating teams.
- Interviews with process owners who can explain how their work receives and passes on information.
- Observation of how a supplier notice, concern or change is routed to someone with authority.
- Evidence that findings from monitoring or audit changed the arrangements.
No specific manual title is required.
Common nonconformities with clause 4.4
Findings against this clause usually describe a system that exists in pieces.
- Processes are documented but nobody follows them, and real approvals happen informally by message.
- The management system sits beside product and procurement work, so new AI features reach customers without passing through it.
- Approval records show only a status such as approved, with the assumptions and conditions missing.
- All interactions depend on one overloaded coordinator, and the system stops working when that person is absent or leaves, because no deputy or alternative route has been defined.
Illustrative software example: an approval loses its conditions
A software company approves an AI writing assistant for internal support notes. The assessment assumes that a knowledgeable employee checks technical statements before use. Product development later embeds the feature in a customer portal but sees only “approved” in the project record.
The problem is an interaction failure between governance and release management. The company improves how approved purpose and operating conditions reach product teams, and how proposed extensions return for assessment. Adding a second policy without changing that hand-off would leave the same failure path open.
Illustrative construction example: supplier change reaches the wrong team
A construction consultancy receives a notice that its planning tool has changed how missing subcontractor data is estimated. Procurement files the notice; project planners continue treating estimates as confirmed dates. The AIMS needs an interaction that routes relevant supplier information to the people who assess its effect and update operating instructions.
A suggested improvement assigns responsibility for reviewing notices and identifies which changes need project-owner attention. It also checks that revised instructions are understood. This connects the externally provided service with internal assessment, communication and monitoring rather than assuming that document storage is enough.
Document what makes the system understandable
The requirement expressly includes documenting the AIMS, its processes and interactions. The format is not prescribed. A concise process description with linked responsibilities and records may be sufficient for a simple activity; a complex portfolio may need more detail. Existing quality, security or procurement arrangements can be used where they meet the relevant needs.
Useful documentation distinguishes a process rule from evidence that it operated. An approval procedure explains how decisions should be made. An actual decision record shows what was considered and authorised in a particular case. Both should remain connected with current operating arrangements.
Test the system through an exception
After following an ordinary use, examine an exception: a supplier gives insufficient information, a reviewer is absent, or a significant limitation appears after launch. Can the organisation obtain an authorised response? Can the people affected find the changed conditions? These original tests reveal whether the interactions work under pressure.
Common mistakes include creating an AIMS that sits outside normal product and procurement processes, assigning every interaction to one overloaded coordinator, and treating certification preparation as the system's only purpose. Software can support agreed arrangements but cannot supply missing judgement or authority.
Use operational planning and control to examine daily application and internal audit to follow evidence across these interactions.
Frequently asked questions
Does ISO 42001 require an AIMS manual?
It requires a documented system, but not one universally prescribed manual title or format. Choose information that makes the processes and interactions clear.
Can existing management processes be reused?
Yes, where they address the AI requirements and actual activities. Check the content and interfaces rather than merely renaming existing documents.
How can we tell whether the processes connect?
Trace a real use and an exception from initial request through decisions and later evidence. Look for missing information, unclear responsibility or conditions lost at hand-offs.
Design a system around the decisions that matter
Ask Sterling to map one AI decision across your existing processes. Scoped implementation can include documentation, audit preparation and Effivity ISO & GRC automation software. ISO/IEC 42001 Awareness helps process owners understand the wider system. Independent bodies decide certification. See clause 4 and the requirements hub.