Enterprise AI Adoption: Getting a Demo to Run Is Only the Starting Line — the Real Difficulty Lies in These Four Things

The Tencent Research Institute recently published a report, *Co-creation on the Front Line, Empowerment in Both Directions: Industry Observations and Practice of the FDE Model*. Drawing on first-hand interviews and surveys with multiple organizations, plus Tencent Cloud's own experience with customers, it analyzes the problems that recur in enterprise AI adoption and discusses how those difficulties actually play out at delivery sites. FDEs (Forward Deployed Engineers) go deep into customer sites to help technology truly take hold — but many of the problems the report discusses are just as familiar to AI teams inside enterprises.

Shift the perspective from the delivery side to the enterprise itself, and four prominent problems come into view, along with three changes companies need to make.

1. Mistaking "the demo runs" for "the product can ship"

AI projects should build a feasibility demo early: how well the model performs on your own data, whether the interfaces connect, whether the actual results meet requirements — all of this needs to be tested in a demo. That is exactly where a demo earns its keep: validating feasibility and surfacing risk early.

The problem is that some demos look impressive and start falling apart the moment they enter production. Take AI customer service. In a demo, ask "what are the return conditions?" and it may answer beautifully. Real customer questions are far messier: "The item has already been opened," "the previous agent promised special handling," "so can I return it or not?" In production, what happens when an order lookup fails, when a tool call times out, or when the model isn't sure whether to keep going or hand off to a human? These exception paths all need explicit handling rules.

The report uses three numbers — 80%, 95%, and 99% — to illustrate the gap. An agent that covers 80% of scenarios gets working quickly, with an LLM and a simple prompt. But pushing coverage to 95% and improving production reliability requires continuously adding business knowledge, refining prompts, and doing a great deal of engineering work. The hardest part is pushing coverage to 99%.

Enterprise AI is not the same as personal AI: a single mistake can have serious consequences, and the more systems you connect, the more complex auditing, rollback, and human handoff become. The report divides enterprise AI adoption into five stages — scenario identification, prototype validation, pilot operation, production deployment, and scale-up — but after go-live there is still a great deal of work to be honed in the real business.

2. Being able to build an AI application is not the same as choosing a high-value scenario

The report splits the capabilities an FDE needs into two kinds: one role judges what should be done, and the other builds it. AI has lowered the cost of the latter — the cost of engineering implementation — but identifying high-value scenarios and understanding the business still requires human judgment. Just because building has become easier does not mean an enterprise automatically knows what is worth doing.

A typical example: "Our competitor has an AI customer service agent, so we should build one too." That is a lead, not a statement of the problem. It doesn't say what we actually need to solve — is it too many repetitive inquiries, complex issues handled too slowly, unstable service quality, or information that isn't connected? Different problems call for different solutions and different investments. Some problems suit AI; others might be solved by connecting information or adjusting existing systems.

There are many places an enterprise could apply AI, but the value and the difficulty of landing it differ from one to the next. The AI team needs to work with the business to judge which problems are worth solving first, which metrics will improve once they are solved, and whether the investment pays off. Being able to build an AI application and needing to build it are two different things.

3. What employees can do, AI may not do better

Choosing a high-value scenario only answers "is this worth doing." It does not answer the other half: are the business knowledge, rules, and system conditions needed to complete it actually in place?

Much of the collaboration inside a company depends on timely communication; decisions depend on key individuals; and a great many processes and judgment rules live in employees' experience and a team's tacit understanding. The business running smoothly every day does not mean that way of operating has been clearly articulated — still less that AI can execute it correctly just by being handed the existing documentation.

The report gives the example of ERP. A company asks AI to handle order flow automatically, and only at implementation does it discover a pile of rules that need adapting: for instance, orders above a certain amount require the general manager's approval before shipping, and the finished-goods warehouse and the raw-materials warehouse have different receiving and shipping rules. A generic process working does not mean it understands how this particular company does business.

So the employee experience, process rules, and tacit knowledge tied to the target scenario all need to be sorted out and turned into context AI can use.

4. Individual productivity is not organizational productivity

One person can finish a task faster with AI, but the work still goes through the same handoffs, reviews, and decisions — the business as a whole isn't necessarily faster. If a company wants overall efficiency gains, it has to re-examine process collaboration and performance assessment.

First, business processes. Adding AI inside an existing business and redesigning the process around AI are two fundamentally different approaches. The former keeps the old process and organization and uses AI for local efficiency gains. But once AI is in the picture, you should ask again: does this business still need to run the old way? What work can be completed directly? Which steps can be merged? Which redundant information transfers can be cut? If waiting time and repetitive labor in the process don't shrink, the time individuals save will not translate into overall efficiency.

Second, how AI adoption is organized. Knowledge sorting and effect validation require business experts to take part directly. But if the company still treats the business as the side that simply "submits requirements," who is supposed to supply the professional knowledge? A gap in responsibility opens up: product and engineering receive the requirement, but not the domain knowledge needed to fulfill it. And after launch, business experts still need to keep judging the results.

Third, assessment and incentives. Once the process has been redesigned around AI, why would business staff be willing to change the way they work? Business experts spend time organizing experience, analyzing errors, and verifying results — but if their original workload doesn't shrink, that effort isn't reflected in performance reviews, and business outcomes don't improve either, it is hard to keep pushing forward. Ultimately, no one is jointly accountable for the outcome.

Back to the enterprise: three things to start on now

Companies' expectations for AI have risen, but project investment, business participation, and organizational management have not kept pace. They want demos to become stable products quickly, they want the technical team to be handed high-value scenarios, and they want AI to absorb the experience employees have accumulated over years. But if validation, knowledge sorting, and continuous improvement don't get the corresponding resources, those expectations are hard to fulfill.

Drawing on the four problems above, there are three things to start on right away.

First, don't use the pace of a demo to estimate the entire adoption cycle. After the demo works, real data handling, exception response, and production reliability all need continuous validation. Management must set aside time and resources for this work and decide whether to keep investing based on results at each stage. Demanding a full rollout too early easily drags problems that never surfaced in the demo into the business.

Second, organize small teams around high-value scenarios, with business and technology jointly accountable for the outcome. Business owners should take part in judging what is worth doing, and business experts should take part in sorting out knowledge. Whether using internal resources or bringing in an outside team, the business cannot show up only when it's time to submit requirements.

Third, when processes, responsibilities, and assessment are changing, senior leadership has to genuinely take part and drive it. The CEO, or a business owner with decision-making authority, needs to lead the effort, coordinate departmental investment, and adjust how performance is assessed. If these things are always just "extra cooperation," the AI team will find it very hard to push them through alone.

A company can hand system development to a professional team, but how the business changes, how people are invested, and how responsibility is borne are decisions management has to make itself. That is also why so many companies find AI adoption so difficult.