A water utility wants analytics AI near OT historian data. Which protective design pattern should security require?

Water-utility OT historian data is valuable for analytics AI, but return paths from IT/AI networks into OT can enable unsafe command or configuration influence on critical infrastructure. The protective pattern security should require is a one-way data transfer or equivalent diode design so historian telemetry can feed analytics without opening return paths into OT. That preserves the confidentiality and integrity posture of plant networks while still allowing municipal AI to consume historian feeds for leak analytics and situational awareness.

Deploying the analytics cluster inside the OT historian segment behind the process firewall fails because it places analytics inside the OT trust zone, giving the cluster direct adjacency to the historian and potential controllers instead of keeping OT isolated behind a one-way data transfer.

Publishing a read-only historian replica in the enterprise DMZ synchronized over a stateful firewall that permits analytics queries toward OT fails because it still allows the enterprise side to initiate sessions toward OT, creating return paths into the historian zone rather than enforcing strict one-way flow.

Allowing the AI subnet to poll the historian through mutual TLS and role-based accounts restricted to time-range reads on process tags fails because it still lets the AI subnet initiate sessions into OT, opening a return path from analytics into critical historian infrastructure.

Exam caveat: When AI consumes OT data, look for unidirectional or tightly mediated transfer patterns—not colocating analytics inside OT, querying OT from the DMZ, or polling the historian from the AI subnet.

Operational check: Verify historian-to-analytics flows are one-way (diode/broker with no return route to controllers), the analytics cluster stays outside the OT historian segment, and no analytics or DMZ system can initiate sessions into OT.