AI Governance for AI Vendors: Practising What You Sell

The full executive answer

I will give you the honest maturity picture rather than an org chart we do not have. What exists today is governance as enforced code, which for a company of our size is stronger than governance as committee minutes. Concretely: a model registry that the build pipeline forces engineers to update; model cards for every AI module with purpose, model family and an EU AI Act risk classification; an append-only audit log of every generation, fallback and cache event; hard quality gates — types, lint, tests, eval harness — that block any change from shipping; and kill switches at three levels: per-tenant no-third-party-model policy, consensus and guardrail modes, and an EU AI Act geo-gate.

Mapped to ISO/IEC 42001, the AI management system standard: our policies, inventory, operational controls, and monitoring exist in code and documentation; what does not yet exist is certification, an external audit, or a formally chartered AI governance committee with independent members. As a pre-launch company, the accountable person for AI risk is me — the founder — and I would rather tell you that plainly than invent a committee. The roadmap, in order: qualified counsel sign-off on the EU AI Act workforce classifications, then a formal governance charter as we take on enterprise customers, then external audit and ISO/IEC 42001 certification when scale justifies it.

One thing I would gently point out: most vendors who show you a governance committee slide cannot show you a build that fails when a model is swapped without a governance entry. We built the enforcement first because committees without enforcement are how AI incidents happen.