Responsible use of AI systems: what Annex A.9 of ISO 42001 requires

Many organizations starting with ISO 42001 do not develop AI themselves. They buy functionality, deploy existing models or give staff access to generative tools. For those organizations, Annex A.9 is one of the most important parts of the standard. The domain covers the use of AI systems: who may work with them, for what purpose, within which boundaries, and how you ensure that practice stays within those boundaries. This article walks through the three controls of A.9, with the nonconformities we encounter most often as auditors and the documents a certification body will want to see.

What Annex A.9 covers

Annex A of ISO 42001 is organized into domains, from policy and internal organization to data and supplier relationships. The domain on use contains three controls. A.9.2 asks for defined and documented processes for the responsible use of AI systems. A.9.3 asks for objectives that give that responsible use direction. A.9.4 asks for assurance that each AI system is actually used for the purpose it is meant for, in line with its accompanying documentation.

As with the other Annex A controls, the risk assessment and the Statement of Applicability determine whether and how these controls apply. In practice they almost always do. An organization without AI use does not need an AIMS, and as soon as there is use, the question of boundaries and oversight becomes unavoidable.

A.9.2: processes for responsible use

The core of A.9.2 is that usage is not an open space. For each AI system in scope, the boundaries should be fixed: which type of decisions the system may support, where automation stops and a human takes over, and what happens in borderline cases.

Human oversight is the most visible element here. A workable approach ties the form of oversight to the risk of the decision. Decisions with major consequences get a human review up front. For medium risks, the system flags cases for review afterwards. For low risk, a periodic sample of the outcomes is enough. That classification has to be based on something, and this is exactly where the AI risk assessment from chapter 6 touches usage.

Oversight on paper is not enough. Auditors expect boundaries to be enforced technically where possible: thresholds below which an AI outcome automatically escalates to a human, input validation that recognizes requests outside the validated scope, and access management that prevents unauthorized use. Organizational measures complement this: training before someone gets access, usage guidelines that explain what is and is not allowed, and periodic reviews of usage patterns to detect misuse or out-of-scope application.

A.9.3: objectives you can measure

A.9.3 asks for objectives that steer responsible use. This is a control many organizations misjudge. "We use AI responsibly" is an intention, not an objective. An auditor looks for something testable.

Usable examples from practice: all users complete a responsible use training before they get access. A defined percentage of high-risk decisions receives a human review, and that percentage is met. Usage reviews of the main systems take place every quarter. Reports of improper use are investigated and resolved within an agreed timeframe.

The objectives should align with the AI policy, be communicated to the people who have to work with them, and be tracked with figures that come back in the management review. An objective that is never measured does not count in an audit. Objectives that only cover adoption or efficiency do not satisfy the control either: the point is the responsible side of the use.

A.9.4: use according to the intended purpose

A.9.4 closes the loop. Where A.9.2 covers the processes and A.9.3 the direction, A.9.4 is about whether each system is actually used for what it is meant for.

That starts with an intended use statement per AI system. It records which problem the system solves or which decision it supports, who the intended users are, in which context it runs, within which conditions it has been validated, which limitations are known and in which situations the system must not be used. That last part is forgotten most often and is exactly what an auditor finds informative: an organization that knows where its system becomes unreliable has thought the system through.

Next, the organization must be able to detect when usage steps outside that frame. Monitoring of usage patterns is the common instrument. And when a system gets a new application or is deployed in a different context, the intended use documentation should change with it, including a fresh look at the risks.

Anyone who sees a parallel with the EU AI Act sees it correctly. Article 26 of Regulation (EU) 2024/1689 obliges deployers of high-risk systems to use them in accordance with the instructions for use and to assign human oversight to people with the right competence. A.9 asks for comparable things, more broadly and without legal status, for all systems within your AIMS. Setting up A.9 well builds the foundation for those legal obligations.

The nonconformities auditors see most often

A number of patterns keep coming back in audits of this domain. Users work with AI systems without any guidance on intended use. Human oversight is in the policy but is performed nowhere, and nobody can produce review records or sampling results. Technical enforcement is completely absent, so systems can be used outside their validated scope without any barrier. Objectives are phrased so generally that there is nothing to measure, or they exist but are not tracked. And intended use documentation only exists for the systems the vendor happened to ship with a model card, not for the systems the organization composed or configured itself.

The common thread: the difference between writing down and doing. This domain is a place where an auditor tests operation, not design. Interview questions turn to concrete cases: show a decision that was escalated, show the latest usage review, show who was granted access last month and whether the training had been completed by then.

Which documents an auditor expects

For a certification audit or internal audit of this domain, a recognizable set of documents is needed: procedures for responsible use, intended use statements with boundary definitions per AI system, records of human oversight actually performed, configurations of the technical measures that enforce boundaries, the objectives with their measurements and progress reports, training records and the reports of usage reviews. If these are in place and demonstrably current, the core of this domain stands.

Our internal audit module has this guidance built in per control, with interview questions, common nonconformities and expected documents, so you can run an internal audit of A.9 before the certification body arrives. Want to know where you stand with ISO 42001? Feel free to contact us.