Writing

IT governance was built for recommendations, not actions

The article I keep coming back to is titled “Who gets to decide?”, and the question is more precise than it looks. Most IT governance was built for systems that recommend, not systems that act. A dashboard can suggest, a scoring model can rank, a rules engine can flag. Governance around those systems is mostly about review, validation, and sign-off. When the system itself takes an action, that governance no longer fits. The assumption underneath the old model is that a person will always be there to accept or reject the recommendation. That assumption is now the bottleneck.

The shift matters because agents are moving from the recommend side to the act side. They don't just surface an exception; they approve it. They don't just flag a transaction; they block it. The architecture of authority changes at that boundary. A recommendation can be wrong without doing damage. An action can be wrong and create a liability, a customer incident, or a compliance problem before anyone notices. The gap between those two outcomes is where the new architecture of enterprise authority has to live.

This is where I part company with the idea that model confidence solves the problem. Confidence is a technical property. Authority is not. If a model is 94% sure a payment is fraudulent, that still doesn't answer whether it is allowed to stop the payment. A model can tell you what it thinks; it cannot tell you what it is allowed to do. That decision belongs to the business, and it has to be encoded as policy, not inferred from a score.

Authority isn't a technical property; it's a business decision that must be encoded as policy, not left to model confidence.

The fraud example makes the difference concrete. A fraud model that flags false positives is annoying. Analysts waste time, customers get asked for verification, and the backlog grows. But the system is still fundamentally in recommendation mode. The business can ignore the flag, adjust thresholds, or accept the noise. The same model set to auto-block payments is no longer a filter; it is a decision-maker. A false positive becomes a revenue incident and a customer experience problem. The cost of being wrong changes category, and the governance has to change with it.

That is why the authority matrix matters. For every automated action, someone has to say who decided that the system may act, under what conditions, and what happens when the model is wrong. This is not a data science artifact. It is an accountability structure. It should name the action, the policy that permits it, the owner who approved it, and the path for a human to override or escalate. The matrix doesn't have to be heavy; it has to be explicit. It can start as a table that maps each automated action to its policy owner and escalation path.

I don't think this means slowing automation down. It means being explicit about what automation is allowed to do. The bottleneck isn't the model; it's the absence of a mapping from model output to business authority. When that mapping exists, agents can act faster because the decision to act has already been made by someone accountable. When it doesn't exist, the organization is pretending that a confidence score can carry authority it was never given. That is not a technical problem; it is an organizational one.

CIOs will have to build that matrix before the models ship, not after the first revenue incident. The article's title asks who gets to decide. The answer has to be: the business decides, in advance, and the system encodes that decision as policy. Everything else is just confidence wearing authority's clothes.

Originally covered at cio.com ↗