AI Act in manufacturing: high-risk classification and what it means for deployment
AI Act in manufacturing: high-risk classification and what it means for deployment
Reading time: approx. 12 min. Cluster: compliance. Author: Fryderyk.
The short answer
Most AI systems a factory runs are not high-risk under the AI Act. A document assistant, visual quality inspection, predictive maintenance, or drawing-to-quote tooling usually does not fall into the high-risk category. A system is high-risk by only one of two routes: as a safety component of a product already covered by EU harmonisation law (Annex I), such as machinery, or as one of the use cases named directly in Annex III, which in a factory most often means worker management. Everything else is at most subject to the transparency duties in Article 50. July 2026 brought a material change: the Digital Omnibus package pushes the high-risk deadlines back (Annex III to 2 December 2027, Annex I to 2 August 2028), but the Article 50 transparency duties stay at 2 August 2026, and until the amendment is published in the Official Journal the original dates formally still apply. Where you deploy, on-prem or cloud, does not change the classification. It only changes how easily you can evidence some of the obligations. This note shows how to classify a system and what the classification means for deployment.
Contents
- State of play in July 2026: what just changed
- Two routes to high-risk: Annex I and Annex III
- What this means concretely for a factory
- Classification step by step
- Obligations if the system is high-risk
- How this affects the on-prem versus cloud decision
- Three classification mistakes
- FAQ
- Disclosure and biases
- What this note does not cover
- Related notes
State of play in July 2026: what just changed
The AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024 and applies in stages. Prohibited practices have applied since February 2025, obligations for general-purpose AI models since August 2025, and the heaviest layer, obligations for high-risk systems, was set to begin on 2 August 2026 for Annex III use cases and 2 August 2027 for systems embedded in Annex I products.
That calendar has just moved. The Digital Omnibus on AI was approved by the European Parliament on 16 June and formally adopted by the Council on 29 June 2026. It defers the high-risk obligations: Annex III to 2 December 2027, Annex I to 2 August 2028. One important caveat: the amendment is not yet in force. It takes effect on the third day after publication in the Official Journal, expected in the second half of July 2026. Until then the original dates formally apply, so plan against the direction of travel but do not treat the deferred dates as settled until publication happens.
Three parts of the amendment matter for manufacturing. First, the Machinery Regulation was moved to Annex I Section B, so the full AI Act obligations no longer apply directly to machinery. Instead the Commission is to set requirements for AI in machinery through delegated acts under the Machinery Regulation itself, by 2 August 2028. Second, the definition of a safety component was tightened: AI used solely to assist the user, optimise performance, automate, or control quality is not a safety component unless its failure could endanger health or safety. Third, the Article 50 transparency duties were not deferred and apply from 2 August 2026, with a short grace period to 2 December 2026 for content marking in systems already on the market.
The architecture of the AI Act itself did not change. The risk-based approach, the annex categories, and the classification logic all stay. Mostly the clock moved.
Two routes to high-risk: Annex I and Annex III
A system is high-risk in one of two ways.
Route one, Annex I. The system is a product, or a safety component of a product, that is already covered by EU harmonisation law: machinery, medical devices, toys, lifts, radio equipment. In manufacturing this usually means machinery. After the Digital Omnibus change, though, the machinery route runs through the Machinery Regulation and delegated acts rather than through the direct application of the AI Act.
Route two, Annex III. Regardless of any product, the system performs one of the listed use cases: among others biometrics, management of critical infrastructure, employment and worker management, access to essential services, law enforcement. For a factory the two realistic areas are worker management and, if the company runs infrastructure of that kind, management of critical infrastructure.
If a system fits neither route, it is not high-risk. It may still carry transparency duties or sit outside the material scope, but it does not carry the weight of the high-risk obligations.
What this means concretely for a factory
Map this onto the systems a plant actually deploys.
A RAG-based AI assistant over documentation, manuals, and standards is a tool that supports the worker. It is neither a machinery safety component nor an Annex III use case, so it is not high-risk. If it converses with a person, it carries a transparency duty: the user must know they are dealing with an AI system.
Visual quality inspection that flags defects on the line is the classic case where the tightened safety-component definition makes the difference. If the system only classifies quality and its error does not endanger health or safety, it is not a safety component and not high-risk. If, on the other hand, its output directly stops a machine in a situation dangerous to the operator, the assessment looks different and has to be done properly.
Predictive maintenance and drawing-to-quote generation are also efficiency tools, not safety components. Outside the material scope of high-risk.
Worker-management AI is different. A system that screens candidates, allocates tasks, monitors, or evaluates workers falls into Annex III as an employment use case. This is the most common high-risk in a plant, and the easiest to forget, because it reads as HR rather than production. Here the high-risk obligations apply for real, on the deferred date of 2 December 2027.
Classification step by step
A simple path you can walk for any system.
Step one: is the system a product or a safety component of an Annex I product, and could its failure endanger health or safety. If yes, it is the Annex I route, and for machinery currently through the Machinery Regulation.
Step two: does the system perform one of the Annex III use cases, in manufacturing mainly worker management or critical infrastructure. If yes, it is high-risk by the Annex III route.
Step three: if the system lands in Annex III, check the Article 6(3) exemptions, for example for systems performing a narrow procedural task or improving the result of prior human work. Note that even with an exemption a simplified registration duty in the EU database remains.
Step four: if no route leads to high-risk, the system is limited or minimal risk. Then check whether the Article 50 transparency duties apply, because those apply regardless of the risk classification.
Record the outcome of each step. That is the classification trail you show when someone asks why you classified the system the way you did.
Obligations if the system is high-risk
First fix the role. A provider is the entity that develops the system and places it under its own name. A deployer is the one that uses it in a professional capacity. Most factories are deployers, because they buy the system from a provider. Watch the trap: if you substantially modify the system or put it out under your own brand, you can be reclassified as a provider and inherit the heavier duties.
On the provider side sit: a risk-management system, data governance, technical documentation, event logging, transparency to the user, human oversight, accuracy, robustness and cybersecurity, conformity assessment, CE marking, EU database registration, and post-market monitoring.
On the deployer side sit mainly: using the system in line with the instructions, ensuring human oversight, monitoring operation, keeping logs for at least six months, informing workers and their representatives where the system touches employment, and a fundamental-rights impact assessment where required.
How this affects the on-prem versus cloud decision
The key point: classification depends on the use and purpose, not on where you deploy. Hosting the model in-house does not make a system stop being high-risk, just as the cloud does not automatically make it risky. You classify what the system does, not where it sits.
Where you deploy does change how you evidence some of the high-risk obligations. Data governance, event logging, cybersecurity, and human oversight are easier to demonstrate when data and model stay inside the organisation, because you control the flow and do not have to work through a cloud provider chain of sub-processors. In the public cloud part of the proof shifts to the provider and its contracts, which I set out in a separate note on public cloud LLMs and NIS2.
It also pays not to duplicate work across regimes. The AI Act high-risk obligations, such as risk management, logging, and cybersecurity, overlap heavily with the Article 21 areas of NIS2. The same artifact often satisfies both regimes. I mapped NIS2 onto an AI system in a separate cheat sheet, and the minimum network split in a note on network isolation.
Three classification mistakes
First: deciding every AI system is high-risk and building the full compliance machine where a transparency duty would do. That wastes resources and dilutes attention on the systems that really are high-risk.
Second: assuming that because a system runs internally or on-prem it is out of scope of the AI Act. The Article 50 transparency duties and the Annex III use cases, worker management above all, apply regardless of the fact that nobody outside the company uses the system.
Third: treating the deferred dates as permission to do nothing. Inventorying systems and classifying them is work that has to be done anyway, and the deferral buys time for it, not a pass on it. In December 2027 the same question arrives that would have arrived in August 2026: can you show that the system was assessed, classified, and brought under oversight.
FAQ
Is our internal document assistant high-risk?
Usually not. An assistant that supports a worker is neither a safety component nor an Annex III use case. It carries a transparency duty if a user converses with it, but not the weight of high-risk obligations.
Do the deferred dates mean we can do nothing?
No. The deferral concerns the dates on which high-risk obligations apply, not the need to classify. Inventory and classification are due now, and the extra months are for putting things in order, not for delay. On top of that the Article 50 transparency duties apply from August 2026 and were not deferred.
Does on-prem remove our AI Act obligations?
No. Where you deploy does not affect classification. On-prem can make some obligations easier to evidence, such as data governance or logging, but it does not take a system out of scope.
Are we a provider or a deployer?
If you buy the system from an outside provider and use it as intended, you are a deployer. If you build it yourself, place it under your own brand, or substantially modify someone else's, you may be a provider and take on the heavier duties.
What about the Machinery Regulation?
After the Digital Omnibus change, AI embedded in machinery does not fall directly under the full AI Act obligations. Requirements for AI in machinery will be set by the Commission through delegated acts under the Machinery Regulation, by 2 August 2028.
// disclosure & biasesDisclosure and biases
I write from the perspective of someone working on AI solutions deployed outside the public cloud, so I naturally emphasise data-flow control and on-prem architecture. I have tried to separate the content of the regulation from that preference. This text is not legal advice. I describe the legal state as of mid-July 2026, when the Digital Omnibus is adopted but awaiting publication in the Official Journal, so the dates may still be refined. Classifying a specific system depends on the facts and should be checked with a lawyer.
What this note does not cover
I do not go through the full list of Annex III use cases beyond those realistic for manufacturing. I do not get into the details of conformity assessment, CE marking, or the EU database registration procedure, each of which deserves its own note. I leave out the obligations for general-purpose AI models and the new Article 5 prohibitions, which concern uses other than typical manufacturing. The focus here is classification and its consequences for deployment.
Related notes
Building CortexMine, an on-prem AI platform for European manufacturers under NIS2. Where this bias could affect conclusions, it is flagged inline.
Want to apply this to your case: architecture, compliance, and cost?
→ Book 30 minAI Vendor DPA: 8 Clauses Whose Absence Breaks Your Audit
A vendor's boilerplate DPA stays silent exactly where an auditor looks first. Eight clauses whose absence breaks an NIS2 or GDPR audit: from the sub-processors behind the model API and training use of your data, to logs, breach notice and data deletion.
NIS2 and AI: mapping Article 21 to concrete controls, one cheat sheet
The ten Article 21 NIS2 areas mapped to an AI system. For each area, the question an auditor will ask and the single artefact you need to show.
NIS2 audit readiness for AI: the 7 documents an auditor asks for
NIS2 does not ask for a standalone AI policy. It asks that your AI system sits inside seven documents you already produce. Here is the list, with a mapping table.