As an architect, I’m watching a still-immature space, one where organisations are throwing themselves into AI faster than the structure around it can keep up. I keep seeing the same moment play out, usually right after something goes slightly wrong: who was supposed to be watching this? A chatbot gives a customer bad advice. A model quietly drifts after a few months in production. A team spins up a new use case on a foundation model without checking whether it’s allowed near the data it’s touching. Each time, I look for the model problem, and each time, I find a structure problem instead. That’s the perspective I bring to AI: the model is rarely what actually failed. What was missing is the structure meant to catch exactly this. That structure is AI governance.
A fair objection is that every area of an organisation needs governance, and AI is no different in that respect. I’ve spent enough time in data governance to know it already solved a version of this problem: shared definitions, named owners, a RACI structure that removes ambiguity about who decides what. I borrow all of that when I set up AI governance, but I treat it as its own discipline, for one specific reason: AI systems change on their own.
A dataset doesn’t quietly start behaving differently six months after it’s approved. A trained model can. It drifts as the world it was trained on shifts. It gets fine-tuned, repointed at new data, or wrapped in a new application, and its behaviour changes in ways that are genuinely hard to predict from the outside. The governance structures I built for static things, a dataset, a report, a database schema, never had a mechanism for catching a system that keeps changing itself. The ones I build for AI have to.
Closing the Maturity Gap
The gap I keep describing, adoption outpacing structure, isn’t permanent. I’ve found it only closes when governance is designed to move at the same speed as the AI it oversees, as a living system rather than a fixed rulebook.
Four practices make that possible, in my experience:
I treat governance as a product, not a policy
I give the governance framework an owner, a backlog, and a release cycle. Every incident, audit finding, and regulatory change becomes an input to the next iteration, the same way user feedback shapes a product roadmap.
I embed the gates in the delivery pipeline
Approval, documentation, and monitoring requirements should live inside the same tooling teams use to build and deploy models. A gate that runs automatically at deployment keeps pace by construction; a committee that meets quarterly does not.
I review on triggers, not on calendars
I schedule re-assessment around change events: a model retrained, a use case repointed, a new regulation announced. Calendar-based reviews assume a static system; trigger-based reviews match a system that changes on its own.
I scan the horizon deliberately
I assign explicit ownership for tracking new AI capabilities and emerging regulation, and route the findings into the charter and the risk-tiering criteria. Governance that only reacts to what’s already deployed will always lag; governance that anticipates the next class of use case arrives together with it.
Leave a Reply