Written by Successful implementation of AI requires a solid strategy. Whilst that might sound overwhelming, there is only a handful of key principles to keep in mind.
On this page
Fundamentally, a good AI strategy builds on the same principles as any other strategy. However, because of the rapid changes in this industry, these principles are less intuitive. This guide will cover what you should look out for when creating your organisation’s AI strategy.
A good AI strategy is an admittedly dry and boring document: decision changes, what solutions pair that change, the order of things, and how you’ll know if you got things right.
What a good AI strategy actually is
An AI strategy is not a technology choice. It’s a subordinate clause of your business strategy, answering one question: which decisions, made repeatedly across the business, would be worth more if they were faster, cheaper, or more consistent?
That framing implicitly states a recognition of a problem: repeated processes are ineffectively handled; and a proposed approach: speed, cost and consistency could optimise some of these. Take note that there is no hint (yet) of using AI or even data. For example, in our engagement with a UK wine distributor, we had discussions with several different stakeholders on a dozen issues. However, only four of those cases had an impactful and meaningful data-solution in the short term. So, we picked those as the starting point of the wider strategy and developed an integrated data platform with automated reporting and generative AI applicability for the more free-form exploration.
The strategy also has to take governance and cost into account. The EU AI Act and equivalent regimes elsewhere mean some use-cases carry compliance weight before you write a line of code, and a model that works cheaply in a demo but costs more to run than the decision justifies isn’t a good strategy either. All subsequent decisions have to follow similar governing rules set out at the start. This will give management a framework to rely on when the project grows.
The main pillars of building a good strategy are:
- Diagnosis
- A stated approach
- Coherent action plan
How to pick a good use-case
When deciding on the scope of your AI strategy, you always have to consider the above three points as the principle for a solid framework.
Then, for AI projects, you ultimately have to ask whether AI is a right solution. Whilst this is not a black and white decision, here are some guiding principles to pick the right problems:
- The decision is already being made, often, by a person: This will provide the benchmark for success.
- The judgement is pattern-based, not principled: Whilst more advanced AI models are capable of less-pattern-based delivery, these are difficult to scale and so it is best to stick to this point for your groundwork.
- Someone can name key changes after the work is complete: If the ideal outcome wouldn’t change anyone’s workflow, the problem isn’t ready to be meaningfully solved. Consequently, the business impact will be minimal (not a good strategy).
- What is the tolerance for being wrong: Depending on your use-case a model with 80% accuracy is excellent or a catastrophe. It is paramount to consider these thresholds and decide whether an AI solution is safe or there needs to be a human in the loop (or no AI at all).
We’ve written a fuller framework for scoring candidate use-cases and checking whether your data can actually support them in our piece on AI readiness: it covers the core questions to ask of each data source and the team you need on-board before you commit.
Picking the right AI tools
Technology for the problem’s sake
Once the use case is picked, resist the urge to reach for the most capable technology on the market. Reach for the cheapest one that meets your requirements. A mechanical logic with quality data might outperform a fine-tuned model on a small, well-defined problem.
The same principles apply to the project infrastructure as well. We optimised a client’s cloud warehouse by splitting the workload into distinct storage and analytics flows and picked the appropriate (i.e. cheapest) database solution that excels in those respectively. The monthly costs dropped from around £5,000 to just £300 with 97% of queries still running under 5 milliseconds. Same vendor, same account, correct tool for each half of the job. The discipline is very simple: match the tool to the shape of the workload, not to what’s trending.
The same logic applies to cutting edge AI layers too. A vendor API is usually right for a first version of a well-scoped task. A fine-tuned or self-hosted model should be considered only if its costs outweigh the volume, latency, or data-residency costs associated with a vendor API. You should switch when your current approach becomes unmaintainable, not when there’s a trend for it.
Be incremental
Ship the narrowest version of the use case first, on the smallest slice of the problem that produces a real, measurable outcome, then widen it.
Three reasons this matters. First, a narrow first version gives you an effective check on whether the use case was well-chosen before you’ve spent the annual budget finding out. Second, most of the cost of AI projects is in the plumbing, not the modelling, and you learn where your data actually breaks or becomes unruly by shipping something small. Third, a working small thing builds the internal trust to go do the ambitious thing next; we had been called into projects that were being abandoned because trust was not backing them.
Furthermore, an incremental approach ensures there’s a sequence of things that ship and get measured. Reevaluation and steering is a natural feature at every point of delivery, making your AI strategy flexible and robust.
Build on what you already have
Most companies underestimate what they already have and overestimate what they need to buy. The most valuable dataset in the building is often a spreadsheet someone already maintains by hand; and in our data platform management projects we so often rely on the expertise put into these manual reports.
The same applies to outside expertise. Bringing in specialists earns its cost when it closes a specific gap you lack internally. What a data consultancy actually does and when it’s worth the call is its own question, but the short version is the same discipline as everything above: bring in the expertise the problem at-hand requires, on a well-defined timeline, with a well-defined and strategic set of outcomes.
Build a roadmap that fits the wider business strategy
A use case in isolation is a pilot. A sequence of them, each building capability the next one needs, is a roadmap to your strategic goals. The roadmap should read like a business plan. Avoid referring to specific technologies or solutions. Focus on time-scales, decisions made, measurable improvements, budgets and required project owners. Scope out milestones building on each other, and make sure there is a room for ambiguity and learnings for goals further down the line. Of course, do this without losing sight of what matters.
Two things keep a roadmap relevant and transparent. First, every item ties to a business objective someone in the room actually cares about. Second, the roadmap accounts for the running costs of AI systems. Things that go beyond the initial build are: drift, upstream schema changes, provider churn, and the ongoing human review that keeps a model’s judgement calibrated to a business that keeps changing under it. A roadmap that only budgets for launch will undermine its own success when maintenance gets neglected and outcomes deteriorate.
How FloreData can help
FloreData is a data and AI consultancy built with a people-first mindset. We help with the parts of your AI strategy that are easiest to get wrong from the inside:
- Use-case selection. Scoring candidate decisions on value, frequency, data availability and error tolerance, including an honest recommendation when the answer is “this isn’t an AI problem.”
- Right-sizing the stack. Matching infrastructure and modelling approach to the actual workload. For example, our data warehouse migration above.
- Incremental delivery. Shipping a narrow first version fast enough to learn from, with a roadmap for how to build on top.
- Handover. Documentation and knowledge transfer so the capability stays with your team, not locked inside ours.
See our case studies and data and AI engineering services for more details.
Not sure where to start? Start a conversation and we’ll help you find the first use case worth shipping.
