The EU AI Act on the Plant Floor

The enclosure was a standard wall-mount, IP54, sitting at the end of a dryer line. Inside, next to the PLC and a managed switch, ran a small industrial PC with an inference model on it. The model read a dozen process tags over OPC-UA and pushed back a moisture estimate the operators trusted more than the lab. A good install. Then the plant manager asked the question that every operations team in the EU is now asking: does the AI Act apply to this box, and if it does, what do we have to do about it?

It's a fair question, and the honest answer takes longer than a yes or no. The regulation exists, it's in force, and the clock is running. But a lot of what gets written about it is aimed at lawyers, not at the people who own the panel. So this is the field version: what the EU AI Act says, which parts touch a processing plant, and what an operator should actually have on their checklist before the deadlines land.

What's in force, and the clock that's already running

The law is Regulation (EU) 2024/1689, usually called the AI Act. It entered into force on 1 August 2024, and unlike a directive it applies directly in every member state without national transposition. There's no Estonian version or German version to wait for. The text is the text.

What confuses people is that it doesn't switch on all at once. The obligations phase in over several years, and the dates matter because they decide what you're on the hook for and when. The European Commission's own timeline sets out the staging.

Read that last row twice if you make or run machines. The longest runway in the Act is the one that lands on the factory floor. Everything else is closer than it looks.

Provider or deployer? Get this right first

Before you ask whether your AI is high-risk, ask what role you play. The Act treats a provider (whoever develops a system and puts it on the market under their name) very differently from a deployer (whoever uses one under their own authority). A plant that buys a vision system, a soft sensor, or an optimiser and runs it is, in the usual case, a deployer. The provider carries the heavy conformity work. The deployer carries a shorter, operational list.

That comfort has a trap door in it. Under Article 25, a deployer becomes a provider, and inherits the full provider obligations, in three situations: if you put your own name or trademark on a high-risk system already on the market; if you make a substantial modification to one; or if you change the intended purpose of a system so that it now counts as high-risk. That third one is the quiet one. Take a general-purpose model your integrator handed you, point it at a safety decision it wasn't sold for, and you may have just promoted yourself to provider without signing anything. Where does the integrator's responsibility end and yours begin? Often, exactly at the moment you start tuning the thing yourself.

Is your plant AI even high-risk?

Here's what surprised us when we sat down and read the classification rules instead of the headlines: most of the AI we put into plants doesn't fall into the high-risk bucket at all. Process optimisation, energy balancing, a soft sensor inferring a value you can't measure cheaply, condition monitoring that flags a bearing before it fails. None of that is automatically high-risk. The Act doesn't regulate AI because it's AI. It regulates specific uses.

There are two doors into the high-risk category. The first is Annex III, which lists use cases: biometrics, critical infrastructure, education, employment and worker management, access to essential services, law enforcement, migration, and justice. For a processing plant, two of those are live. Annex III point 2 covers AI used as a safety component in the management and operation of critical infrastructure, including the supply of water, gas, heating, or electricity. Annex III point 4 covers AI used to recruit, screen, allocate tasks to, or monitor and evaluate the performance and behaviour of workers. So the dryer-line moisture model is fine. A system that ranks your maintenance crew on productivity is not.

The second door, and the one that catches industrial builders, is Annex I, which we'll come to. But first, a filter that softens the picture. Under Article 6(3), even a system that sits in an Annex III category is not high-risk if it doesn't pose a significant risk to health, safety, or fundamental rights, and it only does one of a narrow set of things: a narrow procedural task, improving the result of a human activity already completed, flagging deviations from prior decision patterns without replacing the human review, or a preparatory step to an assessment. There's one hard exception. If the system profiles people, it's always high-risk, no matter what. So a tool that pre-sorts shift logs for a supervisor to read is likely out; a tool that builds behavioural profiles of operators is firmly in.

The machinery overlap, where the deadlines bite

Annex I is the door that matters most on the plant floor, because it ties the AI Act to product-safety law you already live under. If an AI system is itself a product, or a safety component of a product, covered by the EU harmonisation legislation in Annex I, it's treated as high-risk. Machinery is on that list.

The timing here is its own knot. The Machinery Regulation (EU) 2023/1230 replaces the old Machinery Directive 2006/42/EC and applies from 20 January 2027. It's the first time mechanical safety and digital aspects, software integrity, updates, connected functions, sit in the same instrument. An AI component that performs a safety function on a machine, or a self-evolving safety behaviour driven by machine learning, pulls that machine into both the new Machinery Regulation and the AI Act's high-risk regime. The AI Act gives this product-embedded category its longest transition, to 2 August 2027, precisely so the two conformity processes can be run together rather than twice.

For an operator, the practical read is this. A safety PLC doing interlock logic is not AI and not in scope. An ML model that decides when to trip a press, throttle a burner, or release a guard is a safety component, and that's where the documentation, assessment, and oversight duties stack up. The boundary is the safety function, not the algorithm's cleverness.

What "high-risk" actually asks of you

When a system does land in high-risk, the obligations aren't vague principles. They're an engineering bill of materials. The provider has to stand up a risk management system across the lifecycle (Article 9), govern training and input data for quality and representativeness (Article 10), keep technical documentation (Article 11) and automatic logs (Article 12), make the system transparent enough for a deployer to use it correctly (Article 13), build in real human oversight (Article 14), and meet stated targets for accuracy, cyber-resilience, and consistent performance under fault (Article 15). If you've worked to IEC 61508 or IEC 62443, the shape is familiar: a documented safety and security case, maintained, not a one-time sign-off.

As a deployer, your list under Article 26 is shorter but specific. Use the system according to the provider's instructions. Assign human oversight to people with the competence, training, and authority to actually exercise it, not a name on an org chart. Where you control the input data, keep it relevant for the intended purpose. Monitor operation, and tell the provider and your market surveillance authority without undue delay if something goes wrong or a serious incident occurs. Keep the system's automatic logs for at least six months. And, the one that catches employers off guard: before you put a high-risk system to work in the workplace, inform the workers' representatives and the affected workers that they'll be subject to it.

The duty that's already live

While the high-risk deadlines sit in 2026 and 2027, one obligation has applied since 2 February 2025 and reaches almost everyone: AI literacy. Article 4 requires providers and deployers to ensure a sufficient level of AI literacy among the staff and others operating AI on their behalf, weighed against their technical knowledge, training, and the context of use. It applies regardless of risk tier. The plant running a single off-the-shelf model on a dryer line is a deployer, and it owes its operators enough understanding to run that model sensibly and know its limits. There's no fine attached directly to Article 4, but it's the cheapest box on the whole list to tick, and the most embarrassing to be caught missing.

The prohibitions that switched on the same day are unlikely to touch normal plant work, but worth knowing: things like manipulative AI, social scoring, and, relevant to a workplace, AI that infers emotions of workers except for safety or medical reasons. If someone pitches you an "operator alertness" camera that reads mood, that's the clause to read first.

What it costs to get it wrong

The enforcement teeth have bite, and they scale with company size. The fines under Article 99 are set as a euro ceiling or a share of worldwide annual turnover, whichever is higher.

For SMEs and start-ups, each cap is applied as the lower of the figure or the percentage, which softens the blow but doesn't remove it. The number that should focus attention isn't the headline ceiling. It's that getting a notified body to accept your conformity case takes months, and the surveillance authority can order a non-compliant system off the market while you sort it out. A line that depends on an AI safety component is a line that can be told to stop.

How to get in front of it

None of this needs panic, but it does need an inventory. Start by listing every AI system in the plant and, for each, writing down two things: are we the provider or the deployer, and does the use case touch Annex III or Annex I. Most rows will come back low-risk, and that's a defensible answer as long as you wrote down why. Keep that record with the system, the way you'd keep a datasheet or a P&ID, so the reasoning survives the engineer who made the call. The rows that come back high-risk are the ones to resource now, not in mid-2026. Treat each one like a new safety function entering the plant: it needs an owner, a review cadence, and a place in the change-management process, because that's effectively what it is.

For the management scaffolding, you don't have to invent a framework. Two reference points predate the Act and map onto it cleanly. ISO/IEC 42001:2023, published in December 2023, is the first international standard for an AI management system, the governance-and-process layer that sits above any single model, much as ISO 9001 sits above any single product. The US NIST AI Risk Management Framework (AI RMF 1.0), released in January 2023, is voluntary and organised around four functions, govern, map, measure, and manage, and it's a practical way to structure the risk work the Act will ask for. Neither is a substitute for conformity, but adopting either now means the AI Act audit finds a system already running instead of a blank page.

This is the part of the work we spend most of our time on in our industrial AI deployment practice: instrumenting plants so the data going into a model is clean and traceable, and so the logs coming out of it satisfy a six-month retention duty without a scramble. Good telemetry hygiene is the same discipline whether the goal is a better moisture estimate or a defensible compliance record. The Act, read plainly, mostly rewards what good operations already do, knowing what your data is, who's watching the model, and what happens when it's wrong.

Where this stays fuzzy

Honesty matters more than reassurance here, so a few caveats. The harmonised technical standards that will let a provider claim a presumption of conformity for high-risk systems were not finished as of late 2025; CEN-CENELEC's committee was still drafting them. Until those land, "how exactly do I prove Article 15 compliance" doesn't have a tidy checklist answer, and anyone who tells you it does is selling something. The Commission's classification guidance for high-risk systems was still in draft form too. And the line between a "substantial modification" that makes you a provider and ordinary tuning that doesn't is going to be argued case by case for years.

So the defensible posture isn't certainty. It's a documented, current view of what you run, why you've classified it the way you have, and who owns the decision. Get the inventory and the roles right, keep your data and logs in order, and the rest is detail you can fit as the standards firm up. That's not a regulatory burden so much as a description of a well-run plant. The dryer-line box, in the end, was a deployer's low-risk soft sensor. The plant just needed to be able to say so, and to prove it.