TL;DR
ISO/IEC 42001 does not hand you a role taxonomy for ISO 42001 roles.Clause 4.1 and Clause 4.3 tell you to determine your organization’s role in the AI ecosystem. The standard points you to ISO/IEC 22989 for the vocabulary: provider, producer, customer, partner, and subject. Most guides on this topic, including an earlier version of this one, collapse that into a borrowed “provider, operator, user” frame. Neither standard uses that frame, and it drops two roles that carry real Annex A duties.
- ISO/IEC 22989:2022 defines five AI ecosystem roles: provider, producer, customer, partner, and subject. Not three.
- Most organizations hold more than one role. A firm that builds a model and sells access to it is a producer and a provider at once.
- Annex A holds 38 controls across nine themes, A.2 through A.10. There is no Annex A.11.
- Your declared role decides which Annex A controls you can justify excluding. It does not decide which controls exist.
- The EU AI Act uses its own terms, provider and deployer. Mapping ISO’s roles onto them is a choice your organization makes.
Sources: ISO/IEC 42001:2023 · ISO/IEC 22989:2022
What ISO/IEC 42001 asks you to determine #
ISO/IEC 42001 is a copyrighted standard, so this guide paraphrases rather than reproduces it. Buy the text before you build against it.
Clause 4.1 requires you to determine the issues relevant to your AI management system. Clause 4.3 requires you to set the scope of that system. It draws on those issues and on the needs of interested parties from Clause 4.2. Neither clause hands you a list of role names to pick from. The standard points you, in its normative references, to ISO/IEC 22989 for AI vocabulary. That is where the role terms live.
What trips people up
A lot of compliance content describes ISO 42001 as defining three organizational roles: provider, operator, and user. Some of it comes from firms that sell ISO 42001 services. Neither ISO/IEC 42001 nor ISO/IEC 22989 uses that set of three terms. Compliance writers borrow the frame from the EU AI Act. It understates what the standard asks you to think about.
The five roles ISO/IEC 22989 defines #
ISO/IEC 22989:2022 sets out AI stakeholder roles in its terminology section. Five of them describe an organization’s relationship to an AI system. A sixth covers the people affected by one.
Producer
Designs, develops, trains, or modifies an AI system. The producer holds the deepest technical control: model architecture, training data selection, and the testing that catches bias before release.
Provider
Delivers an AI system, platform, or model to customers, whether or not the provider built it. A firm that wraps a third-party model in its own product is a provider without being that model’s producer.
Customer
Acquires an AI system from a provider and puts it to use. This is the most common role in most organizations. Using a vendor’s AI-powered software counts.
Partner
Supports a provider or producer in the AI supply chain. Examples: a data annotation vendor, an infrastructure host, or a consultant who integrates a model into a customer’s workflow.
Subject
A person affected by an AI system’s output, often without interacting with it. A loan applicant scored by a credit model is a subject, not a customer.
None of these roles rules out the others. Most organizations hold more than one. A software firm can train its own model, sell it inside a SaaS product, and let staff run commercial AI tools day to day. That firm is a producer, a provider, and a customer, for three systems.
Producer and provider are not the same thing
This is the distinction the borrowed three-role frame erases. A firm that licenses an open model and fine-tunes it for a niche use case is a producer of the fine-tuned version. That holds whatever role it held for the base model. A firm that resells someone else’s model unchanged is a provider without being a producer at all. The Statement of Applicability has to reflect which one you are, because the Annex A controls differ.
How to determine which roles apply to you #
Work from an inventory, not a guess. Most organizations find more AI systems than they expected once they count shadow AI and embedded AI features.
- Inventory every AI system. Include commercial tools, AI features embedded in business software, internal models, and anything staff adopted without formal approval.
- Ask the producer questions for each system. Did you design, train, or fine-tune it, even for internal use only? Fine-tuning a pre-trained model makes you a producer of the result.
- Ask the provider questions. Do you deliver this system, or a product built on it, to a customer, inside or outside the organization?
- Ask the customer questions. Do you or your staff use an AI system that another organization built or delivered?
- Ask the partner questions. Do you supply data, infrastructure, or integration work that a producer or provider depends on?
- Document the role set and get management approval. The result feeds your scope statement and your Statement of Applicability. Review it whenever you adopt or retire an AI system.
How your role shapes your Annex A scope #
Annex A holds 38 controls across nine themes, A.2 through A.10. Your role does not decide which themes exist. It decides which controls you can justify treating as not applicable, and which ones need your strongest evidence.
| Annex A theme | What it covers | Falls hardest on |
|---|---|---|
| A.2 Policies related to AI | The AI policy itself, its alignment with other management system policies, and its review cycle | Every role with its own AIMS |
| A.3 Internal organization | Governance roles, accountability, and how AI issues get reported | Producer, provider |
| A.4 Resources for AI systems | Data, tooling, computing infrastructure, and the human expertise to run them | Producer, partner |
| A.5 Assessing impacts of AI systems | The process for assessing an AI system’s impact on people, groups, and society | Producer at design time, customer at deployment |
| A.6 AI system life cycle | Responsible design, development, verification, deployment, and decommissioning | Producer, provider |
| A.7 Data for AI systems | Data governance, quality, provenance, and preparation across the life cycle | Producer, partner |
| A.8 Information for interested parties | What you disclose to customers and affected subjects about how the system works | Provider |
| A.9 Use of AI systems | Intended use boundaries, acceptable use, and operational monitoring | Customer |
| A.10 Third-party and customer relationships | Supply chain accountability and how responsibility splits between partners and customers | Provider, partner, customer |
The right column is a starting point for your risk assessment, not a substitute for it. A theme outside your primary role can still be in scope. The Statement of Applicability needs a written reason either way.
AI literacy is not one of these nine themes. It sits in the main clauses instead: Clause 7.2 for competence, Clause 7.3 for awareness. It applies to every role with staff who interact with an AI system. An earlier version of this article, and several other guides, filed it as an “Annex A.11.” Annex A stops at A.10.
What the Statement of Applicability needs from each role #
The Statement of Applicability sits under Clause 6.1.3. For each of the 38 controls, it records one of three states. Applicable and implemented. Applicable and not yet implemented. Or not applicable, with a written reason. Role is the justification you write down. It is not a shortcut around writing it.
The exclusion auditors reject
“We are a customer only, so the data and life cycle controls do not apply” is not, by itself, a justification. It becomes one once you show the reasoning. No training data passes through your organization. No model development happens inside it. The AI system arrives from a provider under a contract that assigns those controls to them. Write the reasoning, not just the role.
How ISO’s roles relate to the EU AI Act #
The EU AI Act defines its own roles under Article 3: provider, deployer, importer, distributor, and authorised representative. None of those names match ISO/IEC 22989’s provider, producer, customer, partner, and subject. The two standards were not built to align term for term.
A practical cross-walk exists. Organizations subject to both frameworks draw it this way. An ISO producer or provider maps to an EU Act provider. An ISO customer maps to an EU Act deployer. An ISO partner can fall under the EU Act’s importer or distributor, depending on what it supplies. Treat this as a translation your organization adopts for its own records, not a rule either standard states.
Common role combinations #
A regional bank buys a credit-scoring model from a fintech vendor and gives staff access to Microsoft Copilot. That bank is a customer for both, and nothing more, unless its own data team trains models for production use.
A SaaS firm trains its own machine learning features and ships them inside its platform. Its own staff also use commercial AI tools day to day. That firm is a producer, a provider, and a customer, three roles across three systems.
A hospital deploys a vendor’s radiology tool without modifying it. The hospital is a customer for that system, whatever oversight workflow its clinicians build around it. Configuring how a tool gets used does not make an organization its producer.
Frequently asked questions #
Does ISO/IEC 42001 define provider, operator, and user as its official roles?
No. Neither ISO/IEC 42001 nor ISO/IEC 22989, the vocabulary standard it references, uses that set of three terms. ISO/IEC 22989 defines five AI stakeholder roles: provider, producer, customer, partner, and subject. The three-role frame is a common simplification, borrowed from the EU AI Act. Neither ISO standard states it.
What is the difference between an AI producer and an AI provider?
A producer designs, develops, trains, or modifies an AI system. A provider delivers a system to a customer, whether or not the provider built it. A firm that resells an unmodified third-party model is a provider without being a producer. A firm that fine-tunes that same model becomes a producer of the fine-tuned version.
How many controls does ISO/IEC 42001 Annex A contain?
38 controls across nine themes, numbered A.2 through A.10. There is no Annex A.1 or Annex A.11. AI literacy is not an Annex A control. The main clauses cover it instead, competence under Clause 7.2 and awareness under Clause 7.3.
Can one organization hold more than one AI role?
Yes, and most organizations do. Roles apply per AI system, not once per organization. A firm can be a producer for a model it trains. The same firm can be a provider for the product that ships that model. It can be a customer for the commercial AI tools its own staff use, all at once.
Does my declared role let me exclude Annex A controls?
Role is a starting point for the reasoning, not a substitute for it. The Statement of Applicability still needs a written justification for every control you mark not applicable. Being a customer rather than a producer only holds up once you show the facts. No training happens inside your organization. No development happens there. No data governance work happens there either.
How do ISO/IEC 42001’s roles relate to the EU AI Act’s provider and deployer?
The two standards use different terms. They were not built to line up term for term. A common working translation maps an ISO producer or provider to an EU Act provider, and an ISO customer to an EU Act deployer. That mapping is a choice organizations make for their own records, not a requirement in either text.
Key takeaways #
- ISO/IEC 42001 does not mandate a role taxonomy. Clauses 4.1 and 4.3 require you to determine your role and document it.
- ISO/IEC 22989 defines five AI ecosystem roles: provider, producer, customer, partner, and subject, not three.
- Producer and provider are different. Reselling a model you did not build makes you a provider, not a producer of it.
- Annex A holds 38 controls across nine themes, A.2 through A.10. There is no A.11.
- AI literacy lives in Clause 7.2 and 7.3, not in Annex A.
- Most organizations hold multiple roles across different AI systems, not one role for the whole organization.
- Role justifies an Annex A exclusion only when you write down the reasoning behind it.
- The EU AI Act’s provider and deployer terms are a separate taxonomy. Mapping ISO’s roles onto them is your organization’s choice.
Get your role right before you scope the AIMS #
Nank.ai runs ISO 42001 programmes for companies in Canada and the United States, with a dedicated compliance manager backed by AI agents. We work out your producer, provider, customer, and partner duties before your Statement of Applicability goes anywhere near a certification body.
