You wrote an AI policy. You posted it to the intranet, presented it at an all-hands, and added a line about AI governance to the leadership deck. That’s real in one narrow sense: the document didn’t exist before, and now it does.
But a policy isn’t governance. Governance is the set of things that are actually different at work next week. A document only records what you meant to do, and nobody was ever short on intentions.
Most organizations, maybe even yours, could have started much earlier. A year ago, two years ago, the tools were already open in everyone’s browser, and the exposure was already sitting in your contracts, your code, and your customer data. ISO 42001 was established in 2023, the same year the NIST AI Risk Management Framework was published. Some of the delay was reasonable. The technology kept moving, the budget wasn’t there, and regulators hadn’t said anything yet. Being careful was the correct instinct. But the guidance has been out for three years and counting, and caution is easy to mistake for diligence: at some point it becomes a way of putting off the decision rather than taking action.
Execution is difficult. It asks for trust, for the willingness to disagree in the open, for a real decision someone has to commit to, for the discipline to be held to that decision afterward, and for caring more about the result than about how it looks. Those happen to be the five things Patrick Lencioni says a functioning team needs, which means they are also the five things your council will deal with.
1. Absence of Trust. A Room That Won’t Admit What It Doesn’t Know
Trust, in Lencioni’s sense, is the willingness to look uninformed in front of each other. Most AI councils run the other way. There’s a tacit agreement not to say the obvious thing: hardly anyone at the table really understands the technology they’ve been asked to govern. That’s no special failing of the council. Even the people who build these systems can’t fully predict how they behave, let alone how to secure or govern them.
The failure isn’t the gap; it’s the silence around it. A gap no one will admit is a gap no one can close. So the room settles on the one thing it can agree on without anyone exposing themselves: that employees, left alone with these tools, will leak data or create a mess the council gets blamed for. Restriction becomes the default setting and blocking becomes the easy answer, all of it resting on the assumption that employees are a hazard to be managed rather than people who might do something useful with the tools. A group that can’t be straight with itself isn’t going to produce anything but lockdown.
Restriction becomes the default setting and blocking becomes the easy answer, all of it resting on the assumption that employees are a hazard to be managed rather than people who might do something useful with the tools.
2. Fear of Conflict. The Conversation That Never Happens
Governance turns on one question that has to be argued all the way through: given the constraints you actually operate under, where does acceptable risk end and real value begin? In a regulated business, legal, compliance, and security should have a strong voice in that argument, and that part is fine. What goes wrong is that nobody does the harder work of figuring out what’s still possible inside those constraints. The first credible risk anyone raises ends the discussion, because saying “no” requires no follow-up and no defense, while saying “yes” requires both.
The conflict that most needs airing usually runs upward, not across the table. When the CEO declares that every team will have a set number of AI pilots running in ninety days, the mandate itself collides with good governance and security, and everyone in the room knows it. But nobody wants to be the one who disagrees with the CEO, or with the chorus that formed behind the CEO before the meeting ended. So the council absorbs an impossible deadline rather than arguing it down to a defensible one, and the policy inherits the contradiction: move fast by decree, stay safe by implication, and never say out loud that the two instructions point in opposite directions.
Given the constraints you actually operate under, where does acceptable risk end and real value begin?
3. Lack of Commitment. Vagueness in the Shape of a Policy
With no real argument, there’s no real decision, so the document falls back on language like “use AI responsibly” and “exercise good judgment.” Those phrases sound like guidance but commit to nothing; because no one can act on them, no one does. The vagueness isn’t careless writing. It’s doing exactly what it’s there to do: spare the council from making a call that someone might later be asked to stand behind.
The missing piece has names attached. Commitment belongs to the people on the council: legal committing to what it will clear and how quickly, security committing to which tools it will approve, and business owners committing to what they will actually pilot. And commitment is measured in resources, not sentiment. This is no longer just an opinion: ISO 42001, the management-system standard for AI, makes dedicating resources to managing AI systems an auditable requirement. A council with no staffing, no budget, and no time allocated to run what it governs isn’t merely under-committed. It’s carrying the kind of gap an auditor writes up as a finding. If nobody’s calendar changed and nobody’s budget changed, nothing was committed. The policy is just the written record of those commitments. Without them, it is prose.
4. Avoidance of Accountability. No One Owns What Happens Next
Time passes, adoption goes nowhere, and people start quietly pasting source code and client data into consumer chatbots, mostly because the approved route is a dead end. When that surfaces, the council can point to the document and say it published a policy. That’s the full extent of what it’s answerable for. There’s no metric attached, no name attached, and no consequence for the distance between what the policy said and what actually changed, which, by now, is nothing.
5. Inattention to Results. No Read on Adoption or Value
In the end there are only two things worth knowing: whether people are actually getting good use (call it ROI) out of AI, and whether the risk is going down. Answering those two questions is the whole reason the council exists. A dysfunctional one can’t answer either. By the time you’ve avoided the honest conversation, assessed no risk, built no controls, and assigned no owner, there is nothing left that can be measured. What the council can still count is its own activity, the meetings and the documents, and it treats that as a sign of progress. This is not so much the fifth failure as the result of the other four.
Governance and Security Are Cultural, Not Single-Shot Actions
The five are not a list of separate faults; they follow from one another. A council that will not admit what it does not know cannot hold the risk conversation. Without that conversation there is nothing real to decide. Without a decision there is nothing to hold anyone to. And a body accountable for nothing will measure everything except whether it worked.
The fix is not a better document. It’s a council that can do the five things this one couldn’t: admit what it doesn’t know, have the argument, commit with names attached, own what happens next, and measure whether any of it worked. That’s governance.
If any of this sounds like your company, that’s because it sounds like most of them. Your council won’t fail because the people on it are bad at their jobs, but because it can’t see what it’s deciding about: it has no picture of what employees actually want to do with these tools, no honest sizing of the risk, no controls worth the name, and no number that would tell anyone whether a single thing it did made a difference. Getting that picture is the cheapest fix available: before the next meeting, ask people what they are using and what they wish they could use. The answers turn the council’s guesswork into something it can actually govern.
The framework referenced in this piece is adapted from Patrick Lencioni, The Five Dysfunctions of a Team (Jossey-Bass, 2002).