In early November, a government-enterprise organization placed a batch of domestic terminals at workstations and equipped them with desktop agents. They could look up documents, view data, and monitor processes, and the demo went quite smoothly. When the IT department met to discuss it, the first question was not how much computing power it ran or how large a model it connected to, but: what gives it the right to touch business systems.
This order of questioning is closer to reality than any AI selection PPT. Yonyou's article on November 2 described the scenario very concretely: the biggest difference between a desktop agent and a chat box is that it has to take action. Checking documents, looking at data, and monitoring processes—these actions ultimately have to land in real ERP, finance, and HR systems. Once they land in the systems, the question shifts from 'is it easy to use' to 'who signs off when something goes wrong.'
In the past week, I went through more than a dozen public documents—from the government-enterprise procurement list at the Tianjin summit, to consultant discussions after TechEd Berlin, and to several 2027 planning guides—and found that everyone is actually catching up on the same assignment: AI can already reach into ERP to do work, but the acceptance forms in the client's hands haven't caught up.
The consistent baseline that multiple government and enterprise AI selection checklists this week set for runtime logs: a unique trace identifier covering the complete chain from user request to tool invocation
1. Replace adjectives with four clauses that can be stress-tested
At the summit, a phrase was used: 'Above the bottom line of security and controllability, efficiency, intelligence, and ecosystem maturity are becoming the core criteria for government and enterprise customers when choosing solutions.' (Huanqiu.com, November 5) It sounds elegant, but when the four-character phrase 'secure and controllable' lands on an acceptance form, it has to be broken apart.
In 2026, the breakdowns given in multiple enterprise AI Agent selection checklists are quite consistent, so I'll run through them in an order that can be verified on site:
| Acceptance item | How to conduct on-site stress testing | What needs to be returned? |
|---|---|---|
| Intranet closed loop | Offline stress test to confirm that inference, retrieval, scheduling, and execution are all local | Outbound connection list, proving there are no components that call external APIs by default |
| Permission granularity | Use different user identities to ask the same question and give the same instruction | Row- and column-level permission matrix, least privilege + independent authorization on every call |
| Operation Trace | Randomly pick a certain day and person, and have the security team restore it themselves from the backend. | Unique tracking identifier + 180-day log retention, covering request→retrieval→output→tool invocation |
| Authentication path | Ask about progress, not 'whether there is any'. | Respective rollout plans and timelines for MLPS Level 3, cryptography assessment, and CAICT evaluation |
There is one criterion that is especially useful: whether the security team can, without asking the vendor, reconstruct on their own from the backend "what someone made the agent do on a given day."
There is another sentence that should be posted in the procurement document: as the “Yonyou” article itself wrote—private deployment itself does not equal security; the key is whether the intranet closed loop is thorough. If only process tools are placed locally while inference still goes through the public cloud, the risk is not eliminated. For finance, energy, government affairs, and pharmaceuticals, “physically isolating data so it does not leave the domain” is not a bonus point; it is an admission requirement.
In domestic substitution projects over the past two years, this is the section where things most easily go wrong. Hardware, operating systems, and databases have all been replaced, yet an external API is still attached to the model and inference chain—no one asks during acceptance, and no one checks after go-live.
“Private deployment” is a deployment method, not a security conclusion.Writing it into a contract only proves where the machine is; it cannot prove where the data is, where inference happens, or whether you can retrieve the logs yourself.
II. Division of labor is not rhetoric; it determines who signs after something goes wrong
Yonyou has given that set of capabilities in YonWork a name: 'autonomous business closed-loop execution': it runs on top of enterprise business systems, connecting existing systems across products, brands, and versions, and within the scope of authorization and rules breaks business goals into executable steps, invokes tools, advances processes, and returns results. Immediately following is a division-of-labor statement—real employees are responsible for goals, judgment, authorization, and accountability; digital-intelligent employees are responsible for decomposition, execution, verification, generation, reminders, and reporting back.
This passage looks like product copy, but it is actually a liability clause. The words “bear responsibility” are written on the human side, and not casually. It determines who to turn to when a voucher is wrong, who to turn to when a payment is approved incorrectly, and who can explain that chain completely when auditors come asking.
Sugon Cloud OneBox takes another path: “Data Bridge” does not let the model connect directly to the database; instead, it adds a server-side data management module between agents and traditional business systems to capture live data from ERP, MES, finance, HR, and other systems. The two technical routes differ, but they avoid the same minefield—handing database credentials to a large model.
Real employee
Goals, judgment, authorization, accountability; accountable for results and compliance boundaries
Digital intelligent employee
Break down, execute, verify, generate, remind, send back; does not define rules
This is actually the same as our old rules when doing implementation: who configures, who reviews, what traces are left, and whom to escalate exceptions to—these four things are written into the policy, and then the switch is flipped. The only difference is that this used to constrain people; now it must also constrain a piece of code that runs on its own.
III. Execution capabilities have raced ahead, while governance is still playing catch-up
Colette's November 6 article about SAP TechEd 2026 made Joule Work's position quite clear. Its predecessor was SAP Mobile Start; now it is a unified work entry point where employees interact with agents; CTO Philipp Herzig put it directly: in the past, AI learned your business; now it gets work done within your business. When inventory falls below the safety stock line, it automatically initiates a purchase requisition and pushes it for approval; if things go smoothly, it proceeds, and if it gets stuck, it is handed over to a human.
But there are two more sentences in the same article that buyers should pay more attention to: agents cannot formulate business rules, compliance requirements, and risk standards on their own; complete permission control and audit traceability capabilities will not be fully available until Q1 2027, and are currently only open to a small number of pilot customers.
This is the most realistic time gap right now. Vendors have pushed out “it can do the work” first, while “it can be controlled” is placed in next year’s roadmap, yet the client is already preparing to use it to process real business documents. This gap in between will not be filled by the vendor for you.
The article is also quite restrained in its judgment of the consulting profession: what will be replaced first are 'execution tasks that can be rule-based and audited, and have a relatively low density of responsibility,' not the consultant role itself. The space for people who can only do basic execution will be compressed; by contrast, the value of those who can sort out chaotic business into systematic rules and take responsibility for data quality and compliance boundaries will become clearer.
In our industry, we've really had this feeling over the past two years. Clients no longer pay a premium for "getting the features configured"; what they're willing to pay for is "making the boundaries clear and catching the exceptional cases." That is precisely the part agents are least good at.
4. Do Not Write “Expectations” as “Results” on the Acceptance Form
Mondelez, together with Accenture, built order-to-cash on a newly built global cloud ERP, covering millions of transactions annually. The wording in the draft is 'expects to be able to'—expected to simplify daily tasks, speed up delivery, and improve accuracy. These are expected values, not acceptance values, and it is written fairly properly.
Conversely, looking at that Infor case from Constellation Research, its approach is worth copying: before go-live, first set the outcome targets—the target for invoice processing automation was stated as 60% to 70%, and in the end they reported 75%; then use process mining to compare before and after go-live, while measuring both time savings and error rates. Set the targets first and define the measurement criteria upfront, so that the results can be compared.
In China, several 'Enterprise-Level Agent Platform Selection Guides' have also emerged in the past few weeks, assessing them across four dimensions: architecture, data, governance, and industry accumulation. The direction is right. But be careful: many of them carry explicit disclaimers and are vendor promotional materials or reposted information. Their certification numbers and market share figures can be used to build a question checklist, but don't copy them directly into a selection report as independent conclusions.
The acceptance wording is actually very simple: don't use 'efficiency improved by about 20%'; use 'using our September 2026 days to close the books and manual reconciliation hours as the baseline, compare after running for a full three months.' The baseline is your own, so the numbers can't get away.
V. Before launch, hard-code these three rules first
First, translate adjectives into stress-test items. Network-disconnection stress-test report, outbound connection inventory, row/column-level permission matrix, 180-day logs and sample restoration demonstration, certification progress plan—if any one of these five is missing, do not sign the acceptance form yet. The security team must be able to independently determine “what someone made the agent do on a given day,” not rely on vendor screenshots.
Second, write responsibilities and escalation paths into the rules. Who configures, who reviews, who is accountable, where an alert escalates if no one handles it for a week, and how to roll back—each item should be assigned to a role. High-stakes actions (large payments, master data changes, tax-related matters) must always retain a human fallback; the agent can draft and execute approved steps, but the person who makes the final call cannot be absent.
Third, validate against your own baseline, and look at only one process. Pick the most painful one, such as accounts receivable collection or supplier order confirmation, and lock down the target value, reviewer, exception fallback, and record-keeping location in writing, then run it for a month. If it runs smoothly, then discuss expanding the scope; if it doesn't, you only lose one month.
There's a line in Metanow's 2027 planning guide that I quite agree with: model upgrades and business rule changes should both trigger regression testing, just like software changes. It labels the guide as forward-looking planning and doesn't dare claim that the 2027 results are already known. That kind of restraint is more credible than a bunch of pretty predictions.
In the past two years, AI in ERP has been moving faster on the feature side than anyone else. What's really holding it back is that no one is willing to fill out that acceptance form in advance. If you wait until something goes wrong to fill it in, the cost is no longer just the time it takes to fill out a form.
Before handing over the keys, first write clearly "who can open which door, and how to check after it has been opened." This statement is not new, but all the developments this week, no matter how they circle around, are talking about it.
Sources: Yonyou BIP, 'After a Domestic Computer Is Placed on the Workstation' (2026-11-02), CCIDnet (2026-11-03), Huanqiu.com report on the Tianjin Summit (2026-11-05); Kelaite Education via NetEase Subscription, 'Joule Work Reconstructs SAP Consultant Work' (2026-11-06, SAP TechEd 2026 Berlin 10/27–28); Consumer Goods Technology (Mondelez × Accenture); Constellation Research (Team Air Distributing × Infor Velocity Suite); Metanow, 'AI Agents in Business: What Changes in 2027' (research verification 2026-11-06); ITBear / IT168 / China Industrial Control Network, Enterprise-Level Agent Platform Selection Guide (2026-11, including vendor promotional claims, as marked in this article).
This article was compiled and written by Guangzhou Zhongdi Information Technology for the reference of those responsible for enterprise digitalization and informatization, and does not constitute procurement advice. The illustrations are AI-generated.
