Enterprise AI Implementation: It's Not the Tools Being Rebuilt, but the Production System

A contradictory scene is emerging in enterprise AI adoption: bosses talk about the whole company embracing AI, employees say they are already using it, and companies can produce a few impressive demos. However, looking back at delivery cycles, output quality, and customer experience, the overall change is not significant.

This doesn't mean AI hasn't created efficiency. On the contrary, the improvement in individual productivity is often real. The problem is that enterprises have merely placed AI into old organizational structures; AI is still working around old processes.

Therefore, the core issue for enterprise AI today is not "whether there is a model," but whether data, expert knowledge, system actions, and accountability mechanisms can be organized into a new business production line.

This is also my judgment on enterprise AI adoption: what will create the future gap is not who gives employees accounts the earliest, or who integrates a certain model the earliest; it's who completes this reconstruction of the production system the earliest.

Everyone is taking action, so why are the organizational results still not obvious?

Wang Dong, Product Lead of WPS 365, described a typical enterprise state in a podcast: from frontline employees and middle managers to top leadership, everyone believes AI will change productivity, and everyone worries that they or their company haven't truly kept up.

Thus, enterprises are not inactive. Employees are already using AI to write code, perform analysis, and process documents; management is also paying attention to models, computing power, and budgets. But most of these actions remain scattered and point-based.

The questions that truly stump management are: Which business process should we start with? How much budget should we allocate, and how do we control costs? And what metrics should we use to determine whether AI is bringing personal convenience or enterprise-level value?

Without answers to these questions, goals, plans, and organizational coordination cannot be established. Enthusiasm for individual AI use is high, but the overall organizational effect has yet to materialize. Wang Dong likened this state to a "quake lake": water has accumulated, pressure keeps building, but the outlet leading to organizational-level value hasn't been opened.

From this perspective, the difficulty of enterprise AI does not lie in whether employees are willing to use the tools. Bottom-up individual efficiency gains are already quite common; the harder part is top-down reconstruction of goals, processes, data, interfaces, budgets, and responsibilities to converge these point-based uses into a measurable production line.

Three types of friction truly encountered by frontline practitioners

I've also spoken with many employees and FDEs (Frontline Deployment Engineers) involved in enterprise AI adoption. Most are not resistant to AI and even use it proactively; what truly troubles them is that the company demands "comprehensive AI embrace," but new ways of working, responsibility boundaries, and support conditions haven't been established simultaneously. They mainly encounter the following three difficulties:

First, AI is treated as a speed-up slogan but hasn't become a shared workflow.

A design and front-end engineer mentioned that the company wants to use an Agent to standardize post-meeting requirement documents. He isn't opposed and even believes it can reduce confusion. The problem is the team only received the "adopt it quickly" directive, without jointly agreeing on: which meetings enter the process, who maintains the context, where generated results are written, and what constitutes completion.

Tools were distributed first, but organizational rules didn't catch up.

Second, AI can generate results but cannot automatically assume verification and responsibility.

When AI can read organizational data, historical configurations, and related system information, it can indeed shorten troubleshooting, requirement breakdown, and configuration work. But even if AI generates tests or configurations, reviewers are still responsible for the final outcome.

The reason is simple: it might produce content that seems reasonable and even passes tests, but hasn't validated critical business logic. Generation time is shortened, but verification, accountability, and exception handling don't automatically disappear.

Third, management expects cost reductions, but the complex work faced by the frontline hasn't disappeared.

One practitioner mentioned that the company requires comprehensive AI-driven development and expects development costs to be halved. But writing code is just one part of software work. Requirement understanding, architectural trade-offs, quality control, cross-team communication, and responsibility for customers and production incidents won't disappear just because AI appears.

AI compresses the time of the implementation phase and may also shift more review, coordination, and risk to frontline employees. Without redefining roles and resetting responsibilities, local speed-ups might instead deliver more outputs requiring downstream review to the next stage.

These are not minor conceptual flaws but real friction in enterprise AI adoption. They explain why many companies have bought tools, conducted training, and run pilots, yet still don't see organizational-level productivity improvements.

Thus, a seemingly powerful question arises: AI capital expenditures keep increasing, but enterprises temporarily see no obvious results. Could AI just be another technology bubble?

Why the productivity dividends of general-purpose technologies always arrive later

This question cannot be refuted simply by saying "AI is important." Placing it in the longer history of technology makes the problem easier to see.

Economic historian Paul David pointed out in his 1990 paper The Dynamo and the Computer that from the 1880s when electricity entered factories to the 1920s when productivity gains were clearly released, several decades passed in between. Early factories weren't incapable of using electricity; rather, after replacing steam engines with electric motors, they still retained old structures like line shafts, drive belts, multi-story buildings, and centralized drive systems.

The advantages of electricity—distributed power supply, independent scheduling of different processes, more flexible factory layouts—could only be truly unleashed after factories, equipment, and work rhythms were redesigned around it.

Personal computers went through a similar phase. Solow's famous observation—"You can see the computer age everywhere but in the productivity statistics"—pointed not to computers lacking value, but to enterprises initially treating them as more expensive typewriters: typing, printing, filing into folders on the computer, then handing them to people for archiving.

The same goes for the internet and cloud. Connecting to the network or migrating to the cloud doesn't automatically bring new unit economics; product distribution, collaboration methods, data flows, and decision rights need to be rewritten accordingly.

Different technologies cannot be mechanically compared. But history offers a useful reminder: general-purpose technologies are often first adopted, then embedded into old processes, and only manifest as significant productivity gains after organizational restructuring.

Today, AI is easily misinterpreted precisely because the progress in model capabilities is explicit, while the cost of organizational restructuring is implicit. The former updates monthly; the latter involves departmental boundaries, budgets, permissions, performance, and responsibilities, typically advancing quarterly or even annually.

Therefore, the fact that productivity hasn't immediately and significantly improved is not enough to prove AI lacks value; it could also mean local efficiency has already increased, but the whole is still bottlenecked by the old organization.

The real bottleneck: It's not that AI isn't fast enough, but that AI is waiting for people

Many enterprises today are exactly stuck at this stage: having AI write meeting minutes faster, then having people copy them into systems; having AI help with analysis, then having people compile it into reports; having AI generate code, then plugging it back into the original lengthy processes of requirements, reviews, testing, and release.

These modifications aren't wrong. They are necessary "sesame seeds" and the beginning of an organization building AI literacy. But if they stop here, the enterprise has merely installed an electric motor on an old loom.

Databricks Co-founder and CEO Ali Ghodsi shared an internal case in a Stanford public lecture. Databricks needed to securely and stably connect data from business systems like Salesforce and Workday into its platform; the "data connector" here is the data ingestion component responsible for this system integration.

Following the original process, building a production-ready Salesforce data connector typically took 3 quarters, about 9 months. In the first quarter, product managers repeatedly visited customers, gathered requirements and usage patterns, and finally submitted a 60 to 80-page requirements document; only then did they enter the stages of development, building test environments, verifying security, and handling customer feedback.

Ghodsi himself used AI to write a version in two days, but the team considered it just a demo: it hadn't undergone complete testing and couldn't guarantee safe, stable service for real customers. Even adding AI to the original process, the team estimated the cycle could only be shortened from 9 months to about 7.5 months.

The turning point wasn't switching to a stronger model, but rewriting the process: shortening the requirements phase from a quarter to a week, first quickly forming a usable version, then correcting errors through iteration; handing test environment setup to a more capable external team for parallel work; and changing the collaboration method from "one person guarding one connector" to a team collectively covering a group of connectors, eliminating single points of dependency.

Ultimately, they delivered 7 different production-grade data connectors within one quarter. Ghodsi's conclusion was straightforward: even with more advanced models, this type of problem wouldn't be automatically solved; what truly needs solving is process reconstruction and human collaboration methods.

This case illustrates not how fast AI can write code, but how limited AI's role is when requirements, testing, and collaboration still follow old methods. Only by rewriting the entire delivery chain can productivity see an order-of-magnitude improvement.

For enterprise AI adoption, which layers actually need reconstruction?

"Organizational restructuring" can easily become a correct but vague phrase. I prefer to break down the structure of enterprise AI adoption into five layers.

1. Value Layer: First, choose which core production line.

   • Clarify which key link AI is meant to transform: R&D, contract and delivery, manufacturing quality, sales operations, or customer service;
   • It must relate to delivery, revenue, gross profit, risk, or customer experience, not just pursue "seeming time-saving";
   • Prioritize "high-difficulty, high-value" business areas.

2. Context Layer: What AI Bases Its Judgments On

   • Place unstructured knowledge, structured business facts, historical cases, and expert judgments within the correct data boundaries;
   • The goal is not to build a general knowledge base, but to enable the model to understand "this specific moment, this specific enterprise, this specific process";
   • Without this layer, AI can only provide generic advice and cannot reliably undertake enterprise tasks.

3. Work Design Layer: How Humans and AI Divide Labor

   • Who defines goals and constraints, who handles exceptions, who holds final approval authority;
   • Senior experts cannot only appear at acceptance meetings; they must participate in iterations as business architects;
   • Human time should shift from repetitive execution to judgment, review, and rule improvement.

4. Production System Layer: How Results Safely Flow to the Next Step

   • Tool invocation, system interfaces, permissions, auditing, manual escalation, failure recovery, costs, and observability must be designed together;
   • This layer transforms an Agent that "answers well" into a system that "can be trusted in production."

5. Learning & Measurement Layer: How the System Improves with Use

   • At the task level, look at completion rate, duration, rework, escalation, and errors; at the business level, look at delivery, risk, revenue, or gross profit;
   • Feed expert corrections, manual approvals, and online results back as cases, rules, and evaluation datasets;
   • Without this layer, projects can only produce demos repeatedly and cannot accumulate into the enterprise's own capabilities.

These five layers are not a linear project checklist, but a closed loop. Focusing only on the value layer often stops at a consulting proposal; focusing only on the context layer often builds an unused knowledge base; focusing only on the production system layer often becomes a platform without business goals; focusing only on the measurement layer can easily mistake tokens and lines of code for value.

The hardest part of enterprise AI is precisely aligning these five layers within the same real business closed loop.

First Question: Which Production Line Is Worth Rebuilding?

Personal tools can proliferate quickly. They can improve basic efficiency and help organizations develop AI literacy. But organizational-level investment requires a different set of selection criteria.

"High difficulty, high value" is crucial. Scenarios that are too easy or too peripheral often only add icing on the cake; an enterprise's true productivity still comes from its core business production lines.

For a software company, the production line runs from requirements to deployment to operational feedback; for a manufacturing company, it's processes, equipment, quality, and supply chain; for a service company, it might be from customer commitment to delivery, payment collection, and renewal; for an innovative pharmaceutical company, it's from target identification and screening to experiments, clinical trials, and regulatory approval.

When selecting a scenario, start by asking five questions:

1. Does this step genuinely impact delivery, revenue, gross profit, risk, or customer experience?
2. Is there usable real data, along with clear criteria for judging whether results are right or wrong?
3. Are the most experienced business experts willing to co-create in short cycles, not just perform final project acceptance?
4. Can AI results be safely integrated into the next action, with a preserved manual escalation path?
5. If successful, can the rules, interfaces, evaluations, and permission models be solidified as assets owned by the enterprise itself?

When the first three questions are unclear, don't rush to build an "all-powerful Agent."

Why Coding Often Lands First

As we know, among various vertical tracks, the first to take off was Coding (the widespread layoffs in major internet companies are solid proof). This isn't because programmers are easier to replace, nor just because developers are more eager to try new things. A more fundamental reason is that software development, even before AI arrived, already possessed a relatively complete digital production foundation.

Code is in repositories, requirements and changes can be tracked, compilation can check syntax and dependencies, testing can verify some behaviors, CI/CD can deliver results to environments, and there are logs, monitoring, and user feedback online.

In other words, most parts of the "loom" for writing code already existed. AI can directly read code, documentation, issues, and test results, generate candidate changes, and immediately receive feedback from compilation, testing, and review.

Image: Ilya Pavlov / Wikimedia Commons, CC0 1.0.

It has three first-mover conditions:

1. Relatively clear boundaries. A function, interface, bug, or set of acceptance criteria is usually easier to break down into local tasks than "managing a customer relationship well."
2. Highly digitized process. Code, configuration, dependencies, historical commits, and runtime logs can all enter the context. AI doesn't have to first bridge paper, phone calls, offline operations, and implicit rules.
3. Results can be quickly measured. Whether it compiles, whether unit tests pass, whether regressions occur, whether latency and error rates change—these provide denser feedback signals than subjective evaluations.

Therefore, the reason Coding Agents landed first is that they were the earliest to possess the closed loop of "digital raw materials + clear tasks + automatic feedback."

But faster code generation doesn't mean software creates value faster. Lines of code, PR counts, and test pass rates are only R&D productivity metrics; they cannot replace user needs, product judgment, system architecture, and operational responsibility.

The faster AI can generate a part, the more teams need to shift their attention to intent clarification, constraint design, review, observability, and online quality. This is also the most important lesson Coding AI offers other industries: first complete digitization, task boundaries, and verifiable feedback, then talk about scaled intelligence.

What Determines AI Effectiveness is Runnable Context

The effectiveness of enterprise AI depends not primarily on which model is used, but on whether the enterprise connects the correct context to the correct process.

Every company has "that person": when a problem arises, people say "go ask him." He knows which customer's historical promises cannot be touched, which type of anomaly is normal fluctuation, which contract is superficially compliant but must be escalated. This knowledge is not automatically possessed by general models, yet it's crucial judgment in the enterprise's core business.

But dumping thousands of PDFs into a knowledge base does not equate to giving context to AI. An organizational system capable of entering production needs at least four types of elements:

1. Unstructured knowledge: Contracts, proposals, emails, meeting notes, and historical cases;
2. Structured facts: ERP, CRM, finance, MES, orders, inventory, and real-time business status;
3. Business rules: What can be processed automatically, what must be escalated, what needs whose confirmation;
4. Action & feedback: What tools the system can call, where results are written back, who reviews, which results are used for subsequent evaluation.

Without the latter two, AI is mostly just a talking search box; giving it action authority without permission boundaries, auditing, and manual review might scale errors.

Therefore, data governance is not a one-time "clearance" before an AI project, but the ongoing process of turning knowledge, permissions, and feedback loops into infrastructure.

The Most Senior People Cannot Only Appear at Acceptance Meetings

There's a paradox in enterprise AI implementation: the more important the process, the more it needs the most senior people involved; yet the more senior they are, the less time they have to cooperate with a project that may not seem likely to succeed.

Traditional software projects often waste this scarce time: first, ask experts for a round of research, then the project team goes back to write proposals, develop, and test; weeks or months later, ask the experts for acceptance. By then, the system and real judgment have already diverged significantly.

The key change AI can bring is aligning expert judgment and system implementation on the same timescale. After a senior legal expert points out "18 items are missing here" or "this situation must be escalated," the system should produce new runnable results within hours, not wait months for another acceptance.

Experts are no longer just validators, but business architects.

This also explains the value of FDE (Field Development Engineer) or similar delivery roles: they don't just write a bit more custom code for the enterprise, but enable the people who best understand the business, real data, system capabilities, and evaluation mechanisms to form a short-cycle closed loop on-site.

What's truly reusable is not just an Agent, but this reliable workflow that translates expert experience into production capability.

Evaluating AI Projects Requires Three Sets of Metrics, Not Just a Token Bill

Enterprises ask: Is this AI investment worth it? The answer cannot rely solely on model token usage, nor just on a profit and loss statement.

I prefer to divide metrics into three layers:

• Individual efficiency: Whether tasks like drafting, searching, analyzing, and coding become faster;
• Team productivity: Whether cycle time, rework, escalation, defects, expert review time, and task completion rates improve;
• Business value: Whether delivery is faster, risk is lower, customer response is better, and whether revenue, gross profit, or payment collection changes.

The first two layers usually appear earlier, the third layer slower. This isn't making excuses for projects, but reminding managers: more code, reports, and tokens do not equal more value; but shortening key cycle times, reducing errors, and amplifying expert capabilities should not be simply dismissed because "the P&L hasn't changed yet."

The real question should not be "how many people did AI save us," but "what more did this production line accomplish than before, what fewer mistakes did it make, and who was therefore able to invest time in higher-value decisions."

A More Pragmatic 90-Day Timeline

Organizational restructuring sounds grand, but the start doesn't have to be. Based on my experience, 90 days can produce a genuinely noticeable effect.

First two weeks: Select one process, record the baseline. Don't start with a tool list, but with a high-value, high-difficulty, well-defined task. Record who handles it now, how long it takes, where the waits are, where errors occur, and which results require a person to be ultimately responsible.

Weeks 3 to 6: Have experts and the delivery team run a real closed loop together. Use real data, real rules, and real users—don't just work with demo data. First, get one critical judgment or action to run from input to result, and explicitly expose the exceptions that cannot be automated.

Weeks 7 to 12: Build out production capabilities. Permissions, auditing, evaluation, cost, failure recovery, human escalation, and operational responsibility are not "polishing items" for post-launch; they are the parts that determine whether the system is worth scaling up.

Only then discuss scaling. By solidifying recurring rules, cases, evaluations, interfaces, and delivery methods, the enterprise avoids starting from scratch with one-off customizations every time and prevents locking core capabilities entirely within a single vendor.

Conclusion: AI Transformation is Not a One-Time Purchase, but an Organizational Capability Building

Making all employees faster does not equate to making the organization stronger.

True organization-level AI is not about giving everyone their own smart assistant. It's about enabling a group of people, with shared context, clear permissions and responsibilities, and verifiable results, to collectively manage a new production system.

This is much more troublesome and slower than just plugging a large model into old processes. But once established, what remains is not just a one-time efficiency dividend, but the long-term capability of the enterprise to re-orchestrate expert knowledge, data, and computing power.