When the Approved Tool Is Worse

The approved option is frequently a generation behind, more restricted, or missing the capability that made the shadow tool worth using. Denying it does more damage than the gap does.

The controls in “When the Approved Tool Is Worse” only remain useful when someone owns the reviews, exceptions and follow-up work. An organisation evaluating this working reference can attach time and responsibility to those recurring governance tasks, but the platform should support the policy rather than decide whether an AI use case is acceptable.

For an independent benchmark, compare the local approach with NIST AI Resource Center; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

Why it happens

Procurement takes months and the field moves faster.

The enterprise configuration disables features for risk reasons.

The chosen supplier is the one with an acceptable contract rather than the best tool.

And integration with existing systems weighs more in the decision than capability does.

Each is a defensible reason and together they produce a real gap.

What not to do

Claim parity that people can disprove in a minute.

They will test it, find the difference, and conclude the whole policy is uninformed.

One overstated claim costs more credibility than the gap itself.

The honest response

Name the gap: the approved tool does not do this, we know, here is why.

Say what you are doing about it, with a date if you have one.

And give interim guidance for the affected task — which may be an exception, a different approved tool, or doing it the old way.

When the gap is large enough to act on

If a substantial task cannot be done, that is a procurement failure rather than a user compliance problem.

Revisit the configuration first: frequently the capability was disabled by a default rather than by a decision.

Then the supplier, then the choice.

The configuration check

Worth its own look, because it is the cheapest fix available.

Organisations routinely deploy the most restricted settings and never revisit them.

Go through the disabled features and ask which were disabled for a stated reason and which by default.

The second category is usually larger.

Accepting a gap deliberately

Sometimes the answer is that the capability is not available with acceptable terms.

Say that, specifically, and record it as an accepted limitation with the reason.

People handle a stated constraint; they route around an unexplained one.

What this buys you

A programme that admits its tool is behind is believed when it says something else is dangerous.

That credibility is the main asset the programme has, and overstating capability is the quickest way to spend it.

What to check

Do you know where your approved tool is behind what people were using?

Have you said so?

Were any features disabled by default rather than by decision?

And is there an accepted-limitations list with reasons?

The point

If the approved tool is genuinely worse, say so.

One overstated claim costs more credibility than the gap itself.

Underlying all of this

Everything in this collection reduces to four habits: find out what people are doing and why before deciding anything, provide something good enough that the approved route is the easy one, write rules about information rather than about tools, and monitor the destination rather than the content. None requires a product, and a programme doing all four controls more than one built on prohibition.

The recurring pattern

The recurring pattern across every section here is the same: the response that feels like control reduces it. A ban removes visibility rather than use. Content inspection drives activity to personal devices. A discovery exercise with consequences produces quiet answers. In each case the organisation ends up knowing less about a risk it believes it has handled.