Robert M. Lee AI Warning: Critical Infrastructure Is Adopting AI Faster Than It Can See the Risks

Robert M. Lee issued an AI warning after Dragos found only 30% of operational technology networks had visibility into their environments. The Robert M. Lee AI warning targets a growing conflict inside utilities, factories, data centers, and energy systems. Operators are adding autonomous software before many can reliably observe their existing equipment.

Lee, Dragos CEO and co-founder, argues that AI adoption is moving faster than security monitoring across operational technology. Operational technology, or OT, includes the hardware and software controlling physical processes. Unlike a typical office application, an OT failure can interrupt electricity, water, manufacturing, transportation, or another essential service.

This is not simply another warning about criminals using AI. The harder problem comes from placing AI inside environments that already contain legacy equipment, incomplete inventories, and weak monitoring. AI can improve forecasting and efficiency, but it can also obscure why a physical process changed.

That tradeoff puts infrastructure operators between pressure for faster automation and the engineering discipline required for safe operations. Attackers are also studying control systems more closely. The race is therefore not AI adoption against resistance to technology. It is rapid automation against operational visibility.

Lee’s Warning Moves the AI Debate Into Physical Operations

The important change is that AI is moving from advisory tools toward systems that can influence physical processes.

Lee made his case in a September 11, 2026, infrastructure analysis published by the World Economic Forum. He described AI applications entering manufacturing plants, electric grids, data centers, battery farms, renewable energy sites, and mining operations.

Some deployments still help people review data or predict maintenance requirements. Others are moving closer to the control loop, the feedback process connecting sensors, decisions, and physical equipment. That shift changes the possible consequences of an error.

A mistaken recommendation inside a dashboard can be reviewed before anyone acts. An automated controller can alter equipment behavior before an operator understands the reasoning. Greater autonomy shortens the distance between a model output and a physical result.

Boards and executives see substantial reasons to pursue these systems. AI can help forecast demand, optimize energy use, detect abnormal equipment behavior, and prioritize maintenance. Infrastructure operators also face staffing shortages, aging equipment, and demands for greater efficiency.

Those benefits create pressure to shorten validation schedules. Lee warns that the same pressure can reduce scrutiny of new vendors and increase system complexity. The organization gains another decision layer while its security team may still lack a complete asset inventory.

The underlying systems have already experienced several technology transitions. Mechanical controls became digital systems. Isolated industrial networks gained connections to business networks, remote services, and internet protocol devices.

Each transition created useful capabilities and new dependencies. Many organizations did not achieve complete visibility before the next transition arrived. AI now enters that unfinished environment.

The risk is not limited to a model producing an incorrect answer. The model may depend on external data, cloud services, application programming interfaces, or vendor updates. Each dependency creates another failure path that operators must understand.

An AI service might disappear during a vendor failure or market correction. A model update might change behavior that engineers previously tested. Compromised data could distort recommendations without producing an obvious software error.

Critical infrastructure cannot treat those possibilities like ordinary application downtime. Operators must preserve safe states, manual procedures, and reliable evidence for incident investigations. The Robert M. Lee AI warning makes those operational requirements the center of the debate.

Lee is not asking infrastructure owners to reject AI. He is arguing that governance, visibility, and failure planning must arrive before deeper autonomy. Otherwise, adoption can increase uncertainty inside systems where uncertainty already carries physical consequences.

The Dragos AI Infrastructure Risk Starts With Missing Visibility

AI does not create every infrastructure weakness, but it can multiply the consequences of weaknesses defenders cannot see.

The 2026 threat findings behind Lee’s argument describe a serious visibility gap. Dragos says only 30% of assessed OT networks had sufficient visibility into their environments. It also reports that 56% could not see below the boundary between IT and OT.

The company says 88% struggled with detection and response. These figures come from Dragos, an OT security vendor, rather than an independent government census. They should be treated as findings from the company’s customers, investigations, and telemetry.

Even with that limitation, the pattern matters. An organization cannot protect assets that it has not identified. It also cannot investigate suspicious activity when network traffic, controller changes, and engineering actions were never recorded.

This creates a distinct Dragos AI infrastructure risk. New AI systems can add data flows, software components, credentials, and external connections. They may also make decisions across equipment that follows specialized industrial protocols.

Traditional IT monitoring does not always interpret those protocols or physical processes. A corporate security team might detect an unusual login without understanding whether it changed a pump, relay, turbine, or production line. OT-native monitoring connects cyber activity with expected equipment behavior.

Dragos says organizations with comprehensive OT visibility detected and contained ransomware incidents in five days on average. Lee contrasted that figure with a 42-day industry-wide average. The comparison suggests visibility can materially reduce an attacker’s operating window.

However, it does not establish that monitoring alone caused the difference. Organizations with broader visibility may also have better staffing, segmentation, incident plans, and executive support. The figures show an association that deserves attention, not a universal performance guarantee.

The visibility problem becomes more difficult when AI introduces decisions that are probabilistic rather than deterministic. Traditional control logic usually follows defined rules that engineers can inspect. A machine learning system can respond differently when its inputs, model, or surrounding context changes.

That variability does not automatically make AI unsafe. It does make testing and documentation more demanding. Operators need records showing which model version ran, what data it received, what action it recommended, and whether a person approved it.

They also need to distinguish model behavior from malicious interference. An unexpected action could come from corrupted data, a compromised account, an unsafe instruction, a software defect, or normal model variation. Without sufficient logging, those scenarios can appear identical.

Infrastructure organizations should therefore map every AI dependency before assigning operational authority. That map includes training and operational data, model providers, cloud services, integrations, users, credentials, update channels, and affected physical assets.

This work resembles building a searchable technical knowledge base, but the requirements are stricter. Teams need controlled records, clear ownership, and tested recovery procedures. A broader engineering knowledge base can support documentation, but it does not replace OT security monitoring.

Visibility also has a human dimension. Operators must know when automation is active and what authority it holds. Security teams need enough process knowledge to recognize when a technically valid command creates an unsafe physical state.

The goal is not to record more data without purpose. It is to preserve enough context for detection, intervention, and root cause analysis. AI critical infrastructure security depends on that evidence throughout the system’s operating life.

Attackers Are Mapping the Same Control Loops AI Will Enter

Infrastructure operators are adding intelligence to control environments while adversaries are learning how those environments behave.

Dragos reports tracking 26 OT threat groups during its 2026 reporting cycle. It says adversaries moved beyond basic access and began mapping control loops. That work included identifying engineering workstations and collecting configuration files or alarm data.

A configuration file can reveal how industrial equipment communicates and which limits govern a process. Alarm data can show what operators consider abnormal. Engineering workstations often provide privileged access to controllers and other sensitive assets.

This reconnaissance matters because disrupting a physical process requires more than entering a network. Attackers must understand equipment, timing, safety controls, and operational dependencies. Detailed mapping reduces that knowledge barrier.

Lee identified ELECTRUM and KAMACITE as examples of groups pursuing this deeper understanding. He said KAMACITE spent months mapping control loops across United States infrastructure. ELECTRUM previously targeted Ukraine’s power grid and continued developing capabilities against energy systems.

According to Lee, ELECTRUM attacked distributed energy resources in Poland during December 2025. Those resources included renewable energy management systems. They resemble the environments where operators increasingly want AI to optimize output and storage.

This does not mean AI caused that incident. It shows that the underlying control environments already attract capable adversaries. Adding poorly governed automation could increase the number of components attackers can study or manipulate.

AI also changes the economics of offensive work. Models can assist with code analysis, reconnaissance, translation, documentation review, and script creation. They can help less experienced attackers understand unfamiliar equipment more quickly.

Recent reporting suggests AI often accelerates existing techniques instead of inventing entirely new ones. Attackers still benefit from exposed devices, default credentials, weak segmentation, and delayed patching. AI can help them find and exploit those familiar weaknesses faster.

That distinction prevents the story from drifting into science fiction. A utility does not need to face a fully autonomous superintelligence before experiencing AI-related danger. A human-led group using AI to scale routine reconnaissance can create immediate pressure.

The defensive opportunity is equally real. AI can help security teams prioritize alerts, analyze large datasets, identify unusual sequences, and retrieve technical context. Those uses can be valuable when qualified people retain authority over consequential actions.

The conflict appears when organizations treat defensive AI as a substitute for fundamental controls. An alerting model cannot compensate for unmanaged remote access. Automated analysis cannot recover logs that the organization never collected.

CISA’s OT security principles emphasize decisions that preserve safe and secure operational environments. The guidance predates this particular warning, but its priorities remain relevant.

Infrastructure owners still need accurate asset inventories, secure configurations, network segmentation, controlled remote access, and tested incident response. AI should operate inside those controls. It should not become a shortcut around them.

The strongest deployment pattern gives AI narrow, observable responsibilities. A model might rank maintenance cases without directly changing equipment. It might draft an investigation summary while analysts verify its evidence.

Higher-risk systems require stronger boundaries. Operators can restrict commands, enforce deterministic safety limits, require human approval, and isolate critical functions. They can also test how the system behaves when data becomes unavailable or misleading.

This approach treats AI as one component in a safety system, not as the system’s unquestioned operator. It preserves the benefits of faster analysis while limiting the path from a model failure to physical disruption.

Robert M. Lee AI Warning Exposes an Automation Tradeoff

The main choice is not whether to use AI, but whether automation will remain observable, reversible, and subordinate to safety controls.

The Robert M. Lee AI warning describes a tradeoff that ordinary enterprise deployments can obscure. More autonomy can reduce workloads and reaction times. It can also reduce the time available for a person to challenge an unsafe decision.

Infrastructure operators have long managed automation through engineering review, change controls, redundancy, and fail-safe design. AI does not invalidate those practices. It increases the need to apply them carefully.

A deployment should begin with a defined operational problem. Teams must state what the model can access, what it can recommend, and what it can change. They should also identify actions the model can never take.

These boundaries need technical enforcement. A policy document cannot stop an overprivileged integration from issuing commands. Access controls, network architecture, and safety systems must limit the model’s actual authority.

Testing must cover more than average accuracy. Operators need scenarios involving missing sensors, corrupted inputs, conflicting instructions, unavailable cloud services, and unexpected equipment states. They must test recovery after the AI component fails.

NIST’s AI risk framework organizes risk work around governance, mapping, measurement, and management. In April 2026, NIST also announced work on a critical infrastructure profile for the framework.

That profile is intended to help infrastructure operators translate trustworthy AI principles into sector-specific practices. Its development signals that general AI policies are not enough for physical operations. Energy, water, transportation, and manufacturing face different consequences and constraints.

NIST also treats security and resilience as core characteristics of trustworthy AI. Resilience means a system can withstand problems and recover without unacceptable harm. For an industrial deployment, that includes operating safely when the model is unavailable.

Manual operation therefore remains an important test. Teams should know whether staff can continue essential services after losing an AI vendor, model endpoint, or supporting dataset. They also need realistic estimates of how long that fallback can last.

A manual fallback that exists only in documentation may fail during an emergency. Operators must exercise it under controlled conditions. Staff turnover, equipment changes, and growing automation can quietly make old procedures unusable.

Vendor continuity creates another concern. An infrastructure operator may depend on a startup, proprietary model, or cloud integration that changes rapidly. Contractual assurances cannot replace technical exit plans.

Organizations should retain the data and configuration needed to transition away from a provider. They should understand which functions stop when a service disappears. They also need controls for updates that could alter validated behavior.

Data governance belongs inside the same operational plan. AI tools can expose sensitive network details, equipment documentation, or incident information when teams submit material to external services. Uncontrolled prompts can become another data-exfiltration path.

A governed information workflow can help teams organize approved material and reduce scattered handling. Critical infrastructure operators still need sector-specific controls governing classification, retention, access, and external processing.

The skeptical question is whether vendors and operators can validate fast-changing models with the rigor expected for long-lived industrial equipment. Models may update monthly while control systems remain deployed for decades. Those timelines do not align naturally.

No framework can remove that mismatch. Operators must manage it through version control, repeatable testing, staged deployment, monitoring, and rollback capability. They should assume that model behavior and threat conditions will change.

AI critical infrastructure security therefore depends on limiting surprise. Teams cannot predict every failure, but they can preserve evidence, authority boundaries, and safe recovery paths. Those capabilities determine whether an anomaly becomes a manageable incident or an unexplained outage.

Regulation Is Moving, but Operators Cannot Wait for a Perfect Rulebook

Government guidance increasingly recognizes the risk, yet responsibility still falls on operators making deployment decisions now.

CISA’s AI security roadmap explicitly addresses AI adoption across critical infrastructure. The agency said deployment could increase exposure to failures, physical attacks, and cyberattacks.

The roadmap called for secure-by-design practices, red teaming, vulnerability management, and engagement with infrastructure stakeholders. Those goals established a direction. They did not create binding technical requirements for every sector or deployment.

Critical infrastructure regulation is fragmented because sectors differ substantially. A power grid, water utility, hospital, pipeline, and transportation network do not share identical technology or risk models. Ownership and regulatory authority also vary.

That fragmentation can produce uneven AI governance. A large operator may build a specialized review program. A smaller municipal utility may rely on a vendor’s assurances because it lacks AI security expertise.

This is where the Robert M. Lee AI warning places pressure on boards and procurement teams. They cannot assume regulators or model providers have resolved every operational risk. Purchasing decisions become security architecture decisions.

Contracts should require documentation of model dependencies, update processes, security incidents, data handling, and support obligations. Operators also need the right to test systems and receive information about meaningful changes.

Independent evaluation can help, but the evaluator must understand OT. A generic application assessment may miss process safety, controller behavior, or operational recovery. Infrastructure security requires cooperation among cybersecurity specialists, engineers, vendors, and frontline operators.

Regulators can improve consistency by defining minimum evidence for higher-risk deployments. That evidence could include threat models, validation results, human-control requirements, incident reporting, and demonstrated fallback procedures.

Still, compliance should not become the only goal. A system can satisfy a checklist while leaving important physical dependencies unexplored. The relevant question is whether the organization can maintain safe operations during attack, error, or service loss.

The economic challenge remains significant. Many infrastructure organizations have limited staff and aging equipment. New mandates without funding or implementation support can create paperwork without meaningful risk reduction.

That is why baseline controls matter. CISA’s performance goals prioritize practices with broad risk-reduction value. They include protections for both information technology and operational technology.

Operators should establish those foundations before giving AI wider authority. Strong authentication, secure remote access, segmentation, backups, logging, and response plans protect systems regardless of whether an incident involves AI.

Policy should also distinguish between AI risk categories. Attackers can use AI against infrastructure. Adversaries can target an AI system or its data. An AI deployment can also fail without any attacker.

Those categories require different controls. Threat intelligence helps with malicious activity. Model evaluation addresses performance and failure modes. Governance determines who can approve, monitor, modify, or disable the system.

Treating every issue as an “AI cyberattack” hides those differences. It can also encourage expensive purchases that do not address the actual weakness. Clear incident classification will become increasingly important as deployments grow.

The regulatory test is whether guidance changes operational behavior before a major failure forces the issue. Publishing another framework is not enough. Adoption reviews, procurement requirements, exercises, and incident disclosures will show whether governance is becoming real.

Three Signals Will Show Whether Visibility Catches Up

The next test is whether infrastructure owners build measurable safeguards before AI receives broader control over physical systems.

The first signal is NIST’s critical infrastructure profile for the AI Risk Management Framework. Its recommendations should translate general principles into actions that operators can test. Specific guidance on model changes, OT logging, fallback operations, and vendor dependencies would strengthen Lee’s case.

A vague profile would leave organizations interpreting risk differently. A detailed profile, especially one adopted by sector regulators and buyers, would create a common baseline. That would reduce the space for rushed deployments supported only by vendor claims.

The second signal is movement in OT visibility metrics. Dragos currently reports that only 30% of OT networks have visibility, while 56% cannot see below the IT and OT boundary. Future reports should show whether those numbers improve as AI adoption expands.

Improvement would suggest organizations are building monitoring before assigning greater autonomy. Stagnant visibility alongside rapid adoption would strengthen the Dragos AI infrastructure risk. It would mean complexity is growing faster than defenders’ ability to observe it.

The third signal is the first wave of disclosed AI-related OT incidents. Reports must distinguish malicious use, attacks against models, unsafe integrations, and ordinary software failures. Without that detail, organizations cannot identify which controls failed.

A transparent incident record would help operators learn before experiencing the same problem. It would also test whether current logging supports meaningful root cause analysis. Repeatedly unexplained incidents would validate Lee’s concern about growing blind spots.

Infrastructure leaders should not wait for all three signals. They can inventory AI deployments now, identify affected physical processes, and verify who holds shutdown authority. They can also test operations without the model or its external services.

Developers should demand clear interfaces, restricted permissions, versioned behavior, and complete audit trails. Enterprise buyers should ask vendors for evidence rather than broad safety promises. Knowledge workers should avoid sending sensitive infrastructure information into unapproved tools.

The Robert M. Lee AI warning ultimately offers a practical decision rule. Automation should not gain operational authority faster than the organization gains visibility, control, and recovery capability.

AI can still improve critical services. However, the deployment must remain understandable enough to investigate and constrained enough to stop. Before approving the next integration, ask one question: if it acts incorrectly tomorrow, can your team see why and recover safely?