Every business that builds, supplies, or uses AI already operates an AI management system. It is not a question of whether you have one. It is a question of what maturity it runs at.
The system you already run
We could bet that all (if not most) of businesses in the digital asset space are leveraging AI daily. Surprisingly, it does not seem clear to some stakeholders that they are in fact operating an AI Management System (AIMS), similar to the way they operate an Information Security Management Systems (ISMS ISO/IEC 27001 certified). Maybe the reasoning is the business has to run a project to acquire a certification, and until you have run that project, you do not have an AIMS.
An AIMS is not a certificate, in the same way an ISMS is not a certificate. It is the set of processes by which an organisation governs the AI and AI-enabled systems it builds, buys, and/or runs. The business that has documented how AI-driven decisions get made, reviewed, and corrected is running an AIMS. So is the business that has not. In that latter case, it just does so at low maturity and, the ungoverned AIMS is already producing outcomes.
The useful question is therefore not whether you have an AIMS. It is where yours sits on a maturity scale. Let us consider a standard six-level scale, from zero to five. At level 0 there is no identifiable process. At level 1, things happen case by case, with no method. At level 2 non-standard processes exist. At level 3 processes are documented and communicated. At level 4 they are monitored and measured. At level 5 they are continuously improved.
ISO/IEC 42001 is, in effect, the discipline that moves an AIMS off the bottom of that scale — i.e. ungoverned, ad hoc, invisible — to level 3 and above, where the process is defined and a third-party can audit and verify it.
Getting ISO/IEC 42001 certified is not a requirement. A business may not be planning to get audited any time soon or ever. However, it is about applying a best-in-class framework, taking the decisions your business already makes about its AI and turning them into a discipline that enable responsible and safe development and/or use of AI to support and deliver on business objectives. And, if necessary or at any point required, that can be audited by a third-party.
ISO/IEC 42001 is the standard for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System (AIMS) within organizations. It defines key roles and most digital-asset businesses occupy more than one at once. You are an AI producer (incl. AI developers, AI evaluators, AI deployers) when you put an AI system to work in your own operations, whether you built it or bought it from a third party. You are an AI provider when you make an AI system or AI-powered product available to others: a platform, product, or service you sell, license, or supply. You are an AI customer when you put a third party's AI system to work in your own operations. The people AI systems decide on — e.g. the applicant a KYC classifier rejects, the account a fraud model freezes — are AI subjects, the role that gives the 42001 standard's AI impact-assessment requirement its force. Each of those roles comes with its own obligations. The same business can be producer, customer, and provider at once.
And yet:
"No client has asked for it, so we don't need one"
This treats client demand as the trigger for the obligation. "No one has asked" describes the maturity of the market's demand signal, not the maturity of your risk or, if applicable, your regulator's expectations. Procurement demand is a lagging indicator. ISO/IEC 27001 entered enterprise RFP questionnaires after it became the sensible thing to hold (roughly a decade); the firms that waited for the questionnaire to demand it were the ones scrambling to answer it. AI-governance attestation is now moving through the same curve, and it is moving faster due to regulatory considerations.
For regulated digital asset players, MiCA hands its operational-resilience layer to DORA, and DORA requires an ICT risk-management framework under Articles 5–15 that reads across every operation material to clients and the market. Neither carves AI out as a special case, which means the supervisor expects appropriate controls over the AI components of every function you have been authorised to run. The regulator does not need a customer to raise the point first.
For firms outside the regulatory perimeter (pre-authorisation startups, infrastructure and tooling vendors, protocols operating where no licensing regime yet applies) the demand will still arrive at some point, coming through the supply chain. A monitoring service, wallet provider, or analytics tool that sells into a MiCA-authorised CASP or a bank inherits that buyer's third-party risk obligations: under DORA Articles 28–30 the regulated client must evidence oversight of its ICT providers, and the AI components of your product sit inside that scope. The questionnaire asking how you govern AI systems within your organisation will arrive from your enterprise and institutional clients. AI governance is starting to enter due diligence processes. So the point is "No client has asked for it, yet".
"We don't have any AI in our product"
ISO/IEC 42001 does not scope AI at the level of your product, it scopes it at the level of your organisation. A business can ship a product with no AI in it whatsoever and still run a dozen AI systems across its operations, every one of them in scope. Each is an AI system your company deploys, and each carries failure modes (drift, bias, etc.) that land on you, not necessarily on the vendor.
42001 and the EU AI Act both govern AI you deploy and procure, not only the AI you build into your own product. A deployer is any organisation using an AI system under its own authority, and there are specific obligations attached to that role. You do not have to have built a model, or shipped one in your product, to be accountable for how you run it within your organisation.
ISO/IEC 42001 requires an inventory of the AI systems and resources in scope; you cannot run an inventory you have never compiled. A business that cannot name AI systems used by its team (shadow AI) is at a low AI governance maturity level, because governance begins with knowing what there is to govern, and that business does not yet know.
"We're not EU-based, so it doesn't apply"
Regarding jurisdictional reach, the EU AI Act binds providers and deployers established outside the Union where the output of the AI system is used within it. A firm headquartered in Dubai, Singapore, or Delaware that serves EU users, or whose model output touches the EU market, is inside the territorial scope regardless of where its servers or its incorporation sit.
An ungoverned AI decisioning process (particularly in high-risk systems) is a control failure under most jurisdictions. The regulators differ. The question they ask does not: show me how you govern this. Maturity does not carry a passport.
ISO/IEC 42001 is designed to be a jurisdiction-neutral management-system standard that maps onto whatever local regime applies, rather than a separate governance build per country. Being non-EU is a reason to want the portable standard. It is not a reason to skip it.
"We're doing SOC 2 right now", "We're doing ISO 27001 right now"
SOC 2 and ISO/IEC 27001 raise your information-security maturity but neither standard addresses AI systems lifecycle, drift monitoring, bias testing, explainability, or the impact of an AI system on the individuals subject to its decisions. Annex A.5 (assessing impact of AI systems), Annex A.6 (the AI system lifecycle), and Annex A.7 (data for AI systems) have no equivalent in a 27001 Statement of Applicability or a SOC 2 Type II report. Reading those certificates across to AI by analogy is not the same as evidencing AI governance, and an auditor testing the difference will find it quickly.
In addition, we could argue that a compliance programme already in flight is an appropriate moment to raise AIMS maturity, not a reason to defer it. The evidence discipline, the control ownership, the internal-audit function, and the management-review cadence are all being stood up for the security certification anyway. ISO/IEC 42001 shares the Annex SL high-level structure with ISO/IEC 27001, which means the AIMS bolts onto scaffolding you are already erecting, with a combined Statement of Applicability and a combined audit (cheaper). The alternative of finishing SOC 2 or ISO-27001, then starting the AIMS build from cold later or when pressed to do it, may need to be questioned.
The principle that runs through all of this
If your business builds, supplies, or uses AI, you do not get to choose whether you operate an AI management system or not. You already are operating one and you get to choose its maturity.
An AI management system at maturity zero still produces outcomes. The exposure is not that the firm lacks an AIMS. It is that the firm has one it cannot see, running decisions it cannot account for.
ISO/IEC 42001 moves the system you already run from ungoverned to defined. From a set of outcomes nobody can inspect (internally or externally) to a discipline that enable supervision, improvement and auditing.
An ISO certification is not the system. The system is already yours. The open decision is whether you manage it to a recognised standard before a key stakeholder asks you to.