Can systems built from scratch by the general public using AI tools solve the pain points of enterprise digitalization?

A while back, a CIO complained to Lao Yang: The business departments in the company use tools like WorkBuddy to build many small applications on their own, such as business forms, reports, query pages and so on, which can be launched in just a few days. The boss was very pleased after seeing these, then turned to ask him: "Since the business teams can develop software on their own, why do we still need so many people in the IT department?" The implication of this question is self-evident.

This scenario is no longer an isolated case. Various AI tools have lowered the threshold of software development to the minimum, and business personnel can generate applications using natural language, which has indeed addressed a large number of long-tail demands. However, Lao Yang believes that it is a new misunderstanding to equate "self-built ad-hoc systems" with "the great victory of enterprise digital transformation", or to conclude that "the IT department is no longer needed": this is a misjudgment that treats an efficiency problem as an architecture problem.

The popularity of self-built ad-hoc systems is not a fake demand. It is more like an "edge efficiency revolution" rather than a "core architecture revolution". The current core and key issue is: how can these applications connect to the existing "1" that the enterprise already has, that is, the historical legacy systems, permission systems, data red lines, and audit compliance requirements.

I. What problems do self-built ad-hoc systems solve, and what do they not solve

Take WorkBuddy as an example, it has powerful functions that can quickly generate forms, approval workflows, reports, data processing scripts, and even internal query pages. It accurately solves many pain points in the process of enterprise digital construction, for example: a huge number of demands lead to long IT scheduling cycles that business teams cannot afford to wait; developing simple demands is not cost-effective; business logic is stored in the minds of business personnel, and half of the information is lost when relaying it to the IT team; a large number of temporary, department-level, non-critical processes need to be implemented quickly.

However, there are also some limitations for AI tools to carry out development: self-built ad-hoc systems are only suitable for scenarios that are "lightweight, partial, read-heavy and write-light, for single users or small teams, and with simple processes".

It is worth noting that the most difficult part of enterprise digitalization has never been system development. The replacement and integration of core systems, master data and data standard governance, cross-system transaction consistency, complex permission inheritance, and performance stability, operation & maintenance and audit after scaling up are exactly what "self-built ad-hoc systems" cannot solve. That is to say, enterprises have improved the efficiency of part of the "last mile", but cannot solve the problems of the "main road". Such systems cannot replace core systems, nor can they replace enterprise architecture governance.

II. It is easy to grow from 0 to 1, but the real difficulty lies in growing from 1 to N

What is the most critical issue in enterprise digital construction? It is data connectivity! In other words, solving the problem of data silos. At present, most traditional enterprises have a large number of old systems, such as ERP, CRM, MES, etc., and some systems do not have standard APIs at all. At this time, the technical limitations of AI emerge: no matter how intelligent the AI control layer is, it cannot connect to these systems out of thin air.

This is the most underestimated hurdle for AI implementation in enterprises. AI can understand intentions, plan tasks, and generate invocation logic, but to actually execute the tasks, it has to rely on a set of stable "tools" and "connectors", such as standard REST APIs, read-only database replicas, intermediate tables, RPA, screen scraping, message queues, legacy proprietary interfaces, etc. If none of these are available, the AI control layer is "unable to achieve what it intends to do".

Therefore, what enterprises really need to supplement is not "adding an AI control layer", but building an "enterprise integration layer" that abstracts the capabilities of legacy systems into standard services: API gateway, iPaaS, ESB, data integration platform, RPA platform, and master data management platform. Without this layer, any AI tool can only be a gimmick with no practical long-term value.

Lao Yang reminds everyone here: for legacy systems, don't fantasize about "seamless connection" with AI tools, you need to have an adaptation strategy. For example, for query and report demands, use read-only replicas and data warehouse synchronization to let AI query the data platform instead of directly accessing the production database; for write operations, such as creating orders, modifying customer information, and initiating approvals, if there is no available API, use intermediate tables, dedicated adapters, etc., but do not directly modify business data, because the cost of errors will be extremely high. These professional work related to the entire business and data architecture cannot be completed by business personnel through ad-hoc self-building.

Therefore, the correct approach should be: AI control layer → tool registration layer → enterprise integration layer → legacy systems. Without the middle two layers, trying to use AI to achieve "black box direct connection" will definitely cause major problems.

III. Data Security Red Line: How AI Accurately Inherits Permissions

The second fatal problem: how does the AI control layer ensure that sensitive information is not accessed beyond authorization? Many self-built ad-hoc systems directly use high-privilege accounts, service accounts, or even administrator identities to call systems in order to run through the process. This works fine in the demo environment, but it will be a disaster in the production environment.

It should be noted that the large language model itself has no permission boundaries. It does not know that "Zhang San is an ordinary employee and should not view the salary information of all employees in the company". If the AI uses a unified high-privilege robot account when calling tools, unauthorized access is inevitable. Permissions cannot be placed in the model layer, and must be sunk to the execution layer and policy layer.

It is necessary to achieve "identity penetration": when a user initiates a request on the AI interface, the AI calls the tool with the identity of that user, and the backend performs authentication according to the user's original permissions. The permission scope of AI should be exactly equal to what the user himself can do, no more. Technically, this can be realized through OAuth token exchange, user-level API Key, identity assertion and policy engine.

Each tool that can be called by AI must have a metadata statement: purpose, required permissions, data scope, risk level, whether manual confirmation is required, and audit requirements. For example, the "query customer list" operation with low risk can run automatically, the "modify customer credit limit" operation with high risk requires secondary confirmation, and the "export all employee information" operation is prohibited from being directly called by AI or requires approval. Sensitive fields also need to be desensitized at the column level, filtered at the row level, and dynamically masked at the data service layer, which must take effect before AI outputs results. In addition, every tool call, data access, and write operation must have a complete log: who initiated it, what tool was called, what permissions were used, what data was accessed, what the result was, and whether there was manual confirmation. Otherwise, once a data leak or misoperation occurs, it is impossible to trace the responsibility.

IV. Challenges and Opportunities for Software Companies

The challenges are straightforward: low-end customized development, including CRUD, simple reports, and process forms, will be taken over by AI generation tools; customers are more inclined to "self-develop" and reduce their dependence on outsourcing; if products only provide general functions, they will easily be submerged by AI tools.

But on the other hand, there are greater opportunities. The more popular the self-built ad-hoc systems are in enterprises, the more platforms are needed to manage these systems. Whoever provides a secure AI control layer, connectors, permission agents, and audit platforms will create high value. A large number of legacy systems do not have APIs, which forms a huge market for integration services, and software companies can focus on developing connectors, adapters, and modernization transformation for legacy systems. General AI is not sufficient, and industry-specific AI Agents and templates have competitive barriers: for scenarios such as manufacturing equipment inspection, retail inventory analysis, and medical compliance approval. It is easy for business personnel to build a prototype through ad-hoc self-building, but it is extremely difficult to make it run stably, safely and maintainably in the production environment, and software companies can undertake this part of "formalization" project. Data security and compliance are also rigid demands.

V. How Small and Medium-Sized Software Companies Survive

With limited resources, they cannot compete with large manufacturers for general platforms, but they can compete in depth, service, and industry understanding.

Do not compete with AI generation tools for efficiency. If a customer needs a simple form or report, AI can complete it in a few minutes, and you will definitely lose if you compete on that. Be the "integrator in the AI era", focus on a certain type of legacy system to develop in-depth connectors, for example: specialize in API encapsulation for a certain brand of ERP, AI connection for MES in a specific industry, and bridge connection between WeCom, DingTalk, Feishu and legacy systems. These tedious and tiring tasks are unwilling to be done by large manufacturers, but have extremely high value. Develop "permission agent plus data security" middleware, and build a desensitization and audit component between the AI control layer and the business system, which is not large in scale but extremely critical. Bind to platform ecosystems and become a vertical plug-in service provider for WorkBuddy, DingTalk, and Feishu, instead of building a complete platform on your own. Transform from project-based system to continuous operation: provide subscription, hosting, and scenario accompanying services, and help customers bring self-built ad-hoc systems into governance, which itself is a long-term stable business.

VI. Final Summary

The popularity of self-built ad-hoc systems gives business teams more autonomy, and addresses a large number of long-tail efficiency issues, but it cannot replace the deep-water areas such as enterprise architecture, integration, permission, and data governance.

Real enterprise digital transformation requires four layers of capabilities: AI control layer, enterprise integration layer, identity and permission layer, and data governance layer. Missing any one layer, the self-built ad-hoc system is just a castle built on the beach.

Therefore, it is not difficult to see from the above that the existence of business self-built ad-hoc systems and the IT department are not contradictory. The role of IT only needs to change from "builder" to "platform enabler and gatekeeper".

For software companies, the popularity of self-built ad-hoc systems is not the end, but an opportunity for re-division of labor. The teams that will be eliminated are those that only know how to do simple CRUD operations, have no in-depth industry understanding, and no governance capabilities. The companies that can help enterprises "formalize self-built prototypes into production-grade systems" and "securely connect the AI control layer to legacy systems" will usher in a new wave of growth.

So what's your opinion on this? Welcome to leave a message in the comment area!

This article is from the WeChat Official Account "Xiangjiang Digital Review" (ID: benpaoshuzi), written by Lao Yang, and authorized for release by 36Kr.