What AI actually changes in industrial control software
AI in industrial automation has been over-hyped and under-specified. Strip away the marketing and the genuine changes are concrete and limited. Large language models can generate plausible draft code in PLC languages and structured text. They can summarize controller logs, propose alarms based on operational patterns, and generate first-draft documentation from existing code. Specialized models can detect anomalies in sensor streams, predict equipment failures, and propose process-optimization adjustments. None of this is trivial. None of it changes the underlying physics of running a treatment plant or a high-tech production line.
The mistake is to read these advances as a replacement for the discipline of building reliable control systems. They are tools that help engineers work faster within that discipline. They do not absorb the discipline.
Where AI delivers clear value
Several use cases have moved from speculative to practical in the last few years.
Documentation generation. AI can produce first-draft documentation from existing models or code. The draft is rarely good enough to ship, but it is good enough to give a human a starting point that saves substantial time.
Anomaly detection. Trained on operational data from a specific asset, models can flag deviations from normal behavior earlier than threshold-based alarms. The outputs are diagnostic suggestions, not control commands.
Predictive maintenance. Vibration signatures, temperature trends, and current draw can predict component degradation. The value is in scheduling, not in autonomous response.
Optimization proposals. Process-control optimization (energy, throughput, yield) can be suggested by models that learn from historical operations. Humans evaluate the proposals against constraints AI does not see, then approve or reject.
Engineering productivity. Code completion, configuration suggestions, and natural-language search across engineering artifacts speed up routine work without changing what the engineer is responsible for.
Behavioral interpretation of runtime data. When every PLC cycle is captured against the model, AI can be applied to the structured behavioral record to identify patterns, surface anomalies in operational sequences, and propose model improvements based on actual production behavior. This use case is not available when the runtime data is fragmented across historians and SCADA systems with no link back to design intent.
All of these have a common pattern: AI produces a suggestion, a human decides what to do with it, and the system retains a clear record of which decision was AI-suggested and which was human-judged.
Where AI creates new problems
The risks are not theoretical. They show up in projects where AI was deployed without thinking through the operational consequences.
Fragmentation. AI tools that generate code or configuration in their own format, without integrating with the engineering work product, recreate exactly the document drift problem that model-centric architecture was designed to eliminate. Each AI-generated artifact becomes another tool's output that has to be kept in sync.
Governance gaps. Code generated by an AI tool, accepted into the running system, and then modified by hand creates an audit trail with three states: AI-generated, AI-generated-and-edited, and human-written. If the engineering work product cannot distinguish them, the system loses traceability without anyone deciding to give it up.
Traceability loss. AI-generated artifacts often lack the linkage back to the originating requirement. The output is technically correct (or at least plausible) but disconnected from the traceability thread, which means change impact and audit defensibility erode silently.
Skill erosion. Engineers who routinely accept AI proposals without verifying them lose the deep understanding that lets them catch the cases AI gets wrong. Industrial control is full of those cases, and the cost of catching them late is operational, not just engineering.
Why model-centric architecture amplifies AI's value
AI is most useful when it operates inside a structured environment that absorbs the governance AI does not provide. A model-centric platform is exactly that environment for industrial control.
The model is structured: AI proposals can be expressed as model elements with the same typing, traceability, and validation hooks as human-authored elements. The model is executable: AI suggestions can be simulated before they are accepted, so the human-in-the-loop step has real evidence to evaluate. The model is the source of truth: AI artifacts inherit the lifecycle governance of everything else, with no separate AI-output store to drift away from the running system.
The deeper architectural point is that AI is only as useful as the form its output can take. An AI that produces plain text cannot be tested against requirements. An AI that produces structured model elements can. Cordis SUITE has been solving the model-integrity problem in industrial control since 2000. That is exactly the substrate AI needs to be useful at scale: structured, linked, validated, governed. AI on top of code-centric automation amplifies fragmentation. AI on top of a model-centric platform amplifies engineering throughput without giving up traceability.
How Cordis SUITE handles AI
AI in Cordis SUITE is treated as an accelerator inside the model-centric architecture, not as a parallel tool generating artifacts that have to be reconciled later. Three patterns shape the integration.
AI proposes model elements, not freestanding code. When AI suggests new behavior, configuration, or test cases, the output is expressed in the same structured form as engineer-authored elements. It carries the same typing, the same traceability links, and the same validation hooks. The model does not have an "AI-generated zone" that drifts away from the rest. AI output is governed by the same structural rules as everything else.
Every AI suggestion is simulatable before acceptance. Because the model is executable, an AI proposal can be exercised against scenarios and validated against requirements before any engineer accepts it. The human-in-the-loop step is informed by real behavioral evidence, not by reading text and guessing whether it is correct.
The traceability of AI contributions is explicit. The model records which elements originated as AI suggestions, which were modified by which engineer, and which validations were re-run after the change. For regulated environments, this is the difference between AI as a productivity tool and AI as a compliance liability. The audit trail does not have to be reconstructed; it is part of how the model is structured.
The architectural consequence is that AI productivity gains compound across the lifecycle instead of accumulating as governance debt. The same model that absorbs AI contributions today is the model that engineers, regulators, and incident investigators will be reading in five years. AI does not fragment the work product, because there is no second work product for it to fragment into.
Cordis SUITE has been refining this integration pattern as AI capabilities have matured around the platform. The architecture was already model-centric. The AI integration was a question of how to let new tools work inside an architecture that was correctly shaped for it from the start.
Practical guidance: where to use AI today, where to wait
The honest answer depends on what is at stake.
Use AI today for non-control work where errors are recoverable: documentation drafts, log summarization, code-review assistance, search across engineering artifacts, training material generation. These pay back quickly and have low blast radius.
Use AI carefully for engineering productivity inside a model-centric environment: suggesting model edits, generating test scaffolding, proposing optimization parameters. The model absorbs the governance, the human-in-the-loop step makes the final call, and the system retains traceability for what AI suggested versus what the engineer accepted.
Wait, or use only as a diagnostic suggestion for autonomous control loops: AI driving setpoints, AI making safety-relevant decisions, AI replacing engineering review. Existing functional safety standards (IEC 61508, IEC 61511) require deterministic, verifiable behavior for safety-critical functions, which is fundamentally incompatible with the probabilistic outputs of current AI systems. The combination of these existing constraints, the operational risk profile of industrial systems, the immaturity of explainability tooling, and the regulatory uncertainty around new regimes (EU AI Act, ISO/IEC 42001) makes this premature for most contexts.
The honest framing
Whether AI helps or hurts in industrial control is the wrong framing. AI does both, depending on what it is operating inside. On top of fragmented vendor stacks, AI generates more artifacts that nobody can keep in sync. On top of a coherent model-centric platform, AI accelerates work that retains its traceability, its verification, and its long-term governance.
The architectural decision that compounds is not "what AI tools do we adopt?" It is "what do AI tools have to attach to?" Organizations that answer "the same fragmented toolchain we already have" will pay the productivity gain back in compliance cost. Organizations that answer "a model-centric platform built for governed change" will compound the productivity gain across the asset lifecycle.
Twenty-five years ago, the case for model-centric architecture was about lifecycle governance, traceability, and vendor independence. The AI wave has not changed that case. It has made it more obvious. Model-centric architecture is the answer that has been quietly correct for twenty-five years and is now being validated by the AI wave.