Two very different types of organizations are pursuing ISO 42001 today, and they need almost completely different implementations. The standard is the same. The scope, the evidence, and the audit focus are not.
Understanding which side of the line your organization is on, or whether you sit on both, changes how you scope the project, how you allocate resources, and what the certification actually tells the market.
## The common belief
The initial assumption in most projects is that ISO 42001 is one implementation with one methodology, applied uniformly. Companies look for templates, example policies, and sample risk registers, assuming that a good starting point for one organization is a good starting point for another.
It is not. The shape of the management system depends heavily on the role the organization plays in the AI value chain.
## The two roles the standard distinguishes
ISO 42001, echoing the EU AI Act and most global frameworks, distinguishes between two operational roles an organization can play with respect to any given AI system:
### AI Provider
An organization that develops an AI system or a general-purpose AI model and places it on the market under its own name or brand. Examples: an HR Tech company building its own CV screening model; a FinTech developing a proprietary credit-scoring algorithm; an AI startup offering a foundation model via API; a medical AI company training its own diagnostic model.
### AI Deployer
An organization that uses an AI system under its own authority, typically integrating a third-party model into its operations. Examples: a bank using a vendor’s anti-money-laundering model; an insurer using an external fraud-detection system; a retailer using a third-party recommendation engine; a public-sector body using a commercial identity-verification AI.
Many organizations are both. A fintech that trains proprietary credit models and also integrates external KYC providers is a provider for some systems and a deployer for others. The management system has to handle both modes.
> Provider obligations are about what you build. Deployer obligations are about what you choose, how you use it, and how you oversee it.
>
## Where the real problem lives
The scope and evidence expectations diverge significantly between the two roles.
### For providers
The auditor will expect to see evidence across the full AI lifecycle: design decisions, training data governance, model documentation, bias and robustness testing, human oversight design, documentation accompanying the system for deployers, post-market monitoring, and incident response for customers using the system. The controls in Annex A of ISO 42001 that emphasize impact assessment, data for AI systems, and information for users become central.
A provider implementation touches product management, engineering, data science, legal, and customer success. It produces artifacts that often need to be shared with enterprise customers and regulators.
### For deployers
The auditor will expect to see evidence around supplier evaluation, acceptable use policies, instructions-for-use implementation, internal operator training, human oversight in the deployer’s specific context, monitoring of outputs in the deployer’s operation, and incident handling relevant to how the system is actually used. The Annex A controls on AI system impact assessment, data quality for operation, and human oversight in deployment become central.
A deployer implementation touches procurement, operations, legal, risk, and the specific business functions using the AI. It produces artifacts that are mostly internal, supporting the organization’s own accountability.
## Reframing the question
The question to ask is not “How do we get ISO 42001 certified?” The question is “For each AI system in our scope, what role do we play, and what evidence does that role require?”
The answer usually reveals that the scope of the management system must explicitly handle dual-role operation. Hybrid organizations need a single management system that applies the provider obligations where they build and the deployer obligations where they buy or integrate.
## The structural shift
Traditional product assurance assumed a single, clear responsible party: the manufacturer. Modern AI operations distribute responsibility across a chain. A foundation model is built by one company, fine-tuned by another, embedded into a product by a third, deployed into an operational context by a fourth, and experienced by an end user who has no visibility into any of it.
ISO 42001’s distinction between provider and deployer roles is how the governance framework adapts to that distributed reality. Each node in the chain has to govern the decisions it actually makes, and document those decisions in a way that lets the next node govern responsibly.
## What this means for your organization
Map the role per system before scoping. Build an inventory of AI systems that explicitly tags each as provider, deployer, or both. A mid-sized organization usually has a mix; the distribution determines which Annex A controls require the most attention.
Do not over-implement for your non-primary role. A deployer that copies a provider’s evidence approach wastes effort on documentation it does not need, while under-documenting the supplier evaluation and operational oversight work that actually applies.
Use role clarity to communicate externally. A certificate accompanied by a clear scope statement (“certified AIMS covering our role as provider for systems A, B, C and deployer for systems X, Y, Z”) carries more weight with sophisticated buyers than a generic certificate claim.
> In the AI value chain, everybody is governing something. Your certification should tell the market precisely what your organization takes responsibility for.
>
—
Ready to move from documentation to certification?
📩 [[email protected]](mailto:[email protected]) · 🌐 [zertia.ai](http://zertia.ai)
–
