Why Most AI Adoption Fails (And What Actually Works)

Scott Evans made a New Year’s resolution at the end of 2024 to quit his job by May without knowing what he would do next, and ten months later runs Wonderland AI, teaching leaders and teams to use AI without the hype. Richard Geary took a deliberate year out after 25 years in corporate technology, spent it renovating a house and asking small business owners peculiar questions about their processes, and came out of it running Flow HQ. Together with others they founded the AI Foundry, a community that started as nine people in a Paddington pub and now runs to over a hundred. In this episode they talk to Rob Woodhead about why so many AI rollouts stall after week two, what genuinely belongs in an AI policy, how to tell a credible AI consultant from a confident one, and what happens to all of this when the pricing stops being subsidised.

Key takeaways

• Most AI rollouts fail at enablement rather than at procurement, because a licence gives people access without giving them capability.
• AI differs from previous business software because it arrives unconfigured, which makes experimentation a necessary part of adoption rather than an optional extra.
• Buying a tool and then hunting for a problem to apply it to is the most common and most expensive sequence, and the reverse order works.
• A small champion group testing first produces better adoption than issuing licences to everyone at once.
• The most diligent employees often adopt last, because they are the most worried about getting something wrong.
• An AI policy can be one or two pages: approved tools, what data may and may not go in, and who to ask when unsure.
• Most data incidents are not malicious, they are someone pasting client information into a free tool nobody told them not to use.
• Consumer AI tools default to sharing your data for training, and paying for a personal plan does not give you enterprise protections.
• Current AI pricing is subsidised, and businesses building on it should plan for the point where a small monthly line item becomes a large one.

Episode chapters

• 01:24  Scott: a New Year’s resolution to quit without a plan
• 04:18  Richard: taking a year out and finding an underserved market
• 07:50  Why it is hard to change your trainers while on the treadmill
• 08:30  Nine people in a Paddington pub, and the origin of the AI Foundry
• 10:37  Creating a space where leaders can say they do not know
• 16:27  Why AI rollout is different from any previous software rollout
• 19:37  Why Copilot licences go unused after six months
• 22:39  AI champions, psychological safety and the drop-off after week two
• 25:48  The use cases that work for almost every knowledge worker
• 28:32  Vibe coding in larger businesses, and the shift to interactive artifacts
• 31:00  Ecosystem, context and how many AI tools one person needs
• 34:34  AI governance, and the three Vs of data
• 38:00  What a leak actually means when it involves an LLM
• 39:51  What belongs in an AI policy, and why it can be two pages
• 43:26  How to tell a credible AI consultant from a confident one
• 48:02  Predictions: agents, the business brain and cultural change
• 51:56  The end of subsidised pricing

Why do most AI adoption projects fail?

Because organisations buy the tool and then go looking for a problem to point it at.

Richard describes the correct sequence as the exact inverse: understand your processes, identify your pain points and opportunities, then buy the tool that addresses them, then invest in the enablement that lets people actually use it.

Scott’s diagnosis of the same failure focuses on literacy. Companies distribute Copilot licences across the business in one go, without anyone having established what the tool is for, and adoption collapses. There is a widespread lack of understanding of what AI can do, and no corresponding sense of urgency about upskilling people, while media coverage simultaneously insists that a single agent is about to replace the workforce.

His illustration is domestic and effective. His wife is a teacher. He runs two AI businesses. When he asked whether she had used Copilot, she asked whether that was the rainbow-looking button in Outlook.

Richard adds a structural point that makes this worse than it first appears. Applying AI to a process that is already broken or poorly defined does not fix the process. It shows you what bad looks like at scale, and faster.

What makes AI different from other software rollouts?

It arrives unconfigured, and that changes everything about how you introduce it.

Richard’s point comes from years in SaaS. When you bought traditional software, it was configured for you and you used it in the way it had been configured. AI is not that. It is a tool that acts as a doorway to a set of capabilities, which means how an individual uses it matters more than with any business tool he has seen deployed.

The consequence is that experimentation becomes part of the rollout, which is genuinely new. Walking into a leadership group of eighty people and telling them everyone is going to experiment produces visible panic, because experimentation is not how businesses usually operate. Most people want a defined process to follow repeatedly. What is being offered instead is a capability they have to collaborate with in order to work out what their process should be.

That collides with the two things businesses hold most dear, quality and consistency, because two people using the same tool in the same company with slightly different prompts will get materially different results.

How should a business actually roll out AI?

Small group first, then everyone, with education throughout.

Scott recommends a champion group of around four people rather than a broad distribution of licences. Let them test, find real use cases, and identify which business problems AI can genuinely solve. Flooding the organisation with access before anyone knows what it is for is what causes adoption to fall away.

Richard’s version layers basic education for everybody underneath the champions, so that the use cases the champions establish can be published downwards as examples for people to follow.

His observation about who adopts last is worth sitting with. It tends to be the most diligent employees, precisely because they do not want to get something wrong, make a mistake or leak anything. Those people need explicit permission and psychological safety: the tool is sanctioned, here is how to take your first step. Providing that, he argues, accelerates adoption sharply.

He also notes that adoption is genuinely voluntary in a way earlier technology was not. You cannot mandate use before you know the use cases people will have.

On the drop-off pattern, Richard cites Microsoft research on a very large user base showing enthusiasm in week one and a collapse by week two, which he compares to gym attendance in February, with real value only arriving months later. What pulls people back in is champions, enablement programmes, hands-on days and hackathons, because the only way to get better at these tools is to use them.

Which AI use cases work for most businesses?

The ones common to nearly all knowledge work, before you niche down at all.

Richard puts deck creation near the top, citing a figure that the average knowledge worker spends around a day a week reading and building presentations. Generating summaries, or building decks from meeting notes, takes a visible bite out of that.

Then the basics: meeting note takers, which are now near-universal and let people be present in a conversation instead of transcribing it; summarising long documents; comparing two documents and identifying the differences; and catching up on an email thread or an entire inbox after time away.

Beyond that it niches immediately, and pharma, law and a cabinet maker share very little. Richard’s own favourite example is from before Flow HQ existed: helping a cabinet maker take proposal generation from two or three hours down to roughly fifteen minutes, drawing included.

The more advanced pattern is chaining tools together, so a meeting produces notes, which produce a presentation, which produces an executive summary. He is candid that agents themselves are frightening to most businesses right now, with good reason, but chaining is available today.

What remains human, on his account, is relationships, genuine creativity and novel ideas, none of which these tools are good at and may not be for some time.

What should an AI policy contain?

Less than people fear. Scott is emphatic that this does not require an enormous document, and that one or two pages will do for most businesses.

The essentials: which tools are approved, what data may and may not go into them including client data, financials and IP, and who to ask when someone is unsure. His point about why this matters is the important one. Most breaches are not malicious. They are someone pasting client information into a free tool because nobody told them not to.

He also recommends keeping an inventory of where AI is actually being used across the business, and reports being repeatedly surprised by how few companies know. Marketing may be using a video generation tool, and existing vendors frequently add AI features to products already in the stack, which means data starts flowing somewhere new without any fresh vendor assessment. Human review should be mandatory for anything client-facing or decision-making, particularly given the EU AI Act if you serve EU customers.

Richard’s addition is about defaults, and it is the single most practical thing in the episode. These tools are configured to share by default, because the companies building them want data. Signing up to ChatGPT or Claude without changing anything means your conversations feed their training. Paying for a personal plan does not confer enterprise protection, because you are renting a capability rather than owning one.

On governance more broadly, he is unromantic: it is old-fashioned consulting work. Process mapping, five whys, and the three Vs of data, volume, veracity and variety. Where does the data sit, how much is there, what is in it, is it labelled, and how quickly does it move and to where. That last question is where he sees most organisations come unstuck.

He also draws a useful distinction about what a leak means in this context. The well-known case of engineers pasting proprietary source code into an LLM is not a leak in the sense of information appearing publicly. It is that the material left the company’s control and now sits on someone else’s server. The probability of prompting it back out is very small. The loss of ownership is the actual problem.

How do you spot a credible AI consultant?

The same way you check anything else, with one addition that is specific to this field.

Scott’s test is proof. Plenty of people post confidently about AI on LinkedIn with nothing behind it. Look for real named use cases, evidence of actual client work and demonstrated return on investment, rather than an unbroken stream of thought leadership with no substance underneath. He is fair about it too, noting that everyone starts somewhere.

Richard puts weight on references, and on speaking to someone the consultant has actually worked with rather than reading the curated five-star quotes on their own site. He also thinks the human fit is a legitimate criterion, and says plainly that he has encountered obviously talented people in this industry whose working style meant he would not work with them.

The addition specific to AI is his sharpest observation. Ask an AI tool. If you cannot find the consultant you are considering through an AI model, and they have not managed to get their own site surfaced and recommended, that tells you something about whether they can do it for yours.

Scott confirms the traditional check still happens: a prospective client recently phoned one of his past clients to verify he was legitimate before engaging.

The same principle applies to any technology partner. You can read how we work with clients and see the products we have delivered.

What happens when AI pricing stops being subsidised?

Both guests think this is the story the next eighteen months will actually be about, and that it is underpriced into most people’s planning.

Scott’s framing is that we are in a grace period. Providers are offering enormous capability for very little while losing money, and he does not expect that to continue. He notes providers already adjusting what sits inside entry-level plans. The consequence for businesses is that AI cannot simply be rolled out everywhere and called a strategy. You have to know where it earns its cost.

Richard would treat it like an outsourcing decision and apply the same diligence. He cites a company that went all in on agents and is averaging a few hundred dollars a day in token spend, which annualises to roughly the salary of the engineer it replaced. The headcount moved. The cost did not.

He also points at the structural driver. The major providers are widely expected to go public, and once they do, the question of where every dollar comes from arrives abruptly. His question for any business building on these tools is what happens when a thirty dollar per month line item becomes three hundred, or three thousand.

On the wider prediction, he expects AI to stop being a novelty and simply become a thing, with more spend flowing to enablement, agentic capability arriving inside the ecosystems businesses already use rather than being assembled by hand, and a cultural shift towards smaller teams of individual contributors working alongside agents. He also expects a swing back: he points to a large software company that reduced support headcount substantially, then rehired a considerable number after concluding the models were not where it had expected them to be.

The idea he keeps returning to is the business brain: a company’s information consolidated and linked in a way that makes sense, with an agentic layer above it and humans as instigator and reviewer. He is realistic that structuring data to be both human-usable and token-efficient is its own substantial problem.

About the guests

Scott Evans is the founder of Wonderland AI, which helps senior leaders and their teams cut through AI hype and get practical results. He spent eight years delivering digital transformation in financial services and fintech before starting the business. He is a co-founder of the AI Foundry.

Richard Geary is the founder of Flow HQ, helping business owners make practical AI decisions that fit real budgets and real workflows. He spent 25 years in corporate technology, including senior roles at Salesforce and SeatGeek, and is also a co-founder of the AI Foundry.

The AI Foundry is a free community for business owners and leaders navigating AI adoption, offering resources, peer discussion and regular in-person events. It began as nine people meeting in a pub in Paddington and now has over a hundred members.

About the host

Rob Woodhead is a co-founder of Old St Labs, a London-based software agency building web and mobile products for startups and innovators. He also runs Tech Startups in the Pub, a monthly London gathering of founders.

Frequently asked questions

Why do AI rollouts fail in businesses?

Usually because organisations buy tools before understanding their processes, and distribute licences without enablement. People are given access but not shown what to ask, so usage drops away within weeks and the investment produces nothing measurable.

How should a company introduce AI to its staff?

Start with a small champion group testing real use cases, supported by basic education for everyone else. Publish what the champions learn as examples others can follow, and give explicit permission to experiment, since cautious employees typically adopt last.

What should be in an AI policy?

Approved tools, what data may and may not be entered, who to consult when unsure, an inventory of where AI is already used across the business, and a requirement for human review of anything client-facing or decision-making. One or two pages is enough for most companies.

Is my data used to train AI models?

By default, usually yes on consumer plans. These tools are configured to share, and paying for a personal subscription does not provide enterprise-level protection. Settings need changing deliberately, and enterprise agreements offer materially different terms.

How do you choose an AI consultant?

Look for named use cases, demonstrated return on investment and references you can actually speak to, rather than volume of thought leadership. Richard Geary also suggests searching for them through an AI tool, on the basis that a consultant who cannot surface their own site is unlikely to help with yours.

‍