Why So Many AI Projects Deliver No Return—and How to Avoid the Same Mistakes

“95% of AI projects deliver no return.” The figure gets repeated often—and it sounds alarming. But before writing off AI altogether, it is worth understanding what the number actually measures.

The real lesson is not that AI does not work. It is that a project launched without a clearly defined problem, baseline metrics, or an adoption plan is unlikely to create value.

First, Put the 95% Figure in Context

The figure comes from MIT NANDA’s report, The GenAI Divide: State of AI in Business 2025. It concerns generative AI pilots conducted primarily by large enterprises—not Québec SMBs.

According to the report, only a small proportion of these initiatives produced a measurable financial return. It would therefore be misleading to conclude that 95% of AI projects undertaken by small businesses fail.

The finding remains relevant, however: even large budgets and specialized teams cannot compensate for a poorly defined problem, inadequate data, or a solution that employees cannot—or do not want to—use.

Preparation cannot guarantee success. It can, however, help you eliminate weak ideas early and direct your investment toward opportunities with measurable potential.

Four Common Pitfalls

An IT services firm identified four problems that repeatedly undermine AI projects. They also reflect many of the challenges Québec SMBs encounter in practice.

1. Inadequate or Scattered Data

An AI system cannot produce reliable results from information that is incomplete, contradictory, or scattered across numerous files and applications.

This does not mean every record must be perfect before work begins. You should, however, understand where the data comes from, how reliable it is, and what limitations it carries.

2. A Solution Isolated from Existing Tools

An AI system that cannot exchange information with your CRM, accounting software, email, or other operational tools may add another manual step instead of removing one.

Not every project requires a complex API integration. What matters is knowing how information will enter the system, how the result will return to the workflow, and where human intervention will be required.

3. No Baseline Metrics

If you do not know how much time a task takes today, how many errors it creates, or what it costs, you will not be able to demonstrate that AI improved it.

Before building anything, measure a few simple indicators:

• The volume of work processed

• The time spent on each case

• The error or rework rate

• The processing time

• The approximate cost of the process

These measurements will provide the baseline against which the project can be evaluated.

4. Adoption Left to Chance

A tool that nobody uses generates no return. The people who perform the work should therefore participate in defining the problem, testing the solution, and identifying exceptions.

Employee resistance is not always an aversion to change. It may be evidence that the tool slows people down, produces results that are difficult to verify, or fails to address the real problem.

Is Your Business Ready?

The prerequisites depend on the project. A straightforward document-processing automation does not have the same requirements as a predictive system trained on several years of operational data.

Before investing, however, you should be able to answer the following questions:

• What specific problem are we trying to solve?

• What does that problem cost us today?

• Does the task occur frequently enough to justify automation?

• Do we have the necessary data or documents?

• Is their quality sufficient to support an initial test?

• Will the solution need to communicate with our existing systems?

• Who will be accountable for the project and its results?

• Who will review the output and handle exceptions?

• What sensitive information will the system process?

• What result would convince us to continue—or to stop?

If several answers remain unclear, the project is not necessarily a bad idea. It simply means that the next step should be a limited assessment or prototype, not a full deployment.

Data Preparation: An Effort to Estimate, Not Assume

Cleaning and structuring data can represent a significant part of an AI project. In some cases, it takes several weeks. In others, a carefully selected sample is enough to test feasibility quickly.

It is better to estimate this work at the beginning than to discover later that documents are incomplete, fields do not match, or nobody knows which source is authoritative.

This preparation is not wasted effort. Even if the AI project does not proceed, better-organized data can improve existing operations and reporting.

Protecting Sensitive Information

Separating “open” tools from “closed” systems is not enough. Before sending internal information to an AI service, verify:

• Whether the provider uses your data to train its models

• How long the data is retained

• Where it is hosted

• Who can access it

• What activity is logged

• Which contractual and technical safeguards apply

Some professional AI services can process internal information safely when configured with appropriate controls. Conversely, even a privately deployed tool can create risk if it is poorly configured.

Financial information, personal information, client records, and high-impact decisions require controlled access, traceability, and human review.

Large-Enterprise Successes Show Potential, Not a Target

Alibaba reportedly saved approximately $150 million per year by automating a large share of its customer inquiries. Vodafone reportedly automated around 70% of certain routine requests. An anonymized construction company reportedly reduced its employee onboarding time substantially.

These cases illustrate what may be possible at scale. They are not budget benchmarks or performance promises for an SMB.

For a smaller business, a better first objective may be far more modest: recovering a few dozen hours each month, reducing missed follow-ups, accelerating an administrative process, or eliminating duplicate data entry. A limited but recurring gain can be more valuable than an ambitious system that is difficult to maintain.

What This Means for Your Business

AI projects can fail for many reasons: the wrong problem, insufficient data, expensive integrations, weak adoption, or technology that is simply not reliable enough for the intended task.

The best protection is to begin with a real process, measure its current cost, and test the proposed solution on a limited scale. A prototype should answer three questions:

1. Is the result reliable enough?

2. Can the team incorporate it into its daily work?

3. Does the benefit justify the implementation and maintenance costs?

If the answer is no, it is better to find out early. If the answer is yes, you then have concrete evidence on which to base a larger investment.

At yeevy, this is where we begin: understanding the process, measuring the time being lost, assessing the available data, and building a focused initial prototype. The objective is not to introduce AI everywhere. It is to determine where automation can deliver a measurable result—and where it is not worth the investment.

A well-prepared project is never guaranteed to succeed. It is, however, easier to evaluate, less expensive to correct, and considerably more likely to create lasting value.