EU AI Act for Manufacturing SMEs: What to Prepare

The EU AI Act applies to manufacturing SMEs, but far less of your factory AI is high-risk than the headlines suggest. A vision model that grades surface finish, an algorithm that predicts bearing failure, a forecast that fills next week's schedule: in the Act's terms these are ordinary industrial software, carrying little beyond internal diligence. What pulls a system into the high-risk tier is a narrow set of triggers, mainly performing a safety function in machinery that requires third-party certification, or making decisions about the people who work on your lines. Establishing which of your systems cross that line, and which plainly do not, is a few days of structured work that saves quarters of misdirected effort.

This is a practical readiness guide for engineering, quality, and operations leaders, not legal advice. The goal is to help you scope the technical and organisational work early enough that it is cheap, and to stop you from either ignoring the regulation or over-reacting to it. For a formal compliance position on a specific system, you will still want regulatory and legal counsel. What follows is how to get manufacturing AI into a defensible state while the deadlines are still comfortably ahead of you.

Why does the EU AI Act matter to a manufacturer at all?

Because the Act regulates AI as a product characteristic, and manufacturers already live inside product law. If your company puts machinery on the EU market, you know the shape of this: intended purpose, technical file, risk assessment, conformity assessment, CE marking, post-market surveillance. The AI Act reuses that structure and points it at software behaviour. For a firm that has never shipped a regulated product, this is an alien framework. For a machine builder or a mid-sized manufacturer with a quality system, it is largely familiar plumbing applied to a new component.

Two roles decide how much of it lands on you. A provider develops an AI system and places it on the market under its own name, which is where machine builders and OEMs embedding AI in their equipment sit. A deployer uses an AI system in the course of its own activity, which is where most manufacturing SMEs sit when they buy an inspection cell or a maintenance platform from a vendor. Provider obligations are substantially heavier. Deployer duties are real but narrower, centring on using the system as intended, assigning competent human oversight, keeping logs, and informing affected workers.

The trap is that the boundary moves. Buy a vision system and configure it: you are a deployer. Train the model yourself on your own defect images, rebrand a vendor's system as your own, or repurpose a tool well outside the intended use its provider documented, and you can become a provider without ever intending to. That reclassification is the single most consequential thing an audit finds in a factory, because it changes the obligation set entirely.

What are the actual dates now?

The timeline moved in July 2026, and a lot of guidance still online has not caught up. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and deferred the high-risk deadlines to fixed new dates. The picture as it stands:

• 2 February 2025, already in force: prohibited practices, plus the AI literacy duty. That literacy obligation applies to any organisation using AI, including small ones, and it is the item manufacturers most often have not noticed.
• 2 August 2025, already in force: obligations on providers of general-purpose AI models, which reach you indirectly through what your vendors must hand over.
• 2 August 2026, already in force: the Article 50 transparency duties, covering disclosure when a person is interacting with an AI system and labelling of synthetic content, with a grace period to 2 December 2026 for watermarking systems that already existed.
• 20 January 2027: the new Machinery Regulation (EU) 2023/1230 applies. For machine builders this is the nearest hard date, and it is not an AI deadline that anyone has postponed.
• 2 December 2027: standalone high-risk systems under Annex III, which is the route that covers worker-related AI.
• 2 August 2028: high-risk AI embedded in products already covered by EU product-safety law under Annex I.

Read that list as a manufacturer and the priority inverts from the usual commentary. The AI Act's own high-risk obligations are now years out. The Machinery Regulation is roughly a year out, and it is the instrument that will actually decide how AI in your machines gets certified.

How do the AI Act and the Machinery Regulation fit together?

They have been deliberately untangled so a machine builder does not run two parallel conformity processes for the same product. Where the overlap exists, AI embedded in machinery is largely handled through the Machinery Regulation rather than through direct AI Act obligations, with the Commission empowered to adopt delegated acts adding AI-specific health and safety requirements into that regime. The July 2026 amendments also narrowed what counts as a safety component, so an AI system used purely for non-safety purposes does not become high-risk merely by sitting inside a regulated product, unless its failure or malfunction would endanger health and safety.

The practical consequence for machine builders is concrete and near-term. Under the Machinery Regulation, machinery with safety functions that rely on self-evolving behaviour or on AI falls into the categories requiring a notified body, which removes the self-certification route many builders rely on today. Notified body capacity is finite and the queue forms early. If you are planning to ship a machine after January 2027 with any AI in a safety function, that is a 2026 procurement question, not a 2027 one.

Is every AI system in a factory high-risk?

No, and assuming otherwise is the more expensive mistake. The Act sorts systems into prohibited, high-risk, limited-risk with transparency duties, and minimal-risk. The overwhelming majority of production AI in a mid-sized manufacturer sits in the bottom tier, where the Act asks for essentially nothing beyond the AI literacy duty and whatever your own engineering standards demand.

Two routes lead into high-risk. Annex I captures AI that is, or is a safety component of, a product covered by EU harmonised legislation where that product needs third-party conformity assessment: machinery, lifts, pressure equipment, medical devices, and similar. Annex III lists standalone high-risk use cases, and for manufacturers exactly one entry usually matters, employment and worker management. If you want to work a specific system through the logic, our walkthrough of the risk framework covers the general case, and the free EU AI Act Risk Classifier gives you a first-pass answer in a few minutes. Treat either as a triage step that tells you where to spend expert time, not as a compliance verdict.

Which manufacturing AI systems are actually affected?

Working through the five use cases we see most often makes the pattern clear.

Computer vision quality inspection

Usually not high-risk. A camera grading welds, checking labels, measuring tolerances, or sorting scrap is doing quality control, and quality control is not a safety function in the machinery sense. The output is a pass, a fail, or a measurement, and rejecting a good part is a cost problem rather than a health and safety problem. Our guide to computer vision inspection for manufacturing SMEs covers the engineering side in depth.

The classification changes when the same camera does something else. If the vision system decides whether a press cycle may continue, detects a hand in a danger zone, or gates a machine's motion, it has become part of a safety function and it is now a Machinery Regulation question with a notified body attached. The hardware may be identical. The regulatory position is not. Draw that line explicitly in your specification rather than letting it be decided by a PLC integration late in the build.

Predictive maintenance

Almost always outside high-risk. A model that watches vibration, temperature, or current draw and raises a work order is generating a maintenance recommendation for a human planner, and equipment availability is a commercial objective. Nothing in the Act treats it specially. As we argued in when predictive maintenance works and when it does not, the hard problems here remain engineering problems: enough failure examples, reachable machine data, and a maintenance process that acts on the alerts.

The exception is narrow but genuine. Where the model's output feeds a protective function, for example inhibiting operation on a predicted failure of a safety-relevant subsystem, it stops being advisory and becomes part of how the machine keeps people safe.

Process anomaly detection

It depends entirely on what happens next. Anomaly detection that surfaces a drifting parameter on a dashboard for a process engineer is minimal-risk monitoring. The same detector wired to trip a line, vent a vessel, or halt a furnace is a safety function. The model is the same, the deployment decides the tier, and this is exactly the distinction the narrowed safety component definition is drawing.

Production scheduling and demand forecasting

Not high-risk under the Act, with one caveat worth stating. Planning, sequencing, and forecasting are commercial optimisation and the Act leaves them alone. But if the scheduler also allocates shifts, assigns individuals to tasks, or scores operator performance, that part of it lands in Annex III as worker management, whatever the vendor calls the module. Judge the function, not the product name on the licence.

Worker monitoring and safety-related systems

This is where a manufacturer is most likely to be genuinely high-risk, and where the risk is most often unrecognised. Annex III covers AI used in employment and worker management, including recruitment and selection, decisions on promotion or termination, task allocation based on individual behaviour or personal traits, and monitoring and evaluating performance. Systems that quietly qualify include cameras tracking operator productivity at a station, wearables scoring individuals for fatigue or ergonomic compliance, algorithms distributing overtime, and analytics ranking workers by throughput or error rate.

Two further points. Emotion recognition in the workplace is prohibited outright, not merely high-risk, and that prohibition has been in force since February 2025. Anything marketed as detecting operator stress, attention, or emotional state from video needs checking now rather than in 2027. And every one of these systems processes personal data, so the GDPR applies in full and in parallel, with works council consultation on top in Germany and much of the EU. The two frameworks interact awkwardly, which we worked through in GDPR versus the EU AI Act. In practice the GDPR and your works council will constrain a worker-monitoring project long before the AI Act does.

What questions decide the risk classification?

Five questions resolve most systems without specialist input. Ask them of every AI system you run or plan, and write down the answers.

• Is it a safety component, or part of a regulated product? Concretely: would a failure or malfunction endanger health and safety, and does the product it sits in require third-party conformity assessment? If yes to both, you are in Annex I territory and the Machinery Regulation is your primary instrument.
• Does it affect workers or their opportunities? Anything touching hiring, task allocation, promotion, evaluation, or monitoring of individuals falls under Annex III, regardless of how modest the feature looks in the product.
• Is it decision support, or an automated decision? A recommendation a qualified person reviews before acting sits differently from an output that actuates a machine or changes someone's shift with no one in between. Automation degree is the variable you most directly control.
• Is the human oversight meaningful? Not whether a person is nominally in the loop, but whether they have the information, the time, the authority, and the competence to disagree. An operator who must acknowledge forty alerts a shift is not exercising oversight, and calling the system advisory does not make it so.
• What documentation and traceability exist today? If a customer, an auditor, or an accident investigator asked which model version produced a given output, on what data it was trained, how it was validated, and who reviewed it, could you answer from a record rather than from memory?

The last question is the one that separates firms with a manageable path from firms facing a reconstruction project, and it is worth answering honestly before anything is at stake.

What should a manufacturer do in the next twelve months?

The deferred deadlines bought preparation time, not permission to ignore this. Six steps, in this order, and none of them requires a compliance department.

• Inventory every AI system, in production and planned. Include what your vendors ship inside their equipment, because a machine builder's embedded model is still AI running in your plant. For each entry record the intended purpose, whether you are provider or deployer, whether it touches a safety function, and whether it touches people. Most mid-sized manufacturers are surprised by the length of this list.
• Classify early and coarsely. Sort into clearly out of scope, clearly high-risk, and genuinely unclear. Only the third bucket needs expert time, and it is usually small. Classifying at the design stage costs a meeting, whereas classifying after deployment can mean rebuilding an interface or renegotiating a supply contract.
• Document data sources and model purpose while you still remember them. Which machines and sensors, what sampling rate, which time periods, which product variants, how labels were assigned and by whom, how the data was split. This is the artifact that is nearly impossible to reconstruct two years later, and it is also what makes your own debugging possible. Our data infrastructure assessment goes deeper on the OT side of this.
• Define human oversight deliberately. For each system, name who reviews what, with what information, on what timescale, and with what authority to override. Then check the alert volume is compatible with a human actually doing it. Write down why the oversight point sits where it does; that reasoning is half of what an assessor wants to see.
• Build evaluation and monitoring into pilots from day one. A held-out test set that reflects real production variation, performance tracked by shift, line, product variant, and material batch, and drift detection on the inputs. Manufacturing conditions change constantly, so a model validated once on last spring's data is an unmonitored liability. This costs almost nothing during a pilot and is disruptive to retrofit.
• Align vendors and internal teams. Put the questions in your purchasing process: what is the declared intended purpose, what is the system's classification and on what basis, what technical documentation and instructions for use come with it, what happens to your position if you retrain on your own data, and who is the provider of record. Getting this into the specification is far cheaper than discovering after installation that you inherited provider obligations along with the machine.

Why start with an AI readiness audit?

Because classification and value assessment are the same investigation, and running them separately wastes the effort. Deciding whether a use case is worth building requires you to state its intended purpose, the data behind it, the decision it influences, and who acts on the output. Those are precisely the inputs a risk classification needs. A manufacturer that has honestly scoped a project has already done most of the compliance triage, and one that classifies without scoping ends up documenting systems that should never have been built.

An AI Readiness Audit in a factory context runs both together: which use cases are worth pursuing given your lines and your machine data, which of them carry regulatory weight, where the classification is genuinely ambiguous, and what sequence keeps the first project small enough to learn from. We wrote about how that assessment differs for mid-sized manufacturing companies specifically, where brownfield equipment and OT data access dominate the picture. Where a system does land in the high-risk tier, our EU AI Act compliance work takes it from classification through documentation, oversight design, and monitoring, alongside your notified body and legal advisors rather than in place of them.

The manufacturers who will handle this well are not the ones with the largest compliance budgets. They are the ones who wrote down what their systems do, kept records of the data they trained on, and thought about human oversight while the design was still on a whiteboard. That work pays for itself in engineering quality whether or not a single system turns out to be high-risk.

Frequently asked questions

Does the EU AI Act apply to small manufacturers?

Yes. The Act has no small-company exemption, though obligations scale with risk rather than headcount, and there are simplified documentation routes for SMEs with high-risk systems. In practice a mid-sized manufacturer with no worker-monitoring AI and no AI in safety functions faces only the AI literacy duty and, where relevant, the transparency rules. That is a genuinely light load, but it is not zero, and it starts with knowing what you run.

Is my computer vision quality inspection system high-risk?

Almost certainly not, if it inspects parts and its output is a quality decision. It becomes high-risk if the same system performs a safety function, for example detecting a person in a hazard zone or gating machine motion, in a machine that requires third-party conformity assessment. The deciding factor is whether a malfunction would endanger health and safety, not the sophistication of the model.

What happens if we buy AI from a vendor instead of building it?

You are normally a deployer, which is the lighter role, but not an empty one: use the system for its declared intended purpose, assign competent human oversight, keep the generated logs, and inform workers where a system affects them. You also inherit a dependency, because you cannot demonstrate compliance without documentation your vendor holds. Ask for it before you sign, and be aware that retraining the model on your own data or using it outside its intended purpose can make you the provider.

Did the 2026 omnibus mean we can postpone this work?

It moved the high-risk deadlines to December 2027 and August 2028, so the legal pressure eased. The preparation work did not, for two reasons. The Machinery Regulation applies from 20 January 2027 and was not deferred, and notified body capacity for AI-bearing safety functions is limited. And the items that take longest, data lineage, evaluation harnesses, and monitoring, are the ones that must be built into systems as they are developed rather than added to systems already running.