# The pattern I keep seeing in failed AI projects Source: https://getstartedwithai.net/blog/the-pattern-i-keep-seeing Site: Get Started With AI Tagline: Build AI automations that actually run your business. Audience: solo professionals, freelancers, consultants and AI implementers in training Contact: hello@getstartedwithai.co.uk This Markdown companion is generated from the prerendered page for AI crawlers. # The pattern I keep seeing in failed AI projects Why AI projects fail: the published failure rate sits between 70 and 95 percent depending on which study you read, but the cause sits in a smaller bracket than the headline number suggests. After 120+ AI implementations across 15+ industries, I see the same failure pattern repeat. The cause is rarely the model and rarely the tool. The cause is the missing owner. This post is the pattern in detail, the four week-by-week stages of decay, the role-specific failure modes, three real UK examples, and a checklist that predicts whether your project is heading the same way. ## The pattern in nine months A team buys an AI tool. Someone, usually the founder or a curious operations lead, configures it on a Friday afternoon. The tool runs for two weeks and produces useful output. Then the configuring person gets busy with another project. Nobody else owns the tool. Output decays without anyone noticing because nobody is reading it. By month four, the team has stopped trusting the output. By month six, they have stopped using it. By month nine, somebody quietly cancels the subscription. The team concludes AI does not work for their business. The model worked and the tool worked, but the ownership structure that would have kept either of them running did not exist. The failure mode shows up in 90 percent of the cases I have audited after the fact. ## How the decay shows up week by week - Weeks 1 and 2: outputs read daily, corrections fed back, the build improves visibly. - By week four, outputs are sampled inconsistently, two or three small issues compound, owner attention drops. - Through weeks 5 to 8, outputs are rarely read, the tool runs in the background, drift accelerates. - In the second month, the team starts checking the output by hand because they no longer trust the build, which doubles the cost. - Months 5 to 9: the build is paused, then quietly cancelled. The team writes off AI for that workflow. ## Failure modes by role The pattern varies by who started the project. The sponsor failure: an executive bought a tool from a vendor demo, the operational team never agreed to own it, the build runs for a quarter, then nobody renews. The builder failure: an internal practitioner configured a clever tool, the practitioner left or moved roles, no successor was named, the build dies with the practitioner. The ops lead failure: an operations lead inherited the tool from someone else, the documentation was thin, the lead spends three months reverse engineering the prompt and gives up. Each failure mode has a different fix, but all three have the same underlying gap: there is no Bus Test on the build. If the original person disappears, the build does not survive the month. ## The handover gap as primary cause Almost every published AI failure analysis names hype, data, talent or strategy as the cause. The pattern I see most often is none of those. It is the handover gap: a build that works on day one but has no document, no named owner, no review cadence and no escalation path. The handover gap is invisible while the build is producing output, which is why it shows up at month four rather than week one. By the time the gap is visible, the team has already lost trust and the consultant has long since stopped getting paid. The fix is structural, not technical. The Embed step of the WIRE Method exists exactly to close this gap. ## Three UK examples from the last 18 months A 30-person recruitment firm bought a CV summarisation tool in March 2025. The founder configured it on a Friday. By June, the founder was rolling out a new ATS and stopped reviewing the summaries. By October the summaries had drifted into a tone the consultants no longer trusted. The tool was cancelled in December. The same firm rebuilt the workflow in February 2026 with a named ops lead, a fortnight of output review and a written handover. The build is still running. A 12-site lettings agent shipped a maintenance triage build in June 2025. The first ops lead left the firm in October without naming a successor. The build paused for six weeks. The new ops lead picked it up in December using the WIRE Method handover document and was running cleanly inside a fortnight. A solo accountancy practice configured a Custom GPT in 2024 and never wrote anything down. The Custom GPT still runs but the practitioner cannot tell whether the output is right because there is no baseline to compare against. ## How the WIRE Method prevents the pattern The Embed step names a human owner with three responsibilities: review output samples weekly, escalate problems within 48 hours, hand the system to a successor before they leave the role. The Bus Test is the one-line check that confirms the Embed step worked: if the original configurer disappears tomorrow, does the build still run on Monday. The Four Breaks (silent drift, owner change, input change, downstream change) are the named failure modes the owner watches for. Without those three structures, the build is not finished, regardless of whether it produces output today. The technical work is the easy part of the engagement; the ownership work is what decides whether the engagement was worth the fee. ## A predictive checklist: is your project going to fail? - Can you name the owner of the AI workflow, by name and email, today? - Did somebody read every output this build produced this week? - If the original configurer left tomorrow, does a written document let a successor pick it up inside a week? - When the output has been wrong, was the prompt or trigger updated, or was the wrong output ignored? - Has the success metric been measured against its baseline at least monthly? - Is the login, API key and account ownership held by the team, not the original configurer? - If the tool changed its pricing or its model overnight, who would notice and what would they do? ## How to apply this to existing builds Audit any AI workflow currently running in your business. Answer one question per workflow: who reviewed the output this week, by name and date. If you cannot name them, the workflow is unowned and at risk. Fix the ownership gap before adding any new builds. The fix is small: a named owner, a one-page handover, a weekly review cadence and a written escalation path. About four hours of work per build. The fix earns its time back inside two months on any build saving more than two hours a week, which is most of them. ## Build your first AI system live with Richard A 60-minute live build with Richard Batt. Bring one repeatable task. Leave with a mapped automation, success metrics and a deploy plan you can test the next morning. Free seat, no upsell. ### Live build session The next live session covers the WIRE Method end to end on a real audience build. [Join the next session](/webinar) ## Questions people ask before they start ### undefined undefined ### undefined undefined ### undefined undefined ### undefined undefined ### undefined undefined