Most of this workflow doesn't need AI. One step might.

AI strategy is the work of deciding where AI is genuinely useful in a business: which job it should do, what data and system access that job depends on, what needs to be fixed before it is possible, what should stay under human control, and how the opportunity gets tested before anyone commits to building it.

A good AI use case usually repeats often enough to be worth automating, has an input that can actually be reached, needs interpretation that no fixed rule covers, produces something a person can check, and carries a cost of error the business can live with while it is being proven.

AI readiness is whether the specific thing you want to build is actually possible yet: is the workflow clear, is the data reachable and consistent, is there a way into the systems involved, does somebody own the outcome, can the result be measured, and is there a person who reviews it. It is assessed per use case, not as a single company-wide state.

AI opportunities are prioritised by how often the job repeats, how bounded the scope is, whether the result can be checked, and what has to exist before it can start — not by scoring every idea on the same scale and taking the top three.

A bounded pilot is usually the safest way to test an AI use case, because it limits the workflow, the data and the actions involved while still showing whether the idea produces enough value to justify a wider build. It also produces the thing a business cannot get from a proposal: evidence about its own material.

After the strategy phase a business should have a prioritised set of use cases, the findings that block or enable each one, a defined pilot for the first, and a sequence for what follows — including the things that are deliberately not planned.

Buy when the need is standard and a trusted product already does it, because configuration is faster and someone else maintains it. Build when the workflow is specific to your business, depends on your systems and approvals, or has to handle context a product cannot know. Connect when a tool you already pay for has the capability and nobody has turned it on.

Human approval is decided by what an action commits the business to. Low-impact work that is read internally and easy to correct can run on its own within a defined scope; anything that leaves the company usually gets read first; anything that moves money, changes a price or removes data should be decided by a person every time.

After the strategy phase, each prioritised use case has a destination: a workflow to build, a content system, a customer-facing conversation, an internal search layer, ordinary software, or a decision not to build anything yet. A strategy that cannot produce the last one is not making a recommendation.

An AI strategy engagement is sized by how many workflows are being assessed, how many teams and stakeholders are involved, how reachable the data and systems are, how many use cases go into the priority map, how deep the pilot definition goes, and how much architecture, governance and roadmap work the business needs alongside it.

Each project lists the work as it was delivered. Where an assessment leads to a build, that build is a separate engagement with its own scope.

What is AI strategy?

The work of deciding where AI is worth using before anything is built. In practice most of an engagement is spent narrowing: a business arrives with a broad ambition and leaves with two or three specific steps worth doing and a written reason for everything that was ruled out.

What does an AI consultant actually do?

Goes through the work your team does step by step, and returns a decision on each step: ordinary automation, AI, a person, a blocker to fix first, or not worth doing yet. Then puts the ones worth doing in an order, defines the first as a pilot, and says what would make it a success.

Does every business need AI?

No. Plenty of businesses get more from better process, cleaner data or ordinary automation than from anything with a model in it. The point of an assessment is to find out which situation you are in before spending anything.

When should we use AI instead of normal automation?

The test that settles it quickly: could somebody write the rule down and would it still be correct next month? If yes, ordinary automation will do it more cheaply and more predictably. AI earns its place where writing the rule down is the part nobody can do.

What makes a good AI use case?

The one that gets underweighted is checkability — whether somebody can look at an output and tell within seconds whether it is right. A use case nobody can check is not a use case you can run a pilot on, however well it scores on everything else.

What is AI readiness?

A question about one specific idea, not about a company. The same business can be entirely ready for one use case and years away from another, which is why a single organisational readiness rating tells you nothing you can act on. What blocks a given idea is usually one named thing, and naming it is the useful output.

Should we start with a pilot?

Usually, and the reason is evidence rather than caution: a pilot run on your own material tells you something a vendor demonstration cannot. It is worth agreeing in advance what result would make you stop, because a pilot with no failing condition is a rollout that has not admitted it yet.

Should we build AI ourselves or buy something?

Check the third option first, because it is the one people skip: something already in your stack may do this and be switched off. After that it comes down to whether the difficulty is in what is being done, which a product handles, or in how your business does it, which is where building starts to pay.

Do we need our own AI model?

Almost certainly not, and the question usually arrives from a worry about data rather than capability — which is better answered by how a provider handles your material than by training something yourself. The rare case for your own model is narrow, high-volume and already sitting on years of labelled examples.

How do you choose which AI model or provider to use?

Against the task in front of us: how it performs on your own examples, how the provider handles your data, what a run costs at your actual volume, how fast the answer has to come back, what systems it needs to reach, and any constraint on where it runs. The comparison is made per project, because the answers change.

Can AI connect to the software we already use?

Usually, if the system has a way in — an API, an export, or an integration platform that already covers it. Whether that access exists, and what it allows, is one of the first things an assessment checks, because it decides what is buildable.

When should a person approve what AI does?

The practical line is reversibility. If getting it wrong costs a correction, it can run unattended; if getting it wrong costs an apology, a refund or a contract, it should not. Worth deciding once per action rather than per project, because the answer rarely changes between them.

What makes one AI strategy engagement larger than another?

Rarely the technology. It is how many people have to agree — one team assessing one workflow is a contained piece of work, and the same assessment across departments that disagree about priorities is a different engagement wearing the same name.

What happens after the strategy phase?

You should be able to brief somebody else with it. The output is specific enough to act on without us: what to build first, what it depends on, what would prove it worked, and what was deliberately excluded. If the strategy only makes sense with its author in the room, it was a conversation rather than a deliverable.

Can Branditify build what it recommends?

Yes — as a separate engagement, with its own scope. The recommendation is made before that question comes up, which is why an assessment can end with ordinary software, an existing product, or nothing being built yet.

What if the answer is that we should not use AI?

Then that is the finding, and it is worth what you paid for it. Knowing that four steps of a workflow are ordinary automation and one is blocked by a missing definition saves considerably more than a pilot that was never going to work.