Article 6(1) safety components: when AI in a regulated product becomes high-risk
A manufacturer whose regulated product contains AI needs to know one thing first: does the AI Act make that AI high-risk? Under Article 6(1), it does when the AI is a safety component of a product, or is itself a product, covered by Annex I harmonisation legislation, and that product must undergo third-party conformity assessment under that legislation. Both parts must be true. If the AI sits inside a product that never needs a notified body or other third party under its sectoral law, the Article 6(1) route does not apply, although other obligations may. Start by listing each AI function in the product, then check which Annex I act governs the product and whether its conformity route requires third-party involvement.
The 2026 amendments narrowed the test. Article 6(1a) to 6(1c) state that AI used solely for non-safety purposes, such as user assistance, performance optimization, efficiency, automation, convenience or quality control, is not a safety component unless its failure would endanger health and safety. Article 6(1c) adds that a product needing third-party assessment only for non-safety reasons, such as radio spectrum or electromagnetic interference, does not meet the third-party assessment condition. In practice, a manufacturer should document the intended purpose of each AI function and the consequence of its failure, for example by recording whether a fault in a scheduling or comfort feature could create a hazard. Have the sectoral conformity body or a legal adviser confirm the reasoning, since the Commission's draft guidelines on high-risk classification are still a draft.
The timing also changed. As amended, Article 113 applies the high-risk rules to Article 6(1) systems from 2 August 2028, instead of 2 August 2027. Confirm this date against the consolidated text of Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 before you set a release plan. The structure of the obligations is what matters most. Under Article 43(3), these systems follow the conformity assessment already required by the sectoral legislation, and the AI Act requirements, including the Article 17 quality management system, are assessed as part of that procedure. Article 11(2) requires a single set of technical documentation, so the manufacturer should extend its existing product technical file rather than build a parallel one. Ask your notified body early which harmonised standards and evidence it will accept.
Which products and AI components fall under the Article 6(1) route
Article 6(1) turns on three questions: is the AI a safety component or does it only support non-safety functions, does the product sit in an Annex I act, and does that act require third-party conformity assessment. Each card below is a decision point that changes the compliance work, and the answers should be recorded before any technical documentation is started.
Safety component or non-safety support
Start by asking what the AI does when it fails. Article 6(1a) to 6(1c), added in 2026, treat AI used solely for user assistance, performance optimization, efficiency, automation, convenience or quality control as outside the safety component test, unless its failure would endanger health and safety. A failure-impact analysis of each AI function, written down with the product's hazard analysis, is the record an assessor will ask to see. Confirm the reasoning with the product's notified body or sectoral authority where the boundary is unclear.
Annex I Section A acts
Section A lists the New Legislative Framework acts that the 2026 amendments kept in Annex I, including toys, lifts, radio equipment, pressure equipment, personal protective equipment, and medical and in vitro diagnostic devices. Map each product line to its governing act and the specific article that requires third-party assessment. A product covered only by Section A acts may still fall under Article 6(1) if its AI is a safety component, so the mapping must be done per product, not per company.
Annex I Section B machinery
Machinery moved from Section A to Section B under the 2026 amendments, so machinery products need a separate scoping pass. Check whether the machinery's safety functions depend on an AI component, such as learning-based control, vision-based stopping or collision avoidance. Machinery makers should confirm with counsel and their conformity assessment body how the Section B placement changes the applicable requirements and the timing of the high-risk rules.
The third-party assessment condition
Article 6(1) applies only when the underlying act requires a product to undergo third-party conformity assessment. Article 6(1c) excludes products that need third-party assessment only for non-safety reasons, such as radio spectrum or electromagnetic interference. For each product, record whether the act requires a notified body, which module applies, and whether the AI-related elements fall inside that assessment. Where the act allows internal control only, the Article 6(1) route may not apply.
Component makers and integrators
The AI component may come from a supplier, a model vendor or an open-source project, while the finished product is placed on the market by someone else. Each party in the chain needs to know whether it is a provider of the component, a product manufacturer, or both. Request written statements from suppliers on intended purpose, safety role and the documentation they will hand over, and confirm how a single set of technical documentation will be shared under Article 11(2).
Dates for the product route
Under the 2026 amendment, the high-risk rules for Annex I product systems apply from 2 August 2028, instead of 2 August 2027. Products already in the market and products placed later follow different transition questions, so the scoping record should note the placement date for each product version. Confirm with the relevant conformity assessment body how they plan to assess AI elements, since the first harmonised standard, EN 18286:2026 on quality management, was cited in the Official Journal on 14 October 2026.
Where the non-safety carve-outs help and where they do not
Article 6(1a) and 6(1b), added in 2026, state that AI used solely for purposes such as user assistance, performance optimization, efficiency, automation, convenience or quality control is not a safety component, unless its failure would endanger health and safety. The word solely does the work here. If the same model also decides something that protects users from physical harm, the carve-out for that function does not cover the product as a whole.
- Clear functional boundary: Document each AI function in the product and assign it a purpose category, so that a convenience feature and a protective feature are not blurred together.
- Solely means solely: Check whether the AI output feeds any protective function, interlock, alarm or control loop, even indirectly through shared data or a common model.
- Failure analysis: For each non-safety function, record what happens if it fails or behaves wrongly, and whether that outcome could endanger health or safety.
- Change control: A later software update that adds a protective use turns a carved-out function into a safety component. Tie the classification to the release process.
- Evidence package: Keep the intended purpose statement, architecture diagram, failure analysis and sign-off together so the argument can be produced on request.
Before relying on this carve-out, confirm the current wording of Article 6 and the draft Commission guidelines on classification, and ask your conformity assessment body how it expects the boundary to be documented.
Article 6(1c) addresses a narrower case. A product may need third-party assessment under an Annex I act, but only for reasons unrelated to safety, such as radio spectrum use or electromagnetic interference. In that case the product does not meet the third-party assessment condition for the high-risk route through Article 6(1), even if it contains AI. The test is not whether the product is regulated, but why the third-party assessment is required.
- Read the legislation for the reason: Identify which Annex I act applies and the specific essential requirement that triggers third-party assessment, then confirm whether that requirement concerns safety.
- Separate the assessment routes: A product can require a notified body for radio equipment and still have a safety-related AI function under another act. Each route is assessed on its own terms.
- Watch for mixed requirements: Where one act covers both safety and non-safety aspects, the carve-out does not remove the safety part.
- Record the mapping: Keep a table linking each Annex I requirement to its purpose, so an assessor can see why the condition is or is not met.
- Check with the notified body: Where the assessment reason is contested, ask the body that would perform the assessment to confirm its scope in writing.
Ask the product's conformity assessment body or competent authority to confirm the reason for third-party assessment before you conclude that Article 6(1c) applies.
The carve-outs stop applying where failure of the AI would endanger health and safety. This is the limit that most often decides the outcome. Even an AI function that looks like convenience, such as a quality inspection model on a production line or a monitoring feature on a medical device, can fall back into scope if a wrong output could lead to injury or harm. The question is what happens when the AI is wrong, not how the feature is described in marketing material.
- Consequence over label: Describe the worst credible outcome of a wrong output, including delayed or missing outputs, and judge it against health and safety rather than product category.
- Human oversight does not automatically remove the risk: State clearly whether a person can detect and override the output in time, and document how that works in practice.
- Quality control on safety parts: Inspection AI that accepts or rejects parts used in protective equipment or structures should be assessed against the consequence of a false pass.
- Scenario records: Keep dated failure scenarios and their reviewers, so the conclusion can be reviewed when the product or its environment changes.
- Independent review: Where the answer is close, obtain an independent safety review before filing the classification, because the burden is on the provider to justify it.
Confirm with your assessment body which failure scenarios it expects you to analyze for your product type, and whether it accepts your reasoning before you invest in a classification that depends on it.
A carve-out is not a self-declared exit from high-risk status. The provider makes the classification, but must be able to defend it to a notified body, a market surveillance authority or the Commission, and must keep the documentation that supports it. If the argument cannot be produced, or if the authority disagrees, the system is treated as high-risk and the full set of obligations applies. Planning for the defense from the start is far cheaper than rebuilding the reasoning after an inquiry.
- Written classification decision: Record the decision, the article relied on, the facts used, the people who approved it and the date.
- Traceable to the product: Tie the argument to a specific version of the product, hardware and software, so that it is clear what the decision covers.
- Reviewed on change: Set triggers for re-review, such as new AI functions, new markets, a new intended purpose or a substantial modification.
- Consistent with other documents: The risk management file, technical documentation and instructions for use must not contradict the classification.
- Ready for an authority request: Be able to explain the reasoning to a non-specialist within a short time, supported by the evidence rather than assertions.
Before you rely on a carve-out in a contract, tender or market submission, confirm with qualified counsel and the relevant assessment body that the documentation will stand up to review.
How an assessor tests the Article 6(1) classification
This table compares each step an assessor takes to test an Article 6(1) classification, the evidence requested for that step, and the findings that appear most often. Read it as a checklist: if your file cannot answer the evidence column for a row, the classification is not yet defensible. The main takeaway is that the product route depends on the sectoral conformity route, so the sectoral file must be checked before the AI Act label is settled.
| Test area | Test approach and evidence requested | Common findings |
|---|---|---|
| Annex I coverage | Confirm the product or its safety component falls under an Annex I act, checking Section A (New Legislative Framework acts) or Section B (machinery). Request the product's legal basis and the Annex I entry cited. | Product classified under an Annex I act that does not list it, or Section A and B references confused. |
| Third-party conformity requirement | Confirm the sectoral act actually requires third-party conformity assessment for this product. Request the sectoral conformity route and the notified body or self-declaration record. | Product classified as high-risk without checking whether the sectoral act requires third-party assessment at all. |
| Safety component test (Article 6(1a) to 6(1c)) | Test whether the AI performs a safety function, or whether its failure would endanger health and safety. Request function analysis and failure-impact reasoning for each AI component. | AI described as user assistance, optimization or convenience with no analysis of what happens on failure. |
| Non-safety third-party reasons | Check whether third-party assessment exists only for non-safety reasons, such as radio spectrum or electromagnetic interference. Request the specific clause that triggers assessment. | Assessment for radio or electromagnetic reasons treated as a safety trigger without documented reasoning. |
| Intended purpose documentation | Review the stated intended purpose and its consistency with the product instructions, marketing and risk file. Request versioned intended purpose statements tied to the classification decision. | Intended purpose written narrowly for the classification file but broader in product documentation. |
| Article 43(3) conformity route | Confirm the sectoral conformity assessment covers the AI Act requirements and the Article 17 quality management system. Request the combined assessment plan and the scope of the notified body mandate. | AI Act requirements assumed to be covered by the sectoral assessment without checking the scope in writing. |
| Article 11(2) single technical file | Check that one set of technical documentation covers both the sectoral act and the AI Act requirements. Request the file index and the mapping of AI Act articles to sectoral sections. | Separate AI Act documentation kept outside the product technical file, creating version conflicts. |
| Application date (2 August 2028) | Confirm the Article 6(1) obligations apply from 2 August 2028 as amended in 2026, and that the product's placing on the market timeline matches. Request the launch plan and compliance milestones. | Plan still keyed to the earlier 2 August 2027 date, or the 2026 amendment's dates not reflected in project schedules. |
How to classify a product and prepare the Article 6(1) file
This sequence takes an organization from an inventory of products with embedded AI to a single technical documentation set that covers both the AI Act and the sectoral conformity assessment. Each step ends with a record that an assessor or market surveillance authority can check.
Inventory every product with embedded AI
Product or engineering owners list every product, component and firmware release that contains AI or machine learning functionality, including models bundled from third parties and updates pushed to products already on the market. Compliance leads record the product name, version, intended purpose, the markets where it is placed, and the business owner. The step is complete when the inventory covers every product line and each entry names an accountable owner, because later steps cannot classify what is not listed.
Map each product to Annex I legislation
Regulatory affairs staff match each product against the Annex I harmonisation acts, checking Section A and Section B as amended in 2026. Products that fall under none of these acts are not high-risk under Article 6(1), although they may still fall under Article 6(2) or other obligations. The output is a mapping table that names the applicable Annex I act for each product and the legal reference used to reach that conclusion.
Confirm whether third-party assessment applies
For each mapped product, the team checks whether the sectoral legislation requires a conformity assessment by a notified body, rather than a self-declaration by the manufacturer. Products assessed only for non-safety reasons, such as radio spectrum or electromagnetic interference, do not meet the third-party condition under Article 6(1c). Legal counsel or the notified body contact should confirm the result in writing. The output is a yes or no per product, with the procedure named.
Record the safety component reasoning
For each AI function in a product that is covered by Annex I, the team documents whether the AI is a safety component, meaning its failure could endanger health and safety, or whether it serves only non-safety purposes such as user assistance, performance optimization, efficiency, automation, convenience or quality control. The record names the function, the failure modes analysed, the hazard assessment that supports the conclusion, and the reviewer who signed it. Assessors will test this reasoning, so it should cite the hazard analysis rather than assert a conclusion.
Build one technical documentation set
Engineering and compliance teams assemble a single technical file that serves both the AI Act requirements and the sectoral conformity assessment, as Article 11(2) requires one set of technical documentation. The file covers the system description, data governance, risk management, quality management, logging, human oversight and the test results. Each section is cross-referenced to the sectoral technical file so that duplicated records are avoided. The step is complete when a reviewer can trace each AI Act requirement to a specific document in the set.
Assess the quality management system under the sectoral route
Where Article 43(3) applies, the notified body or the sectoral assessment body examines the AI Act requirements and the Article 17 quality management system as part of the existing conformity assessment. The manufacturer confirms that its quality management system covers AI-specific processes, such as data management and post-market monitoring, and that the procedures are documented. The output is a gap list agreed with the assessor, plus the evidence of each closed gap. Ask the notified body early which harmonised standards it will use for the assessment.
Set the 2 August 2028 milestones
Program managers translate the 2 August 2028 application date for Article 6(1) and Annex I systems into a plan with internal gates for classification sign-off, documentation completion, conformity assessment and market placement decisions. The plan also covers products already on the market that will receive AI updates before that date. The output is a dated milestone plan owned by a named executive, reviewed whenever the Commission publishes further guidance or the notified body schedule changes.
How the AI Act and sectoral conformity assessment combine into one route
For an Article 6(1) system, the AI Act does not add a second assessment on top of the one the sectoral law already requires. Under Article 43(3), the conformity assessment of the Annex I legislation is the procedure that applies, and the AI Act requirements, including the quality management system under Article 17, are assessed as part of it. A manufacturer that already certifies a product, for example a medical device, machinery or a radio product, keeps its existing notified body or conformity assessment route and extends its scope to cover the AI component. The practical question is whether the notified body or assessor that already holds the sectoral certificate is competent to assess the AI-specific requirements, and whether the manufacturer's current quality system already covers the data, logging and human oversight duties that Chapter III sets out.
Article 11(2) makes the documentation side concrete: one single set of technical documentation must cover both the sectoral and the AI Act requirements, so the manufacturer should not maintain a parallel AI file. In practice, this means mapping each AI Act requirement to a section of the existing technical file, identifying gaps such as training data governance, accuracy metrics and post-market monitoring, and assigning an owner to each gap. Ask your notified body early which harmonised standards and which parts of the technical file they will check, and confirm the version of the sectoral legislation that governs your product.
EN 18286:2026 is the first harmonised standard for quality management under the AI Act, and it was cited in the Official Journal on 14 October 2026. Citation is what gives a standard presumption of conformity, so a manufacturer that follows it can use that presumption for the quality management elements it covers. It does not cover every AI Act requirement, and the requirements on data, technical robustness and documentation may still need evidence drawn from other standards or from your own demonstration. Confirm with your assessor which clauses of the standard they will accept, and check the current status of the Commission's implementing decision on harmonised standards before you rely on it in a conformity file.
Evidence that shows an Article 6(1) classification holds
An Article 6(1) classification is only as strong as the records behind it. The six records below show why the system is high-risk, how the sectoral conformity assessment was determined, and when the classification must be reopened. Review them together at each change, since a single stale record can undo the others.
Annex I mapping record
This record names the Annex I harmonisation act that covers the product or safety component, the specific section of Annex I under which it falls, and the product category. After the 2026 amendments, Section A lists eleven New Legislative Framework acts and machinery sits in Section B, so the section reference matters. Check the act reference against the current consolidated text each time you review the record, and confirm with the sectoral regulator or notified body which version applies to your product.
Third-party assessment determination
Article 6(1) applies only when the sectoral legislation requires a third-party conformity assessment. Record which procedure the sectoral act prescribes, the body that performs it, and the date of the most recent assessment or certificate. If the product needs third-party assessment only for non-safety reasons, such as radio spectrum or electromagnetic interference, the condition is not met, so document that reasoning explicitly. Refresh this record whenever the sectoral act or its notified body arrangements change.
Safety component reasoning
This is the written analysis showing whether the AI function is a safety component, meaning its failure would endanger health or safety. Where AI serves only non-safety purposes such as user assistance, performance optimization, efficiency, automation, convenience or quality control, record why the Article 6(1a) to 6(1c) carve-out applies and confirm that no safety failure path exists. Revisit the analysis after each functional change, because a feature added later can move a component into scope.
Intended purpose statement
The intended purpose describes the use the provider designed the system for, including the operating context, the users and the conditions of use. Classification depends on it, so a statement that omits a safety-relevant use leaves a gap. Write it in plain terms, list the excluded uses, and have the product, safety and legal owners sign it. Compare it with how the product is marketed and deployed, since differences between the stated and actual use are a common audit finding.
Single technical documentation file
Article 11(2) requires one set of technical documentation that covers both the AI Act requirements and the sectoral conformity assessment, so the two do not drift apart. Keep the classification reasoning, the mapping record and the assessment outcome inside this file, with version numbers and dates. Ask your notified body or sectoral assessor which template they accept, and confirm that the file can be produced in full on request.
Change log for reclassification
A dated change log records each modification to the model, the training data, the intended purpose or the product that could alter the safety-component analysis. Each entry should state whether the classification was re-tested and by whom. Set a rule that a change to the model or intended purpose triggers a fresh review before release, not after the next scheduled audit. Keep the log with the technical documentation so an assessor can trace every classification decision over time.
What classifying and documenting Article 6(1) systems costs
The table compares each cost component of an Article 6(1) program, who is paid for it, whether it is one-time or recurring, and what moves it up or down. No figures are supplied for these costs, so ask for a written scope and a quote, and confirm any notified body fees directly with the body before budgeting.
| Cost component | One-time or recurring | What drives it and how to keep it down |
|---|---|---|
| Internal legal and product-compliance time for classification | One-time, revisited on change | Number of products and AI functions in scope. Keep a single classification memo per product and reuse the Annex I analysis when the design changes. |
| Engineering time for technical documentation | One-time build, then recurring updates | Complexity of the AI component and how many sectoral acts apply. Use one set of technical documentation, as Article 11(2) requires, to avoid duplicate files. |
| Evidence upkeep and version control | Recurring | Frequency of model, data and software releases. Generate logs and inventory exports automatically so evidence follows each release. |
| Notified body or third-party assessment fees | Per assessment, plus re-assessment on substantial change | Set by the notified body and the sectoral act that requires third-party assessment. Confirm fees, scope and timing in writing with the body, since not every Article 6(1) product needs one. |
| External review by an independent specialist | Optional, per review | Scope of the review and the readiness of internal files. Ask for a fixed-scope proposal covering deliverables, dates and what is excluded. |
| Implementation partner preparation work | One-time, plus any retainer | Systems, logging and evidence gaps that exist at the start. Agree deliverables in a written scope before work begins. |
Who owns the classification, who prepares the evidence and who decides
Your organization owns the classification decision and the product decision. Under Article 6(1), the question is whether your AI system is a safety component of a product, or is itself a product, covered by Annex I legislation that requires third-party conformity assessment. The answer depends on the sectoral law that governs your product, not only on the AI system's function, so legal, product compliance and engineering leads should decide it together and record the reasoning.
- Scope the product: identify the Annex I legislation that applies and whether it requires third-party assessment for your product.
- Test the safety link: determine whether the AI's failure could endanger health and safety, since AI used solely for convenience, optimization or quality control falls outside the safety component route unless that test is met.
- Check non-safety assessments: confirm that a third-party assessment driven only by radio spectrum or electromagnetic interference does not trigger the route.
- Own the intended purpose: document the intended purpose and the reasoning in a classification record that an assessor can read.
- Sign the decision: name the accountable owner who approves the classification and revisits it after each substantial modification.
Before relying on the classification, check the current draft Commission guidelines and confirm the final application dates with your legal counsel and notified body.
An implementation partner prepares the systems and evidence that your conformity assessment will examine. DeployOpen works in this role: it plans, builds and documents the self-hosted platforms and controls inside your own infrastructure, and it prepares the technical file inputs, logging, testing records and inventory. The partner does not decide whether the system is high-risk, does not declare conformity and does not issue certificates.
- Technical file inputs: assemble design descriptions, data governance records and risk management outputs that feed the single set of technical documentation required by Article 11(2).
- Logging and traceability: configure event logging and retention so records can be produced for the assessor.
- Testing evidence: run and document security and robustness testing, including AI-specific tests, and keep the raw results.
- System inventory: maintain an accurate inventory of hardware, software and AI components, using tools such as GLPI or Wazuh where they fit your environment.
- Scoped statement of work: agree the deliverables in writing before work starts, so you know which evidence is produced and which remains your responsibility.
Confirm with the partner which items it prepares, which it only reviews and which it does not touch, and who keeps the final records.
The notified body, or the independent body that conducts the assessment under the sectoral legislation, is the party that decides whether conformity is demonstrated and issues certificates where the law requires them. Under Article 43(3), the AI Act requirements and the Article 17 quality management system are assessed as part of the conformity assessment of the sectoral legislation. The assessor must be independent of you and of the party that prepared the evidence.
- Independent assessment: the body tests the evidence against the requirements, and it is not bound by the preparation work.
- Certificates: only the notified body or certification body issues certificates, and it must be designated under the applicable legislation.
- Independence line: a partner that helped build the system may not also act as the assessor for it.
- Early engagement: ask the body which documents it expects, how it samples evidence and how long its review takes, since these vary by sector.
- Ongoing duties: confirm what the body requires for surveillance, changes and reassessment after a substantial modification.
Ask the body in writing which standards and evidence it accepts for your product before any build work starts.
Common gaps in Article 6(1) classification
Most Article 6(1) errors come from treating the AI as a feature rather than as part of a regulated product's conformity process. The cards below cover the gaps that recur, and each one names the check that closes it.
Non-safety claims without a written argument
Teams often label an AI component as user assistance, efficiency or convenience and stop there. Article 6(1a) to 6(1c) only exclude AI used solely for non-safety purposes, and only where its failure would not endanger health and safety. Write a classification memo for each AI function that names the product, the failure modes, the hazard analysis result and why no safety outcome depends on the output. Have the product safety lead sign it, then keep it with the technical file.
Missing the sectoral assessment link
Article 6(1) applies only when the product must undergo third-party conformity assessment under the Annex I legislation. A team that assumes the AI triggers the route, or that a self-declared product is out of scope, can reach the wrong answer in both directions. Map each product to its Annex I act, identify the conformity assessment route that act requires, and record whether a notified body is involved. Confirm the current Annex I section placement with the sectoral regulator, because the 2026 amendments moved machinery to Section B.
Separate technical files for product and AI
Running the AI documentation and the product documentation as two unrelated files creates contradictions that assessors notice quickly. Article 11(2) calls for a single set of technical documentation, and Article 43(3) assesses the AI Act requirements inside the sectoral conformity assessment. Assign one owner for the combined file, cross-reference hazard analysis, risk controls and test evidence in both directions, and version the file with each product release.
No trigger to reclassify after changes
A classification that was correct at launch can become wrong after a firmware update, a new model, a new sensor input or a new use in a safety function. Treat a substantial modification as a trigger to repeat the Article 6(1) analysis, not only the conformity file. Add a change-control gate that asks whether the AI now influences a safety function, whether the Annex I assessment route has changed and whether the product still needs third-party assessment. Record the outcome in the change ticket.
Planning to the old 2027 date
Some plans still assume the product route applies from 2 August 2027. As amended in 2026, Article 113 applies the high-risk rules to Article 6(1) and Annex I systems from 2 August 2028. Update the program calendar, the procurement timing and supplier commitments to that date, and check whether any notified body or sectoral deadline in your product line falls earlier. Ask counsel to confirm which transitional provisions apply to products already on the market.
Questions manufacturers ask about Article 6(1)
Is a product that needs only radio or EMC assessment caught by Article 6(1)?
No, not on that basis alone. Under Article 6(1c), as added in 2026, a product that needs third-party assessment only for non-safety reasons, such as radio spectrum or electromagnetic interference, does not meet the third-party assessment condition, so an AI feature in it does not become high-risk through Article 6(1). The test is whether the AI is a safety component and whether the product needs third-party assessment for a reason that the AI bears on. Confirm with your notified body and the sectoral legislation which assessment routes apply to your product, and check the Commission's draft classification guidelines dated 19 May 2026 for worked interpretation. Document the reasoning in your classification file either way.
Is a non-safety AI feature in a medical device high-risk?
Usually not under Article 6(1) if the feature is solely for non-safety purposes. Articles 6(1a) to 6(1c), added in 2026, state that AI used only for purposes such as user assistance, performance optimization, efficiency, automation, convenience or quality control is not a safety component unless its failure would endanger health and safety. A scheduling assistant or report formatter in a medical device would normally fall outside, while an AI feature that influences diagnosis or treatment would likely be a safety component. Medical and in vitro diagnostic devices are listed in Annex I Section A. Ask your notified body and regulatory affairs team to confirm the failure analysis for each AI function, and record it.
How much does preparing the single technical file add to existing certification effort?
The amount depends on how much of the AI Act evidence you can build into documentation you already maintain. Under Article 43(3), the AI Act requirements and the Article 17 quality management system are assessed as part of the sectoral conformity assessment, and Article 11(2) requires a single set of technical documentation. The main cost drivers are the number of AI functions, the depth of data governance and logging evidence you lack, and how far your existing quality system already covers AI-specific risks. Ask any consultant or notified body for a written breakdown of what is new, what is reused, and who performs each task. No figure is given here because none was supplied for this topic.
Can our team prepare this in-house?
Often yes, for teams that already run conformity assessment for their product line, but the AI-specific work usually needs skills that sit outside a typical product team. The in-house team must own classification, the risk management file, data and model documentation, logging, and post-market monitoring. Gaps tend to be in harmonised standard interpretation and in evidence for model behavior. An implementation partner can prepare systems, logs and evidence, and run security testing of AI components, but it does not issue conformity assessments or certificates. Only the notified body or the relevant assessor does that. Your organization keeps ownership of every control and the declaration of conformity.
What does the work need from engineering and legal?
Engineering owns the technical evidence, and legal owns the classification position and the obligations that follow it. Engineering typically supplies the system architecture, training and validation data records, test results, logging design, cybersecurity measures and change control for AI components. Legal and regulatory affairs typically own the intended purpose statement, the safety-component analysis, the mapping to Annex I legislation, contract terms with suppliers of AI components, and the decision on which assessment route applies. Agree on one owner for the single technical file so that the two teams do not maintain conflicting versions.
How does the 2026 date change affect our plan?
As amended by Regulation (EU) 2026/1744, the high-risk rules for Article 6(1) and Annex I product systems apply from 2 August 2028, instead of 2 August 2027. The Commission's researched timeline moved that obligation, but your product certification schedule, notified body queue and supplier commitments may not move with it. Plan against the 2 August 2028 date, but confirm the current consolidated text on EUR-Lex and any later changes before you lock milestones. Record the date you used in your project plan so that audit trails show why the schedule was set.
How self-hosted tools support the classification and technical file
A product that falls under Article 6(1) needs an accurate register of every device, software package and endpoint it depends on before anyone can say which AI component sits inside which product. GLPI Assets can serve as that anchor. Its Assets module tracks computers, monitors, software, network equipment, peripherals, printers, phones and racks, and the GLPI Agent can push inventory automatically through native inventory built into GLPI since version 10. Wazuh Syscollector complements it from the endpoint side, collecting hardware, operating system, installed software, network interfaces, running services and users, and storing them in the Wazuh indexer for reports in the dashboard. Together they give the compliance lead a dated, reproducible record of what runs where, which the conformity file can cite. GLPI is licensed under GPL-3.0-or-later and Wazuh under GPL-2.0-only, so both can be reviewed and deployed inside your own environment. Confirm with your legal team how each license applies to your deployment and any modifications you make.
For language-model components, the evidence has to show how the system behaves in testing and in operation. Langfuse (MIT) records traces that capture each operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. Those traces can document how a component behaved over time and support the monitoring duties that follow a conformity assessment. garak (Apache-2.0) probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks, and writes a JSONL report of every attempt and evaluation plus a hit log of successful attempts. Keep these reports versioned alongside the model and configuration they tested. Check that your logging design does not store personal data you have no basis to keep.
None of these tools classifies a product, decides whether Article 6(1) applies, or replaces the conformity assessment that the sectoral legislation requires. The classification decision and the technical documentation remain the provider's responsibility, and any third-party assessment under the relevant Annex I legislation is carried out by the body that the legislation names. Use the tools to produce inputs, then confirm with the notified body or assessor which records they will accept. Scope the implementation work in writing before deployment so that the inventory, trace and test outputs map to the documents the assessor expects.
