ISO 42001 Annex A.9.2: Define Processes for Responsible AI Use
ISO 42001 control A.9.2 concerns defining and documenting processes for responsible use of AI systems. It applies to the organisation's decisions about use, whether the technology is developed internally or obtained externally. A list of approved products is helpful only if people also understand which purposes and conditions are permitted.
What control A.9.2 requires in practice
Control A.9.2 asks the organisation to define and document the processes for using AI systems responsibly. It applies whether the system was built in house or obtained from a supplier. The word processes signals something repeatable: a way of proposing a use, assessing it, authorising it and supporting it. Annex B guidance gives example considerations, namely required approvals, cost including ongoing monitoring and maintenance, approved ways of sourcing, and legal requirements that apply to the organisation. It also allows existing policies for other systems and assets to be reused where they fit. The standard prescribes no particular workflow or form. The outputs are the documented process, evidence of it being followed for real requests and records of conditions attached to approved uses.
Connect proposal, decision and operation
Annex B.9.2 considers relevant approvals, sourcing, costs including ongoing work, and applicable requirements. It allows existing organisational policies to contribute. The guidance must be considered under clause 6.1.3(e), while B.1 permits implementation suited to the organisation.
A practical use process explains how a proposed activity is described, assessed, authorised and supported. It should also handle changes and exceptions. The exact workflow is an implementation choice, but its decisions need to remain understandable to the people doing the work.
Why control A.9.2 matters to the business
Without a use process, adoption happens through side doors. A team starts with a free tool, colleagues begin to rely on it and the business is soon exposed through a decision nobody reviewed. A clear route lets people ask for what they need, receive a timely answer and understand the conditions. It also protects client relationships, because the organisation can explain why a requested use was approved, limited or declined. Auditors check whether the process distinguishes access to a product from approval of a purpose, and whether real requests, including unusual client demands, were routed through it.
How to implement control A.9.2
Make the route easy enough that people prefer it to the workaround. Keep the process proportionate to the consequence of the use, with a light route for low-impact tasks and deeper review for decisions that affect people, so that the approval effort goes where the risk actually sits.
- Describe how a person proposes an AI use: the task, users, information involved and role of the output.
- Decide who assesses it, including security, privacy, quality, legal and the business owner, and what each looks at.
- Define the possible decisions, such as approve with conditions, pilot, decline or escalate, and who may make them.
- Include running costs, review effort, monitoring and support in the decision, not just the initial price.
- Link the process to procurement, change control and acceptable-use rules so there is one route, not several.
- Publish a short guide for staff covering when to use the process and who to ask when unsure.
- Review informal adoption periodically and bring discovered uses into the process.
Illustrative BPO example: a client request changes the purpose
A BPO client asks employees to use an approved AI summariser to recommend responses to disputed claims. The tool is already licensed, so the supervisor assumes the request can begin immediately.
The responsible-use process distinguishes product access from approval of a particular use. It routes the changed purpose to the appropriate assessment and decision-makers and clarifies the response to the client while that work occurs. A purchasing approval alone does not establish that the new consequence was considered.
Illustrative construction example: an informal tool becomes a team process
A project planner uses an external AI tool to organise personal notes. Colleagues begin sending it project correspondence and relying on its summaries in coordination meetings. What began as individual experimentation has become an organisational activity.
The process should make that transition visible and provide a usable route for assessment and authorised conditions. If the only option is a lengthy form no one understands, informal adoption may continue outside the system. A practical route can preserve scrutiny while fitting actual work.
Consider the full cost of the use
Ongoing review, monitoring, maintenance and support can require resources beyond the initial subscription. Identify who provides them before describing the use as approved and sustainable. A control dependent on specialist review cannot operate simply because the tool is inexpensive.
Connect with AIMS resources and the supplier process. A supplier may operate the technology while the organisation remains responsible for how outputs enter its business decisions.
Reuse existing processes carefully
Procurement, change management and acceptable-use arrangements can provide a foundation. Examine whether they address AI purpose, relevant impacts and output reliance. Existing security approval may be necessary but insufficient for the wider use decision.
Document the relationships rather than create a parallel route that contradicts normal work. Staff should know when to use the process and which authority can resolve an uncertain case. Connect approved use with the system's intended uses and documentation.
Evidence and common weaknesses
The control calls for a defined and documented process. Evidence of implementation can follow an actual request through assessment, approval, operating conditions and later change. Test whether an unusual client demand or a new team use reaches the correct decision route.
Common failures include equating a licence with approval, assessing only initial purchase and ignoring ongoing resources. Another is making policy so vague that employees cannot distinguish a permitted use from an extension needing review. A process should help responsible action, not merely create a record after the decision has already been made.
Frequently asked questions
Is a list of approved tools enough?
Not necessarily. The same tool can support different purposes with different consequences. Define the relevant use conditions and decision route.
Does the process apply to internally developed systems?
Yes, where relevant to the organisation's use. Internal development does not remove the need for authorised operating decisions.
Can procurement perform the whole use assessment?
Procurement can contribute, but suitable technical, domain and affected-party knowledge may also be needed. Assign responsibilities according to the actual decision.
Make the approval route fit an actual AI use
Discuss an AI-use request or informal adoption pattern with Sterling. Scoped implementation can connect assessment, documentation and Effivity ISO & GRC automation software. ISO/IEC 42001 Awareness helps staff recognise the route. See the use controls and the full library.