Don't rush to build an "industrial brain" for industrial AI startups.

A few days ago, I attended an offline roadshow themed on industrial AI.

The project directions varied. Some focused on production optimization, some on equipment management, some on quality inspection, and some aimed to enter more complex industrial decision - making scenarios. The founders also had strong backgrounds. Some came from traditional industrial software companies, and some had experience in industrial projects, so they were not unfamiliar with the customer sites.

However, after listening, one thing was quite consistent: many projects would first spend a lot of time criticizing traditional industrial software and then claim to develop "full - stack solutions" or "end - to - end closed - loops". Taking it one step further, it was a so - called "industrial brain" in a sense.

The story flowed smoothly and the logic made sense.

Criticizing traditional industrial software is not difficult. The problems of old systems, fragmented data, cumbersome processes, and poor communication between departments do exist. Those who have worked on factory informatization have probably heard of these issues.

However, the problem is that traditional industrial software has never only addressed efficiency issues.

It deals with how to solidify processes, how to allocate permissions, how to record operations, how to report exceptions, and how to trace responsibilities. Efficiency is important, but in the face of safety, responsibility, and regulations, efficiency may sometimes be downgraded.

Founders see inefficiency, while customers may see controllability. Founders want to optimize processes, but customers worry about who will bear the risks if the processes are disrupted.

Therefore, criticizing the inefficiency of a system does not mean you have the ability to replace it.

The most common misjudgment in industrial AI startups is not that the technology is not advanced enough, but that they treat the customer site as a blank slate.

A factory is never a blank slate. It already has equipment, systems, processes, positions, suppliers, acceptance standards, and a responsibility chain that may not be clear but definitely exists. If you want to enter, you first need to figure out where you stand in this picture.

1. The language used for financing and the language used for customers are two different things

Founders like to talk about full - stack for practical reasons.

Full - stack implies a large market, wide boundaries, and a complete story. If they only mention that they are developing a quality inspection module or an equipment early - warning tool, it may seem "small - scale" at the roadshow. But if they talk about integrating data, models, processes, and business closed - loops, the financing narrative immediately expands.

During the roadshow, founders need to tell a complete story. At the customer site, problems are usually compressed into small ones.

Industrial customers are not unaware of the inefficiency of their existing systems. In many cases, they are more aware of the problems than external entrepreneurs. However, inefficiency does not mean immediate replacement. A seemingly cumbersome industrial software may be tied to production processes, equipment interfaces, organizational permissions, audit records, supplier relationships, and internal management habits. Just because it's not user - friendly doesn't mean it can be easily removed.

Therefore, the first question customers usually ask is not "Are you smarter than the original system?", but "Can you solve a specific problem without creating new troubles?"

Founders are thinking about full - stack replacement, while customers are thinking about whether it can be safely integrated into the existing processes. There is no direct translation between these two ways of thinking. Even if the presentation on stage is perfect, it's still unclear how to implement it at the customer site.

2. Traditional systems carry not only processes but also responsibilities

In this roadshow, the criticism of traditional software mainly focused on efficiency.

However, in industrial scenarios, efficiency has never been the only issue.

Many traditional industrial software programs seem cumbersome not only because of outdated technology but also because they are designed to institutionalize management: who enters data, who approves, who reviews, who signs, who is responsible for the production line results, and how to investigate problems when they occur. These may not be highly efficient but make the organization controllable.

Industrial sites are different from Internet products. In the Internet field, a wrong recommendation or generation is mostly an issue of user experience. But in industrial scenarios, a wrong suggestion may affect equipment, production lines, energy consumption, quality inspection, safety, and even delivery cycles.

Therefore, what customers really want to figure out is who will review the suggestions, who will decide whether to implement them, who will take responsibility if something goes wrong, and where the operation records will be stored.

These questions may sound "traditional", but they are often the bottleneck for the implementation of industrial AI.

Traditional industrial software is difficult to replace not because of advanced technology or a user - friendly interface, but because it has occupied a position of responsibility within the customer's organization. Once established, external startups cannot simply use "more intelligent" or "more efficient" to explain the replacement logic.

Customers will be interested in an AI system that only improves an auxiliary link. But if it attempts to change the decision - making process and the boundary of responsibility from the start, customers will definitely be cautious. This is not conservatism but the basic logic of industrial scenarios.

What is really difficult to replace in traditional systems is not their functions but their position within the customer's organization.

3. Small scenarios are not small opportunities but the first segment of the process that customers are willing to hand over

There are many aspects in industrial scenarios that are worth being transformed by AI: difficult to accumulate experience, delayed anomaly detection, insufficient data utilization, and uneven levels of on - site personnel. The opportunities do exist.

However, in more complex scenarios, it's not advisable to start with the "industrial brain" narrative.

A more realistic approach is to first find a small but clearly - defined scenario. Who will use it, what problems it will solve, what the inputs and outputs are, how to conduct acceptance, and who will handle problems when they occur - all these can be clearly stated.

Similar approaches can also be seen in public cases. For example, the defect detection of injector valve seats: the detection volume is large, it relies on the visual inspection of skilled workers, the labor cost is high, and the results can be verified. AI enters not the factory brain but the most labor - intensive part of the inspection process. Customers pay not because of "AI transforming the manufacturing industry" but because this workstation is really labor - and time - consuming, prone to missed detections, and the improvement results can be quantified.

The same logic applies to quality inspection in automobile manufacturing. Measuring gap and flush, detecting the standardization of assembly actions, and identifying component defects are all very specific scenarios. Instead of replacing the entire production system, AI enters a certain inspection link, first makes the results accurate, and then discusses expansion.

The same goes for predictive maintenance. Instead of overthrowing the equipment management system, it first connects to existing sensors, PLCs, MES, or maintenance systems, starts with key equipment, and checks whether it can detect anomalies in advance and reduce unplanned downtime.

These scenarios may not sound as appealing as the "industrial brain", but they are closer to the customer's budget. Customers pay not for concepts but for specific problems, definite results, and controllable risks.

Being able to be accepted is the entry point. Being able to enter the responsibility chain indicates that customers really start to rely on you.

For a project to truly succeed, it's not just about customers seeing the demo or being willing to conduct a pilot. It's when customers start to let the system participate in a real process: the output is referenced by on - site personnel, the suggestions start to influence operations, misjudgments need to be handled, and the effectiveness is reviewed internally.

By this stage, AI companies are faced not only with model problems but also with delivery, training, operation and maintenance, anomaly handling, and internal customer collaboration. Who will explain the output? Who will handle misjudgments? What if on - site personnel don't trust the system? What if the data in the old system is incomplete? What if customer departments are not cooperative?

These problems are troublesome. But barriers are gradually built in the process of dealing with these troubles.

4. Projects are the entry point, not the end

Many industrial AI companies start with projects in the early stage, which is quite normal. Industrial sites are complex. Without working on projects, it's difficult to truly understand customers and obtain data and process experience.

The problem is whether there is any accumulation after the projects.

If the first customer is obtained through the founder's connections, the second project is redone by the project team, and the third one needs to be customized again, there will be revenue, but each project is a new manual delivery, and growth will be hampered by the delivery cost.

What really matters is whether the problems solved in the first scenario can be accumulated into reusable assets: models, data processing methods, interface experience, delivery manuals, and customer training paths. If these can be accumulated, the deployment cost for the next customer will decrease, and the company will start to approach a real industrial AI company.

Expansion should occur in this way: from one workstation to a production line, from one type of equipment to a family of equipment, from one quality inspection link to the quality management process. Instead of drawing a complete closed - loop first and asking customers to adapt, it's better to first take over a small real process within the customer's existing system, deepen and stabilize this process, and develop replicable delivery capabilities. Only then can the full - stack narrative hold water.

5. The interest of large customers does not equal market validation

Another common phenomenon in the roadshow is that many projects claim to be in touch with large customers, that a certain large enterprise is interested, and that a certain scenario has great potential in the future.

The interest of large customers does not mean they will make a purchase. Willingness to conduct a pilot does not mean they will accept the results. The approval of leaders does not mean on - site personnel will be willing to use it. One department's recognition of value does not mean the budget department will pay.

What industrial AI really needs to prove is that customers are willing to hand over a problem to you, integrate a process with you, write an improvement into the acceptance criteria, and allocate a budget to you.

The most dangerous situation is not the lack of large - customer leads but treating large - customer leads as market validation. Verbal interest can easily create an illusion, as if the demand has been proven and all that's left is product improvement and financing. But real commercialization often gets stuck later - who will promote it within the customer, who will sign, who will use it, and who will bear the risks. If these issues cannot be resolved, no matter how beautiful the story is, it's just a story.

After the roadshow, I had a brief chat with one of the founders.

He was working on equipment predictive maintenance, and his PPT talked about platformization, full - life - cycle management, and industrial digital twin. I asked him how many real paying customers he had. He said he was still in talks, but several large factories had shown strong interest.

I didn't ask further.

But what I really wanted to ask in my heart was quite simple: Is there a customer willing to let you connect to one piece of equipment first and deliver an acceptable result within three months?

If so, this is the starting point.

If you're still waiting for the interest of large factories to turn into formal projects, no matter how complete the full - stack story is, you're just waiting for an opportunity that hasn't even started.

Industrial AI is not afraid of small entry points. What it fears is telling big stories too early before establishing a foothold in small scenarios.

This article is from the WeChat official account "Path and Boundary", written by Yan Jun, and is published by 36Kr with authorization.