ISO/IEC 42001: An AI Management System for Industry

The model had been running for three weeks before anyone asked who owned it. It sat on an edge gateway next to the dewatering line, reading torque and flow and a moisture probe, nudging a setpoint every few seconds. It worked. The operators trusted it. And that was the problem. Nobody could say, on paper, how it had been validated, what it would do on a bad sensor, who signed off on the retrain, or where the training data came from. The thing was load-bearing and undocumented at the same time.

This is the gap that ISO/IEC 42001:2023 is built to close. Published by ISO and IEC in 2023, it's the first international management-system standard written specifically for artificial intelligence. Not a model-quality benchmark. Not a checklist of fairness metrics. A management system: the same species of standard as ISO 9001 for quality or ISO/IEC 27001 for information security. If you've ever been through a quality audit, the shape will feel familiar. If you haven't, the shape is the point.

What the standard actually is

An AI management system (the standard calls it an AIMS) is, in the standard's own framing, a set of interrelated elements an organization uses to set policies and objectives and the processes to meet them, for the responsible development, provision, or use of AI. Read that again and notice what it doesn't say. It doesn't say the model has to be accurate. It says you have to have a system for deciding what "good enough" means, checking that you got there, and catching it when you drift.

Structurally it follows the same harmonized skeleton ISO uses across its management standards. Clauses 4 through 10 cover the management system itself: understand your context and interested parties, set an AI policy, plan how you'll treat risk, resource and operate the AI processes, evaluate performance, and improve. Then there's a reference set of controls in an annex, plus implementation guidance. Anyone who has lived inside ISO 9001 or ISO 50001 recognizes the pattern immediately, because it's deliberately the same pattern. That shared structure is the feature. It means a plant that already runs a certified quality or energy or information-security system can bolt the AI controls onto governance it already has, rather than standing up a parallel bureaucracy.

So what makes the AI version different from the quality version? The controls. The annex covers things a quality manual never had to: AI-specific impact assessment, data provenance and quality for training and operation, transparency to the people affected by an automated decision, the full system life cycle from design through decommissioning, and the management of third parties who supply models, data, or compute. That last one matters more than it looks. Almost nobody trains from scratch anymore.

Why a plant needs a system, not a model card

Here's the honest version of the problem. A model card or a validation report is a snapshot. It tells you the model was good on a Tuesday, on a particular dataset, on the day someone wrote the report. A processing plant is not a snapshot. Feedstock changes. Ambient conditions swing. A flow meter fouls. Someone swaps a pump and the vibration signature shifts. The model that was right in commissioning is quietly wrong by the next quarter, and nothing about a static report tells you that.

A management system is the machinery that keeps asking the question after commissioning. Who monitors drift, and against what threshold? When the impact assessment says this model influences a safety-relevant setpoint, what extra oversight kicks in? When the vendor pushes a new model version, what re-validation has to pass before it touches the line? These are operational questions, not academic ones, and they're exactly the questions an AIMS forces you to answer once and then run as routine.

We see the same failure mode across sites. The data science is competent. The MLOps is decent. What's missing is the connective tissue between the model and the rest of the plant's documented operations. The standard is, in plain terms, that connective tissue written down. It's also the thing that turns "the model the night-shift trusts" into an asset the company actually owns. (Three weeks of undocumented autonomy is not ownership.) Building that layer is most of the work, long after the model itself is finished, and it's the part operators consistently underestimate because it looks like paperwork rather than engineering.

Here's what surprised us

Going in, you assume the hard part of an AIMS will be the modeling controls — validation, monitoring, bias. It isn't. The hard part is data lineage, and it's hard for a reason nobody warns you about: the data is already there, and that's the trap.

A process plant has been logging for years. The historian holds millions of tags. So when the standard asks you to document the provenance and quality of the data your AI uses, the instinct is to wave at the historian and say "it's all in there." But the standard wants something the historian doesn't store. Which tags fed which model version. How gaps were filled. Whether a sensor was in calibration during the training window. Which manual overrides were in the data and whether they should have been. A historian records values. It doesn't record the judgment around the values, and the judgment is what governance needs.

So the first real deliverable of a 42001 effort is usually unglamorous: a documented map from physical instrument to tag to model feature to decision, with the calibration and quality caveats attached. It's tedious. It also surfaces problems that have nothing to do with AI — orphaned tags, a probe that's been reading through a failed reference cell for months, two "identical" lines that log in different units. Cleaning that up is worth doing even if you never deploy a model. That's the part that surprised us: the governance standard pays for itself in instrumentation hygiene before the AI controls ever bite. A system that captures lineage at the edge, where the tag meets the model, makes this far less painful than reconstructing it after the fact.

Where 42001 meets the EU AI Act

Standards are voluntary. Regulation isn't, and the regulation has arrived. The EU AI Act, Regulation (EU) 2024/1689, was published in the Official Journal in July 2024 and entered into force on 1 August 2024. Its obligations phase in over years rather than landing all at once, and the phase that matters most to industrial operators is the high-risk regime: for the use cases listed in the Act's Annex III, the obligations apply from 2 August 2026. For high-risk AI tied to products already covered by EU safety legislation, the date runs later still.

Is a plant's process-control model "high risk" under the Act? Often not, by the letter — the high-risk list is built around named domains like biometrics, critical infrastructure management, employment, and the like, and a yield optimizer on a dewatering line may sit outside it. But "often not" is not "never," and the answer depends on the application, not on the fact that it's industrial. If an AI system manages the safety of critical infrastructure, the analysis changes. The point for operators is that you need to do the classification deliberately and write down why, rather than assume your way out of it.

Here the standard earns its keep. The Act's Article 9 requires providers of high-risk systems to run a continuous, iterative risk-management process across the whole lifecycle: identify known and foreseeable risks to health, safety and fundamental rights, estimate them, adopt mitigations, and test before the system goes to market. Read that list against an AIMS and the overlap is obvious. ISO/IEC 42001 doesn't make you compliant with the AI Act on its own — no standard does that, and anyone telling you a certificate equals legal compliance is selling something. What a certified management system gives you is the evidence trail: documented risk assessments, impact analyses, lifecycle records, and the monitoring you'd otherwise have to invent under deadline. It's a head start, not a get-out-of-jail card.

Mapping to NIST's framework

If your operations span the Atlantic, you'll meet the other major reference point: the NIST AI Risk Management Framework, released as AI RMF 1.0 on 26 January 2023. NIST's framework is voluntary and deliberately not a certification — there's no auditor, no certificate. It organizes the work around four functions: Govern, Map, Measure, and Manage. Govern is the culture-and-policy backbone that runs through the others; Map establishes context and identifies risks; Measure analyzes and tracks them; Manage acts on them.

The framework also names what it's trying to protect, and this is the part worth pinning to the wall. NIST AI 100-1 lists seven characteristics of trustworthy AI: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair, with harmful bias managed. Notice that "valid and reliable" comes first and is treated as the foundation the others build on. For a plant engineer that ordering is intuitive. A model that isn't reliable isn't safe, and a model that isn't safe has no business near a setpoint.

The practical move is to treat the two as complementary, not competing. NIST gives you the vocabulary and the risk-function structure; ISO/IEC 42001 gives you the auditable management system to run it inside. A reasonable approach is to use the framework's functions to shape how you think about risk, and the standard's clauses and controls to make that thinking repeatable and provable. They were designed in the same few years for the same problem, and they don't fight each other.

The security boundary nobody puts in the AI plan

An AI control loop is a new path into the process. That's easy to forget when the conversation is all about accuracy. The model reads from the control network and writes setpoints back to it, which means it's now part of your attack surface and your safety case, not a tidy analytics box off to the side.

This is the axis I'd argue most AIMS efforts under-weight. ISO/IEC 42001 has security controls, but it's not an OT-security standard and it doesn't pretend to be. The depth lives elsewhere. The ISA/IEC 62443 series is the recognized framework for securing industrial automation and control systems across their lifecycle, built around a risk-based, zone-and-conduit model that bridges the operations and IT worlds. On the US side, NIST SP 800-82 Revision 3, published in September 2023, is the reference guide to operational-technology security, expanded from its industrial-control-systems roots to cover OT broadly. Neither mentions your model. Both govern the network it lives on.

The link back to 42001 is logging and traceability. The standard expects records — what the system did, when, on what inputs. So does any incident investigation. So does Article 9's lifecycle thinking. In OT terms that means your AI's decisions and inputs need to land somewhere tamper-evident and time-synced, ideally the same historian discipline you already trust for the rest of the line. Get the security architecture wrong and the governance records are worthless, because you can't prove they weren't altered. Why bother certifying a management system whose evidence you can't defend? You wouldn't, and that's why the OT-security baseline isn't optional context — it's load-bearing.

What it costs to stand up, and who owns it

The blunt part. A certifiable management system is real work, and most of the cost isn't software. It's people writing things down, agreeing thresholds, sitting in review meetings, and maintaining the documentation after the auditor leaves. For a single model on a single line, the overhead can look absurd relative to the model. That's a legitimate objection, and the honest answer is that 42001 isn't priced for one model. It's priced for a portfolio. The fixed cost of the management system amortizes across every model you'll deploy over the years, which is why it makes more sense for an operator with an AI roadmap than for one running a single pilot.

Ownership is the quieter cost. A management system has to have an owner with authority — someone who can stop a deployment, not just file paperwork about it. On the plants where this works, that's usually a named operations or quality leader, not the data team, because the data team can't credibly govern its own work. Get that wrong and you build a documentation exercise that everyone resents and nobody enforces. That's the most common way these efforts quietly fail.

There's a tooling decision buried in the cost question too. Much of the recurring overhead is evidence: lineage, version records, decision logs, the artifacts an auditor wants and an incident review needs. Capture that automatically, where the tag meets the model, and the management system mostly runs itself. Reconstruct it by hand each audit cycle and the cost never stops. It's one of the reasons we built our edge telemetry and analytics platform to record lineage at the point of decision rather than leaving it to be pieced together later from a historian that was never meant to hold it.

A starting sequence that doesn't stall

You don't begin with certification. You begin with an inventory, and most plants are shocked by what the inventory turns up — models in spreadsheets, a vendor "optimizer" nobody can explain, scripts on someone's laptop touching live tags. Start there:

• Inventory every AI or automated-decision system touching the process, including the ones that arrived inside vendor equipment. You can't govern what you haven't found.
• Classify each one by impact. Does it advise a human, or does it act? Does it touch safety, quality, emissions, or none of those? This is also your first cut at the EU AI Act high-risk question.
• Fix data lineage for the systems that act. Instrument-to-tag-to-feature-to-decision, with calibration and quality caveats. This is the slow part; start it early.
• Write the AI policy and assign an owner with stop authority. One page that means something beats fifty that don't.
• Map your existing ISO systems and OT-security baseline (62443, SP 800-82) so the AI controls extend them instead of duplicating them.

Certification, if you pursue it, comes after those are real and running, not before. The standard rewards a system that operates, and an auditor can tell the difference between governance that's lived and governance that was written the week before the visit.

The shift 42001 asks for is small to state and hard to do. Stop treating an industrial model as a clever artifact and start treating it as a governed part of the plant, with an owner, a lifecycle, a data trail, and a security boundary — the same things you already demand of every pump, valve, and safety interlock on the floor. The model that ran for three weeks unowned wasn't a technology failure. It was a governance gap. The standard is just the discipline for not leaving that gap open.