AI in machine risk assessment: help or false confidence?

AI has moved fast into spaces once ruled by Excel, checklists, and documents copied from project to project. AI in machine risk assessment is the latest temptation: enter a machine name, add a few generic facts, and seconds later you get a polished table with hazard descriptions, consequences, protective measures, and residual risk. It looks professional. That is exactly why it is dangerous.

A nice-looking table is not a risk assessment. Not under ISO 12100. A real machine risk assessment is not about filling cells with technical language. Its value comes from something much harder: whether you can reconstruct the thinking that led to specific design decisions. That is the difference between a document and a process.

If you want the baseline before bringing AI anywhere near the workflow, review machine risk assessment under ISO 12100 and the practical obligations in Machinery Regulation (EU) 2023/1230.

AI in machine risk assessment: the old problem, accelerated

For years, weak assessments followed the same pattern: Excel file, list of hazards, generic consequences, standard protective measures, and a final column showing risk reduction as if by magic. The document existed. The boxes were filled. The colors looked right. What was often missing was the core logic required by ISO 12100: the real link between a hazard, the human task, the life phases of the machine, the hazardous situation, and the hazardous event.

Excel was never the real problem. It was just very easy to turn Excel into a fake process. Write moving parts, crushing, fixed guard, operator instruction, training, and the document starts to look familiar, technical, serious. But a familiar layout does not prove that anyone actually assessed risk.

Now AI lets people make the same mistake faster, more smoothly, and more convincingly. A weak spreadsheet used to give itself away. It looked repetitive, thin, assembled from canned phrases. An AI-generated table may look mature, coherent, and complete. It can create the impression that somebody really analyzed the machine. But the impression of analysis is still not analysis.

That is why the risk is bigger now. AI does not create the problem from nothing. It amplifies an old one: confusing the document with the process.

ISO 12100 does not start with hazards

One of the most common mistakes in machine risk assessment is starting with the question: what hazards does this machine have? On the surface, it sounds reasonable. There are drives, so there are mechanical hazards. There is electrical supply, so there are electrical hazards. There is pneumatic energy, so there is stored energy. There are hot parts, so there is burn risk. The table grows quickly.

Useful? Yes. Sufficient? No.

ISO 12100 does not ask you to look at a machine as a static collection of dangerous parts. It asks you to look at the machine in relation to the people who transport it, install it, commission it, operate it, adjust it, clean it, maintain it, repair it, diagnose it, carry out changeover, use manual mode, and eventually decommission it. In other words, the starting point is not a catalog of hazard labels. The starting point is exposure during real work.

A hazard by itself does not describe risk. A sharp edge is a hazard. Risk appears when somebody can contact it. A moving mechanism is a source of energy. Risk depends on who is near it, when, why, and under what conditions. A mechanism may be fully isolated during normal operation and become critical during cleaning, jam clearing, setup, or testing in manual mode.

The better question is this: which specific person, during which task, in which life phase, and under what conditions may end up in a hazardous situation?

Only then do the next questions make sense:

• What can trigger the hazardous event?
• Unexpected start-up?
• Loss of stability?
• Access to moving parts?
• Control logic failure?
• Residual energy?
• Material jam?
• Wrong adjustment?
• Poor visibility?
• Badly designed access?
• A normal task wrongly treated as a service task?

That is where machine risk assessment actually starts.

Task-based and event-based thinking both matter

Weak assessments often force everything into one neat line: task, hazardous situation, hazardous event, measure, done. Real machines do not always behave that neatly.

Sometimes the task is the right starting point: cleaning, adjustment, jam clearing, changeover, maintenance. Sometimes the hazardous event is the right starting point: hose rupture, unexpected start-up, falling load, control system fault, power loss, release of stored energy, fire, or loss of stability. Sometimes the event creates the hazardous situation. Sometimes both develop together.

A robust process has to handle both directions of thinking. That matters because AI loves tidy linear structures. It will happily produce arrows, columns, and smooth logic. Real machines, real failures, and real human behavior are often messier than that.

AI in machine risk assessment needs context, or it guesses

If a user enters a prompt such as prepare a risk assessment for a packaging machine, AI will usually return something that looks plausible. Mechanical hazards, electrical hazards, ergonomic issues, maybe noise, maybe hot surfaces, maybe pneumatic energy, and a few generic protective measures. At first glance it may even look competent.

But that answer is not an assessment of a specific machine. It is a statistically probable description of a typical machine. The gap between those two things is enormous.

A real machine has specific limits of the machine, specific access points, specific sequences of movement, specific stopping times, specific maintenance tasks, and specific operating constraints. It sits in a real factory, under real production pressure, with real workarounds that appear when design ignores reality.

AI does not know that the operator has to reach deeper than the design assumed. It does not know that the panel is on the wrong side, so the operator watches the machine from an unplanned position. It does not know that the guard is heavy, so after two weeks people leave it open. It does not know that the cleaning method in the instruction is ignored because it takes too long. It does not know that the instruction assumes two people while the real task is done by one. It does not know that changeover happens six times per shift, not once in a while. It does not know that a fault the designer considered unlikely is routine for maintenance.

This is why AI without context is dangerously persuasive. It is often right at the level of generality. Machine risk assessment is rarely decided at the level of generality. It is decided in the detail: this access, this task, this life phase, this hazardous situation, this hazardous event, this sequence, this human behavior.

Used well, AI can help ask good questions:

• Did you consider cleaning?
• Can the operator reach the hazardous zone during jam clearing?
• Is this task limited to maintenance, or does it happen during normal production?
• Is risk reduction achieved by inherently safe design measures, by protective measures, or only by information for use?
• Does the selected measure create a new problem that will encourage bypassing?

Used badly, AI answers those questions without machine-specific facts. Then it is not analyzing. It is guessing. In machine safety, guessing only looks elegant until the first accident.

A prompt is not a methodology

A better prompt can improve the output. That part is true. You can tell AI to consider ISO 12100, all life phases, reasonably foreseeable misuse, risk estimation, risk evaluation, and risk reduction. You can ask for fifteen columns, sharper wording, and cleaner structure.

What you cannot do is turn missing facts into real engineering by writing a smarter prompt.

AI does not add machine facts it does not know. It can infer them, average them, or assume a typical configuration. That is exactly the problem. The most important risks are often hidden in the non-typical details: an access point out of sight from the control position, a rotating part that coasts after stop, a cleaning step that requires guard removal, a maintenance point treated as if it were not a working position, a machine installed in dust, moisture, cold, vibration, or between other machines that change the real access conditions.

A prompt is not ISO 12100. A prompt is not a site walk. A prompt is not observation of an operator. A prompt is not a design decision. And a prompt is definitely not responsibility.

The decision trail matters more than the table

Every serious machine risk assessment should be reproducible. Not just readable. Reproducible.

That means somebody reviewing it later should be able to understand why a given risk was estimated in a given way, why a hazardous situation was considered relevant, why a certain severity was assumed, why a certain exposure was judged likely, why one protective measure was selected, why another was rejected, and why the residual risk was considered acceptable.

That is the decision trail. Without it, the document is hard to defend in an audit, a redesign, an incident investigation, or a dispute after delivery. Saying AI generated it is not an argument. Saying it looked fine in Excel was never an argument either.

This is also where the ISO 12100 hierarchy matters. Risk reduction is not supposed to come from whatever sounds convenient in the last column. First ask whether the hazard can be eliminated or reduced by inherently safe design measures. Then consider protective measures. Only then move to information for use, warnings, procedures, training, and personal protective equipment.

In weak assessments the order is often reversed. The row gets closed with guard, instruction, training, LOTO, sign, and everybody moves on. But did anyone verify whether the guard makes the task so awkward that people will bypass it? Is LOTO realistic for a task performed several times per hour? Is training actually a valid risk reduction measure here, or just a way of shifting the burden to the operator? Does the instruction solve the design problem, or merely describe it?

If the table shows a lower residual risk but the machine still forces the person into the same exposure, the risk has not been meaningfully reduced. The spreadsheet may look better. Reality has not changed.

A repeatable process is what prevents this kind of drift. The structure should be consistent even when machines differ: limits of the machine, life phases, tasks, hazardous situations and or hazardous events, hazards, possible harm, risk estimation, risk evaluation, risk reduction, residual risk, and justification. Without that structure, outcomes start depending on the mood, habits, and prompt style of whoever fills in the form.

That is how you end up in elegant fog: more text, better wording, and still no clear reasoning.

Example: a slitter, a fork sensor, and the smart-sounding wrong answer

Take a simple real-world example. On a slitter, a fork sensor detects web position. During width changeover, the operator must reposition the fork sensor. The problem is that the adjustment point sits inside the hazardous zone. To move the sensor, the operator enters an area with moving rollers, rotating shafts, in-running nips, tensioned material, or cutting elements.

What does a generic AI answer usually look like? Something like this: operator access to hazardous zone during changeover, possible injury by entanglement, crushing, cutting; apply LOTO, train the operator, mark the zone, provide instructions, use guards, provide emergency stop.

It sounds competent. It may even be formally tidy. It may also be engineering nonsense.

The correct question is not how to describe the risk of entering the zone. The correct question is why the operator has to enter the hazardous zone at all to perform a normal changeover.

If width changeover is a normal, repeated production task, you cannot treat it like an exceptional service intervention and hide behind LOTO. You have to ask harder questions:

• Is the sensor adjustment a normal operator task or a maintenance task?
• How often does changeover occur?
• Must the machine be fully stopped for the adjustment?
• Is observation of web position needed during setup?
• Does the task happen with energy removed, with retained energy, in manual mode, or during test movement?
• Does access require removal or defeat of a guard?
• Is unexpected start-up possible?
• Can the sensor be adjusted from outside the hazardous zone?
• Could the support, guide, scale, recipe positioning, or sensing method be redesigned?

Now you are doing real machine risk assessment.

The root cause may be poor design of the adjustment itself. The better answer may be to relocate the adjustment outside the guard, provide external positioning, add a mechanical scale, use stored setup positions, or change the sensing concept entirely. Only if access cannot reasonably be eliminated should you move down the hierarchy toward interlocking, controlled setup conditions, limited speed, hold-to-run control, an enabling device, safe stop, energy isolation, and then information for use.

Sequence matters. AI often jumps straight to procedure. ISO 12100 asks first whether design can remove the need for exposure.

AI in machine risk assessment as support, not substitution

This does not mean AI has no place here. It does. The useful role is narrow but real.

AI can support an engineer by:

• checking completeness against a structured process,
• highlighting missing life phases or tasks,
• suggesting overlooked hazardous situations or hazardous events,
• spotting inconsistencies between the selected measure and the claimed residual risk,
• helping write clearer justifications,
• comparing scenarios across similar projects without blindly copying them.

What AI should not become is the author of responsibility. Responsibility stays with the manufacturer, designer, integrator, engineering team, and the person signing the documentation. They must be able to show that the assessment is not just text, but the result of a deliberate process.

AI can write apply an interlocking guard with locking. A human still has to answer: why this measure, for which access, with what stopping time, for which safety function, at what entry frequency, with what effect on cleaning, and with what risk of bypassing?

AI can write train the operator. A human still has to check whether training is actually relevant. If the design forces daily contact with the hazard, the real problem is not lack of training. The real problem is the design.

AI can write use LOTO. A human still has to ask whether this is monthly maintenance or jam clearing several times per shift. If no one will realistically perform full energy isolation for that task, then the cell contains a wish, not a control.

AI in a safety function is a different league

There is one more line that must stay very clear. Using AI to support machine risk assessment is one thing. Using AI or machine learning inside the machine itself, especially in a safety function, is a completely different matter.

Machinery Regulation (EU) 2023/1230 requires the manufacturer to carry out a risk assessment to determine the applicable essential health and safety requirements and the measures needed for risk reduction. That duty belongs to the manufacturer, not to a language model.

The regulation also treats safety components with fully or partially self-evolving behavior using machine learning approaches that ensure safety functions, and machinery embedding such systems with respect to those systems, as a special category subject to third-party conformity assessment. That is not a stylistic choice. It reflects a hard engineering truth: a safety function cannot rest on vague confidence that the algorithm usually works.

The AI Act reinforces the same logic. An AI system can be high-risk when it is used as a safety component of a product covered by relevant Union harmonization legislation and that product requires third-party conformity assessment. For high-risk systems, the AI Act requires a lifecycle risk management process, consideration of intended use and reasonably foreseeable misuse, human oversight, accuracy, robustness, and cybersecurity.

The key point is simple. In machine safety, 95 percent accuracy is not the interesting number. The interesting question is what happens in the remaining 5 percent. What happens when the model does not detect a person? What happens when the input data shift because of dirt, lighting, vibration, temperature, unusual material, sensor failure, or operator behavior nobody expected? What happens if the system changes behavior after deployment?

Those are not marketing questions. They are engineering questions. And when AI is part of a safety function, they become conformity assessment questions too.

Final point: use AI to strengthen the process, not replace it

There are two dangerous illusions in this field. First: AI generated a document, so we have a machine risk assessment. Second: AI performs well in tests, so it can take over a safety function. Both are risky shortcuts.

The practical rule is straightforward. Use AI to challenge completeness, improve clarity, and support a consistent process. Do not use it as a substitute for knowing the machine, observing the task, understanding the life phases, identifying reasonably foreseeable misuse, and making accountable design decisions.

Machine safety is not about producing polished paperwork. It is about showing, step by step, why a hazard exists, how a hazardous situation can arise, what hazardous event can lead to harm, what risk reduction measure was selected, and why the residual risk is what it is. If that reasoning is missing, the document may still look impressive. It is still just a document.

And in this field, elegant fog lasts only until the first accident.