传统企业的 AI 项目，为什么大多数都白做了？Why most AI projects at traditional companies end up wasted

The boss comes back from a dinner and says: "We need to do AI too."

So you kick off a project, hire people, line up vendors, and go hard for six months. And then? The money's spent, a demo exists, the presentation happened — but the business runs exactly as before, and the system quietly stops being mentioned.

I've seen this script too many times.

I've spent 8 years as a CTO (at two groups) and have been on the front line of enterprise AI since 2018 — early on with the discriminative AI that came before large models (computer vision, speech, NLP), shipped into one concrete business scenario after another; and since 2024, on LLM applications. Along the way I built a group-level AI platform serving 10+ business units at a large property group, led a full digital transformation at a listed education group, and recently served as an outside AI advisor to several large state-owned enterprises. The most counterintuitive conclusion I've drawn:

When AI projects at traditional companies fail, it's almost never the technology. It's the execution.

Specifically, three traps.

Trap 1: The boss decides, the business doesn't hurt — a "political project" from day one

The most common failure mode: the requirement comes from one sentence by the boss, not from a real pain point in the business.

Bosses have AI anxiety; that's normal. But when a project is driven by "the boss wants it" rather than "the business needs it," it's misaligned from the start:

• The business unit has no urgent need, so cooperation is lukewarm;
• The most critical training data — usually held by that business unit — is hard to get in sufficient quality and quantity;
• Once the demo is done and the presentation is over, the "political task" is complete, and no one in the business has any incentive to push it into production.

I led an intelligent-customer-service project for a large group's property arm, where the stack iterated from multi-turn dialogue all the way to LLMs, RAG, GraphRAG, and multi-agent. Technically it all worked. But some versions stalled at the demo stage — not because we couldn't build them, but because once built, there was no real pull from the business side.

How to avoid it: before kicking off, ask one question — "If we don't build this AI, will the business feel the pain?" If the answer is no, it's probably a political product. Top-down sponsorship isn't the problem; the problem is a sponsor who doesn't settle on a direction and see it through — one idea today, a different one tomorrow.

Trap 2: No baseline — you spent the money but can't say whether it worked

The second trap is almost the twin of the first: when the project starts, no one defines "what it looked like before" and "what counts as success."

An AI project with no baseline, no matter how advanced, can never prove its real contribution to the business. When someone asks "so how much did this actually improve things," the team can only be vague — and to decision-makers, vague means useless.

Worse, by the time you want to add a baseline, the moment has passed: the pre-launch comparison data was never captured, and you can't reconstruct it after the fact.

How to avoid it: put "define KPIs and a baseline" on the project's kickoff checklist, as important as setting the budget. Even a few rough metrics — response time, escalation rate, cases handled per person — beat nothing. Only what can be measured earns the right to talk about ROI.

Trap 3: Chasing shiny tech — when to use LLMs / GraphRAG, and when not to

The third trap is a "better safe than sorry" reflex in technology selection.

In the last couple of years, bosses have heard too many new terms: large models, GraphRAG, multi-agent, agentic… It's easy to fall into "everyone else is doing it, so we must too" — and end up paying a hefty premium for fashion.

Take the most common scenario, an enterprise knowledge base, and the much-hyped GraphRAG, to make clear when it's worth it and when it isn't.

Plain (vector) RAG solves "find similar." It vectorizes the question, retrieves the most semantically similar document chunks, and feeds them to the model. The vast majority of enterprise Q&A — looking up a policy, a process, an FAQ, a specific record — is single-hop factual retrieval. Plain RAG is enough, and it's fast and cheap.

What it can't solve is connecting scattered information into a chain. Because vector retrieval is fundamentally about similarity, it doesn't understand the relationship structure between entities. So it struggles with three kinds of questions: multi-hop reasoning (A relates to B, B relates to C, follow the chain), global aggregation (overall trends, cross-record statistics), and relational reasoning. GraphRAG exists to fill exactly this gap — use an LLM to extract entities and relationships from the corpus, build a knowledge graph, and retrieve over the graph, so it can answer questions that span multiple entities along a relationship chain.

But GraphRAG's costs are real, and easily overlooked:

1. Indexing is expensive — extracting entities and relationships relies on many LLM calls; building a graph over a large corpus is slow and costly;
2. Weak incremental updates — the graph is often built globally, and new data frequently forces a rebuild, making it a poor fit for fast-changing data;
3. Not for real time — it's essentially a static snapshot; it can't do "today's live data" statistics;
4. Performance cost at scale — once the graph gets large, query latency has to be measured, not assumed.

How to avoid it: technology selection always serves the business problem, never the other way around. The right move isn't to choose between plain RAG and GraphRAG — it's to route by question type: point lookups / single-hop retrieval go to plain RAG; multi-hop / relational / global-aggregation questions go to GraphRAG; real-time statistics go straight to structured queries (e.g., Text2SQL). Then use an orchestration layer to route each request to the right path. Betting everything on the single trendiest technology will almost certainly fall over on some class of question.

What the three traps have in common

You've probably noticed: none of these three is "the model isn't strong enough" or "the algorithm isn't good enough."

What they share is this — the real difficulty of AI adoption is never the technology itself, but whether strategy and business are aligned, and whether you're being pragmatic.

• Alignment: who is this AI for, and what real problem does it solve?
• Pragmatism: first get the core business steps online and instrumented, define metrics you can measure, use the appropriate (not the trendiest) technology, win at a single point, build a flagship, then scale out.

For a traditional company to use AI well, the first step isn't buying technology — it's getting clear on these two things. Get them right, and AI is an amplifier. Get them wrong, and AI is just one more sunk cost.