Your RFP Now Demands an AI Certificate Roughly 350 Companies Hold

Why Did an Obscure ISO Standard Turn Into an RFP Question?

Two years ago, ISO/IEC 42001 was a management system standard that almost nobody outside a compliance team had read. It was published in December 2023 as the first international standard describing requirements for an artificial intelligence management system, and for most of 2024 it lived where new management system standards usually live: in consultancy webinars and slide decks about readiness.

Then the frontier labs started certifying, and the standard acquired a market. Anthropic announced certification on 13 January 2025, audited by Schellman, covering its AI management system, positioning itself among the first frontier labs to hold it. AWS had already published accredited certification covering several of its AI services in late 2024. Microsoft, OpenAI, Snowflake, Salesforce and ServiceNow followed with certifications or published scope statements of their own, and by 2026 the standard had moved from a voluntary governance framework to a line item in enterprise vendor questionnaires.

That sequence matters more than the standard's contents, because it explains the mechanism. Procurement functions did not adopt ISO/IEC 42001 because they read Annex A and found it persuasive. They adopted it because their largest AI suppliers held it, which meant it was possible to ask for it, and a question you can ask is infinitely more useful to a procurement process than a concern you can only describe. Once the biggest vendors in the market could answer yes, every smaller vendor inherited the question.

The demand side is now visible in the certification bodies' own numbers. BSI, announcing an accreditation milestone in March 2026, cited research that 26% of organisations report taking steps to align with ISO/IEC 42001, while 62% of global business leaders expect to increase AI investment over the following twelve months. Those two figures describe the same pressure from opposite ends: spending is going up, and the buyers doing the spending want something signed to put in the file.

What Does an AI Management System Certificate Actually Certify?

ISO/IEC 42001 is built on the same skeleton as ISO/IEC 27001, and understanding that skeleton is the fastest way to understand what the certificate does and does not say. It requires an organisation to define the scope of its AI activities, set policy and objectives, assign roles and responsibilities, run a risk assessment and risk treatment process, carry out impact assessments, apply controls across the AI lifecycle, manage the data and third-party models feeding those systems, monitor and audit, and demonstrate continual improvement. An accredited auditor then samples the evidence and issues a certificate against a stated scope.

Note what that sentence certifies: a system of management. It does not certify that a particular model is accurate, that a particular output is unbiased, or that a particular deployment is lawful in a particular jurisdiction. It certifies that the organisation has a defined and operating process for making decisions about those things, and that an auditor found the process running rather than merely documented. This is exactly the distinction that made ISO/IEC 27001 useful and exactly the distinction that buyers routinely collapse when they read the logo instead of the certificate.

The accreditation layer underneath is younger than the standard and worth understanding, because it is where credibility actually lives. ISO/IEC 42006:2025 sets the additional requirements for bodies providing audit and certification of AI management systems, covering auditor competence, audit time calculation and the content of certification documents, and it builds on ISO/IEC 17021-1. National accreditation bodies then accredit certification bodies against it: ANSI's ANAB runs a dedicated accreditation programme for AI management system certification bodies, and Canada's accreditation body has published transition requirements moving accredited bodies onto the 2025 edition. BSI announced on 10 March 2026 that its ANAB accreditation made it the first certification body to hold accreditation from ANAB, UKAS and RvA simultaneously.

The practical consequence for a buyer is that two certificates bearing the same standard number can mean very different things. A certificate issued by an accredited body against a scope covering the whole engineering organisation is a substantial artefact. A certificate issued without accreditation, or issued against a scope covering one product in one region, is a much narrower claim wearing the same badge. The scope statement is the part of the document that carries the information, and it is the part nobody reads.

Brussels Has Already Said This Is Not AI Act Compliance

Here is the part that almost never survives the trip from the compliance team to the procurement template. The European Commission has stated, in its own published guidance on AI Act standardisation, that ISO/IEC 42001 is not the instrument the AI Act requires. Its FAQ acknowledges that European standardisation prefers to build on international standards, then says plainly that although the standard helps to set up an AI management system, its goals and definitions are not aligned with the quality management system required under the AI Act, which is precisely why new European standards are being written.

That is not a technicality. The AI Act's compliance architecture runs on presumption of conformity: when a harmonised standard is cited in the Official Journal, a product built to it is presumed to satisfy the corresponding essential requirements, and the burden shifts to the authority to disprove conformity rather than to the provider to prove it. CEN-CENELEC's JTC 21 is the body writing those standards, the Commission expects the first of them to be published in 2026, and CEN and CENELEC adopted an exceptional package of measures in October 2025 to get prioritised deliverables out by the end of this year. None of that has happened yet in the only sense that matters legally, because presumption attaches on citation in the Official Journal and nothing has been cited.

So the market is in an unusual position. The instrument that would confer legal presumption does not exist yet. The instrument that exists confers no legal presumption and was explicitly described by the regulator as misaligned with the requirement it is being used to proxy. And procurement teams across Europe are treating the second as a stand-in for the first, because waiting was not an option and something had to go in the questionnaire.

None of this makes ISO/IEC 42001 worthless. An organisation that has been through an accredited audit has, at minimum, an AI inventory, a risk register, defined ownership and a documented lifecycle, and those are exactly the raw materials an AI Act conformity file is assembled from. The error is not in valuing the certificate. The error is in believing that a supplier's certificate discharges your obligation as the provider of the system you actually placed on the market.

Then Why Has It Become the Gate Anyway?

Because scarcity makes a signal, and this signal is very scarce. There is no official global register of ISO/IEC 42001 certificates and the standard is not yet tracked in the ISO Survey, so the count has to be assembled from certification-body announcements and company press releases. Those tallies put roughly 350 organisations worldwide holding the certificate as of spring 2026. For comparison, the 2024 ISO Survey recorded 96,709 valid ISO/IEC 27001 certificates, against 71,549 in 2022. AI management system certification is roughly where information security certification was two decades ago.

A signal that few suppliers can produce is a very efficient filter, which is exactly why buyers like it and exactly why it is dangerous. It selects for organisations that could fund a six to eighteen month audit programme and staff the evidence work, and that population correlates with size and compliance maturity far more strongly than it correlates with engineering quality. A twelve-person team that ships careful, well-evaluated AI features and a thousand-person organisation that ships badly can sit on opposite sides of that filter for reasons that have nothing to do with the software.

The absence of a register creates a second, quieter problem: verification. Because there is no authoritative place to look a certificate up, the buyer's control is the document itself. That means asking for the certificate PDF rather than a claim on a website, checking which certification body issued it, checking whether that body carries an accreditation mark from a recognised accreditation body, reading the scope statement to see what is actually covered, and checking the expiry and surveillance cycle. Every one of those checks is trivial. In practice, most buyers do none of them, which turns a scarce signal into an easily imitated one.

The honest reason procurement reaches for the certificate is that procurement needs decidable questions. "Do you hold an accredited ISO/IEC 42001 certificate?" resolves to yes or no and can be scored. "Can you evidence how this model was evaluated before release and who approved it?" is a far better question and cannot be scored by someone who has never run a model release. The gap between those two questions is where most AI supplier risk currently lives.

The Omnibus Moved the Deadline, Not the Question

It would be reasonable to assume that Europe's decision to delay the high-risk regime has taken the pressure off. It has not, and the reason is worth spelling out, because a lot of engineering roadmaps were quietly re-planned on the assumption that it did.

Under the digital omnibus agreement reached in May 2026, high-risk obligations for Annex III standalone systems move to 2 December 2027 and Annex I systems embedded in regulated products move to 2 August 2028, from 2 August 2026 and 2 August 2027 respectively. The stated motivation was implementation readiness, including the unfinished harmonised standards discussed above. Article 50 transparency obligations and the Article 4 AI literacy duty were left where they were.

What the delay did not change is the commercial calendar. Enterprise software selections run on multi-year cycles, and the supplier chosen in 2026 is the supplier who will be inside the conformity file in 2027. A buyer selecting a development partner today for a system that will be classified high-risk is, correctly, asking today about the evidence that partner will be able to produce eighteen months from now. The regulator gave everyone more time to build. It did not give buyers permission to select suppliers who cannot.

There is also an asymmetry in who benefits from the delay. Large providers used the extra eighteen months to finish governance programmes already underway. Smaller suppliers, and the outsourcing partners inside their delivery chains, largely treated the delay as a reason to stop, which means the readiness gap between the two groups will be wider in December 2027 than it was in August 2026. Procurement teams can see that coming, and it is one reason the certificate question got sharper rather than softer after the delay was agreed.

Article 25 Turns Your Development Partner Into a Documented Dependency

The provision that actually reaches into outsourcing contracts is not the certification market at all. It is Article 25 of the AI Act, and it is short, specific and widely unread.

Article 25 requires that the provider of a high-risk AI system and any third party supplying AI systems, tools, services, components or processes used or integrated into that system shall, by written agreement, specify the information, capabilities, technical access and other assistance needed to enable the provider to comply with the Regulation. There is an exemption for tools and components made publicly available under a free and open-source licence, other than general-purpose AI models, and the AI Office may recommend voluntary model terms. The same article treats a distributor, importer or deployer as a provider if they put their name on a high-risk system or substantially modify one.

Read that as an engineering manager rather than a lawyer and the meaning is concrete. If a development partner builds a component that ends up inside a high-risk system, the contract has to state what they will hand over, what access they will grant, and what help they will give when a conformity assessment, a post-market monitoring obligation or a serious incident report comes due. That is not a warranty clause. It is a delivery specification with named artefacts.

The public sector has already written this down for everyone else to copy. The Commission's model contractual clauses for AI procurement were updated in March 2025 with a full version for high-risk systems, a light version for non-high-risk systems and a commentary, published across 24 EU languages, and legal commentators have noted that private-sector buyers have been reusing them as a starting point well beyond their public-procurement origin. If you want to know what your next enterprise customer will put in front of you, that document is the closest thing to a preview.

What Your Engineering Team Actually Has to Produce

Strip away the certification question and the regulatory question, and what both reduce to is one engineering question: can you show, for any AI-touching system you ship, what it is, what it was built from, how it was tested, who approved it, and what happened to it since?

The concrete evidence set is smaller than the compliance literature makes it sound. An inventory of AI-touching systems with a named owner per entry. A registry of models and versions, including third-party models and the licence and terms each arrived under. Dataset provenance for anything used in training, fine-tuning or retrieval, including what was excluded and why. Evaluation records tied to specific releases, so a test result points at a commit rather than at a quarter. A documented human oversight design describing where a person can intervene and what they can see when they do. Logging sufficient to reconstruct a decision after the fact. A change history. A supplier register naming everyone whose code or models are inside the system.

The failure mode is universal and predictable: teams treat this as a documentation project, run it six weeks before an audit or a customer deadline, and reconstruct from memory. Reconstructed evidence is worse than useless, because it is expensive, unreliable, and it goes stale the moment the next release ships. Evidence that is generated as a byproduct of delivery is cheap and always current. That means eval suites living in the repository next to the code they test, model and dataset registries updated by CI rather than by hand, approvals captured in the pull request that shipped the change, and architecture decision records written when the decision was made rather than when it was questioned.

AI coding agents make this both harder and more urgent. When a meaningful share of a codebase is generated rather than typed, provenance questions get sharper, not softer: which model produced this, under what licence terms, who reviewed it, and what evidence exists that anyone understood it before it merged. A team that already captures approvals and evaluations in its pipeline absorbs agentic development without ceremony. A team that does not now has two provenance gaps to close instead of one.

The good news is that none of this expires. An inventory, a model registry, an eval suite tied to releases and a working approval trail are the same artefacts whether the question comes from an ISO auditor, an AI Act conformity assessment, a customer's security review, or a due diligence process during an acquisition. Built once, properly, they answer all four.

What to Ask a Development Partner Instead of "Are You Certified?"

If you are selecting an engineering partner for work that will touch AI, the certificate is a reasonable tiebreaker and a poor primary filter. The questions that actually predict whether you will be able to answer a regulator or a customer are these, and they are all answerable in a technical conversation rather than a questionnaire.

Ask to see the evaluation suite for something they have already shipped, and ask how a given result maps to a specific release. Ask how they record which model version produced which behaviour in production. Ask what their pull request template captures about AI-assisted code and who signs off on it. Ask what happens operationally when a model provider deprecates a version or silently changes behaviour. Ask which artefacts they will hand over under an Article 25 written agreement, and whether they have read the Commission's model clauses. Ask where the data physically sits, who can access production, and under whose jurisdiction. And ask the least technical and most predictive question of all: will the same engineers still be on this system in eighteen months, when someone asks why a decision was made?

That last question is why the delivery model matters as much as the controls. Evidence has an author. A rotating pool of contractors who delivered a feature and moved on cannot explain a design choice two years later, and a conformity file assembled by people who were not there is a file full of plausible guesses. Continuity is not a nice-to-have in this domain; it is the mechanism by which documentation stays true.

This is the shape of engagement Stepto is built around. We put dedicated senior teams in Serbia onto a product rather than a ticket queue, working Central European hours that overlap the full European business day, so the person who can answer a provenance question is available on the same day the question is asked. Working inside the European regulatory perimeter means GDPR, data residency and AI Act obligations are constraints our engineers already build under rather than requirements that have to be translated for them. And because a dedicated team stays with the system, the inventory, the eval suite and the decision record accumulate an author who is still reachable, which is the difference between an evidence set and an archaeology project.

One final caution, because it is the most common and most expensive misunderstanding in this whole area: a certificate held by your supplier does not transfer to your system. If you place the product on the market, you are the provider. Your partner's governance is an input to your file. It is never a replacement for it.