AI Governance Standards: Which One Is Certifiable, Which Is Guidance, and What Each Expects in Production
Six documents get called AI governance standards: ISO/IEC 42001, ISO/IEC 23894, the NIST AI RMF, ISO/IEC 27001 with AI extensions, the EU AI Act harmonized standards work, and OWASP AISVS. Only one of them is certifiable, two are law-adjacent, and they differ sharply in how much production evidence they expect. This sorts them by what they are, how they overlap, and which clauses require runtime records rather than documents.
A procurement questionnaire arrives asking whether you comply with "AI governance standards." Six documents answer to that description, one of them can be certified, two are voluntary frameworks with no audit scheme, one is a security verification checklist, and two are regulatory instruments that are not standards at all. Answering the question well starts with sorting them.
I want to lay out what each document is, where they overlap, and the part that gets skipped in every comparison table I have read: how much of each one requires evidence from production rather than evidence from a filing cabinet.
ISO/IEC 42001:2023, the only certifiable one
42001 specifies requirements for an AI management system, structured on the same Annex SL high-level structure as ISO 27001 and ISO 9001. Context, leadership, planning, support, operation, performance evaluation, improvement. Annex A carries 38 controls across nine objectives covering AI policy, internal organization, resources, impact assessment, lifecycle, data, information for interested parties, third-party use, and system use.
An accredited certification body audits against it and issues a certificate. That is the practical difference from everything else on this list, and it is why 42001 is the answer most procurement questionnaires are fishing for. The implementation shape is in ISO 42001 implementation guide and the control detail in ISO 42001 Annex A controls.
Where it needs production evidence: Annex A's lifecycle, data, and system-use objectives. An auditor reviewing a control that says sensitive data classes are restricted from external models will ask what shows that in operation. A treatment plan and a screenshot of a configuration page are weaker answers than a record of what actually traversed the boundary.
ISO/IEC 23894:2023, the risk method
23894 adapts the ISO 31000 risk management process to AI. It carries no certification scheme and it exists largely to fill the risk clauses of 42001, which points at it for method. Annex B's list of AI-specific risk sources is the section teams use in practice. The full treatment is in ISO 23894 AI risk management.
NIST AI RMF 1.0, the US voluntary frame
Published January 2023, organized around four functions: Govern, Map, Measure, and Manage, with a companion playbook and profile mechanism. Voluntary, no certification, and heavily referenced by US federal and critical infrastructure programs.
Measure is the function that resists paperwork. It expects that identified risks are actually measured with quantitative or qualitative methods and that results are tracked over time. A Measure function backed only by a quarterly self-assessment is the most common weak point I see in AI RMF adoption. The function breakdown is in NIST AI RMF explained.
ISO/IEC 27001 with AI in scope
27001 is an information security management system standard and it predates the AI question entirely. Organizations already certified against it extend the ISMS scope to cover AI systems rather than starting a separate program, which is usually the cheaper path to a defensible position. The relationship and the overlap are worked through in ISO 42001 vs ISO 27001 and ISO 27001 AI Annex A controls.
OWASP AISVS 1.0, the testable one
OWASP shipped the AI Security Verification Standard on June 24, 2026: 514 testable requirements across 14 chapters, modeled on ASVS (OWASP AISVS). This is not a management system standard and it does not compete with 42001. It is a verification checklist that a pen tester, an auditor, or a CI pipeline can run, which makes it the most directly operational document on this list. The gateway-enforceable subset is mapped in OWASP AISVS gateway mapping.
The two that are law rather than standards
The EU AI Act is a regulation with penalties reaching €15 million or 3% of global annual turnover for high-risk non-compliance (Article 99). Harmonized standards developed under CEN-CENELEC will eventually give a presumption of conformity, which is where the standards world and the regulatory world meet. Until those land, compliance is demonstrated directly against the Act's text, including the Article 12 record-keeping obligation covered in EU AI Act Article 12 logging.
Sector rules form the second group. The ECB's July 7, 2026 letter giving 110 directly supervised banks until October 31 to file AI cyber plans is a supervisory expectation, not a standard, and it will be assessed on what a supervisor can inspect. Fannie Mae's LL-2026-04 governance framework works the same way for mortgage originators, effective August 6, 2026.
How they stack
Nobody needs all six. The pattern that works: pick 42001 or 27001-with-AI-scope as the certifiable spine, use 23894 or the AI RMF as the risk method inside it, run AISVS as the technical verification pass, and map the regulatory obligations that apply to your sector on top.
The part every mapping document gets wrong
Coverage claims. I have reviewed vendor mappings asserting that a single control satisfies 30 of 38 Annex A controls, and the assertion collapses on the first one an auditor picks. Annex A includes controls on internal organization, resourcing, and impact assessment that no piece of infrastructure touches.
An honest mapping marks most controls as out of scope for any given technical control and evidences the handful that are in scope properly. It reads as less impressive and survives contact with an assessor, which is the only test that matters. If a mapping you have been handed claims broad coverage across an entire annex, ask which specific record answers control A.6.2.4, and watch what happens.
Where the standards converge
Across all six documents, three expectations repeat in different vocabulary. Know which AI systems you operate. Control who and what may use them and under which conditions. Keep records showing the first two held over time.
The first is an inventory problem, and inventories built from interviews miss what nobody mentioned: 86% of IT leaders report being completely blind to employee AI interactions (Cloud Radix). The second is an authorization problem. The third is a record problem, and it is the one that decides whether an audit goes quickly or badly.
DeepInspect
This is the gap DeepInspect closes. Each of the six documents above expects, in its own words, that AI use is controlled and that the control is evidenced, and DeepInspect sits inline on the HTTP path between authenticated users or agents and any LLM, which is where both happen.
Every request is bound to a verified caller identity, classified against your own data classes, and evaluated against identity-aware policy, with a deterministic fail-closed decision before the call reaches the provider. The same pass builds the AI inventory those standards ask for first, because every endpoint in use appears in the record whether or not it was declared. Each decision commits a signed audit record on a write path the calling application never controls, which is the evidence an assessor tests a control claim against. DeepInspect covers the AI traffic layer and leaves organizational controls, impact assessment, and model evaluation to the programs that own them. If you are mapping to 42001 or the AI RMF and the controls have no runtime evidence behind them, let's talk today.
Frequently asked questions
- Which AI governance standard should we adopt first?
ISO/IEC 42001 if you need a certificate for procurement, because it is the only certifiable AI management system standard. If you already hold ISO 27001, extending that ISMS scope to AI systems is usually faster and cheaper than standing up a parallel program.
- Is the NIST AI RMF certifiable?
No. It is voluntary US guidance with no accreditation or certification scheme. Organizations self-attest against it, and it carries weight with US federal buyers and critical infrastructure programs despite having no certificate attached.
- How do AI governance standards relate to the EU AI Act?
The Act is binding law and the standards are voluntary documents, so conformity today is demonstrated against the Act's own text. Harmonized standards under development at CEN-CENELEC will eventually give a presumption of conformity for specific requirements, at which point compliance against those standards will count directly toward the Act.
- Do these standards require production evidence or just documentation?
Both, in different proportions. 23894 is largely methodological. 42001's lifecycle and system-use controls, the AI RMF's Measure function, and every AISVS runtime requirement expect evidence from operation. Programs that produce only documents pass the first audit conversation and stall on the second.