Are You an AI Provider or an AI User? ISO/IEC 42001 Roles Explained
ISO/IEC 42001 requires you to determine your role, and that role decides which Annex A controls apply. How to tell whether you are an AI provider, producer, customer or user.

“We only use AI, we do not build it, so ISO/IEC 42001 is not really about us.” We hear this in audits often enough that it is worth answering properly. It is a reasonable assumption and it is wrong, and the standard settles the question in a single sentence.
The requirement people miss
ISO/IEC 42001 Clause 4.1 says this:
“The organization shall consider the intended purpose of the AI systems that are developed, provided or used by the organization. The organization shall determine its roles with respect to these AI systems.“
That is a shall. Determining your role is not preparatory thinking, it is a requirement in its own right, and an auditor can raise a finding if you cannot show you have done it.
The note underneath explains why it matters so much:
“The organization’s roles can determine the applicability and extent of applicability of the requirements and controls in this document.”
Your role decides which controls you must implement. It is the input to your Statement of Applicability. Get it wrong and every inclusion and exclusion downstream is built on a wrong premise, which is a far more awkward finding than a missing document.
The six roles
ISO/IEC 42001 does not define the roles itself. It points to ISO/IEC 22989:2022 clause 5.19, which sets out six, each with sub-roles.
- AI provider. You supply a product or service that uses AI to someone else. This includes running a platform other people build their AI on.
- AI producer. You design, develop, train, test or deploy AI systems. This is the builder.
- AI customer. You use an AI product or service, either directly or by making it available to your own users. AI user is the sub-role, and it is where most organisations sit.
- AI partner. You provide a service around someone else’s AI: integrating it, supplying data for it, evaluating it or auditing it.
- AI subject. You are affected by an AI system rather than operating it. In practice this is usually your staff and your customers, not your organisation.
- Relevant authority. You set or enforce policy or law. Regulators and policy makers.
Three questions that usually settle it
1. Did you make the model, or did someone else?
If someone else trained it and you subscribe to it, you are not an AI producer for that system. Their obligations for model design, training data and base model bias testing do not transfer to you by procurement.
But note the boundary carefully. Fine-tuning a model on your own data, building an agent, or assembling a retrieval system around a model does make you a producer. The line is not “did we write the model from scratch”, it is “did we make design decisions that shape its behaviour”.
2. Does anyone outside your organisation use the AI capability you put in front of them?
If your customers interact with AI you have deployed, you are an AI provider to them, whoever built the underlying model. That brings obligations to tell them what it does and what its limits are, and to give them a route to report problems.
Using AI purely internally does not make you a provider. Shipping it does.
3. Do decisions involving AI affect people?
If AI scores, screens, ranks or routes a person, those people are AI subjects. They are not a role your organisation holds, but their presence switches on the impact assessment controls, and those are not optional once a person is in scope.
Most organisations hold more than one role
ISO/IEC 22989 says so explicitly: an organisation can take on more than one role or sub-role. This is the norm, not an edge case.
A company that uses an AI assistant internally, has switched on an AI feature in its HR system, and ships an AI-supported feature to its own customers is an AI customer, an AI user and an AI provider all at once, and quite possibly an AI producer as well. Those obligations add together. They do not cancel out, and you cannot pick the most convenient one.
The case that comes up most: you only use AI
Your staff use a general assistant. Your CRM has added AI scoring. Your developers use a coding assistant. You built none of it.
You are an AI customer, and your staff are AI users. That is a real role with real obligations, and the standard has a section written for it. Annex A.9 is titled “Use of AI systems”, and its objective is to ensure the organisation uses AI systems responsibly and in line with its own policies.
Three controls sit under it:
- A.9.2, processes for responsible use
- A.9.3, objectives for responsible use
- A.9.4, ensuring the system is used according to its intended use and its accompanying documentation
A.9.4 is the one organisations find hardest, because it cannot be delegated to the vendor. You have to be able to show what the provider said the tool was for, and that you checked your use against it. If you are using a summarisation feature to make decisions about people, you have gone beyond intended use, and that is yours to answer for.
Alongside those, A.10.3 covers your suppliers and A.10.2 requires responsibilities across the AI life cycle to be allocated between you, your partners, your suppliers, your customers and third parties. Not internally. Between organisations, in writing.
What an auditor will ask for
- A written statement of the roles you hold, per AI system in scope, with the reasoning behind each
- A Statement of Applicability whose inclusions and exclusions are justified by reference to those roles, rather than by convenience
- Evidence under A.10.2 that responsibilities are allocated with the parties either side of you
- For anything you only use: the vendor’s documented intended use, and your own check that your use matches
The organisations that handle this well are not the ones with the most documentation. They are the ones that can say plainly what they are, what they are not, and who holds what.
Work out your own role
We built a free tool that walks through this. Answer six questions about what your organisation actually does and it will show you the roles you hold, the Annex A controls that follow, and a shared responsibility matrix for the AI tools you use, including general assistants, workplace assistants, coding assistants and AI features inside SaaS products.
Nothing is submitted anywhere. It runs entirely in your browser.
Written by Asma Khan, Quality Assurance and Compliance Manager, and Mehar un Nisa, Head of Middle East, at Cianaa Technologies.
Cianaa conducts ISO/IEC 42001 audits across New Zealand, Australia and the wider Asia Pacific region as an independent certification body. If you are scoping an AI management system and want to check your role determination before it reaches an audit, a pre-audit is the sensible first step.
Talk to Cianaa Technologies
ISO 42001 readiness and AI risk assessments aligned to the EU AI Act and emerging Australian guidance.
Book a discovery callGet the next one in your inbox
One email when we publish. Written by named auditors, never by a marketing robot. Unsubscribe anytime with one click.



