Expert Interview | Jimsher Chelidze: "Automating Chaos Produces Automated Chaos — Only More Expensive and Faster"

We continue publishing our extensive interview with Jimsher Chelidze, an expert in industrial artificial intelligence and member of the FBA EAC Committee on Industry. In the first part, he explained why the race for frontier models is not the right path for us, and why competitive advantage lies on the shop floor: in data, engineering, and access to real-world assets. In the second part, Chelidze discussed how the engineer's role is changing in the era of AI assistants and why companies risk losing an entire generation of expertise while gaining three years of productivity.

In the third and most substantial part, he addresses the main barriers preventing industrial enterprises from moving beyond isolated pilots to systematic AI deployment. Why most digital projects fail, who is to blame, and what to do about data, people, and security.

Responses are published in full, unedited.

Jimsher Chelidze is General Director of Chelidze & Partners LLC, Digital Development Business Partner at Horizontal Drilling Center LLC, and a member of the FBA EAC Committee on Industry. He is the author of articles on the philosophy of technology and five books on digital transformation, and the creator of two AI products. He has hands-on experience working with Gazprom Neft, LUKOIL, the Russian Ministry of Energy, Gazprom Drilling, and other industrial companies in Russia, Kazakhstan, and China.

You say that one should start with processes, not technology, and that "many companies are practically contraindicated from pursuing digitalization." What prevents industrial enterprises from moving beyond isolated AI solutions to systems embedded in the production loop?

Let me first clarify the phrasing — it sounds sharp, but there is no arrogance behind it.

The point is simple: automating chaos produces automated chaos — only more expensive and faster. If a process has not been documented, measured, and standardized, AI will not "bring order." It will codify disorder and lend it the legitimacy of numbers — and that is worse than disorder, because now no one will argue with it.

And worse than failure is only the kind of failure after which a company stops trying altogether. One unsuccessful AI initiative costing a hundred million shuts down the topic for the board of directors for five years.

The numbers here are stubborn: by various estimates, 70 to 84 percent of digital technology implementation projects either fail outright or are problematic — they miss deadlines, exceed budgets, deliver results in only one or two processes, and increase staff turnover. I have been analyzing the causes for many years and have concluded that nearly everything comes down to a small number of recurring root causes. And not a single one of them is technical.

A caveat on the denominator is warranted here. By broader estimates from McKinsey and MIT, up to 95 percent of AI investments fail to deliver expected returns, and roughly three-quarters of pilots never reach production deployment; the 70–84 percent figure refers specifically to projects that are outright failures or severely problematic. The estimates measure different things, but the conclusion is the same: only a minority reach results, and almost always for non-technical reasons.

Root cause: no strategy — and therefore no portfolio

The vast majority of companies lack a quality digitalization strategy — the kind above which AI can actually be deployed. What they have is a slide deck about technologies. A list of initiatives. No strategy.

A strategy is not a document; it is a construct. It must contain four elements.

First — an analysis of the business itself. What are the priorities? Where are the system constraints? Where is the real bottleneck that is holding back revenue? Not "where would it be interesting to apply AI," but "where does it hurt and how much does it cost?" Without this, any list of initiatives is simply a wishlist from individual departments, sorted by the eloquence of their heads.

Second — a portfolio with dependency management. This is where the most money burns, and almost no one talks about it.

Projects in digitalization are tightly coupled. A process engineer's AI assistant will not work until engineering documentation is brought into order. Predictive maintenance will not work without a proper equipment reference database. End-to-end analytics will not work without an integration bus. When a portfolio is assembled without a dependency map, the following happens: Project A launches, runs into the absence of Project B, stalls — and the money is already spent, the team is occupied, the clock is ticking. And this happens across a dozen initiatives simultaneously.

A portfolio without dependency management is not a portfolio. It is a warehouse of work-in-progress, only an extremely expensive one. I have managed a portfolio of several dozen initiatives and can say this: the share of projects blocked while waiting for other projects is the best indicator of portfolio health. If it exceeds twenty percent, no one is managing the portfolio. They merely own it.

Third — the integration of three loops. Every AI project rests on three pillars, and all three must be supported by separate projects within the same portfolio: the technology loop (infrastructure, data, integrations, security), the organizational loop (process maturity, lean manufacturing, project and change management), and the human capital loop (competencies, digital literacy, motivation).

If even one pillar is missing, the project will not take off, no matter how good the algorithm is. Here is a criterion I would propose to any investment committee: before approving an AI initiative, show me which projects cover all three loops. If there is no answer, it is not a project — it is a budget write-off request.

Fourth — a funding model for the shared layer. And this is the root of all roots.

The foundational technology layer — master reference data, data quality, the integration bus, the platform — has no owner. Its beneficiary is the entire company, meaning no one in particular. No shop-floor manager and no department director will give up their budget for a reference database whose benefits will accrue to a colleague next door. Therefore, the shared layer is never built unless it is funded centrally — from a transformation budget, not from the budget of the requesting department.

What happens when none of this exists. Each department begins solving its own problems independently. Five departments buy five different AI tools, pay five times, and the data between them does not align. No resources remain for a common technology foundation — because no one ever commissioned it. There is no synergy: each project's impact is locked within a single process, and the cross-functional effects that justified the entire effort never materialize.

This is what patchwork AI deployment looks like. And it is not the result of stupidity — it is the result of the absence of architecture. If there is no map at the top, everyone draws their own.

Two afflictions of those who do have a strategy

Affliction one: the digitalization strategy is disconnected from the business strategy.

The most common misalignment looks like this. The company's strategy is about reducing operating costs and defending market position — a defensive posture. Meanwhile, the IT department is pursuing innovation projects: dashboards, digital twins, experiments with generative AI. Working on the wrong things in the wrong direction. Sometimes it is the reverse: the business is pursuing growth, new markets, and new products — while IT is busy optimizing servers.

A digital strategy is not autonomous. It is derivative. If the business is in defensive mode, the AI agenda should focus on unit costs, losses, quality, maintenance planning, and standards — the very things that are boring and profitable. If the business is in offensive mode, then it should be about new products and business models. Confusing these two modes means spending the budget on a technically flawless solution to a problem the company does not currently have.

A test that takes five minutes: take the company's three main goals for the year and its three main digital projects. If you cannot draw a line between them, you do not have a digitalization strategy. You have an IT budget.

From here also comes the bias toward photogenic projects. When the digital agenda is not tied to business objectives, the only selection criterion left is how the project looks in a board presentation.

Affliction two: the strategy was written — and never revisited.

There is no regular cadence: no tracking of project progress, no monitoring of market conditions. The document was approved, filed away, and returned to a year later during budget planning. Two consequences follow, and both are costly.

First: key projects fall off leadership's radar. The portfolio runs on inertia, status is collected once a year, and a troubled project surfaces only when there is nothing left to save. And it is usually the key projects that fall through the cracks — they are long, complex, and do not produce quick headlines.

Second, and this is critical for AI: projects reach the finish line in a market that no longer exists. The cycle of a serious industrial project is two to three years. The technology horizon in AI today is six to twelve months. We risk launching in 2028 something we designed in 2026 for an architecture that no longer exists. I have seen this more than once: a company spends a year and a half building an in-house solution that, in the meantime, has become an off-the-shelf product available for a fraction of the cost. Formally, the project is a success — deadlines met, budget adhered to, specifications fulfilled. Economically, it is meaningless. The answer to the question "build or buy" has an expiration date.

A cadence that works: a monthly operational review of active projects, a quarterly strategic portfolio review with the actual authority to shut down an initiative and reallocate funds, and a quarterly technology landscape review. And alongside this — a cultural norm: the right to kill a project must be as normal as the right to launch one. If people are punished for closing an initiative, no one will ever close anything, and the portfolio will drag its dead weight until the end of the budget cycle.

You keep coming back to data. How real a problem is this for industry?

It is not just a real problem. It is a prerequisite without which everything else is meaningless.

Data management has maturity levels. Level one — a unified data model: collection policies, quality criteria, data owners, storage. Boring and invisible. Level two — management based on business analytics: unified metrics understood across all departments, a culture of data-driven decisions. Level three — data-driven hypotheses, exploration, discovery of new profit sources. Level four — new products and business models built on data.

The first two levels represent a defensive strategy: reduce risk, accelerate response, improve decision quality. The third and fourth represent an offensive strategy: new revenue, new products.

Now the critical point. AI is a game played at levels three and four. And the vast majority of industrial companies are at level one or two. Often — not even at level one.

Jumping from level one straight to level three never works. You will not have enough ammunition: there is no quality data, no map of the terrain. You will build a beautiful model on dirty, duplicated data and get a confident, well-formatted incorrect answer.

And here I will say something that usually draws objections.

In years of practice, I have never seen a single manufacturing company that conducted a full inventory of its data. Not one.

This is not a figure of speech. Ask yourself four questions about your enterprise. Do you have a data model — an understanding of what data you have, where it resides, in what format, and how it relates to other data? Who is the owner of a specific dataset — not "the department is responsible," but a name: who is accountable for the fact that the same pump appears three times under different names in the equipment reference database? What is the data lifecycle — where is it created, who enters it, how does it change, when does it become obsolete, who deletes it? What are the interdependencies between systems — what will happen to your analytics if the ERP reference data changes tomorrow?

In the vast majority of cases, there is no coherent answer to any of these questions. And this despite the fact that data exists in the company — in abundance. It is just that no one knows what they have or what it is worth.

And separately — data quality assurance tools. Not only are they absent; most often, there is no understanding whatsoever that data quality is not a one-time cleanup but a process: criteria, regular verification, a master data management system, and training for those who enter primary data. It is the operator on the shop floor who is the source of quality — not the data specialist.

Without this, AI is impossible. Not "difficult," not "less effective" — impossible. You can build the most advanced model you like, but at its foundation will be unreliable data. And you will get a confident, neatly formatted incorrect answer — and make a decision based on it.

And notice where this stems from: data is a shared layer. It has no owner. That is why no one deals with it.

What to do. Order matters more than speed here.

• Digitize core business processes and conduct a data inventory. What data exists, where it resides, who generates it, what is missing.
• Appoint data owners — by name, for every key dataset and every reference database.
• Build a data model and document the lifecycle: creation, modification, obsolescence, deletion.
• Define measurable quality criteria and organize regular verification, not a one-time cleanup before an audit.
• Implement a master data management system. This is the "boring" project that will never make it into a board presentation and without which no AI initiative will work.
• Train those who enter primary data. The most underestimated investment in all of digitalization.
• Visualize input templates before data collection begins. The technique looks primitive, but it eliminates 70–80 percent of data entry errors — people make mistakes not because they are unintelligent, but because they do not understand what is expected of them.

And only after all of this — the conversation about models. Not before.

What about people? Where is the main resistance?

The people barrier operates on three levels simultaneously, and it is different at each.

Level one: top management. In most cases, digitalization is a black box for senior executives. This gives rise to three persistent distortions.

First: the expectation that a wizard will come and fix everything — and they will not need to get involved, articulate requirements, or change themselves. No wizard is coming. Everyone will have to change, including the General Director and the owner.

Second: the time horizon. A proper digital transformation takes 4–10 years, with first results no sooner than nine to twelve months. Yet the request sounds like "results in six months, with guarantees, and tell us in advance who to fire if it fails." It is impossible to design an honest project to meet such a request — only a pretty presentation. It is also important to understand that AI in isolation from other IT technologies delivers very limited impact. Yes, you can solve local problems (document recognition, automated meeting minutes), but it will have no meaningful effect on financial performance overall.

Third, and the most costly: a focus on technology and on "direct" impact within a single process. You saved thirty million, you halved the time it takes to process paperwork. This matters, but it is optimization. The real impact lives in end-to-end, cross-functional metrics — and no one measures those, because doing so requires level-two data, which does not exist.

What to do. Involve senior executives in the change, rather than merely informing them about it. Honestly define the time horizon in the program charter and acknowledge that some initiatives will not succeed. And introduce at least two or three cross-functional metrics: not "we saved money in the shop," but profitability per production stage, production cycle rhythm, profit per employee. Otherwise, you will remain in optimization forever and never reach transformation.

Level two: middle and technical management. This is where the most underestimated failure occurs. Ask line managers how a project differs from a product. What the Plan-Do-Check-Act cycle is. What types of employee resistance exist and how to address them. What percentage of employees will embrace change enthusiastically, and what percentage will oppose it to the end.

You can picture the answer. And these are the very people who are supposed to implement AI on the shop floor.

What to do. The remedy is not what people usually think. Training everyone and certifying them is not the answer: it does not work and it is expensive. What is needed are simple, accessible programs and — instead of lengthy regulations — quick-reference guides that a person can open for three minutes to refresh their knowledge. Regulations are read once, at onboarding. Quick-reference guides are actually used. Better still — tools (including software) that make it impossible to make mistakes.

Level three: front-line workers. This is where reality hits hardest.

I had a project implementing an asset management system where the operational staff could not type on a computer. The first thing we had to do was teach them to type, so that a defect record would not take three hours to enter with thirty typos. In another project, a production supervisor, twenty-seven years old, did not know how to create a spreadsheet in Excel.

And the most common help-desk request during any IT system rollout — 80 to 90 percent of all tickets — is "I forgot my password" and "I cannot register."

On one comprehensive project, we tested approximately 2,500 users affected by the changes. Eight hundred and fifty of them required training in basic computer skills. We delivered a thirty-two-hour program — and it became one of the success factors for the entire project.

A person is not sabotaging. They simply do not know how. This is a different problem, and it requires a different solution.

And separately — about those who know how but do not want to. Before diagnosing "sabotage," look at the incentive system: if the benefits of the system are not reflected in the KPIs of the person using it, that person is working against their own interests — and defending themselves. We often call sabotage what is actually a normal human reaction to a broken incentive system.

The role barrier: a CIO is not a CDTO

A separate and very common mistake is handing digitalization and AI deployment to the traditional IT function.

Traditional IT builds reliable systems. For a CIO, what matters is stability, budget compliance, adherence to regulations, risk reduction, and cost optimization. They have no mandate to think about business profitability or to engage with the internal customer. For a Chief Digital Transformation Officer, the priorities are the opposite: overall business effectiveness, discovery of new revenue sources, working with data rather than hardware, maintaining flexibility, and accepting risk.

In Adizes' framework, these are literally different people: a CIO is dominated by the administration and production functions — "what must be done" and "how it must be done." A CDTO is dominated by entrepreneurship and communication: "for whom, by whom, and when." A CIO is an operations director. A CDTO is a development director.

And here is an observation that offends many but is nonetheless true: the stronger a specialist's traditional IT competencies, the weaker, as a rule, their competencies for transformation tend to be. This is not a personal deficiency. It is a role mismatch.

What to do. There are two workable paths. The first is to establish the transformation function separately: a person with their own team, their own budget, and their own KPIs, operating at the intersection of business and IT. The second is to develop the missing competencies within IT and introduce the institution of IT business partners: people who sit within a business function, speak its language, and translate its needs into system requirements.

What never works is appointing the CIO responsible for digital transformation without changing anything in their KPIs or their team, and expecting a different outcome.

And beneath all of this — culture

If everyone in a company treats each other from a position of "you owe me," if they expect a digitalization specialist to come and make everyone happy — even the most talented digitalization specialist will burn out within three to four months. And instead of a client-oriented partner, they will become an ordinary IT person who does not want to see anyone.

Digitalization and AI deployment at acceptable cost are possible only when the business stakeholder is engaged, motivated, and possesses basic project management skills. Digitalization and AI deployment are about the ability to negotiate. Otherwise, even good tools will be implemented, but no one will use them, and within three to six months everything will be rejected.

What to do. Identify the organizational culture type of the company and its divisions, and select the role model accordingly: what works on the shop floor will not work in R&D. Make the business stakeholder a co-owner of the project, not a recipient: their name in the charter, their KPIs, their defense of results before the steering committee. And an honest rule: if the business stakeholder is not willing to invest their own time in the project, the project does not launch. Not because we are offended. Because it will fail anyway — just later and at greater cost.

A separate question — information security. How much does it hinder AI deployment? 

This is perhaps the most underestimated structural barrier — and it breaks not the process, but the economics.

The typical position of the security function at an industrial enterprise is: either prohibit everything or keep everything inside the internal perimeter. Data anonymization usually does not satisfy them either — "what if they can reverse it?" Formally, there is nothing to object to.

But look at what happens to the money. The requirement of a fully isolated perimeter means: your own servers, your own accelerators, your own infrastructure, your own support team, your own updates, your own maintenance. A project that would cost 1 million in a cloud-based deployment becomes a 20–30 million project. And these are not one-time costs — they are recurring.

The economics of an AI project break not at the model. They break at the perimeter.

As a result, the business case does not add up. The investment committee looks at the numbers and — quite rightly — declines. Only individual initiatives get deployed, those with enough political weight to push through a budget. Everything else dies at the approval stage.

And here is the greatest damage, which no one quantifies: the company does not build practical exposure. No experience accumulates, no competencies develop, no people emerge who understand how any of this actually works. Three years from now, such a company will be negotiating with a vendor without understanding what is being sold to them or what it should cost. Practical exposure cannot be bought. It can only be accumulated — and only through your own projects.

Three reasons, and none of them involve malicious intent

First: the security team itself does not understand what AI is.

This must be called what it is. A security officer who does not understand the difference between sending data to a public interface and running a model locally on your own hardware, who does not know what happens to data during anonymization or whether data remains in the model after a query — cannot assess the risk. They physically lack the tool for assessment. And when risk cannot be assessed, there is exactly one action available. Prohibit.

Prohibition requires no competence. Permission under controlled risk does. Therefore, they prohibit. This is not ill will; it is the only available move from the position in which the person finds themselves.

From this follows an uncomfortable conclusion for leadership: training the security team is as much a part of an AI project as purchasing servers. And it is cheaper than any server. If you trained the business but not security, you have built a project that will be stopped at the approval stage.

Second: the company has no understanding of what actually constitutes a secret — and for how long.

Ask at your enterprise: what data constitutes a trade secret? The answer will most likely be "everything." Now a second question, which almost no one asks: for how long does it remain one?

A drawing of a component discontinued from production ten years ago. A maintenance request from three years ago. A production output summary from the quarter before last. All of this is protected the same way as current unit costs and the active order book — meaning forever and equally.

A secret has an expiration date. Information sometimes loses competitive value within months, sometimes within days. And if a classification has no time limit, you are protecting everything forever. And protecting everything forever means protecting nothing effectively: resources are spread across a mass in which 95 percent has long ceased to hold value for anyone.

Data classification is not bureaucracy. It is what turns the conversation with security from ideological to substantive. Until classification exists, the security officer is obligated to treat everything as critical. And they are right to do so.

Third: no dialogue exists between business, IT, and security.

Three functions speak three different languages. The business does not articulate what value it loses from a prohibition. IT does not translate the technical solution into the language of risk. Security hears neither one nor the other — and no one consults them until the last moment. They meet once — at acceptance testing. And at acceptance testing, security has only one tool left. It is too late to redo anything, and they know it.

And beneath all of this — an asymmetry of incentives. For a security incident, the security officer will be punished. For the absence of development, they will never be punished. As long as incentives are structured this way, they will prohibit — and they will be acting rationally within the incentive system you have built for them.

What to do about it — five measures, all managerial

• Train the security team. Not "hold a meeting," but actually train them: what a model is, where data physically ends up under different architectures, what anonymization does and does not achieve. A security officer who understands the technology starts negotiating configuration rather than issuing blanket prohibitions.
• Conduct data classification — in two dimensions. Not only "how sensitive" but also "for how long." A classification without an expiration date is a classification forever.
• Reframe the mandate. Security should be accountable not for "prohibiting" but for "making possible at an acceptable risk level." Until their KPIs include a single item about enabling development, they will prohibit — and they will be right to do so.
• Introduce the alternative rule. Every prohibition must be accompanied by a working alternative. "You cannot" without "but you can do it this way" is not the security function doing its job. It is avoiding it.
• Establish a trilateral format. Not post-hoc approval, but joint design: business, IT, and security in the same room from day one. And a differentiated perimeter as the outcome: non-sensitive tasks go to external models, sensitive ones stay within the closed perimeter. The majority of corporate tasks, if you look honestly, are not sensitive.

And here it is important not to swing the pendulum the other way

I am not advocating removing security. Because the production loop has a fundamentally different cost of error. An assistant that suggests the correct process parameters in eight out of ten cases is an excellent tool. A model that correctly controls an actuator in eight out of ten cases is an accident.

From this follows a rule: the closer to the control loop, the narrower and more verifiable the model must be, and the more mandatory the failure scenario and the human in the decision loop become. We will not put a large language model into an industrial control system. Nor should we. "Embedded in the loop" does not mean "AI controls"; it means "AI is embedded in the human decision-making process, and that decision is traceable."