1 The OT Data Problem
Operational technology data is not like enterprise data. The distinction is not primarily one of volume or velocity — it is one of consequence. A leaked sales database exposes business strategy. A leaked historian archive can expose the control architecture of a power substation, the process setpoints of a pharmaceutical bioreactor, or the network topology of a water treatment facility. The difference is that one of these can be used to write a better quarter; the other can be used to cause physical harm at scale.
This asymmetry is recognized, though unevenly enforced, by the regulatory frameworks that govern critical infrastructure. The North American Electric Reliability Corporation's Critical Infrastructure Protection (NERC CIP) standards require utilities to classify and protect bulk electric system (BES) Cyber Assets, with explicit requirements around electronic security perimeters and the restriction of outbound data flows. IEC 62443, the international standard for industrial automation and control system security, establishes a zone-and-conduit model that presumes minimal — and always controlled — data movement across trust boundaries. The European Union's Network and Information Security Directive (NIS2), which entered force in January 2023 with national implementation deadlines of October 2024, broadens mandatory incident reporting and risk management obligations to energy, transport, water, and manufacturing operators at scale.
The incidents that shaped these regulations are instructive. Stuxnet — discovered in 2010 but operational as early as 2007 — exploited detailed knowledge of Siemens S7-315 and S7-417 PLCs and the specific process parameters of uranium hexafluoride centrifuges at the Natanz enrichment facility. That knowledge did not emerge from a network intrusion in the conventional sense; it required deep familiarity with process values, setpoints, and control logic. The 2015 and 2016 cyberattacks on Ukrainian power distribution infrastructure demonstrated that historian data and SCADA network maps, once exfiltrated, enable adversaries to build precise replicas of control systems for rehearsal before causing outages. The 2021 Colonial Pipeline ransomware event, which resulted in six days of operational shutdown and a $4.4 million ransom payment, was triggered not through OT compromise but through IT systems — yet its impact propagated because the operators could not safely operate the pipeline without IT visibility restored.
The lesson across these cases is consistent: the value of OT data to an adversary is disproportionate to its apparent sensitivity. Tag names reveal network segments. Alarm histories expose vulnerability windows. Setpoints encode process knowledge that took years to optimize. Sending this data to an external cloud inference service is not a minor architectural decision — it is a fundamental change to the attack surface of the facility.
The value of OT data to an adversary is disproportionate to its apparent sensitivity. Tag names reveal network segments. Alarm histories expose vulnerability windows. Setpoints encode process knowledge that took years to optimize.
2 Why Traditional AI Deployment Fails in OT
Contemporary large-language-model inference operates on a fundamentally cloud-centric model. A user submits a prompt — which may contain retrieved context, tool outputs, or conversational history — to a remote inference endpoint, which processes the input and streams a response. This model is well-suited to enterprise knowledge work, where the data in the prompt is generally already in the cloud and the cost of disclosure to a vendor is bounded by contract rather than physics.
OT networks are designed around the opposite premise. The Purdue Enterprise Reference Architecture (PERA), defined in ISA-95 and widely adopted in industrial installations, establishes a hierarchy of network levels — from Level 0 (field instruments and actuators) through Level 4 (enterprise IT) — with increasing isolation requirements toward the operational core. The cardinal principle is that traffic between levels must be minimized, explicitly authorized, and preferably unidirectional. Firewalls, data diodes, and DMZ architectures between Levels 2 and 3 exist precisely to prevent plant-floor data from reaching the enterprise network, let alone the public internet.
The integration of cloud AI inference into this architecture creates a structural conflict. To ask an AI agent to diagnose why a Modbus register is behaving unexpectedly, the agent must — in a naive implementation — send the register address, the associated tag name, the historical readings, and potentially related alarm states to a remote server. Each of these fields is a piece of the facility's operational intelligence. Aggregated across a session, they constitute a detailed operational fingerprint of the plant.
The threat surface introduced by standard AI deployment in OT is therefore multidimensional:
Vendor-side breach risk. Cloud AI providers are high-value targets. A breach of a major inference provider's prompt logs or fine-tuning datasets could expose operational data from hundreds of industrial customers simultaneously — a single point of failure with industrial-scale consequences.
Supply chain and insider risk. Data submitted to general-purpose AI providers may be used for model improvement, reviewed by human annotators, or stored in jurisdictions with differing data sovereignty laws. Operators subject to NERC CIP or NIS2 may face compliance exposure simply by having CIP data transit a vendor's infrastructure.
Inference-time confidentiality. Even without a breach, the prompt itself is processed on hardware outside the operator's control, in environments whose security posture the operator cannot audit. For Level 2 and below data, this is structurally inconsistent with the defense-in-depth requirements of IEC 62443-3-3.
The question for OT operators is therefore not whether AI is useful — the productivity case is substantial — but whether it is possible to capture that utility without incurring the confidentiality costs that standard deployment imposes. The answer requires an architectural framework, not a policy one.
3 A Tiered Privacy Framework
We propose a four-tier model that maps AI deployment patterns to levels of data exposure. The tiers are ordered by increasing confidentiality protection and, correspondingly, by increasing architectural complexity and latency cost. Operators select a tier based on the classification of the data in scope, the regulatory environment of the facility, and the threat model applicable to their network.
Direct inference: the prompt is submitted to the primary reasoning model without transformation. Raw field values, tag names, hostnames, and process context are transmitted as supplied. Appropriate for non-operational queries — documentation search, ERP-adjacent reporting, training material generation — where the data is already in the enterprise domain and vendor disclosure is contractually bounded. Not appropriate for any data originating below Level 3.5 in the Purdue hierarchy.
A dedicated distillation model — hosted by a separate provider from the primary reasoning model, in an isolated inference environment — receives the raw operational context. Its sole function is to produce a semantic summary: it extracts the operationally relevant structure (anomalies, value ranges, causal relationships) without retaining or forwarding raw identifiers. The primary reasoning model receives only this summary. No single vendor therefore holds both the raw data and the full reasoning context of a session. Appropriate for Level 2–3 data that is operationally sensitive but not subject to per-field regulatory controls. Region routing ensures the distillation step is processed within the operator's preferred jurisdiction.
All identifiers — IP addresses, hostnames, tag names, PLC addresses, process variable names — are replaced with synthetic tokens before any data leaves the local endpoint. A locally-held reversibility map allows the final answer to be de-anonymized at the terminal; the map never transits the network. The distillation and reasoning models operate entirely on pseudonymized representations. An adversary who obtained the vendor's prompt logs would see only synthetic identifiers with no mapping to real infrastructure. Appropriate for data that falls under explicit field-level regulatory controls (NERC CIP BCS, IEC 62443 SL-3 assets) or where the operator's threat model includes targeted vendor-side compromise.
A strict data-diode architecture: the terminal transmits a prompt outbound but accepts no inbound response through the same channel. The reasoning model's answer is routed to an on-site relay — a minimal server deployed inside the OT network boundary — where it is held on a restricted-access page the operator reads separately. The terminal confirms only that the request was received; it never receives the answer. This pattern is appropriate for Level 1–2 environments where network segmentation policy prohibits any inbound data from outside the security perimeter, or where the operator's risk assessment determines that the confidentiality of the answer itself (not just the prompt) warrants unidirectional enforcement. It is the only tier compatible with air-gapped or near-air-gapped configurations.
An adversary who obtained the vendor's prompt logs in Shielded mode would see only synthetic identifiers with no mapping to real infrastructure — the pseudonymization boundary is enforced at the endpoint, before any data enters the inference pipeline.
4 Implementation Considerations
Latency trade-offs
Each tier above Standard introduces measurable latency overhead. The Split tier adds a synchronous distillation step before primary inference begins; in practice this adds 800ms–2.5s to first-token latency depending on context length and distillation model throughput. The Shielded tier adds a local pseudonymization pass — typically under 50ms for contexts under 32K tokens — plus the distillation overhead. The Diode tier's latency is effectively unbounded: since the answer is not delivered to the terminal, the operator reads it asynchronously on the relay page. For diagnostic workflows where human verification is part of the process, this is often acceptable; for interactive troubleshooting where the engineer needs rapid iteration, it is a material constraint. Operators should benchmark against representative query workloads before selecting a tier for production use.
Local key management
Across all tiers, conversation content stored server-side is encrypted at rest using a symmetric key generated and held on the operator's machine. The key format is Fernet (AES-128-CBC with HMAC-SHA256 authentication), compatible with the Python cryptography library's implementation. Only a one-way fingerprint — a 16-character hexadecimal prefix of the SHA-256 digest of the key bytes — is transmitted to the backend at session creation, used solely to associate stored session content with the correct decryption key on retrieval. The key itself never leaves the endpoint. Operators may store the key file on external media and provide it at session time, consistent with physical key management practices already common in high-security OT environments.
Network topology requirements
Standard and Split tiers require outbound HTTPS from the OT terminal to the inference backend — a single TCP connection on port 443, with no inbound connectivity required. Shielded adds a local pseudonymization process that runs without network access. The Diode tier additionally requires an inbound path from the inference backend to the on-site relay; this is typically implemented as a separate DMZ-hosted reverse proxy that the terminal operator accesses over the internal network. The relay holds no AI provider credentials and performs no inference — it is a stateless message store that receives and displays the encrypted answer for retrieval by the operator.
Choosing the right tier
The selection criterion is straightforward in principle, though its application requires facility-specific assessment. Standard is appropriate where data is already in the enterprise domain and vendor disclosure is contractually governed. Split is appropriate for operational data that is sensitive by context but not by specific field — the kind of data where you would not post it publicly, but would share it under NDA with a trusted partner. Shielded is appropriate where regulatory controls, field-level classification requirements, or adversarial threat models require that external parties cannot reconstruct infrastructure topology from inference logs. Diode is appropriate where the network architecture already enforces unidirectional data flow, or where the confidentiality of the AI response itself — not just the prompt — is a concern.
5 Conclusion
The adoption of AI inference in operational technology is not a question of if, but of how. The engineering workforce in critical infrastructure is aging and contracting; the complexity of the systems they maintain is not. The productivity case for AI assistance in diagnosis, documentation, and training is already compelling, and will become more so as the technology matures. The question is whether that adoption can be structured in a way that the security and reliability requirements of OT environments will tolerate.
The tiered framework described here is not a theoretical construction — it is an implementation requirement. Operators who deploy AI inference without explicit attention to the data exposure at each layer of the inference pipeline are making a security decision by omission. The choice of tier is a design decision that belongs in the same engineering discipline as network segmentation, access control, and change management.
The framework also makes a broader argument: privacy-preserving AI deployment in OT is not a luxury feature for particularly security-conscious operators. It is a prerequisite for any deployment that takes the threat model of industrial infrastructure seriously. The standards that govern OT security — NERC CIP, IEC 62443, NIS2 — were written in an era before AI inference pipelines existed, but their core principles apply directly: minimize data exposure, enforce security at architectural boundaries, and fail closed when the security posture cannot be verified. The tiered framework maps these principles onto the specific topology of AI inference in a way that allows operators to make a defensible, documented choice.
Subsequent work will examine the latency-privacy frontier in greater empirical detail, the cryptographic properties of the pseudonymization approach under targeted re-identification attack, and the application of the framework to multimodal inputs — including image and time-series data from plant-floor instrumentation — where the pseudonymization surface is substantially more complex.
Cite this paper
@techreport{boumehdi2026privacytiers,
title = {Privacy Tiers in Operational Technology Networks:
A Framework for Deploying {AI} Agents in
Safety-Critical Environments},
author = {Boumehdi, Hicham},
year = {2026},
month = {June},
institution = {Ashigo},
url = {https://ashigo.com/research/ot-privacy-levels/}
}