Principles I Keep Coming Back To

Roles tell you who; these principles tell you how I actually run it once the roles are in place. The building blocks describe what I assemble; these principles describe how I assemble it well. Each is a test I run a governance design through before I roll it out.

Governance should scale with risk, not with enthusiasm

I don’t govern an internal drafting assistant the same way I govern a model approving loan applications. They’re not the same risk category, and treating them identically either slows the harmless use case to a crawl or under-governs the dangerous one. I tier the process; I don’t flatten it.

Somebody has to own the outcome, not just the model

It’s tempting to let a promising pilot go live because the team building it is clearly capable. I’ve learned that capability isn’t accountability. If nobody can answer who owns this if it goes wrong before launch, that’s the actual blocker I look for, not a formality to clear afterward.

The feedback loop is not optional decoration

The people using an AI system’s output are often the first to notice when it’s wrong, well before any dashboard does. If a governance structure doesn’t route that feedback back to whoever monitors the model, I treat it as missing its own early warning system.

Stay nimble

I don’t let AI governance become heavy-footed. I start small and stay nimble, building with the granularity in the organisation that provides agility and value, not the granularity that merely looks complete on a policy document. That’s the same instinct behind the four practices I opened with: a governance framework that moves like a product, with gates, triggers, and horizon-scanning built in, stays nimble by design. One that sits still as a static rulebook doesn’t.

Pages: 1 2 3 4