Does the EU AI Act replace the CE marking I already do?

No. For a product already covered by Union harmonisation legislation (machinery, medical devices, radio equipment, toys, and the other sectors listed in Annex I of the AI Act), the AI requirements are integrated into the conformity assessment you already run. You keep one technical file, one declaration of conformity and one CE marking. The AI Act adds requirements; it does not create a second, parallel marking.

When does an AI system count as high-risk?

Two routes lead to high-risk. First, the AI system is a product, or a safety component of a product, covered by the Union harmonisation legislation listed in Annex I and that product must undergo a third-party conformity assessment. Second, the system falls into one of the use cases listed in Annex III (biometrics, critical infrastructure, employment, essential services, and others). For a product engineering office, the first route is the one that matters most.

What is the difference between a provider and a deployer?

The provider develops the AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark. The deployer uses an AI system under its own authority in a professional context. A manufacturer that embeds AI in its product is normally the provider of that AI system and carries the bulk of the obligations. The same company can be a deployer of someone else's AI for an internal task.

Do prohibited AI practices affect ordinary products?

Rarely, but you must check. The prohibited practices target manipulative techniques, social scoring, untargeted scraping of facial images, and a short list of other uses. Most embedded product features (predictive maintenance, anomaly detection, vision quality control) fall well outside this list. The point is to confirm, in the design phase, that no feature drifts into a prohibited category.

Does the AI Act apply to a simple rule-based feature?

Not necessarily. The Regulation defines an AI system around inference, autonomy and adaptiveness. A fixed lookup table or a deterministic threshold is usually not an AI system in the legal sense. A machine-learning model that infers outputs from inputs is. Document your reasoning either way, because the classification drives whether the rest of the obligations apply.

How does the AI Act interact with the Cyber Resilience Act?

They overlap on cybersecurity. A high-risk AI system must be robust against attempts to alter its use or performance, and a product with digital elements must meet the CRA essential cybersecurity requirements. The Regulation is built so that meeting the horizontal cybersecurity rules can support the AI Act robustness requirement, avoiding duplicate evidence. Plan one coherent security case that serves both.

When do the obligations actually start?

The AI Act entered into force in 2024 and applies in phases. The prohibitions and AI literacy duties apply first, then the rules for general-purpose AI models, then the bulk of the high-risk regime, with the longest transition reserved for high-risk AI embedded in products already covered by Annex I legislation. Treat the dates as staggered and confirm the exact day for your case against the official text, which is the authoritative source.

EU AI Act: product compliance for manufacturers

Author Hugues Orgitello Last updated 28 May 2026 ~11 min read

Guide · AI Act from a product compliance angle

When a manufacturer adds a learning model to an already-regulated product, a vision sensor that classifies parts, a predictive controller, a diagnostic algorithm in a medical device, the question is rarely "is this AI good enough". It is "what does this do to my CE file". Regulation 2024/1689 answers that question in a way that is friendlier to product engineers than it first appears, because it was designed to slot into the existing New Legislative Framework rather than to stand beside it. This page reads the AI Act the way a bureau d'etudes reads any product regulation, by risk class, by who carries which obligation, and by what changes in the technical documentation file.

What the AI Act is, in product terms

The Artificial Intelligence Act, formally Regulation 2024/1689, is a horizontal regulation. Like the CRA or the IoT baseline of EN 303 645, it cuts across sectors instead of governing one product family. It does not replace the Machinery Regulation, the MDR or the radio rules. It overlays a set of requirements on the AI part of a product, then routes the assessment of those requirements through whichever conformity procedure the product already uses.

For a product engineering office the practical reading is short. First, classify the AI by risk. Second, if the AI lands in the high-risk tier because the host product is on Annex I, fold the new requirements into the technical documentation file you already maintain. Third, manage cybersecurity, accuracy and human oversight as design requirements, not as paperwork added at the end.

The legal definition of an AI system

The Regulation defines an AI system around inference: a machine-based system that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments. Autonomy and the capacity to adapt are part of the picture.

This definition matters for scoping. A deterministic control law, a fixed lookup table, a hand-tuned PID loop is normally not an AI system in the legal sense. A trained classifier or regressor that infers outputs from data usually is. The classification is a design-phase decision that you should record with its reasoning, because everything downstream depends on it.

The four risk tiers

The AI Act is risk-based. Every AI system falls into one of four tiers, and the tier dictates the weight of the obligations.

Tier	What it covers	Core obligation
Prohibited	Manipulative techniques, social scoring, untargeted facial scraping, certain biometric uses	The practice is banned outright
High-risk	AI in Annex I regulated products requiring third-party assessment, plus the Annex III use cases	Full conformity requirements, integrated into CE assessment
Limited-risk	Systems that interact with people, generate or manipulate content	Transparency duties (disclose AI, label synthetic media)
Minimal-risk	Everything else, the large majority	No mandatory obligations under the Act

Most embedded product features sit in the minimal-risk tier. A predictive-maintenance model on an industrial drive, an anomaly detector on a sensor stream, a vision system doing quality control on a line, none of these is manipulating a person or scoring citizens. The compliance work concentrates on the high-risk tier, and that is where the integration with CE marking happens.

Prohibited practices

The top tier is a short blacklist. It targets uses such as subliminal manipulation that causes harm, exploitation of vulnerabilities, social scoring by public authorities, untargeted scraping of facial images to build recognition databases, and some real-time biometric identification scenarios. For a typical industrial or consumer product these are not in scope. The discipline is to verify, once, during classification, that no feature drifts toward this list, and to record that verification.

Limited-risk transparency

A middle tier carries transparency rather than conformity duties. If a system interacts directly with people (a chatbot, a voice assistant), users must be told they are dealing with an AI unless it is obvious. If a system generates or manipulates image, audio or video content, that synthetic output must be marked in a machine-readable way. A product that merely runs an internal model with no user-facing generative output usually has no transparency duty, but check the user interaction surface.

The pivot: AI inside an already-regulated product

This is the heart of the matter for a manufacturer, and the part the AI Act handles more gracefully than its reputation suggests.

When an AI system is a product, or a safety component of a product, covered by one of the Union harmonisation acts listed in Annex I of the AI Act, and that product is already required to undergo a third-party conformity assessment, the AI system is classified as high-risk. Annex I lists the familiar sectors: machinery, medical devices and in-vitro diagnostics, radio equipment, toys, lifts, pressure equipment, personal protective equipment, civil aviation, motor vehicles, marine equipment, and more.

The decisive design choice in the Regulation is what happens next. The AI requirements are integrated into the existing conformity assessment, not bolted on as a separate procedure.

Without integration (hypothetical)	What the AI Act actually does
Two technical files	One technical documentation file covering product and AI
Two declarations of conformity	One EU declaration of conformity
Two markings	One CE marking
Possibly two assessment bodies	Where a notified body is involved, normally the same body assesses the AI requirements
Two surveillance regimes	One coordinated assessment, aligned with the sectoral act

In practice this means a manufacturer adding a learning model to a class IIa medical device or to an Annex IV machine does not open a new front. The AI requirements become additional content in the technical file, additional checks in the conformity route, and additional substance in the same declaration. The Regulation 2024/1689 requirements are read together with the sectoral presumption of conformity machinery, and the notified body that already handles the medical or machinery assessment normally absorbs the AI part.

This is why the AI Act reserves the longest transition for exactly this case: products already covered by Annex I legislation get the most time, because their conformity ecosystems (standards, notified bodies, harmonised standards under the sectoral act) need time to extend their scope to AI.

The second route to high-risk: Annex III

A system can also be high-risk by use case, regardless of any host product, if it appears in Annex III: biometric identification and categorisation, management of critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and administration of justice. For a product engineering office building industrial or consumer hardware, Annex III is usually peripheral, but a product that, say, performs biometric access control reaches high-risk through this door even if no other directive applied.

Requirements for high-risk AI systems

Once a system is high-risk, the Regulation imposes a coherent set of requirements. Read as engineering requirements rather than legal text, they map cleanly onto a competent product development process.

Requirement	What it means in design terms
Risk management system	A continuous, iterative process across the lifecycle, sitting alongside the product risk analysis you already run
Data and data governance	Training, validation and test data sets that are relevant, representative, and managed for bias and gaps
Technical documentation	A file demonstrating conformity, designed to fold into the sectoral technical documentation
Record-keeping (logging)	Automatic logging of events over the system lifetime for traceability
Transparency and instructions	Clear instructions for use so the deployer can operate the system correctly
Human oversight	Measures that let a person understand, monitor and, where needed, override the system
Accuracy, robustness, cybersecurity	Appropriate levels declared and achieved, resilient against errors, faults and adversarial attempts

The last line is where the AI Act meets the rest of the product file. Accuracy is a declared performance metric. Robustness is fault tolerance under realistic conditions. Cybersecurity is resistance to attempts to alter the system's use, outputs or performance, including data poisoning and model evasion. These three are not separate from the product, they are part of how the product behaves, and they belong in the same verification campaign as functional safety and electromagnetic compatibility.

Providers versus deployers

The Regulation assigns obligations by role, and a single company can wear more than one hat. Getting the role right is the first step, because the obligation set differs sharply.

Role	Definition	Main obligations
Provider	Develops an AI system, or has it developed, and places it on the market under its own name or trademark	Ensure conformity, build the technical file, run conformity assessment, register where required, post-market monitoring
Deployer	Uses an AI system under its own authority in a professional context	Use per instructions, ensure human oversight, monitor operation, inform the provider of risks
Importer / distributor	Places or makes available a third-party AI system on the EU market	Verify the provider did its job, check documentation and marking

A manufacturer that builds AI into its own product is the provider of that AI system and carries the heavy end. The same manufacturer may be a deployer when it uses a bought-in model for an internal task, and an importer when it places a non-EU vendor's AI on the market. Map each AI system in the product to a role before deciding which obligations apply. A common mistake is to treat a sub-supplier's model as someone else's problem, when integrating it into your product under your name can make you the provider for the integrated system.

General-purpose AI models

The Regulation also addresses general-purpose AI models, the foundation models that power many downstream applications. These carry their own provider obligations around documentation and transparency, with stricter duties for models presenting systemic risk. A product team that fine-tunes or integrates a general-purpose model should track which obligations stay with the upstream model provider and which transfer when the model is substantially modified or rebranded. As an economic operator integrating such a model, clarify the contractual flow of documentation early.

The phased timeline

The AI Act entered into force in 2024 and applies in stages rather than all at once. The staggering is deliberate: the lighter, most urgent duties land first, and the heaviest integration cases get the longest runway.

Phase (relative)	What becomes applicable
First	Prohibited practices and AI literacy duties
Next	Rules for general-purpose AI models and governance bodies
Then	The bulk of the high-risk regime and transparency rules
Last	High-risk AI embedded in products already covered by Annex I legislation

The exact calendar dates are set in the Regulation itself. Because misquoting a compliance deadline is worse than not quoting one, treat the dates above as an ordering and confirm the precise day for your situation against the official Regulation 2024/1689 text on EUR-Lex, which is the authoritative source. The practical takeaway for a manufacturer is that if your AI is embedded in an Annex I product, you have the most time, and you should use it to extend, not duplicate, your existing CE process.

Interaction with other product regulations

The AI Act was written to coexist with the rest of the product rulebook. Three intersections matter most for an electronics and embedded product office.

Cyber Resilience Act

The CRA, Regulation 2024/2847, sets horizontal cybersecurity requirements for products with digital elements. The AI Act's robustness and cybersecurity requirement for high-risk systems overlaps with the CRA's essential requirements. The Regulation is built so that compliance with the horizontal cybersecurity rules can be relied upon to support the AI robustness requirement, avoiding two separate security cases. Build one security architecture, one threat model, one body of evidence, and map it to both regimes. This is the highest-leverage simplification available to a team facing both at once.

Medical Device Regulation

For a medical device with AI, the MDR (or IVDR) and the AI Act apply together. The device is already high-risk in MDR terms, its AI is high-risk in AI Act terms, and Annex I integration means a single conformity route. The notified body that handles the MDR assessment is the natural place for the AI requirements to be assessed, and the MDR technical documentation absorbs the AI documentation. The risk management of EN ISO 14971 and the AI risk management system are run as one coherent process, not two.

Machinery and radio products

A machine with an AI safety component reaches high-risk through Annex I, and its assessment integrates into the Machinery Regulation route. A connected product with AI also sits under radio rules and, for cybersecurity, under the RED article 3.3 regime and the CRA. The lesson is constant: identify every applicable act, then look for the single integrated assessment the New Legislative Framework was designed to provide, rather than running parallel projects.

A practical sequence for manufacturers

A workable order of operations for a product team adding AI to a regulated product.

Classify the AI system. Is it an AI system in the legal sense? Which risk tier? If the host product is on Annex I and needs third-party assessment, it is high-risk. Record the reasoning.
Confirm it is not a prohibited practice. A one-time check against the blacklist, documented.
Map roles. Provider, deployer, importer, for each AI component, including bought-in and general-purpose models.
Fold AI requirements into the existing CE file. Risk management, data governance, logging, human oversight, accuracy and robustness become sections of the one technical documentation file.
Engineer one security case that satisfies CRA and the AI robustness requirement together.
Engage the existing notified body where one is already involved, so the AI assessment rides the sectoral route.
Issue one declaration of conformity and affix one CE marking.
Stand up post-market monitoring that covers the AI system's real-world performance, feeding the risk management loop.

The throughline is integration. The AI Act adds substance to the CE file and discipline to the design process, but for products already inside the New Legislative Framework it does not create a second compliance universe. See the CE pillar for the underlying conformity machinery that the AI requirements plug into, and confirm scope with the notified body where third-party involvement applies.

Common pitfalls

Assuming a second marking. There is no separate AI marking for Annex I products. One file, one declaration, one CE marking. Teams that build a parallel process waste effort.
Misclassifying the role. Integrating a sub-supplier's model under your own product name often makes you the provider of the integrated system, not merely a deployer.
Treating cybersecurity twice. Running a separate CRA security case and a separate AI robustness case duplicates evidence the Regulation lets you share.
Quoting a wrong deadline. The dates are staggered and case-dependent; confirm yours against the official text rather than a summary.
Leaving data governance to the end. Training-data representativeness and bias management are design inputs, not a final audit item; retro-fitting them is expensive.
Forgetting post-market monitoring. The high-risk regime expects ongoing monitoring of real-world performance, not a one-shot assessment.