The £2.3 million chatbot launched on a Tuesday. By Friday, customer complaints had doubled and the support team was manually answering queries the AI was supposed to handle. The technology worked perfectly in testing. The failure was entirely human.
Most discussions about AI project failure focus on data quality, model accuracy, or infrastructure costs. But after watching dozens of implementations over the past decade, the pattern is clear: technical problems sink maybe 20% of AI projects. The other 80% die because companies staff them like software projects instead of translation projects.
Data scientists can't speak to procurement departments
The typical AI project starts with hiring a data scientist or ML engineer. Makes sense, right? You need someone who understands transformers, gradient descent, and model evaluation metrics. But here's what actually happens: six months later, that brilliant PhD is sitting in meetings trying to explain why the procurement team's request for "AI that reads contracts" isn't technically feasible in the way they've imagined it.
Data scientists optimize for model performance. Business stakeholders optimize for process improvement. Neither group speaks the other's language, and both assume the translation is someone else's job. We've seen this communication gap kill projects that had genuinely promising technical foundations.
The companies that succeed hire translators first. Not consultants who talk about "AI strategy" in abstract terms, but people who can walk into a warehouse, watch how inventory gets tracked, then come back and explain exactly which parts of that workflow an AI system could improve and which parts it would break.
Requirements gathering becomes science fiction writing
Traditional software development has figured out requirements gathering. You can specify how a user registration form should behave, what happens when someone clicks "submit", and how the database should store the information. AI systems don't work that way.
Instead, requirements sessions turn into creative writing exercises. "The AI should understand context" appears in specification documents. "It should learn from user behaviour" gets written down as if it's equivalent to "the button should be blue". Teams spend weeks defining requirements that sound concrete but describe systems that don't exist.
The successful projects we've worked on through our AI adoption consulting start with narrow, measurable outcomes. Not "improve customer service" but "reduce average response time for billing queries from 4 hours to 30 minutes". Not "automate document processing" but "extract supplier names and invoice amounts from PDF invoices with 95% accuracy".
Pilot scope determines everything
Narrow requirements force narrow pilots. And narrow pilots either work or they don't—there's no middle ground where everyone pretends the system is "learning" and will get better eventually.
Integration planning starts after the model is built
Here's how most AI projects actually unfold: data scientists build something impressive in Jupyter notebooks, demonstrate it in a controlled environment, then discover their elegant Python script needs to integrate with a 15-year-old ERP system that communicates via XML files dropped into FTP folders.
The model that achieved 94% accuracy in testing drops to 67% accuracy when it processes real data that hasn't been cleaned, formatted, and validated by researchers. The inference time that seemed reasonable during development becomes unacceptable when the system needs to process 10,000 requests during the morning rush.
Smart teams map integration points before they write training code. They understand how data flows through existing systems, where the AI component will sit in that flow, and what happens when the AI system is wrong or unavailable. This isn't glamorous work, but it's the difference between a successful deployment and an expensive proof of concept.
Companies in our target sectors often have legacy systems that weren't designed for real-time API calls or modern data formats. The AI system might be brilliant, but if it can't communicate with the rest of the technology stack, it's useless.
Success metrics get defined after the system is live
The most damaging question in AI projects is: "How do we know if this is working?" It's damaging because it usually gets asked three months after deployment, when stakeholders realize they can't tell whether the system is performing well or poorly.
Model accuracy isn't a business metric. A sentiment analysis system might achieve 89% accuracy while completely failing to improve customer satisfaction scores. A recommendation engine might have excellent precision and recall while reducing overall sales because it's too conservative in its suggestions.
The projects that survive define success metrics during planning, not during post-mortem reviews. They identify leading indicators—metrics that change quickly and indicate whether the system is moving business outcomes in the right direction. Response times, escalation rates, user adoption percentages, error correction frequency.
More importantly, they define failure criteria. At what point do you pause the system and fix problems rather than hoping they'll resolve themselves? What threshold of user complaints indicates a fundamental issue rather than typical adoption friction?
The 20% of AI projects that succeed aren't the ones with the most sophisticated algorithms or the largest datasets. They're the ones that treat AI deployment as a systems integration challenge with a machine learning component, not a machine learning challenge with a systems integration afterthought. The technical problems are solvable. The human coordination problems require more careful planning than most companies want to admit.
