Why AI Projects Fail: what to check before you sign

If you search “why AI projects fail” on Google, the first page follows a script. Lists of causes after the fact. “Bad data”, “fuzzy goals”, “no governance”. All true. Almost no one offers a simple check before you sign. You can do that in an afternoon.

I use three questions. I ask them with the budget holder and the people who will use the system. No prototype. No contract. Just clarity. If any answer is not concrete, the risk of failure is high. Here is what I ask, how I ask it, and what signs I watch for.

Question 1: Who will use it tomorrow, and what changes in their routine?

I do not ask for an abstract “user persona”. I ask for a role and a specific moment. “The support lead at 9:00 on Monday.” What do they open first? What do they see that they cannot see today? What decision changes? The first real use defines the project. Without that first use, there is no business case. There is only intent.

The check is direct. I ask them to describe the first day’s flow in three minutes. Input, action, output. If they cannot say it out loud in plain words, the operational friction will still come, only later and at a higher cost. A useful script is this: before, the team clicks through five screens to answer an email; after, they send a drafted reply with the evidence already gathered. If no one can say “what they do at 9:00 on the first Monday”, the project is not ready to sign.

Question 2: What data goes in, from where, and with what permissions?

The second question is not technical. It is logistics. What is the primary source? Who controls it? With what latency does it arrive? Can it be used for this purpose? If the key data arrives late or without permission, the model can be brilliant and the result still useless. AI only scales on pipes that already exist.

I run a “bucket of water” test. I do not train anything. I take a small subset and push it through the full path. One case file, ten emails, three chats. Can we extract them without someone on call? Are the fields understood? Are there duplicates? What happens with a corrupted file? This short pass shows where the flow jams and who holds the key. If getting those ten examples requires favours, the project will stall in the first sprint.

I also verify the edges. Do terms of use limit API calls? Is explicit consent required? Is there a signed purpose limitation? If the answer is “we’ll check with legal”, I stop there. It is better to pick the first case with less friction. In this line, a brief guide on where to start in a business to avoid data bottlenecks helps you pick a scope that does not depend on impossible integrations.

Question 3: When do we cut it, and what is the plan B?

Before signing, define the cut-off point. Metric, date, and who decides. Without that, the project drifts, spends, and no one knows why it is still alive. I suggest setting the threshold with an explicit scenario: “if in four weeks the response time does not drop against the manual baseline, we stop and document what we learned”. It is an example, not a universal rule. The key is a verifiable criterion.

Plan B is not surrender. It is a list of what we keep if the threshold is not met. Refined prompts, a data schema, quality policies, reusable connectors. Fail cheap with transferable assets and you still win. If the contract does not allow a clean cut, or no one owns the decision, the operational risk multiplies. An AI project without an exit becomes a recurring expense with no owner.

How to settle this in an afternoon

The format is simple. One meeting with the area lead, two real users, and the person who holds the data keys. Forty-five minutes per question. Notes on one page. No demo. No slides. The goal is positive tension: either we confirm the fit, or we surface the blocker early.

In that session, I ask for two light deliverables. One, the script for the first Monday: three steps, before and after. Two, the minimum data map: source, permission, latency. With that, we draft a small, measurable start. If a serious gap appears, we park the case and find another. A team that spends twenty hours a month cleaning spreadsheets already has a signal: without automating that hygiene, any model costs more than it returns.

Green and red signals I keep seeing

Green: the user already works with a checklist and wants to remove steps, not add screens. Green: there is a field with a label, an owner, and a clear definition. Green: the sponsor agrees to set a cut-off with their metric, not the supplier’s. With three greens, the launch tends to go straight, even if the first model is basic.

Red: “everyone can use it”, and no one claims it out loud. Red: data arrives by email and changes format every week. Red: goals defined by jargon, not by actions (“improve commercial intelligence”). When there are reds on all three questions, the responsible move is to stop. It is cheaper to adjust the case than to insist on an order that will be born underwater.

Why this predicts better than a list of causes

Post-mortem lists describe symptoms. These three questions force early decisions: who changes their routine, what data pipe already exists, and what milestone cuts inertia. They are reality levers. They do not depend on models or brands. They get validated out loud and written into the contract.

They also align incentives. The user area commits to a first concrete use. IT confirms we are not promising what we cannot extract. Management knows when to cut if there is no improvement. If the supplier accepts these rules, there is trust. If they feel uneasy, better to know upfront. AI works when it fits the work, not when it sounds good in a presentation.

I post working automations on @WhatsMarketing_es.

If you want me to look at your case, get in touch. I work from Buenos Aires, originally from Málaga, with clients in Mexico City, Argentina, the rest of Latin America and Spain.