Providing a Good Enough Alternative

Shadow use falls when the approved route is easy and adequate. Nothing else in this collection has as large an effect, and it is the part most often done badly.

The recommendations in “Providing a Good Enough Alternative” become easier to sustain when implementation work has visible owners, dates and review time. Teams evaluating time management software can use it to coordinate the operational side of AI adoption and identify where governance tasks are being missed, without treating activity data as evidence of misconduct or as a substitute for asking people why they chose a tool.

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

What good enough means

Available today, not after a request.

Capable of the tasks people are actually doing, which discovery told you.

Not noticeably worse than what they were using.

And visible: people know it exists and how to get it.

Fail any of those and the shadow tool stays.

The capability trap

Organisations frequently approve the most restricted configuration available, then wonder why adoption is poor.

A tool with the useful features disabled is not an alternative; it is a demonstration that the organisation does not understand the task.

Approve the configuration people need for internal work, and restrict only where classification genuinely requires it.

Provisioning speed

If getting access takes two weeks, people will use the consumer tier for those two weeks and frequently never switch.

Default-on for everybody with a plausible need beats request-based.

The licence cost of over-provisioning is usually less than the cost of the shadow use it prevents, and that arithmetic is worth doing explicitly.

Matching the discovered tasks

Discovery produced a list of what people were doing.

Check the approved tool against that list, task by task.

Where it cannot do something, say so and say what to do instead — which is more credible than implying it covers everything.

The parity point

People compare the approved tool against what they had, not against nothing.

Which means an older model, a worse interface or a missing capability is a visible downgrade and will be treated as one.

If the approved option is genuinely worse, acknowledge it and say what you are doing about it. Its own note covers that case.

Making it visible

Announce it properly, more than once.

Put it where people start work, not in a portal.

Include it in onboarding.

And tell people specifically that ordinary use is fine, because the quiet assumption is that anything AI is suspect.

Measuring the switch

Consumer-tier traffic should fall measurably after a rollout.

If it does not, the alternative is not good enough, and that is a finding rather than a compliance problem.

Its own note covers measuring this, which almost nobody does.

What to check

Can somebody with a plausible need get access today?

Does the approved configuration do the tasks discovery found?

Is it noticeably worse than what people were using?

And did consumer-tier use fall after you rolled it out?

The point

Approving the most restricted configuration and then wondering why adoption is poor is the commonest mistake in provision..

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.