"We should be using AI" is not a strategy

“We should be using AI” is a statement of anxiety dressed as a plan.

Four words capable of launching meetings, subscriptions and a surprising amount of slightly panicked activity without identifying a single business priority.

The pressure is understandable.

AI is everywhere. Competitors are talking about it. Employees are experimenting with it. New tools and impressive demonstrations arrive daily, each apparently capable of transforming the business before morning tea.

Doing nothing begins to feel negligent.

So someone says, “We need an AI strategy.”

Perhaps, eventually, the business will.

But producing a strategy before the business has made even one meaningful decision about AI may be an expensive way to document a large collection of assumptions.

At the beginning, the business needs strategic discipline.

That is not quite the same thing.

Start with the business

The first question is not: how should we use AI?

It is: what is this business trying to achieve?

What needs to improve?

Where are customers becoming frustrated?

Where are people spending too much time?

What work is repetitive, slow or prone to mistakes?

Where are opportunities being missed because nobody has the time, information or capacity to act?

Perhaps the digital front door is not working as well as it should. Customers cannot find the right information, the website is difficult to maintain or routine enquiries are swallowing time that could be spent helping people with more complicated needs.

Perhaps employees are repeatedly moving information between systems, producing similar reports or searching through documents for answers they know exist somewhere.

Perhaps the opportunity sits outside the office entirely—in production, quality control, forecasting, equipment monitoring, logistics or customer service.

Those are business conversations.

AI may become part of the answer.

It may not.

That is rather the point.

Find something worth pursuing

A possible use of AI still needs to earn attention.

How material is the problem or opportunity?

Who experiences it?

What happens if nothing changes?

Is the existing work understood?

Is there a plausible reason AI could help?

Could a simpler solution do the job better?

This prevents an impressive tool from arriving first, looking around for somewhere to live and turning the resulting experiment into accidental business strategy.

It also means looking beyond the most visible uses of AI.

AI conversations can become surprisingly office-shaped. They centre on writing, summarising, meeting notes, emails, images and documents—partly because those are the tools many of us can open and use immediately.

But an AI opportunity is not necessarily a ChatGPT opportunity.

For a manufacturer, something worthwhile may sit in production, quality control, equipment monitoring or forecasting.

For a vineyard or orchard, it may involve sensors, imagery, machinery or decisions about crops and conditions.

Some applications combine AI with automation or robotics. Others are not generative AI at all.

The point is not to catalogue every possibility. It is to look broadly enough that the business does not give every employee a chatbot subscription while the more valuable opportunity sits somewhere else entirely.

Once a material candidate has been identified, the business needs enough direction to examine it properly.

A lightweight pilot frame should clarify:

• what the business is trying to improve;
• why it matters;
• why AI may be relevant;
• what assumptions are being tested;
• what risks and boundaries apply;
• who needs to be involved;
• who owns the decision;
• what the business needs to learn;
• what would cause it to proceed, adjust, park or stop.

That is not an AI strategy masquerading as a single page.

It is enough strategic discipline to stop the first pilot becoming random tool play.

Before starting, ask whether the business is ready

“Ready to pilot?” is a small question carrying a surprising amount of weight. Before crossing that decision point, there are some practical questions to answer.

A worthwhile use case may still be the wrong use case to pursue right now.

Can the business assign a committed leader?

Not someone whose name can be placed in a sponsor box and who reappears for the final presentation.

Someone who cares about the outcome, remains engaged, removes obstacles, gets decisions made and protects the team from being continually reclaimed by ordinary operations.

Can the business assemble the right team?

Availability alone is not enough.

The pilot may need people who understand the existing work, employees affected by the proposed change, people with technical or specialist knowledge and someone with enough authority to make decisions.

Do those people have time that has genuinely been allocated and protected?

Can the business provide the information, system access, budget and practical support the pilot requires?

Are the security, privacy and permission boundaries sufficiently understood for this particular pilot?

Can the pilot be stopped safely?

If the answer is no, that does not necessarily mean the use case is poor.

It may mean: not right now.

That is different from rejection.

The business can record why the candidate is not ready and what would need to change before it is reconsidered. Perhaps the required information needs cleaning up. Perhaps another programme is already consuming the people needed. Perhaps ownership or security questions remain unresolved.

A good use case at the wrong time is still the wrong pilot to run.

Then give it a fair test

Imagine a business receives a steady stream of routine customer questions.

Opening hours. Delivery areas. Booking changes. Product information. What to bring. Who to contact.

“We should install an AI chatbot” is a tool decision.

A more useful proposal is:

Could an AI assistant, working from approved company information, answer straightforward questions and pass anything uncertain, sensitive or unusual to a human?

Now there is something to examine.

The business can look at how many enquiries are genuinely repetitive. It can decide which information the assistant may use, where a human must step in and what a useful result would look like.

Perhaps it reduces the number of routine enquiries reaching the team.

Perhaps customers receive useful answers outside normal business hours.

Perhaps it creates a deeply annoying obstacle between the customer and the human they actually need.

That last outcome is also worth discovering.

A small pilot allows the business to test its assumptions before becoming emotionally or financially attached to the tool.

But the pilot needs a fair chance.

A pilot cannot produce trustworthy evidence if the people, information, decisions and protected time promised at the outset disappear once ordinary operations resume. The business may conclude that the use case failed when it never ran a valid test in the first place.

Test the pilot as well as the idea

At the end, the business needs to evaluate two things.

First: did the proposed use work?

• Was it useful?
• Was it sufficiently accurate and safe?
• Did it improve the customer or employee experience?
• What did it genuinely cost to configure, govern, support and maintain?
• Did it create enough value to deserve another step?

Second: did the business create the conditions required to test it properly?

• Were the right people involved?
• Was there clear ownership?
• Was their time protected?
• Did the team receive the information, access and support it needed?
• Were decisions made promptly?
• Did the pilot operate within its intended boundaries?

These are different questions.

A weak use case should not be excused because the team worked hard.

But a worthwhile idea should not be declared a failure when the business assigned the wrong people, withheld the necessary capacity or allowed the pilot to be interrupted into oblivion.

The purpose of a pilot is not to prove that the original idea was right.

It is to produce enough reliable evidence to make a good decision.

Make the decision valuable

Implementation is not the only successful outcome.

A properly run pilot may lead the business to:

• Proceed because the evidence supports implementation or expansion.
• Adjust and retest because the opportunity remains sound but the approach needs work.
• Park because the use may be worthwhile but the business is not ready to continue.
• Stop because a fair test shows that the proposed use does not create enough value.

Donking an idea on the head before it consumes considerably more money, time and attention can be an excellent result.

It deserves to be recognised as one.

If teams learn that only a proceed recommendation will be celebrated, pilots become theatre. People begin defending the original idea, inconvenient findings are softened and money already spent starts driving the next decision.

Success is not implementation.

Success is a trustworthy decision.

Then ask what comes next

One useful pilot does not automatically produce an AI strategy.

The next step may be to implement the use, adjust and retest it, investigate another candidate, improve an underlying process or address a gap in information, systems or capability.

It may be to park the work.

It may be to stop.

Or the business may now have enough evidence—and enough potential activity—to begin a wider conversation about priorities and strategy.

That conversation should reach across the business.

It should gather possible uses, expose constraints and dependencies, identify what matters most and ask why. It may reveal that the business is ready for broader direction. It may reveal that more learning or groundwork is required first.

Either result is more useful than producing a strategy from a standing start and hoping reality eventually agrees with it.

Doing nothing is also a decision

There are good reasons to be cautious about AI. Cost, security, privacy, accuracy and the effect on people all deserve serious attention.

But caution should not quietly become a permanent refusal to look.

Some uses of AI are becoming practical and commonplace enough that deciding not to investigate them is also a business decision. It may mean continuing to absorb unnecessary work, offering a poorer customer experience or allowing competitors to learn while the business stands still.

The answer is not to race towards every new tool.

Nor is it to wait for the landscape to stop changing. We may be waiting some time.

Waiting does not necessarily preserve the status quo. AI capabilities are already arriving inside software the business uses every day—sometimes through ordinary updates, licence changes or features enabled by default. The business may not have chosen an AI programme, but those capabilities may already be entering the workplace through tools people know and trust.

That does not mean every new feature is dangerous or should be disabled. It does mean the business should understand where AI is appearing, what information it can access, what settings and safeguards apply and whether each capability should be used, restricted or switched off.

The useful middle ground is deliberate curiosity.

Start with the business. Identify something material. Decide whether the business can give it a fair test. Put sensible boundaries around it. Assign the right people and protect their capacity. Pilot it. Look honestly at what happened.

Then make a trustworthy decision about what comes next.

“We should be using AI” may begin the conversation.

It cannot be the strategy.