Why 95% of AI Pilots Fail in Small Business (and the Ownership Fix)

The MIT figure means most pilots never touch a real business process long enough to produce a measurable result. It does not mean AI itself fails. The MIT Project NANDA report, The State of AI in Business 2025, found that about 95 percent of organisations saw no measurable return from their generative AI pilots, with only around 5 percent reaching production and producing value (MIT, 2025). The same study found that purchased, vendor-assisted solutions succeeded roughly twice as often as purely internal builds (MIT, 2025). Other research points the same direction. The share of companies abandoning most of their AI initiatives jumped to 42 percent in 2025, up from 17 percent the year before (S&P Global Market Intelligence, 2025). More than 80 percent of AI projects fail, roughly twice the failure rate of non-AI IT projects (RAND Corporation, 2024). And only 26 percent of companies have moved beyond proofs of concept to generate tangible value from AI (Boston Consulting Group, 2024). Two things are worth holding at once. First, these samples skew towards large enterprises, but small businesses face the same failure modes with far less slack to absorb them. Second, the failures cluster around adoption and ownership, not model quality. The 5 percent who succeed are not using better AI. They are running a better process around it.

The most common killer is an ownership vacuum: the pilot belongs to everyone in principle and to no one in practice. The pattern is almost identical every time in a 10 to 50 person business. The owner sees a demo, gets excited, signs up. For a fortnight it is the talk of the office. Then quoting season starts, or a staff member goes on leave, and the tool quietly stops being opened. Nobody's job description included keeping it alive, so it died. Arman Hezarkhani, co-founder of AI transformation firm Tenex and a former Google engineer, puts it bluntly: "AI is one of the most, if not the most, transformational technologies that's ever existed, but it's incredibly difficult to adopt as a business. It's actually way easier to adopt as an individual" (Proof of Work podcast, 2025). That gap is the whole story. An individual can change a habit overnight. A business has to change a workflow, a job description and a Tuesday afternoon. If your pilot has no named internal owner, with real hours allocated to it each week, it is not a pilot. It is a subscription waiting to be cancelled.

A demo works on clean data and a rehearsed scenario. Production runs on messy inboxes, legacy logins and edge cases nobody ever wrote down. The demo you watched was built to impress. Your actual environment is Xero plus a decade of workarounds, or ServiceM8 and Simpro for a trades business, Cliniko or Nookal for an allied health practice, LEAP or Actionstep for a law firm. Getting AI to do something useful inside those systems, with your real data and your real exceptions, is engineering work, and it is where most pilots stall. Hezarkhani again: "A lot of those AI solutions are actually... a 10-step process and nine out of the 10 steps are just traditional code or technology, and maybe one of the steps is AI" (Tenex, 2025). The implication matters for your budget. If your pilot plan has no line items for integration, data cleanup and error handling, then it is a demo plan, not a rollout plan. A useful test: if the pilot has not touched a live system within its first two weeks, it is still a demo. Given that more than 80 percent of AI projects fail overall (RAND Corporation, 2024), treating integration as an afterthought is how you join that majority.

Most failed pilots started life as a solution in search of a problem: someone bought AI first, then went looking for somewhere to point it. Alex Lieberman, co-founder of Tenex and Morning Brew, describes what happens in stakeholder interviews: "People immediately jump to brainstorming AI solutions... I want this AI use case... so much of the work we do is pushing people to talk about problems." His conclusion: "People are so fixated on this technology that they feel like AI is a hammer and every problem is a nail, but that is just not the case" (Tenex, 2025). The fix is to invert the order. Do not ask where you can use AI. Ask what is slow, annoying and repetitive. Tenex's own readiness surveys barely mention AI at all. The central question is simply: "What are the two most annoying, time-consuming, rote tasks in your job?" Run that question past your team this week and you will get a better automation roadmap than any vendor demo will give you. In trades businesses the answer is usually quote follow-ups and invoice chasing. In allied health it is intake admin and reminders. In professional services it is proposal drafting and onboarding checklists. Start from the pain, then check whether AI, plain automation, or a process change is the right tool for that specific pain.

If you never measured the process before the pilot, you cannot prove the pilot changed anything, so it gets cut at the first budget review. Most pilots run on vibes. Someone feels like the tool helps. Feelings do not survive a quarterly review, and they should not. Before any pilot starts, record three numbers for the target workflow: hours per week it consumes, its error or rework rate, and its cycle time (for example, quote received to quote sent). The dollars make it concrete. Take a bookkeeper spending nine hours a week on $25-an-hour admin tasks while costing the business $52 an hour fully loaded. That is roughly $22,000 a year spent on work that should not need a human (9 hours x 48 weeks x $52). An automation that removes 70 percent of it saves about $15,700 a year, every year. Without the baseline, that win is invisible, and the automation looks like a cost. This is also why the 42 percent abandonment figure (S&P Global Market Intelligence, 2025) should not surprise anyone. Unmeasured pilots cannot defend themselves. Measured ones either pay for themselves or get killed quickly for the right reason.

The fix is structural, not technical: put a named internal owner in charge, train them properly, and ship one real automation into a real system every few weeks until it sticks. The businesses in the successful 5 percent (MIT, 2025) tend to do three things differently: - Train champions, not passengers. Pick two or three people who already know the workflows intimately: the office manager, the senior administrator, the leading hand. They keep their existing jobs, and automation ownership becomes a named part of the role with real hours attached. - Ship on real systems. Every automation must touch live data in Xero, Cliniko, ServiceM8 or your CRM within its first fortnight. Sandboxed experiments teach nobody and save nothing. - Document everything. If the knowledge lives in one person's head, a single resignation resets you to zero. Write the playbook: what the automation does, how to check it is working, how to fix it, and who to call. Notice that none of this is about buying better tools. Remember that vendor-assisted approaches succeeded roughly twice as often as pure internal builds (MIT, 2025). The model that works combines both: outside expertise to train and de-risk, inside ownership to keep it alive.

When ownership is real, the results are measurable within weeks, not quarters. Here are three typical patterns from businesses with 2 to 200 staff. Trades, around 30 staff, Melbourne's north. The office manager owns quote follow-up and invoice chasing automations across ServiceM8 and Xero. Result pattern: about 11 admin hours recovered per week and quote-to-cash cycles cut from nine days to four. At a fully loaded $45 an hour, 11 hours a week is roughly $23,700 a year of recovered capacity. Allied health, around 12 staff, regional Victoria. The practice manager owns intake triage and reminder flows in Cliniko. The pattern to expect: fewer did-not-attends, faster intake processing, and reception staff spending their mornings on patients instead of data entry. Professional services, around 45 staff, Melbourne CBD. A senior administrator owns proposal drafting and client onboarding checklists. Draft proposals that took three hours now take forty minutes of review, and nothing gets missed in onboarding because the checklist runs itself. This is exactly what 13Labs' buildAutomation program does. Over six to twelve weeks, we train two or three of your own staff to diagnose, build and own automations on your real systems, with documentation included. When we leave, the capability stays. See how it works at 13labs.au/buildAutomation.

**What percentage of AI pilots actually fail?** A widely cited MIT Project NANDA study found that 95 percent of generative AI pilots produced no measurable return on investment (MIT, 2025). RAND Corporation separately estimates that more than 80 percent of AI projects fail, about twice the rate of non-AI IT projects (2024). The exact figure matters less than the pattern: most pilots never survive contact with a real workflow. **Why do AI pilots fail more often in small businesses?** Small businesses have no slack. There is no innovation team, no spare analyst, and usually no one whose job includes keeping the pilot alive. Add the demo-to-production gap (real tools must work inside Xero, ServiceM8, Cliniko or LEAP, not a sandbox) and the absence of any baseline measurement, and pilots die quietly within a month or two. **How do I stop our AI pilot from dying?** Do four things before you spend another dollar. Name an internal owner and give them real weekly hours. Measure a baseline: hours, error rate and cycle time for the target workflow. Get the automation touching a live system within two weeks. Document what it does and how to fix it. Most dead pilots skipped at least two of these. **Is it better to buy AI tools or build our own?** The MIT research found purchased, vendor-assisted solutions succeeded roughly twice as often as purely internal builds (MIT, 2025). But buying without internal ownership still fails. The strongest model for a small business is outside help to train your people, with the ownership and capability staying inside when the engagement ends. **How long should an AI pilot run before we call it?** Four to eight weeks is enough, provided you measured a baseline first and review the numbers weekly. If the pilot has not touched a real workflow by week two, it is a demo, not a pilot. Either restructure it around a named owner and a live system, or kill it and put the budget towards one that is.