AI Act for machine builders: AI in safety functions, the Digital Omnibus and the 2028 date

When AI makes a machine high-risk under the AI Act

AI in a machine makes it a high-risk AI case under the AI Act when the AI system performs a safety function and the machine has to pass a third-party conformity assessment, for example a camera system that detects people in a danger zone and stops the machine using a trained neural network. Vision inspection of product quality, predictive maintenance or an operator assistant are not safety functions in that sense. Since the Digital Omnibus on AI of July 2026, the detailed requirements for machinery come through the Machinery Regulation: the Commission is to write them into its Annex III by delegated acts that should apply by 2 August 2028.

We wrote this for managing directors and heads of development at machine and plant builders who add AI to their products, and for the engineers who train the models. The legal frame comes first, in plain words and with the article numbers, then three examples, then what it means for development data and the GPU servers that train the models. It is general information on EU law as of October 2026, not legal advice: your legal counsel and your notified body confirm how it applies to a given machine. Our article on the EU AI Act for companies using LLMs covers the deployer side, and our guide to AI Act and fine-tuning the providers of general-purpose models; here the subject is AI built into machines.

Five terms in plain words

AI system. Article 3(1) of the AI Act defines it as "a machine-based system that is designed to operate with varying levels of autonomy" and that "infers, from the input it receives, how to generate outputs". A trained neural network that classifies camera images is one; a fixed rule in a PLC program is not.

Safety component. Article 3(14), as amended, describes "a component of a product or of an AI system which fulfils a safety function for that product or AI system", or a component "the failure or malfunctioning of which endangers the health and safety of persons or property". The amended text adds that a component fulfils a safety function "where its intended purpose is to prevent or mitigate risks to health and safety of persons or property".

Provider. The company that develops an AI system or has it developed and places it on the market under its own name. A machine builder who ships its own AI with the machine is the provider of that AI system.

Third-party conformity assessment. A notified body, an organisation designated by a Member State, checks the product before it may be placed on the market. For machinery in Annex I Part A of the Machinery Regulation, Article 25(2) allows three routes: EU type-examination followed by conformity to type, full quality assurance, or unit verification. Internal production control is not among them.

Self-evolving behaviour. The Machinery Regulation's term for systems that use machine learning. Its recital 55 says the third-party provisions for safety software "should only apply to systems with a fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions", and not to "software incapable of learning or evolving, and programmed only to execute certain automated functions".

The legal chain from the AI Act to the Machinery Regulation

Article 6(1) of the AI Act makes an AI system high-risk when two conditions are met. It is "intended to be used as a safety component of a product, or the AI system is itself a product" covered by the legislation listed in Annex I, and that product "is required to undergo a third-party conformity assessment". Regulation (EU) 2023/1230 on machinery supplies the second condition: its recital 54 explains that "systems with self-evolving behaviour ensuring safety functions should be included in Annex I" because of "data dependency, opacity, autonomy and connectivity", and that their conformity assessment "should be carried out by a third party, whether or not the safety component has been placed independently on the market". Machinery that embeds a safety component already certified by a third party need not be re-certified "solely on the basis of the embedding of that system".

The Digital Omnibus on AI changed where the requirements sit. Regulation (EU) 2026/1744 of 8 July 2026, in force since 27 July 2026, moved the Machinery Regulation from Section A to Section B of Annex I of the AI Act, where the Commission's AI Act Service Desk now lists it as a new entry. For products in Section B, the amended Article 2(2) states that "only Article 6(1), Article 60a and Articles 102 to 112 shall apply". The classification as high-risk stays; the AI Act's own chapter of requirements does not apply directly.

Recital 42 of Regulation (EU) 2026/1744 explains what replaces it. The Commission "should be required to adopt delegated acts amending Annex III to Regulation (EU) 2023/1230", the annex with the essential health and safety requirements, so that they reflect the high-risk requirements of Chapter III, Section 2 of the AI Act and its Articles 17, 19, 72 and 73, and "those delegated acts should apply by 2 August 2028". Until harmonised standards or common specifications for AI exist under the Machinery Regulation, the recital lets manufacturers rely on those adopted under the AI Act. The details are in the operative article of Regulation (EU) 2026/1744 that amends the Machinery Regulation; check its wording on EUR-Lex before relying on them.

AI Act consolidated as at 27 July 2026 on the Commission's AI Act Service Desk; Regulation (EU) 2026/1744 on EUR-Lex; Commission page on machinery; all read 25 October 2026. Machinery placed on the market before 20 January 2027 follows Directive 2006/42/EC.

Three examples from machine building

Our reading of AI Act Art. 6(1) and recitals 54 and 55 of Regulation (EU) 2023/1230, for illustration; the classification of a real machine is confirmed by your legal counsel and notified body.

Person detection in a danger zone. A trained network that recognises people in camera images and triggers a stop performs a safety function. The open question in practice is the word "self-evolving": whether a network trained before delivery and frozen in the machine counts, or only one that keeps learning in operation. Recital 55 contrasts machine-learning systems with software "incapable of learning or evolving", and the delegated acts, guidance and notified bodies will settle the borderline. Plan development as if third-party assessment applies until your notified body says otherwise.

Surface inspection. A model that sorts out scratched or dented parts protects quality, not people. The AI Act's high-risk classification under Article 6(1) does not reach it, and our guide to visual inspection AI without data scientists covers how such systems are built. The machine still has to meet the Machinery Regulation's essential requirements as a whole.

Predictive maintenance. A model that forecasts wear and schedules service has no safety function either, as long as it does not take over a protective role. Our guide to predictive maintenance covers when such models need a GPU at all.

Which obligations machine builders should expect

The delegated acts are to reflect Chapter III, Section 2 of the AI Act. That section's articles are titled Compliance with the requirements (Article 8), Risk management system (9), Data and data governance (10), Technical documentation (11), Record-keeping (12), Transparency and provision of information to deployers (13), Human oversight (14) and Accuracy, robustness and cybersecurity (15); recital 42 adds the quality management system (17), automatically generated logs (19), post-market monitoring (72) and the reporting of serious incidents (73). How exactly they will read in the Machinery Regulation is up to the delegated acts. The AI Act text shows what to expect.

Data governance. Article 10(2) lists, among other things, "the relevant design choices", "data collection processes and the origin of data", "data-preparation processing operations, such as annotation, labelling, cleaning", "examination in view of possible biases" and "the identification of relevant data gaps or shortcomings". Article 10(3) asks for data sets that are "relevant, sufficiently representative, and to the best extent possible, free of errors".

Technical documentation. Annex IV, which Article 11 refers to, asks for "the training data sets used", "information about their provenance, scope and main characteristics", "how the data was obtained and selected", the labelling and cleaning methods, the validation and testing procedures with "test logs and all test reports dated and signed by the responsible persons", and "the computational resources used to develop, train, test and validate the AI system".

Logs in operation. Article 12(1) requires that high-risk AI systems "technically allow for the automatic recording of events (logs) over the lifetime of the system". That is a design requirement for the machine's controller, not for the training server.

Article 63(1), as amended, lets SMEs, including start-ups, comply with certain elements of the quality management system in a simplified manner. Article 63 is not among the articles that apply directly to Section B products, so whether a similar simplification reaches machinery depends on the delegated acts.

We build GPU servers for training vision and control models and set up the training environment through our Private AI/ML service; send us the model types, image volumes and the number of developers, and our team replies with a configuration.

Development data and the training server

Most of what the documentation asks for comes from the development process, not from the machine: which images were collected on which machines, who labelled them by which rules, which version of the data set trained which version of the model, on which hardware and software, and with which test results. A company that trains its models on a server it controls can keep that chain complete. With a cloud service or an external developer, the same records have to be secured by contract.

Reproducibility is the technical side of it. PyTorch's documentation states that completely reproducible results cannot be expected across "PyTorch releases, individual commits, or different platforms", and that results "may not be reproducible between CPU and GPU executions, even when using identical seeds". It offers torch.use_deterministic_algorithms and warns that "Deterministic operations are often slower than nondeterministic operations". For a safety model that has to be retrained after a field incident, or retested after a software update, it helps to keep the same GPU type and the same container images for the life of the product line, which an in-house server makes simple.

Training images from customer sites raise a further point. Pictures of a danger zone show people; where they can be identified, the images are personal data under the GDPR, and the data from a customer's plant can fall under that customer's confidentiality terms. Storing and labelling them on your own hardware keeps both questions within the company; your data protection officer confirms retention and access.

Reference configurations on our AI servers page; power by our estimate (cards, processors, plus 15 per cent for the rest of the server), as in our guide to GPU servers for training vision models; to be confirmed by a measurement on the delivered system.

Detection models are small: our guide to a GPU server for training vision models lists YOLO11x at 56.9 million parameters, so the number of cards sets how many experiments run side by side. The entry server with two NVIDIA RTX PRO 6000 Blackwell Server Edition cards, two AMD EPYC processors, 384 GB of DDR5 ECC memory and two NVMe drives suits one or two developers; the inference node with four cards and 768 GB a team; the training node with eight H200 NVL, NVLink bridges, 2.3 TB of memory and 400G networking is for models that need all cards at once. The server stands in a server room: two cards fit one 230 V 16 A feed, four need 32 A or three-phase, and eight need three-phase, as our guide to GPU server power on 16 A, 32 A and three-phase feeds explains.

Notes for the development and IT team

1. Version everything. Data set versions with labelling rules, training code, container images, driver and CUDA versions, and the hardware of every training run, stored with the model version they produced.
2. Deterministic runs where needed. Seed every run and switch on deterministic algorithms for the release training and the regression tests, accepting the slower runs PyTorch warns about.
3. Test sets under lock. Keep the validation and test data sets separate from training data, with read-only access, so a test result can be repeated years later.
4. Signed test reports. Annex IV asks for test logs and reports "dated and signed by the responsible persons"; generate them from the training pipeline rather than by hand.
5. Licences. Check the licence of every model and library you build on before it goes into a product; our guide to the Ultralytics YOLO licence covers one common case.
6. Robot and simulation work. Policies trained in simulation follow the same logic; our guide to a GPU server for robotics with Isaac Sim describes what to keep with every run.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We build training servers with two, four or eight cards to order, with RTX PRO 6000 Server Edition or H200 NVL, assembled and tested before delivery, delivered anywhere in the EU on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. Our Private AI/ML service, with our engineering partner Vixen.UNO, sets up the training environment, data set versioning and the model registry on your server. We do not provide legal advice or conformity assessment; your notified body and legal counsel do.

FAQ