🚨 Why Do AI Projects Fail?
Project proposals are becoming increasingly impressive. But can we say the same about the engineering capacity of the teams expected to turn those proposals into working systems?
```Recently, I have been noticing the same problem more and more often during project evaluations.
When you start reading an AI-related project proposal, you often see almost every recent method, technique, and technology somehow included in the project:
On paper, the project looks highly impressive.
However, once you meet the team face to face and begin asking more detailed questions, a very different picture often emerges.
👥 The technology is in the proposal — but is the experience in the team?
Sometimes, the engineers on the project team have never developed even a small-scale application using the technologies described in the proposal.
The company itself may also have no prior experience building, deploying, operating, or maintaining products based on those methods.
After a few questions, the following issues begin to surface:
- Why was this technology selected?
- What real problem does it solve in the project?
- Why is it being used together with the other components?
- Were alternative methods evaluated?
- How will success be measured?
- If the system fails, how will the team determine which component failed and why?
Unfortunately, in some projects, there are no clear answers.
The technology choices appear to be less the result of an engineering analysis and more the result of connecting fashionable concepts to one another.
🧩 A list of technologies is not a system design
Today, it is relatively easy to produce impressive project documents with generative AI.
You can list the advantages of every technology. You can summarize their benefits from the literature. You can draw an architecture with a few boxes and arrows.
But none of this, by itself, constitutes systems engineering.
In a real system design, every component has a reason to exist.
A component should not be added because it is fashionable. It should be added because it satisfies a specific requirement.
For every selected method, the team should be able to explain:
- which requirement it addresses,
- which alternatives it was compared against,
- which metric it is expected to improve,
- which costs it introduces,
- and which new risks it adds to the system.
Otherwise, what we have is not a system architecture. It is merely a list of current technologies.
🔍 Saying “we will use RAG” is easy. Building a working RAG system is not.
For example, the following sentence has become very common in AI project proposals:
Fine.
But the real engineering problem begins exactly where that sentence ends.
📌 How will system performance be measured?
📌 How will the benchmark dataset be created?
📌 How will real user questions be represented in the evaluation set?
📌 How will retrieval quality be separated from final answer quality?
📌 How will chunk size and overlap be selected?
📌 Which experiment will determine the embedding model?
📌 Which metadata fields will distinguish text chunks from tens of thousands of documents?
📌 If multiple versions of the same document exist, which one will be used?
📌 How will obsolete or withdrawn information be removed from the system?
📌 How will unauthorized users be prevented from retrieving restricted content?
📌 How will hallucination be measured?
📌 How should the system behave when a reliable answer cannot be generated?
📌 How will latency be controlled under thousands of concurrent users?
📌 How will the trade-off between cost, accuracy, and response time be managed?
Every one of these is a real-world engineering problem.
Yet in many project documents, instead of answering these questions, the proposal simply explains the generic benefits of RAG.
That tells us that the project may be conceptually defined, but its operational reality has not been sufficiently considered.
⚠️ Using AI to prepare a project is not the same as developing an AI project
I believe a new risk has emerged in recent years.
Generative AI has made project preparation dramatically easier.
Literature reviews, technology descriptions, methodology sections, and technical documentation that once took weeks can now be produced much faster.
This is not inherently a bad development.
On the contrary, when used properly, it can create enormous productivity gains.
The problem begins when the process turns into something like this:
🤖 Ask AI to write the project proposal.
💰 Apply for funding.
🧑💻 If the funding is approved, ask AI to write the code too.
This mindset can easily turn into a dangerous form of shortcut-driven project development.
The engineering gap between a project proposal and a real system cannot automatically be closed simply by using more AI.
🧠 AI does not automatically create experience that the team does not have
Today’s generative AI systems can write code, suggest architectures, create APIs, generate test scenarios, and produce documentation.
But there is still a critical distinction:
Because real engineering is not simply about generating code.
Real engineering means:
- defining the right problem,
- identifying the requirements,
- comparing alternative approaches,
- defining measurable success criteria,
- anticipating bottlenecks,
- handling unexpected cases,
- testing the system under real user behavior,
- and considering scalability and sustainability.
📉 So what happens in the end?
A system that looked extremely strong in the project proposal fails to deliver the expected performance during implementation.
At first, a few demonstrations are prepared.
The system performs well on carefully selected examples.
But once real data, real users, and real operational conditions enter the picture, problems begin to appear.
Costs increase.
Latency rises.
Data quality problems emerge.
Authorization requirements become important.
The model begins producing unexpected answers.
Real user questions do not resemble the clean examples used in demonstrations.
And because there is no properly designed benchmark, the team may not even know which change actually improves the system.
As time passes, the project schedule slips.
The team changes.
Employees leave.
New team members do not understand why previous architectural decisions were made.
Eventually, the project is either scaled down, diverted from its original objective, or left behind as an unused prototype.
🎯 Perhaps we are asking the wrong question
When evaluating AI projects, we often focus on this question:
I believe there is a more important question:
This should be followed by several additional questions:
- Has the team solved a similar problem before?
- Has it at least built a small-scale prototype?
- Does the team understand the technical risks?
- Does it know which assumptions may turn out to be wrong?
- Can it design experiments to measure success?
- Does it know how to validate the system under real user load?
🏗️ How should a good AI project begin?
In my view, the process should begin with the problem, not with technology names.
| Wrong starting point | A better starting point |
|---|---|
| “Let’s use RAG.” | “Let’s understand which information users cannot access and why.” |
| “Let’s add agents.” | “Let’s identify which tasks genuinely require multi-step reasoning and decision-making.” |
| “Let’s personalize everything with an LLM.” | “Let’s measure which user information actually improves response quality.” |
| “Let’s use the most powerful model.” | “Let’s experimentally determine the right trade-off between quality, cost, and latency.” |
🚀 A strong project proposal does not necessarily mean a strong project
Today, it is possible to prepare an excellent project proposal with the help of AI.
In fact, compared with just a few years ago, proposals can now be more professional, more technical, and far more persuasive.
But the quality of the proposal and the feasibility of the project are not the same thing.
AI can accelerate project preparation.
It can accelerate software development.
It can simplify documentation.
It can generate test scenarios.
It can suggest architectural alternatives.
But it does not magically create engineering experience, domain knowledge, systems thinking, or product development culture that the team does not already possess.
🎯 One of the biggest risks in AI projects may no longer be lack of access to technology. It may be the opposite: because access has become so easy, teams may begin highly ambitious projects without sufficient preparation or experience.
At the end of the day, we still need people who understand the problem, ask the right questions, design meaningful measurements, anticipate failure points, and architect the system from end to end.
💬 Have you also encountered AI projects that look extremely strong in project documentation but fail to translate into real-world systems?
