AI-powered machine risk assessment module in Safety Software: a new function for engineers

The AI-powered machine risk assessment module in Safety Software is built around one practical truth: a machine risk assessment starts with a good description of how the machine is actually meant to work. The form is only a tool. Before a team starts entering hazards, estimating risk and selecting protective measures, it has to define the intended use, the way the machine is used, reasonably foreseeable misuse, the limits of the machine, life phases and the tasks performed by each exposed person.

Skip that context and the assessment quickly turns into a pile of generic labels: “moving parts”, “electrical energy”, “sharp edges”, “high temperature”. Those labels may point to hazard sources, but they are not yet real risk scenarios.

That is why we are developing a new AI function in Safety Software. Not an approval machine. Not a shortcut to a declaration of conformity. Not a substitute for the competence of the design team, the integrator or the producer.

The module is there to help engineers move from unstructured information to a first draft for review: something a competent person can check, challenge, edit and use consciously in the next steps of the risk assessment.

AI-powered machine risk assessment module as support for ISO 12100

Risk assessment according to ISO 12100 is a structured process. First, the team defines the limits of the machine. Then it identifies hazards and the related hazardous situations and hazardous events. Only after that does the team estimate risk, evaluate it, choose protective measures and review the risk again after risk reduction.

The AI-powered machine risk assessment module in Safety Software supports selected parts of that process, but it does not close them. It can prepare proposed wording, an alternative description, a checklist of issues to verify or a draft scenario. It does not state that the machine is safe. It does not approve residual risk. It does not decide on its own whether the selected protective measures meet the requirements of type-B or type-C standards.

The final decision stays with a human.

That is a design principle, not a disclaimer hidden in small print. In technical documentation, it is not enough that a field is filled in. What matters is whether the entry matches the real machine, describes the right scenario and can be defended during an audit, after a design change or after an incident on the machine.

AI-powered machine risk assessment module for intended use and reasonably foreseeable misuse

One of the first areas supported by the module is the description of intended use and reasonably foreseeable misuse.

This is the starting line for any serious risk assessment. If the description is too broad, for example “the machine is used for processing components”, the rest of the analysis loses precision fast. That kind of statement says almost nothing. Who operates the machine? In which mode? With which material? Under which conditions? With which limits?

AI can prepare a first draft based on the information provided by the user. The team can then extend it, narrow it down or correct it.

The module can help organise, among other things:

• the process for which the machine is intended;
• the expected user profile;
• the required operator competence;
• machine operating modes;
• types of materials, products or tools covered by the process;
• user behaviour that can be reasonably foreseen;
• use that must be excluded by design or described in the instructions.

This description is not marketing copy. It is the base layer for hazard identification and for the later description of risk scenarios.

Limits of the machine without dangerous shortcuts

In ISO 12100, defining the limits of the machine is one of the first steps. This is not just about the footprint of the machine or the physical outline of the workstation. It is a formal description of the conditions in which the machine is intended to operate and in which the team performs the risk assessment.

The limits of the machine may include use limits, space limits, time limits and other limits resulting from the process, the work environment or the planned operation.

The module can prepare a structured proposal for these limits, for example:

• use limits — intended use, expected users, operating modes and reasonably foreseeable misuse;
• space limits — installation location, working zones, hazard zones, access to the machine, range of movement and interfaces with other machines;
• time limits — expected service life, work cycles, maintenance intervals, component wear and operating time of elements;
• other limits — environmental conditions, temperature, humidity, dust, power supply, media, cleaning, material type and installation requirements.

Well-described limits of the machine bring order to the rest of the assessment. They stop hazard scenarios from floating in the air, disconnected from how the machine is really used.

Hazard scenarios: from hazard source to concrete description

In a risk assessment, identifying a hazard source is not enough. “Moving parts”, “sharp edge”, “high temperature” or “stored energy” are only the opening move. The team still has to describe who is exposed, when exposure occurs, during which task and what harm may result.

A good scenario should include, as a minimum:

• the exposed person;
• the task performed by that person;
• the life phase of the machine;
• the zone where exposure occurs;
• the hazard source;
• the hazardous situation, the hazardous event, or both;
• the possible harm.

The new module can prepare draft scenarios based on the context of the assessment and the data already available in the system. This is not loose text generated outside the documentation structure. The scenario must fit the next steps: risk estimation, selection of protective measures, risk reduction and description of residual risk.

AI can propose content, but the user still has to verify whether the scenario matches the real machine. The design team knows whether the situation exists during normal operation, adjustment, cleaning, fault clearing, maintenance or transport of the machine.

A draft for review, not a ready-to-close entry

In Safety Software, AI proposals are working material. The user can accept them, edit them or reject them. That approach limits the risk of copying text into technical documentation without thinking.

AI can help the team start faster. It cannot remove the need for review. In machine risk assessment, every description should match the actual design, the intended use and the possible behaviour of users.

A good AI proposal should be:

• specific;
• editable;
• linked to the machine being assessed;
• consistent with the language of risk assessment;
• aligned with the ISO 12100 structure;
• useful for technical review.

The value is not in the generated text itself. The value is that the team can reach the engineering judgement stage faster. Is the scenario real? Does it describe the correct exposed person? Does the task occur in that life phase of the machine? Is the possible harm described correctly? Does the protective measure actually reduce the part of the risk identified in the assessment?

A human still has to ask those questions.

Consistency in technical documentation and the trace of decisions

Machine technical documentation often mixes concepts that should stay separate. A hazard source is treated like a full scenario. A hazardous situation is blended with a hazardous event. A protective measure appears without showing which part of the risk it reduces. Residual risk is described with one word or a colour.

The module can help keep the language more disciplined. It can propose a structured description, flag a missing scenario element or help separate terms that play different roles in the documentation.

This becomes especially important in larger assessments. The more tasks, life phases, zones, hazards and protective measures you have, the harder it is to keep the wording consistent. AI can help, provided it works as a process assistant, not as the independent author of the final technical documentation.

The direction in Safety Software is clear: a risk assessment should show not only the result, but also the path to the decision. Who was exposed? Which task was performed? What hazardous situation could occur? What hazardous event could lead to harm? Which protective measure was applied? What remained after risk reduction?

Without that trace of decisions, the risk assessment loses its evidential value.

An AI assistant in day-to-day risk assessment work

We are developing the new module as an assistant for risk assessment work. In practical terms, that means several concrete uses.

First, the user can prepare a working description of the machine, its use and the limits of the machine faster.

Second, AI can support the creation of hazard scenarios for specific tasks, life phases and exposed persons.

Third, the module can help organise the language of the documentation so that the hazard source, hazardous situation, hazardous event, possible harm, protective measure and residual risk are kept apart.

Fourth, AI can support a consistency review of prepared descriptions. Not as the final auditor. As a tool that helps detect missing or overly generic elements.

This is practical support for teams that do not want to build a risk assessment as a static table. They want documentation that shows the logic behind design decisions.

AI does not take over the responsibility of the producer

The module can speed up work and improve the consistency of technical documentation, but it does not take over the responsibility of the producer, integrator or design team.

AI does not see the whole machine the way a mechanical designer, controls engineer, process engineer, safety specialist or maintenance technician sees it. It does not know every operating condition. It does not observe the real bypasses and workarounds used by operators. It does not replace measurement, validation or verification of protective measures.

It also does not decide on its own whether the requirements of the Machinery Regulation, type-B standards or type-C standards have been met.

That is why Safety Software treats AI as a support tool. AI helps prepare material for a decision. The decision is made by a human.

A new function, the same development direction

Safety Software is built around one rule: risk assessment should not be a dead table. It should show the team’s thinking, the risk reduction applied and the reason behind the decision.

The module fits that direction. It does not shorten the process by skipping important steps. It shortens the route from messy information to working material that can be reviewed properly.

This matters most for complex machines and lines, where the number of scenarios grows fast. In those projects, the difficult part is not only risk estimation. It is also keeping descriptions, tasks, hazards, protective measures and residual risk consistent with one another.

AI can support that consistency, as long as it remains an assistant.

Summary: AI supports risk assessment, but does not close it

The new module in Safety Software helps prepare machine risk assessment elements faster and more consistently.

It can support descriptions of intended use, reasonably foreseeable misuse, the limits of the machine and hazard scenarios. It can help organise the language of technical documentation and prepare material for deeper analysis.

It does not replace the engineer. It does not approve risk. It does not perform conformity assessment. It does not release the producer from responsibility for technical documentation and machine safety.

Used well, AI is not an oracle. It is an assistant that helps the team reach a better-structured decision faster.

In Safety Software, AI does not close the risk assessment. It helps run it more consistently, faster and with a clearer trace of decisions.

Example: AI-powered machine risk assessment module proposals for functional testing and trials

In practice, the module can support work at the level of a specific task. If the team is analysing the life phase covering functional testing and trials, Safety Software can prepare proposed hazard scenarios linked to that task.

Such a proposal is not a finished risk assessment. It is a structured draft for review, with fields needed for further analysis: hazard source, possible harm, hazard zone and scenario description. The user can check whether the description matches the real machine, correct it and only then save it into the assessment.

For example, for a task related to functional testing, the module may propose a scenario involving moving elements in the container handling and positioning zone. The description can include the exposed person, the place of exposure, the hazard source and possible harm such as drawing-in, entanglement or impact.

A second proposal may relate to a high-pressure system at the filling nozzle, dosing hose or connection points. In that scenario, possible harm may include injection of pressurised medium or impact from an ejected component or material.

This stage is where the practical value appears. AI does not make the decision for the team. It helps prepare a working scenario description that an engineer can verify technically: whether the zone really exists, whether the exposed person performs that task, whether the possible harm is correctly selected and whether the scenario duplicates an existing item in the assessment.

As a result, the risk assessment does not start from an empty table. The team receives material for review, but the decision still stays with a human.