The implementation gap
From Experiments to Implementation
Your organization ran AI pilots. Some looked promising. Most went nowhere. You are not alone — MIT research shows 95% of AI projects fail to reach production. This is not a technology problem. It is an organizational one. I have spent the past two years leading AI adoption for over 100 engineers at a major European insurer. Before that, 20 years building software systems, running teams, and learning — sometimes the hard way — what separates projects that ship from projects that demo well and die quietly. This page lays out what I have learned about why AI strategies stall and what actually moves them forward.
MIT Sloan / Nanda, 2024 — 95% of AI projects fail to deliver expected results
Why most AI strategies stall
Here is what typically happens. Leadership reads the reports, sees what competitors are doing, and decides the company needs an AI strategy. A consulting firm comes in, produces a 60-page deck with quadrant diagrams and maturity models, and leaves. The deck sits in a shared drive. A few teams run pilots. One or two show results in a demo environment. Then nothing. The pilots never reach production. The teams that ran them get pulled back to their regular roadmap. Six months later, the board asks about AI progress and nobody has a clear answer. The budget is spent. The consultants have moved on to the next client. And the organization is exactly where it started, just with less patience for the next AI initiative.
BCG found that 74% of companies struggle to achieve and scale value from their AI initiatives. Not because the technology does not work — the technology works fine. GPT-4 can process your documents. Computer vision can inspect your products. Recommendation models can predict your customer behavior. The models are ready. The organizations are not. The gap between 'we ran a successful pilot' and 'this is now part of how we work' is where most companies get stuck. That gap is not technical. It is structural. And no amount of better AI models will close it.
BCG, 2024 — 74% of companies struggle to scale AI value
Five frictions that kill AI projects
After working on AI adoption across multiple organizations, I see the same five patterns repeat. I call them frictions because they are not fatal flaws. They are drag forces that slow progress until it stops entirely. Remove them and projects start moving again.
No ownership between strategy and execution
Someone owns the AI strategy at the board level. Someone else owns the technical implementation. Nobody owns the messy middle — the part where strategy decisions become architecture choices, where 'use AI for customer service' turns into specific technical requirements, timelines, and resource allocation. This gap is where most AI projects die. Not in the boardroom. Not in the codebase. In the space between them. I call this the 'translation layer' problem. Strategy people speak in business outcomes. Engineers speak in system requirements. Without someone who speaks both languages and has the authority to make decisions in that middle zone, every AI initiative requires constant escalation. And escalation is where momentum goes to die.
Tool sprawl without governance
Every team picks its own AI tools. Marketing uses one LLM provider. Engineering uses another. Legal has concerns about data flowing through third-party APIs but nobody catalogued which tools send data where. By the time someone tries to create a governance framework, there are 15 different AI subscriptions, three overlapping internal tools, and no way to measure what any of them actually deliver. AWS and Bain found that only 5% of organizations feel prepared for AI governance. The other 95% are improvising.
AWS / Bain, 2025 — only 5% of organizations feel prepared for AI governance
Pilot culture without production standards
Pilots are easy to run. You pick a narrow use case, build a quick prototype, demo it to stakeholders, and everyone is impressed. But pilots operate outside the constraints that production systems face: security review, data governance, monitoring, SLAs, integration with existing workflows. The team that built the pilot often does not have the mandate or resources to bring it to production. So it sits there — technically successful, organizationally useless. The worst part is that every successful pilot that does not reach production actually makes the next attempt harder. The organization learns that AI demos are easy and AI implementation is impossible. That lesson is wrong, but once it takes root, it poisons every future initiative.
Skills gap dressed up as a hiring problem
Companies post job ads for 'AI engineers' and wonder why nobody applies. The reality is that most of the AI skills your organization needs already exist inside your teams. Your senior developers can learn to build AI applications. Your data analysts can learn to evaluate models. What they need is structured upskilling with real projects, not another online course about prompt engineering. BCG found that organizations achieving AI results invest 70% of their effort in people and process, not technology.
BCG, 2024 — successful AI adopters invest 70% in people and process
No measurement beyond the demo
The AI pilot got a standing ovation at the quarterly review. Great. But what happened after? Is anyone tracking whether the tool actually reduced processing time? Whether users adopted it or went back to the old way within two weeks? Whether the data quality improved or just shifted the errors somewhere else? Without production metrics tied to business outcomes, AI projects are demo-ware. They impress in presentations and deliver nothing in practice. I have seen organizations spend six months on an AI initiative and have no way to answer the question 'did this work?' afterwards. Not because they forgot to measure, but because nobody defined what 'work' means in measurable terms before they started.
Why practitioners outperform consultants on AI
The standard approach to AI strategy is to hire a consultancy. They send a team of analysts, interview your stakeholders for two weeks, and produce a strategy document. The document is usually correct in its analysis and useless in its recommendations. Not because the recommendations are wrong, but because they are generic. 'Establish an AI Center of Excellence.' 'Create a data governance framework.' 'Invest in talent development.' These are outcomes, not instructions.
A practitioner approach is different. I do not produce strategy decks for other people to implement. I work inside the organization, alongside your teams, making the same decisions your technical leaders make every day. Which model to use for this use case. How to handle data privacy for that workflow. Whether to build or buy for this specific problem. The advice comes from current experience, not frameworks.
This matters because AI changes fast. What worked six months ago may not work today. The model landscape shifts quarterly. New capabilities appear, old approaches become obsolete, and pricing changes make previously uneconomical use cases suddenly viable. A practitioner who builds AI applications every week has different pattern recognition than a consultant who last touched a codebase three years ago. When your team runs into an issue with model hallucinations in a document processing pipeline, you need someone who hit that same issue last month and knows which mitigation actually works in production, not someone who read about it in a report. The difference between theory and practice in AI is larger than in most fields because the technology moves faster than the textbooks.
From pilot to production in five steps
This is the methodology I use with organizations moving from scattered AI experiments to systematic implementation. It is not a framework you read about and admire. It is a sequence of concrete actions that produce measurable results.
Audit what you have
Before adding anything new, map what already exists. Which teams run AI tools? What data flows through them? Which pilots showed results and which were abandoned? What is the total spend across all AI subscriptions and services? This audit typically reveals that the organization knows less about its own AI usage than it thinks. I have seen companies discover tools processing customer data through APIs they never approved, and teams paying for three different tools that do the same thing. The audit is not about judgment. It is about visibility. You cannot govern what you cannot see.
Define governance first
Most organizations try to build AI applications first and govern them later. This is backwards. Define your governance framework before scaling: which data can be processed by external AI, who approves new AI tools, what monitoring is required, how models are evaluated. This does not need to be bureaucratic. A one-page governance policy is better than a 50-page document nobody reads. The goal is clear decision criteria, not compliance theatre.
Pick one use case and go to production
Not a pilot. Production. Pick the use case with the highest ratio of business impact to implementation complexity. Staff it properly — not as a side project for a team that already has a full roadmap. Give it production standards from day one: monitoring, error handling, user feedback loops, rollback procedures. Treat it like you would treat any critical system launch, because that is what it is. The first production AI system is your proof point. It proves to the organization that AI can move from demo to daily operations. Everything else scales from the credibility that first deployment creates.
Build internal capability
Run structured workshops for your engineering teams. Not two-hour introductions to ChatGPT — your developers will tune out after 20 minutes of slides. Full-day, hands-on sessions where they build real applications against real problems from their own backlog. Follow up with project-based mentoring where they apply what they learned to an actual production use case. The goal is that within 90 days, your teams can evaluate, build, and deploy AI solutions without external help for standard use cases. The best measure of a successful workshop is not satisfaction scores. It is whether the participants ship something to production within 60 days of attending.
Measure, iterate, scale
Define metrics before deployment. Track them after. Compare performance against the baseline you captured in step one. Share results — both successes and failures — across the organization. Failures are especially valuable because they prevent other teams from walking into the same wall. Use what you learn to select the next use case. This is not a linear process. It is a cycle. Each production deployment teaches you something that makes the next one faster and less risky. After three or four cycles, the organization develops its own pattern recognition for what works. That is when you no longer need external help for standard use cases. That is the goal.
Patterns from real implementations
These are anonymized patterns from organizations I have worked with. The details are changed, the problems are real.
The insurer with 12 stalled pilots
A European insurance company had run 12 AI pilots across different departments over 18 months. Two showed promising results in demos. None reached production. Leadership was frustrated. They had invested significant budget and executive attention, and had nothing to show for it. The root cause was not technical — the pilot teams did not have authority to change production systems, and the infrastructure team had no mandate to support AI workloads. There was a structural gap between 'we built a working prototype' and 'this is now in production.' After restructuring ownership so that a single product owner controlled both pilot and production decisions, three pilots reached production within four months. The other nine were deliberately killed because they did not justify production investment. Killing projects is also progress. It freed up resources for the initiatives that actually mattered.
The engineering team that thought they needed to hire
A 200-person engineering organization posted five 'AI Engineer' roles and got zero qualified applicants in three months. They assumed they had a talent problem. The market is competitive, AI talent is expensive, and they could not match the salaries that big tech companies offer. In reality, they had a training problem, not a hiring problem. After a series of two-day workshops with their existing senior developers — people who already understood the domain, the codebase, and the business rules — four of the five originally planned roles became unnecessary. The existing team built and deployed an internal document processing system that reduced manual review time by 60%. The fifth role was filled internally by a developer who discovered an interest in ML during the workshops. Total cost of the workshops was a fraction of what five new hires would have cost in the first year alone.
The governance framework that actually worked
A financial services firm needed AI governance for regulatory compliance. Their compliance team was nervous about AI risk. Their engineering team was frustrated by slow approvals. The first attempt at a solution was a 47-page policy document that nobody read and everyone ignored. The second attempt was a one-page decision tree: can this data go to an external API? Does this use case need human review? Who approves exceptions? Three questions, clear owners, done. Adoption of the governance process went from approximately 10% to over 90% within six weeks. The compliance team was satisfied because every AI use case went through a documented review. The engineering teams could actually work with it because the review took 15 minutes, not three weeks.
Start at the strategy level
If you are a CTO, VP of Engineering, or board member — I work directly with leadership teams to define AI strategy that your organization can actually execute.
For LeadershipStart with your teams
If your teams need hands-on AI skills — I run workshops that take engineers from theory to building production applications in two days.
For TeamsRelated reading
More on AI implementation and strategyThe gap is not technology. It is execution.
Every organization I work with has access to the same AI models, the same cloud infrastructure, the same research papers. The ones that succeed are not the ones with bigger budgets or better tools. They are the ones that figured out how to make AI part of their actual operations — their workflows, their decision processes, their team capabilities. The technology is a commodity. The implementation is the differentiator. That is the gap I help organizations close — not with strategy decks, but by working alongside your teams until AI is part of how you operate, not something you talk about at quarterly reviews.
No slides. No sales pitch. Just a direct conversation about where you are and what the next step looks like.