We have now been brought in to look at enough abandoned AI projects to notice that they fail in the same place. Not at the idea, which is usually sound. Not at the model, which is usually fine. They fail in the gap between a demo that works and a thing your staff use on a Tuesday afternoon without being asked to.
The pattern is consistent enough to describe. A business decides it should be doing something with AI. A consultancy runs a discovery phase, produces a deck, and builds a proof of concept on exported data in an environment they control. Everyone in the room is impressed, because it genuinely is impressive. Then the work of connecting it to the actual business begins, and that is where the months go.
The three walls
The first wall is integration. A pilot runs on a spreadsheet somebody exported. Production has to read from the CRM continuously, write back to it correctly, and behave sensibly when the CRM is down or a record is malformed. That is not a harder version of the pilot. It is a different piece of work, usually larger than the pilot itself, and it is rarely in the original quote.
The second wall is access. Making this real means administrative credentials in your identity provider, permissions on your file storage, an API key for your accounting system. Somebody has to approve all of that for a firm you met eight weeks ago. In our experience this is where projects sit still the longest, and quite reasonably so. The hesitation is correct. It is just expensive.
The third wall is the one nobody puts on a timeline: ownership afterwards. Something that touches four systems will break when one of them changes, and the vendors change things constantly. If the engagement ended at go-live, the first time a Microsoft 365 update alters an authentication flow, your automation stops and there is nobody whose job it is to notice. We have seen more AI work killed by that than by any technical limitation.
Why the sequence matters more than the tooling
The instinct is to start with the most exciting possible project, because that is the one that gets the budget approved. It is close to the worst way to begin. The most exciting project is usually the one touching the most systems, which means the longest path to anything working, which means the enthusiasm runs out before the value arrives.
The better sequence is unglamorous. Start with something contained that has one clear owner and one measurable number attached: calls being missed after hours, or one team retyping the same data into a second system. Get it live in weeks. Let people use it and complain about it. Fix the complaints. Then use what you learned, and the access and plumbing you now have, on the bigger thing. The second project is always dramatically cheaper than the first, because the groundwork exists and stays existing.
The questions worth asking before you sign anything
Ask who will hold the administrative credentials, and whether you are comfortable with that. Ask what happens in month seven when a vendor changes an API: who notices, who fixes it, and is that included. Ask what this connects to in production rather than in the demo, and who is writing that connection. Ask what the ongoing cost is, not just the build cost, because there always is one. And ask what the number is that will tell you in ninety days whether this worked, because a project with no such number cannot fail, which means it also cannot succeed.
Notice that none of those questions are about AI. That is the point of this article. The models have become the easy part, genuinely available to everyone, and largely interchangeable for the work most businesses actually need. What separates an AI project that is still running next year from one that quietly stopped is everything around it: who has access, what it plugs into, and who is still accountable when something changes. If you are evaluating help, weigh the answers to those questions considerably more heavily than the demo.
It is also, to be plain about our own position, why we think this work sits naturally with whoever already runs your infrastructure. Not because we are cleverer about AI than a specialist, but because two of the three walls above are not walls for a team that already has the access and already carries the responsibility. More on how we approach it, and on deciding what to build first.