The question the board cannot answer
Here is a question I have started asking in board conversations, and it lands like a dropped tray. What AI is running in this company right now, who owns each system, and who is accountable when one of them does something wrong? In most organizations the truthful response is a long pause. Nobody has the list. Marketing bought a tool, support switched on a feature, three teams are piloting agents, a vendor embedded a model into software you already use, and no single person could tell you, on one page, what is deployed, what it can touch, and whose name is against it.
That gap is not a technical problem. It is a governance problem, and it is the one most likely to turn a promising AI programme into a headline. You can have excellent engineering and still be ungoverned, because governance is not about how well the model works. It is about whether anyone is accountable for it, whether anyone decided it was allowed, and whether anyone could explain it to a regulator, a customer, or a court. Right now, for a lot of companies, the answer to all three is no.
Governance is not a brake, it is how you move fast safely
The instinct, especially from engineering and product leaders, is to treat governance as the thing that slows you down. I understand the reflex and I think it is backwards. Ungoverned speed is not speed, it is unmanaged risk that feels like progress until it does not. The teams that move fast and stay fast are the ones with clear rules, because clear rules remove the hesitation. When everyone knows what is allowed, what needs sign-off, and who owns what, people ship with confidence instead of quietly worrying that they are the ones who will be blamed.
Good governance is a set of rails, not a set of brakes. It tells a team: inside these lines, go as fast as you like, no permission needed. Outside these lines, here is who to ask. That is liberating, not constraining. The companies that get this build faster than their cautious competitors and more safely than their reckless ones, because they have made the safe path also the fast path. The ones who treat governance as paperwork to be avoided end up with the worst of both, a slow bureaucracy that still does not actually know what it is running.
What a board actually needs to own
Strip governance down to what a board must be able to see, and it is not complicated, which is why it is so striking how few have it. Three things carry most of the weight.
An inventory. A single, maintained list of every AI system in use, what it does, what data it touches, and what actions it can take. You cannot govern what you have not written down, and the act of writing it down surfaces the surprises, the shadow tools and the embedded models nobody flagged. A named owner for each one. Not a committee, a person, accountable for that system behaving, with the authority to pause it. Diffused ownership is the same as no ownership, and when something goes wrong, "the system did it" is not an answer anyone can stand behind. And a risk classification. Not every AI deserves the same scrutiny. A model that drafts internal meeting notes is not a model that decides who gets a loan, and treating them identically either over-governs the trivial or under-governs the dangerous. Sort by consequence, and put your oversight where the harm would be.
That is the spine. An inventory, an owner, a risk tier. Most of the governance theatre that frustrates good engineers exists because those three basics were skipped, so the organization compensates with blanket process applied to everything.
The regulation is arriving whether you are ready or not
There is also an external clock running, and it is not slowing down. Regulators across major markets are moving from principles to rules, and the direction of travel is consistent: a risk-based approach, where the obligations scale with the potential for harm, applied to the organizations that deploy AI and not only the ones that build it. The detail varies by jurisdiction and will keep evolving, so I will not pretend to a precision the law itself does not yet have. The strategic point does not depend on the fine print.
It is this. The capabilities you need to comply are the same capabilities you need to govern well: knowing what you run, classifying it by risk, assigning accountability, keeping records, and being able to explain a decision after the fact. A company that governs itself properly is most of the way to compliant almost by accident. A company that treats governance as a box to tick later will find that retrofitting it under regulatory deadline pressure, across systems nobody inventoried, is expensive, rushed, and exactly the conditions under which things get missed. The regulation is not the reason to govern. It is the deadline for a thing you should be doing anyway.
Third-party AI is your risk too
One blind spot deserves singling out, because it catches careful companies. Most of the AI exposure in an organization is not the models you built. It is the AI inside the software you already pay for, the features your vendors switched on, the models embedded three layers down in your supply chain. You are accountable for the outcome your customer experiences regardless of whose model produced it, and "our vendor's AI did that" protects you with precisely no one.
So governance has to extend past your own code. It means asking vendors what AI is in their product, what it does with your data, and what happens when it is wrong. It means treating a supplier's AI as part of your risk surface, not a detail in their terms of service. The organizations that get surprised here are not careless, they are simply looking only at what they built, while the larger exposure sits in what they bought.
What a leader insists on
So this is the governance I put in place, and I hold the line on it because the alternative is discovering the gaps during an incident. A living AI inventory, owned by a named person, reviewed on a cadence rather than created once and abandoned. A clear, simple policy that most people never have to think about because the safe defaults are built in, with a known path for the genuine exceptions. Risk tiers that concentrate scrutiny where consequences are real and get out of the way where they are not. Incident readiness, so that when an AI system does something wrong, and eventually one will, there is a rehearsed answer rather than an improvised scramble. And vendor AI treated as first-class risk, not an afterthought.
None of this is glamorous and none of it demos well, which is exactly why it gets deferred until it cannot be. The leaders who build it early look slightly over-cautious for a while and then look prescient the first time it matters. The ones who defer it look fast until the day the question gets asked by someone they cannot wave away.
Where this goes
AI is moving from a tool people use to a set of systems that act, and accountability has not kept pace. That gap closes one of two ways: deliberately, by organizations that decide to own their AI before they are forced to, or involuntarily, by regulation and incidents that impose the accountability they avoided. The first path is cheaper, calmer, and a genuine competitive advantage, because trust is becoming a product feature and governed AI is what lets you promise it.
The board question I opened with is not going away. Within a couple of years it will be routine, asked by regulators, by enterprise customers running procurement, by insurers, by the press after someone else's bad week. The companies that can answer it cleanly, here is what we run, here is who owns it, here is how we know it is behaving, will move faster and sell more easily than the ones still assembling the list. Governance stopped being a compliance chore. It became the license to operate.
I am still refining how light I can make this while keeping it real, and I would value comparing notes. If someone asked your board today what AI you are running and who is accountable, how close is the real answer to a clean one.
I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.
