Data & AI Governance in OT.
AI is already inside industrial operations — in vendor platforms, predictive maintenance, vision systems and copilots on engineering workstations. We govern the data leaving the plant and the models making decisions inside it, so adoption can move faster rather than slower.
In OT, a bad model output is a physical outcome.
01 · The gap in the market
AI arrived in the plant before the governance did.
Nobody signed off “AI in OT”. It arrived as a feature: an OEM analytics portal, a vision system on the packing line, a vendor's predictive maintenance service, an engineer pasting alarm logs into a chatbot to work out what tripped. The corporate AI policy governs the office and the models the data team built. It says nothing about production data crossing the boundary, or about an advisory output that a shift operator will act on at 03:00.
Corporate AI01
Where the policy was written
Governed models, a data platform, an AI policy and an ethics board. All of it built around corporate information.
The pipeline02
Where plant data goes
Historian to cloud, vendor portals, third-party training sets. Rarely inventoried, rarely classified, often nobody’s job.
The process03
Where the output lands
A recommendation acted on by a shift operator, or a setpoint written back automatically. This is where AI risk becomes physical.
Governance written for the first two frames does not hold in the third.
Corporate AI governance
Written for information, not process
Frameworks concentrate on bias, privacy and IP. None of them ask what happens when a maintenance model is wrong about a bearing, or whether an output can reach a PLC.
We govern the consequence, not the concept.
Data & platform teams
No visibility below the boundary
They can describe the lake in detail and not the tags feeding it — which asset, which unit, which safety function, and whether that data should have left the plant at all.
We map lineage from the tag upward.
Security functions
No way to assess an OT use case
Asked to approve a vision system or a vendor analytics feed, the honest answer is that nobody in the room can model the physical consequence — so the default becomes no.
We give a proportionate, engineered assessment.
OEMs & vendors
AI features arriving as black boxes
The platform update includes an AI capability, the contract permits data egress, and the buyer discovers both after go-live — often during an audit.
We interrogate the vendor, in engineering terms.
02 · What it is
Governance that lets you say yes.
This pillar is the control layer around our OT AI adoption work. We establish what industrial data you hold and where it flows, register every AI use case touching operations, classify each by consequence rather than novelty, and set the guardrails that let the low-risk majority proceed without a committee.
Then we do the engineering half: threat model the pipelines and the models, test the plumbing that moves plant data to the platform, and put human authority and interlocks where an output could reach the process. The point is not to slow AI down. It is to remove the reason to block it.
The last decision stays human · by design
03 · Paired with adoption
Adoption and governance, run as one engagement.
Our AI adoption work in OT finds the use cases worth doing. This pillar makes them defensible. Split across two suppliers, the governance always arrives after the pilot has already gone live.
Find the use cases that repay the effort
Our OT AI adoption work identifies where machine learning genuinely helps — downtime prediction, quality inspection, energy optimisation, alarm rationalisation — and rules out the rest early.
Make each one defensible before it scales
This pillar wraps the chosen use cases in data lineage, risk classification, threat models, named owners and evidence, so a pilot can become estate-wide without a governance reset.
Implement the guardrails, not just specify them
Egress controls at the boundary, brokered platform access, logging, human authority points and interlocks — configured by the same engineers who do our site enablement work.
04 · What we do
Eight workstreams, from data lineage to model assurance.
Delivered as a whole or picked individually. Each one produces something operable — a register, a control, a test result — not a policy document.
05 · Threat modelling & vulnerability
An AI system in OT has an attack surface the office version does not.
We threat model each AI use case as an engineered system: sensor to historian, historian to platform, model to output, output to human, human to plant. Then we test the parts that can be tested. These are the failure modes we look for, with the consequence stated in process terms rather than CVSS.
We also run this in reverse: using AI on the defensive side, where it earns its place. Anomaly detection tuned on your own process data, automated triage of OT alerts, and machine-assisted review of configuration drift across sites — each with a human decision point before anything touches the plant.
06 · Compliance lens
One evidence set. Several regimes asking similar questions.
AI and data obligations are landing on top of the OT security regimes you already carry. Assembled once, in the right structure, the same evidence answers most of them — and answers your customers' security questionnaires too.
EU AI Act
Obligations follow risk classification and role. Industrial safety-related and employment-adjacent uses attract real duties on risk management, data quality, logging and human oversight.
Use-case register, risk tiers, oversight records
NIS2
Extends security and supply-chain duties for essential and important entities — which now includes the AI and data platforms your operations depend on.
Threat models, vendor assessments, incident routes
NCSC CAF
Asset management, data security and supply-chain outcomes apply to operational data and analytics as much as to control systems themselves.
Data flow map, classification, egress controls
IEC 62443
Zones, conduits and component requirements cover the edge inference devices and data conduits AI introduces into the plant.
Zone model, conduit register, hardening evidence
ISO/IEC 42001 & 27001
A management-system route for AI alongside information security — useful when a customer or insurer wants certifiable governance rather than an opinion.
Policy set, control mapping, audit trail
Customers, insurers & UK GDPR
Questionnaires and cover renewals increasingly ask about AI use and data handling; personal data appears in OT more often than people expect — CCTV, access logs, operator performance.
Answer pack, DPIA input, retention rules
07 · Deliverables
What you are left holding.
08 · Why Nuvantiq
Governing AI in a plant needs someone who understands the plant.
01
We understand the physical consequence
Our engineers have written the control code and recovered the plant. When we assess a model output we can say exactly what it would do to the process — which is the whole question.
02
We are not selling you a model
No platform, no licence, no AI product to protect. Our advice on whether a use case is worth doing carries no commercial interest in the answer being yes.
03
Proportionate, not obstructive
Most industrial AI is low consequence and should proceed quickly. We reserve serious scrutiny for the systems that can move plant, and say so clearly.
04
We implement the controls
Egress restrictions, zoning, brokered access, logging and interlocks are engineering work, and we do it — the same team, on site, in your change windows.
For the CISO & CIO
You need to know which AI systems touch production, what data left the estate to make them work, and whether a model output can reach a controller. We give you the register, the threat models and the control evidence — in one structure that serves the AI Act, NIS2 and CAF at once.
For digital & data leaders
Your programme stalls when security cannot assess an OT use case and defaults to no. We give a proportionate route: guardrails that clear the low-consequence majority quickly, and real engineering scrutiny reserved for the handful that can move plant.
For operations & engineering
You will be the one acting on the model, or overruling it. We define what the system may decide, what it may only advise, and what it must never touch — written into the runbook your shift teams actually use.
Start with one threat model
Adopt AI in operations without betting the plant on it.
Start with a use-case discovery and one threat model. You will know within a fortnight what is already running, what it touches, and what to govern first.
Or email Info@nuvantiq.com.