Provider, Producer or Customer: Determining Your AI Role Under ISO 42001

Why Your AI Role Changes Everything

One of the first practical questions any organisation faces when implementing ISO 42001 is deceptively simple: what is your role in relation to AI? The answer shapes almost every other decision you make, from the scope of your AI management system, to the controls you apply, to the documented information you need to maintain.

ISO 42001 recognises that organisations interact with AI in fundamentally different ways. A company that builds AI models from scratch has very different obligations to one that buys an off-the-shelf AI tool and deploys it for internal use. A business that sells AI-powered services to customers sits somewhere else again. Getting this classification right is not a box-ticking exercise. It determines what the standard actually requires of you.

This article walks through the three primary AI roles defined in ISO 42001, how to determine which one applies to your organisation, what happens when you occupy more than one role, and the practical implications for your AI management system.

The Three AI Roles in ISO 42001

ISO 42001 uses specific terminology to distinguish between organisations based on their relationship to AI systems. These roles are drawn from the standard’s definitions and context requirements, and they are not arbitrary labels. Each one carries different responsibilities and different expectations for your management system.

The AI Provider

An AI provider is an organisation that develops or makes an AI system available for use by others. This includes organisations that train models, build AI-powered products, or offer AI capabilities as a service. If your organisation is selling or licensing an AI system to external customers, you are acting as a provider.

Providers carry the heaviest obligations under ISO 42001. You are responsible for the design of the AI system, the data used to train it, the controls built into it, and the documentation that customers need to use it responsibly. The standard expects providers to conduct thorough AI risk assessments, implement controls from Annex A, and produce documentation that allows downstream users to understand what the system does and does not do.

Examples of AI providers include software companies that build and sell AI-powered tools, cloud platforms offering AI APIs, and organisations that develop custom AI models for client deployment.

The AI Producer

The term producer refers to an organisation that develops an AI system for its own internal use, rather than for external sale or distribution. If your organisation builds a custom AI tool to automate internal processes, analyse internal data, or support internal decision-making, you are acting as a producer.

Producers still carry significant obligations because they are responsible for the design and deployment of the AI system within their own environment. The difference is that the system’s outputs affect the organisation itself and its own stakeholders, rather than external customers. Producers need to conduct risk assessments, apply appropriate controls, and manage the AI system through its life cycle, but the scope of their obligations is generally contained within the organisation.

A manufacturing company that builds a machine vision system to inspect its own products, or a logistics business that develops a route optimisation algorithm for its own fleet, would typically be acting as a producer.

The AI Customer

An AI customer is an organisation that acquires and deploys an AI system developed by someone else. This is the role most organisations will find themselves in, at least in part. If you are using a third-party AI tool, whether that is a document summarisation tool, a recruitment screening platform, or an AI-assisted analytics product, you are acting as a customer.

Being a customer does not mean you have no obligations under ISO 42001. The standard is clear that deploying an AI system, regardless of who built it, creates responsibilities. You need to understand what the system does, assess the risks it creates in your specific context, and apply controls appropriate to how you are using it. You cannot simply assume that because a vendor has controls in place, your own obligations are met.

This is a point that catches many organisations off guard. Purchasing an AI tool from a certified provider does not transfer all responsibility to that provider. Your deployment context, your users, and your customers create risks that only you can assess and manage.

Determining Which Role Applies to You

In practice, the line between these roles is not always obvious, and many organisations occupy more than one simultaneously. The way to work through this is to look at each AI system your organisation uses or develops, and ask a set of structured questions.

Questions to Ask for Each AI System

• Did we build this system? If yes, you are at minimum a producer. If you are also making it available to others, you are a provider.
• Did we acquire this system from a third party? If yes, you are a customer for that system.
• Are we deploying this system to serve external customers? If yes, even if you did not build it, you may have provider-like obligations in relation to those customers.
• Are we modifying or fine-tuning a system we acquired? If yes, the degree of modification may shift your role closer to producer or provider.
• Are we combining multiple AI systems into a product or service? If yes, you are likely acting as a provider in relation to the combined output.

Work through this exercise for every AI system in your scope. Document your conclusions. This becomes part of the context analysis required under Clause 4 of ISO 42001, which we have covered in detail in What Clause 4 of ISO 42001 Asks About Your Organisation’s AI Context.

When You Occupy Multiple Roles

It is entirely common for an organisation to be a provider, producer, and customer at the same time, just for different AI systems. A technology company might build and sell an AI-powered analytics platform (provider), use an internally developed AI model to prioritise its own support tickets (producer), and subscribe to a third-party AI writing assistant for its marketing team (customer).

Each of these relationships needs to be addressed separately in your AI management system. The controls and documented information required for each role differ, and conflating them creates gaps that will show up in an audit.

The practical approach is to maintain a register of AI systems, with each system tagged to its role classification. This register feeds into your risk assessment process under Clause 6.1.2 and your operational controls under Clause 8. It also makes the scope of your AI management system much easier to define and defend to an auditor.

Practical Implications for Your AI Management System

Once you have determined your role for each AI system, the implications flow through every element of your management system. Here are the areas where role classification has the most direct impact.

Risk Assessment

Your role determines the nature of the risks you need to assess. Providers need to assess risks associated with how customers might use the system, including misuse, unintended applications, and downstream harms. Producers focus on risks within their own operational environment. Customers need to assess risks specific to their deployment context, even when the system itself was built and assessed by the provider.

A common mistake is for AI customers to rely entirely on the vendor’s risk assessment. That assessment was conducted in the context of the vendor’s design and intended use cases. Your context is different. Your user base, your data inputs, your regulatory environment, and the decisions the system informs are all specific to you. You need your own assessment.

Annex A Controls

The controls in Annex A of ISO 42001 are not all equally relevant to every organisation. Your role classification guides which controls are applicable and how they should be implemented. Providers, for instance, have specific obligations around documentation for customers (Annex A.8), responsible use frameworks (Annex A.9), and third-party relationships (Annex A.10). Customers need to focus on controls related to deployment, monitoring, and the governance of acquired systems.

Your Statement of Applicability documents which controls apply, which are excluded, and why. Role classification is one of the primary inputs to this document. If your Statement of Applicability does not reflect your actual AI roles, it will not hold up under audit scrutiny.

AI Impact Assessments

ISO 42001 requires organisations to conduct AI system impact assessments. The scope and focus of these assessments vary by role. Providers need to assess potential impacts across the range of likely deployment contexts. Customers need to assess impacts specific to their own deployment. Producers sit somewhere in between, assessing impacts within their own operational environment but with attention to how the system affects internal stakeholders.

If you are acting as a customer deploying a system that makes or influences decisions about people, such as a recruitment screening tool or a performance management system, your impact assessment needs to address fairness, bias, and the rights of the individuals affected. This is true regardless of what the provider has documented about the system.

Documented Information

Your role affects what documented information you need to create and maintain. Providers need to produce documentation that customers can use, including descriptions of the system’s purpose, limitations, training data characteristics, and recommended use conditions. Customers need to document their deployment decisions, risk assessments, and monitoring arrangements. Producers need documentation that supports internal governance and accountability.

Auditors will look for documented evidence that your role classification has been thought through and that the resulting obligations have been addressed. Vague references to AI use without clear role assignment and corresponding controls will be flagged.

A Real World Scenario

Consider a mid-sized Australian professional services firm that has recently started using AI in three ways. First, it has deployed a third-party AI tool to assist with drafting client reports. Second, it has built an internal tool that uses AI to categorise and prioritise incoming client queries. Third, it is developing an AI-powered benchmarking product that it plans to sell to clients in the coming year.

For the third-party drafting tool, the firm is a customer. It needs to assess the risks of using that tool in its specific context, particularly around accuracy, confidentiality, and the potential for the AI to produce misleading content in client-facing documents. It cannot assume the vendor has addressed these risks on its behalf.

For the internal query categorisation tool, the firm is a producer. It needs to manage the system through its development and operational life cycle, assess risks to its own staff and processes, and maintain governance over how the system is updated and monitored.

For the benchmarking product under development, the firm is a provider. It needs to build the system with provider obligations in mind from the outset, including documentation for future customers, controls for responsible use, and a framework for managing third-party relationships once the product is deployed.

Each of these roles requires different controls, different documentation, and different risk assessment approaches. Treating them as a single undifferentiated AI activity would create serious gaps in the management system.

Auditing Your AI Role Classification

If you are an internal auditor reviewing an organisation’s ISO 42001 implementation, AI role classification is one of the first things to examine. Ask to see the AI system register and check whether each system has been assigned a role. Then trace that classification through to the risk assessment, the Statement of Applicability, and the operational controls.

Look for evidence that the organisation has not simply adopted a vendor’s documentation and called it done. Customer organisations in particular often under-document their own deployment-specific risk assessments, assuming the provider has covered everything. This is a common finding and one that auditors examining ISO 42001 implementations are increasingly alert to.

For a detailed walkthrough of how auditors approach the context and role determination requirements of ISO 42001, see our article on Auditing Organisational Context and AI Roles in an ISO 42001 Audit.

Getting Role Classification Right From the Start

Role classification is not a one-time exercise. As your organisation’s use of AI evolves, your roles will change. A producer that starts selling its internally developed tool to external clients becomes a provider. A customer that begins customising a vendor’s model takes on producer-like responsibilities. Your AI management system needs a process for reviewing and updating role classifications as your AI landscape changes.

Build this review into your management review cycle and your internal audit programme. The standard expects your AI management system to remain current with your actual AI activities. A static role classification that was accurate eighteen months ago but does not reflect current reality is a conformity issue waiting to be found.

If you are working through ISO 42001 implementation for the first time, or preparing for certification, understanding your AI role is the foundation everything else rests on. It is worth spending the time to get it right before you build the rest of your management system around an assumption that may not hold.

At Audit Workshop, our ISO 42001 training covers the practical application of role classification, risk assessment, and Annex A controls in the kind of detail that helps practitioners build management systems that actually work, not just ones that look good on paper. Whether you are implementing an AI management system or auditing one, our courses are built around real-world application by trainers who have conducted these audits in practice.