The closer AI moves to the physical process, the more governance must reflect operational consequences.
Thank you to Rich Mason for sharing the White House Gold Eagle announcement with me and prompting a valuable discussion about AI, vulnerability prioritization, and the operational context required to turn intelligence into action.
The announcement is timely, but it also points to a much larger question facing industrial leaders:
How far should we allow artificial intelligence to influence the systems that operate critical infrastructure?
Industrial organizations have used analytics for decades to improve maintenance, quality, energy efficiency, and production. What is happening now is different.
AI is moving closer to equipment, controllers, substations, pipelines, production lines, and other physical processes. At the edge, it can process industrial data locally, reduce latency, limit reliance on cloud connectivity, and enable faster decision-making.
That creates significant potential. It also changes the risk.
An AI model identifying a trend on an executive dashboard is one thing. Another is a model that recommends changes to equipment operation, maintenance priorities, protection strategies, or production settings.
The question is no longer only whether the model is accurate. The more important question is: What authority are we prepared to give it?
We are surrounded by AI claims
AI-generated articles, technical explanations, and confident opinions are now everywhere. Producing information has become easier. Demonstrating experience and applying sound judgment have not.
It is increasingly easy to claim knowledge, as AI models can convincingly explain a subject. But producing a technically polished answer is not the same as understanding how a decision will affect a compressor, boiler, turbine, pipeline, production unit, or electrical network.
After spending significant time testing and applying Top generative AI models from the United States and other markets, both cloud- and on-prem, my conclusion is clear: the technology is powerful and developing rapidly.
AI will automate significant portions of research, documentation, correlation, configuration analysis, troubleshooting, and engineering decision support. It may affect the skilled engineer’s work sooner than many organizations expect.
But automating tasks is not the same as replacing engineering accountability.
In OT, the difference matters because a wrong answer may not simply affect data. It may affect equipment, production, safety, the environment, or the continuity of an essential service.
Industrial experience should make us thoughtful about autonomy
Anyone who has worked in an oil and gas or petrochemical facility will recognize a familiar reality: even in highly automated plants, some important control loops remain manual or are frequently switched from automatic to manual. This does not mean automation has failed. It means the operating environment does not always behave as assumed during design and commissioning.
Feedstock composition changes. Instruments drift. Control valves develop friction or hysteresis. Equipment performance degrades. Process interactions become more complex. A loop that performs well during stable production may oscillate, respond slowly, or become unreliable during startup, shutdown, maintenance, or abnormal operations.
Experienced operators often recognize these conditions before the automation does. They understand the unit's history, the condition of the equipment, upstream disturbances, maintenance constraints, and operational compromises that may not be reflected in the available data.
This experience should influence how we govern Industrial AI.
If mature, deterministic control strategies—developed, tuned, and tested over decades—still require human intervention when conditions move beyond their assumptions, we should be cautious about granting operational authority to probabilistic AI models.
The lesson is not to resist automation. It is to define where automation is dependable, where human judgment remains essential, and what should happen when the process moves outside validated conditions.
Gold Eagle shows both the opportunity and the limitation
The White House recently launched Gold Eagle, an AI-enabled cybersecurity clearinghouse intended to coordinate software-vulnerability discovery, validation, prioritization, remediation, and patch distribution across government, industry, open-source software, and critical infrastructure.
Established through Executive Order 14409, the initiative is intended to reduce duplicated scanning, accelerate vulnerability verification, and distribute prioritized threat and remediation intelligence. White House announcement, Executive Order 14409
The direction is valuable. AI can analyze software and technical information at a speed and scale that human research teams cannot match.
However, faster discovery does not automatically produce better OT risk decisions.
A vulnerability may be discovered nationally, validated, enriched with exploit information, and distributed to asset owners. That does not establish whether the affected product is installed in a particular facility, how it is configured, what function it performs, whether an attacker can reach it, or whether remediation can be safely implemented.
National intelligence can identify the vulnerable technology. Local operational context must determine the action.
That action may be to patch. It may also be to isolate, restrict communications, remove remote access, introduce monitoring, accelerate replacement, or wait for an approved operating window.
AI can accelerate the analysis. It cannot assume accountability for the operational decision.
AI cannot analyze assets; it cannot see
Cybersecurity discussions often assume that industrial assets can be discovered simply by scanning the network.
That assumption does not hold across much of OT.
Many legacy industrial devices were not designed to announce their identity, communicate with a cybersecurity platform, or respond safely to active scanning. Some do not have Ethernet interfaces. They execute a physical function and exchange limited data through serial protocols such as Modbus, sometimes behind a PLC, RTU, controller, protocol converter, or gateway.
A network scan may identify the gateway while revealing little about the field devices and dependencies behind it.
Active scanning may also pose a risk to older or fragile equipment. A dependable OT inventory, therefore, requires more than one discovery technology. It may combine passive monitoring, controller configurations, engineering documentation, gateway mapping, maintenance records, physical verification, and the knowledge held by engineers and technicians.
AI can correlate this information and identify gaps. But it cannot create reliable judgment from assets, configurations, and dependencies that remain invisible.
Architecture and asset context must come before automated prioritization.
Start by defining the AI system’s authority
Not every Industrial AI application requires the same level of governance.
There is a fundamental difference between a system that observes the process and one that directly influences it. A practical approach is to classify Industrial AI use cases according to the authority assigned:
- Observe: Identify patterns, anomalies, or changing conditions.
- Advise: Recommend an action for qualified human review.
- Orchestrate: Initiate a controlled workflow within predefined limits.
- Act: Directly modify equipment, operating parameters, or the physical process.
Controls should become stronger as authority increases.
An AI application that summarizes maintenance history may be suitable for controlled experimentation. A model recommending reduced equipment loading requires engineering validation. A system that permits modification of a control setting requires independent safeguards, failure testing, detailed logging, rollback capability, and explicit accountability.
Governance must follow operational consequence—not excitement about the technology.
“Human in the loop” must mean something
“Human in the loop” is often presented as sufficient protection against AI errors.
But who is the human?
Does he feel threatened or insecure by the AI's presence? Do they understand the process well enough to challenge the recommendation? How much time will they have to intervene? Can they see which data influenced the result? What happens during nights or weekends when fewer experienced people are available?
Human oversight can also weaken over time. If a model performs well for months, operators may gradually come to rely on it. Approval can become a routine click rather than an informed decision.
Meaningful oversight must be engineered. It requires clear decision rights, usable explanations, manageable alert volumes, training, escalation procedures, and the authority to stop or isolate the AI capability.
The operator should not become the final control, compensating for weak AI governance.
Design for wrong answers and unavailable systems
Industrial systems are engineered around failure. Sensors drift. Communications are interrupted. Controllers malfunction. Experienced engineers evaluate these conditions before equipment is placed into operation.
AI requires the same discipline.
Before deployment, leaders should ask:
- What happens when the model is confidently wrong?
- What if the input data is incomplete, delayed, or manipulated?
- What happens when the edge hardware fails?
- Can the facility continue operating if connectivity is lost?
- How will model updates affect validated behavior?
- Can the process return to a known-good manual or deterministic state?
- Can we reconstruct which recommendations or actions influenced operations?
The objective is not to prove that AI will never fail. It is to ensure that its failure does not become an uncontrolled operational event.
Independent safety functions and established control logic must remain authoritative. The organization must be able to disable the AI capability and continue operating safely.
Architecture will determine the speed of adoption
Industrial AI cannot be scaled responsibly on top of weak or poorly understood infrastructure.
It requires trustworthy data, sufficient computing capacity, secure connectivity, governed identities, accurate asset information, and an architecture that supports analysis without disrupting operations.
In some environments, cloud-based AI may be appropriate. In others, latency, data sensitivity, regulation, or availability requirements will favor local models running at the industrial edge.
Local models offer promising opportunities but also require computing resources, lifecycle management, physical protection, cybersecurity controls, and the ability to operate without continuous external connectivity.
AI models may improve rapidly. The practical limits in OT will increasingly be network modernization, computing power, data quality, and integration with the physical process.
Vision-capable AI could help bridge the legacy gap
A modern AI agent cannot be installed on every legacy industrial device. In many cases, there is no operating system, Ethernet connection, or available computing capacity.
Vision-capable AI offers another possibility.
With appropriate controls, AI could read approved engineering screens, drawings, configuration interfaces, alarm displays, firmware information, and test results. It could enter queries through an existing interface and assist engineers without requiring an agent on every field device.
This could extend analytical capabilities into brownfield environments that cannot be modernized quickly.
But seeing a screen is not the same as understanding the process.
AI may identify a configuration difference without knowing that it is intentional. It may read an alarm without understanding the equipment history or operational conditions behind it. It may recommend a technically correct change without recognizing an outage constraint or safety dependency.
Vision can extend the engineer’s reach. It should not create the illusion that the operational context has been solved.
Govern the complete lifecycle
Industrial AI is more than a model. It is an ecosystem involving operational data, sensors, edge hardware, software components, identities, cloud services, engineering tools, updates, third parties, and human decisions.
Organizations should establish controls that:
- Verify the integrity and quality of operational data.
- Secure edge devices and their management interfaces.
- Restrict AI services and non-human identities to required privileges.
- Validate models before deployment and after material changes.
- Monitor data quality and model behavior.
- Maintain inventories of models, software, and supporting components.
- Govern third-party access and supply-chain dependencies.
- Record recommendations and actions for investigation.
- Define rollback, retirement, and replacement requirements.
These controls should become part of the enterprise OT cybersecurity program—not another disconnected innovation initiative.
Make innovation safe enough to scale
Industrial AI can improve reliability, productivity, maintenance, quality, energy efficiency, and workforce effectiveness. Its potential is real.
But a successful pilot is not evidence that a system is ready to influence the physical process at scale.
Before expanding an Industrial AI application, leaders must understand what authority it has, how its decisions will be challenged, how it will fail safely, and how operations will continue without it.
The strongest Industrial AI programs will not be those that automate the most decisions first. They will be those who establish enough engineering discipline, architectural readiness, governance, and operational trust to scale confidently.
AI can discover faster, correlate more information, and help engineers identify relationships that might otherwise take days or weeks.
What it cannot do on its own is create missing asset visibility, modernize legacy architecture, understand every operating constraint, or assume accountability for a decision affecting safety and essential services.
The future of Industrial AI will not be defined by how quickly we automate.
It will be defined by whether we govern the decision before we automate it.