Myths, Mess, and What Actually Matters
Making AI work in the real world.
I’m currently leading the AI and Data Strategy for a major UK retailer.
Why me? Because I’m a translator.
Not in the linguistic sense, but in the business-critical sense. I speak two native languages - Tech and Exec. And more importantly, I build the bridges between them. Where comms have historically broken down, where prioritisation has been muddied by competing incentives, and where business vision and data capability have been misaligned, my role is to bring sense and synthesis. A through line. The thread that connects business strategy with AI and data infrastructure so they can stop orbiting one another and start driving each other.
There is no meaningful path to success today that doesn’t deeply embed AI and data into the core of the business. Not as an add-on. Not as a side initiative. And definitely not as something managed in a silo, away from the day-to-day realities of how the business actually runs. It has to be foundational. Non-negotiable. Baked in, not bolted on.
Too much of what’s being called “AI transformation” right now is driven by hype cycles, hearsay, and glossy vendor decks. It looks good on paper. It rarely lands in practice.
What follows isn’t theory, it’s what I’m learning by actually doing the work.
From testing and prototyping, through to scaling and deploying across an enterprise.
Where it works, where it stalls, and what it really takes to make any of this stick.
It turns out, a lot of the common assumptions don’t hold up under pressure.
So this is part myth-busting, part reality check.
And part blueprint for anyone trying to make AI real, not just impressive.
I hope it helps.
Myth #1: “Data and AI are separate strategies.”
Reality: They’re two sides of the same system, and separating them is why most AI programs fail.
Data is the fuel. AI is the engine. But more than that - data defines what AI can even do. If your data is fragmented, inaccessible, low-quality, or misunderstood, no model - no matter how powerful - can help you.
That’s why your AI strategy must begin with a data reckoning:
What do you have?
Where is it?
Who can access it?
Is it structured, secure, and usable?
What needs to be enriched, acquired, or invented?
You can’t run before you can walk, and walking means getting your data house in order.
Myth #2: “You can turn on AI with the flick of a switch.”
Reality: AI isn’t a feature, it’s an organisational operating model shift. And it’s hard.
You don’t “switch on” AI. You build for it - across data, infrastructure, governance, and most critically: culture.
This is as much a mindset and muscle shift as it is a tech deployment. And if you keep it siloed inside the tech team or an innovation hub, it will die on the vine. You have to socialise it. Operationalise it. Build cross-functional fluency.
AI has to be:
Talked about openly
Challenged rigorously
Focused on real functions, teams, and pain points
Adapted to context, not imposed from above
Top-down AI strategy without ground-up buy-in is a fast track to shelfware.
If it’s not directly relevant to someone’s actual work, they won’t adopt it.
You find real use cases by listening - sitting with functions, understanding their friction, and co-building solutions they want to use. That’s where traction comes from.
You win by making it usable, not just possible.
Myth #3: “AI is the strategy.”
Reality: AI is a capability. Strategy is knowing what you’re trying to change.
AI is a tool. A powerful one. But it’s not a direction, it’s not a decision, and it’s definitely not a strategy. Yet in boardrooms across the world, “we need an AI strategy” is used as shorthand for “we need to look like we’re doing something.”
The result is often abstract vision decks. Generic use-case libraries. Endless pilots with no path to production. AI becomes the performance of progress instead of the engine of it.
This is what actually matters:
Strategy = What are we trying to do, change, or win at - over time?
AI = How can we do it better, faster, cheaper, or in entirely new ways?
You can’t use AI to accelerate until you’ve defined what good looks like.
You can’t prioritise use cases without knowing which business outcomes matter most.
And you shouldn’t be investing in models or infra without a clear theory of value.
AI should serve your goals, not distract from them.
So start here:
Where do we win?
What bottlenecks are slowing us down?
What’s impossible today that AI might make achievable?
Then - and only then - build AI around that.
AI is an amplifier. If you feed it confusion, it will scale that too.
If you feed it clarity, it becomes a multiplier.
Myth #4: “This is a job for the tech team.”
Reality: AI might be built in tech, but it only works when the whole business takes ownership.
Yes, engineers write the code. But the value of AI is decided by who frames the problem, who defines success, and who turns outputs into outcomes.
That’s why AI can’t sit in a silo. It has to be cross-functional by design.
If strategy isn’t involved, it won’t align with business goals.
If product doesn’t lead, it won’t land.
If ops, compliance, and comms aren’t embedded, it won’t scale, or be safe.
This is where I come in.
I’m not an engineer. I come from strategy.
But my job is to translate - between the technical and the commercial. I bridge the gap between what AI can do and what the business needs to do. That’s what makes the difference between a flashy proof-of-concept and a system that actually ships, sticks, and scales.
You need:
Strategy to decide where AI moves the needle
Product to shape the interface and experience
Ops to integrate it into workflows
Compliance to manage risk
L&D to build internal fluency
Comms to drive trust and adoption
Tech builds it. But the business has to own it.
Translation, not just implementation, is the biggest unlock.
Myth #5: “You have to use the most powerful model available.”
Reality: Use power when it’s needed, not by default.
There’s a tendency, especially early on, to reach for the biggest, smartest, most powerful model out there. It feels like future-proofing. It feels safe. But it’s not.
OpenAI, Claude, Gemini and others are fantastic for rapid prototyping. They help you move fast, validate ideas, and show value quickly. But they are expensive, resource-hungry, and often massive overkill for the thing you’re actually trying to do at scale.
Here’s the smarter path:
Use big models to test the concept
Prove that the use case delivers value
Then optimise for context, cost, security, and control
Fine-tune a smaller model
Explore open-source
Internalise it if your data moat warrants it
Powering up should be a deliberate choice. So should powering down.
This is where strategic maturity lives:
Knowing when to go big
Knowing when to go lean
And building the flexibility to do both
Sometimes the best solution is a lightweight retrieval-augmented generation (RAG) model over your internal documents.
Sometimes it’s a highly tuned LLM that costs pennies per thousand tokens.
Sometimes, yes, it’s GPT-4 (or 5) or Claude 3.5. But you don’t lead with firepower, you lead with fit. And if your use case doesn’t need scale, it’s silly to pay for it.
In the long run, your AI estate should be a modular ecosystem:
High-power for exploration
Lightweight for production
In-house where data is sensitive
External where speed matters
This is why partner flexibility (see Myth #7) is key.
Myth #6: “You can’t succeed unless you share your data.”
Reality: Your data is your moat. Protect it like you would any core IP.
In the rush to experiment with AI, many organisations fall into the trap of handing over their most valuable asset - their proprietary data - without fully understanding the implications.
But once it’s out, it’s out. Even if your partner promises privacy, even if you’re not technically “training” their models, you are creating risk - strategic, reputational, and competitive.
That doesn’t mean you never collaborate. It means you need layers of defence:
Airlocks between your core data and external models
Redaction and masking of anything identifiable or sensitive
Abstraction - sharing only derived or synthetic data to prove the case
Strong governance over who gets access, for how long, and under what conditions
You also need to know what you’re giving up in exchange for speed.
Are you seeding someone else’s model with your customer insights?
Are you making your proprietary pricing logic part of their system’s inference patterns?
Are you allowing exposure of edge-case data that reveals your future product roadmap?
You don’t need to share data to test AI. You just need to be smart about what data, when, and why. Start small. Start anonymised. And when in doubt: assume the whole damn internet is watching.
For companies sitting on deep customer intelligence, historical performance data, or rare operational edge, this is your moat. Your differentiation. Treat it like intellectual property.
Because in the AI era, data powers your models, but it also protects your business.
And once you give it away, you can’t get it back.
Myth #7: “You need one AI partner to build with.”
Reality: You don’t need a a single partner, you need a portfolio.
Too many companies treat their AI stack like a monogamous relationship.
They lock into one platform early, hoping for simplicity, speed, and support.
But no single vendor will serve all your needs. Some will excel at reasoning. Others at speed. Others at multi-modality, privacy, or tooling. The landscape is evolving weekly, and what looks best today may be obsolete tomorrow.
Yes, you’ll likely work with some combination of OpenAI, Anthropic, Mistral, Gemini, Microsoft, and NVIDIA. They each bring strengths. They each have trade-offs. But none of them are your north star. Your business is.
The strategy isn’t to pick a winner. It’s to architect for resilience, flexibility, and leverage: But - and this is key - flexibility without structure becomes chaos. A free-for-all stack creates sprawl, technical debt, security risk, and governance nightmares.
So you need to set the rules of engagement:
Why is this partner involved?
What’s their core role in our stack?
Where are the boundaries - commercially, technically, ethically?
How do we measure their impact?
What’s the exit path if priorities shift?
What are the integration implications - and who owns them?
Think of your AI partner ecosystem like a portfolio: Diversify to mitigate risk. Tailor to fit use cases. Evolve as the market evolves. Retain optionality to adapt when the tech shifts (which it will).
And most importantly: keep control of the architecture. Your tech stack should be composable, not dependent. Because in this space, what looks like commitment today could become constraint tomorrow. So plan accordingly.
Myth #8: “Running open-source or on-prem models is too complex and costly.”
Reality: Yes, it’s heavy lifting. But if your moat is your data, this is where you should be investing.
Running open-source or on-prem models isn’t for everyone. It takes infrastructure, engineering talent, security rigour, and a willingness to deal with real complexity.
But for organisations with rich, proprietary, or regulated data, it’s the smartest long-term play.
You can:
Buy compute (you don’t need to own a data centre)
Outsource engineering (to partners who do this at scale)
Use containerised LLMs, fine-tuning toolkits, and open orchestration frameworks that are improving fast
Build once, and re-use across use cases, safely
What you get in return is not just independence, it’s leverage:
Tighter security
Lower variable costs over time
Control over how models evolve, what they learn, and where they live
A stack tailored to your workflows - not shoehorned into someone else’s roadmap
And perhaps most importantly: When your data is your differentiator, your model should be tuned to it, not abstracted from it. The closer your AI runs to your domain-specific data, the more relevant, performant, and defensible it becomes.
Yes, it’s a higher setup cost. But it pays dividends.
Because in a world where everyone’s using the same public models, your edge won’t come from access alone, it’ll come from what you build on your own terms.
……………………………………………………….
These myths are the straightforward part - the stuff you can name and dismantle on a slide. But the real work is messy. It’s human. And it’s far from linear.
It’s unlearning while relearning.
It’s people before platforms - because if your teams don’t trust or understand what’s being built, the tech won’t land.
It’s translating across visions, vocabularies, and incentives.
It’s making tough calls, fast, in a space that shifts by the week.
It’s betting on a future that hasn’t settled yet, and navigating it with incomplete maps.
Anyone who tells you this is clean, simple, or certain is selling something.
Yes, the tech matters. But the difficult, important stuff is about people. Culture. Communication. Courage. And the willingness to move, even when no one fully knows what the fuck is happening.
Inertia is easy.
Pretty vision decks are easy.
This is hard. And that’s exactly why it matters.



This line is so accurate – “we need an AI strategy” is used as shorthand for “we need to look like we’re doing something.”
Superbly written :)
Excellent points across the board. You’re living a year into the future here. Most of the large enterprises I work with have their AI initiatives firmly led by tech and siloed by engineers. That will inevitably change. AI is a horizontal layer and of course IT will be home base, but it’s absolutely an organizational OS as you state.