← All Insights
AI Governance

AI Governance Is Not a Checklist: Why Certification Alone Won't Protect You

Vishal Akshintala

ISO/IEC 42001 certification has become, in the space of roughly two years, a credential companies reach for the way they once reached for ISO 27001 — a signal to investors and enterprise customers that AI governance has been taken seriously. It is a genuinely useful standard, and certification against it is worth pursuing. But certification measures whether a management system exists on paper against a defined structure. It does not measure whether that system reflects how the company's AI systems actually behave.

The gap shows up predictably during an actual regulator inquiry or a serious investor diligence process. A certified company can produce the required policy documents and still be unable to answer the specific question a reviewer actually asks: which risk tier does this particular model fall into, under which specific framework, and what evidence supports that classification? Certification proves a process exists. It does not, by itself, prove the process was applied correctly to the system in front of you.

A certificate answers 'do you have a governance system.' A regulator asks 'does this specific model comply.' Those are different questions, and only one of them is answered by certification alone.

The practical fix is treating certification as the floor for a governance program, not its output. That means maintaining a living, system-specific risk register that gets updated with each model version, not a static document produced once for the audit. It means documented human-oversight protocols tied to specific product features, not a general policy statement. And it means bias and fairness testing results that exist as artifacts you can hand to a reviewer, not a claim that testing was performed at some point.

Companies that treat certification as complete rather than foundational are the ones that discover the gap at the worst possible moment — mid-diligence, mid-regulatory-review, or after an incident, when there is no time left to build the documentation that should have existed from the start.