EN 18286: The AI Act QMS Standard for Medical Devices

Table of Contents

Introduction

EN 18286 is the point at which the AI Act stops being a policy document and becomes something a notified body can sit down and audit. Approved by CEN-CENELEC on 12 July 2026 under the title Artificial intelligence — Quality management system for EU AI Act regulatory purposes, it is the first standard from the JTC 21 work programme to reach publication, and the only document in existence that maps, clause by clause, onto Article 17 of Regulation (EU) 2024/1689. For manufacturers of AI-enabled medical devices that matters more than any AI governance material published in the last three years, because Article 17 is what will be sampled at your next notified body audit rather than debated at a conference.

This article is written for manufacturers who already hold ISO 13485 certification and whose device is, or contains, a machine learning model — the population that will be assessed against the AI Act through the MDR rather than alongside it. It covers what the standard contains, how its clauses attach to a quality system you have already built, what the July 2026 timeline change did and did not do, and where the gaps usually sit. It assumes you know how software as a medical device is qualified and classified; if your ISO 13485 quality management system is not yet stable, close that first, because everything below is built on top of it.

What EN 18286 is, and why CEN refused to reuse ISO/IEC 42001

The standard was developed by CEN-CENELEC JTC 21, Working Group 2, in response to the Commission's standardisation request M/593 and its later amendment. It went out for public enquiry between 30 October 2025 and 22 January 2026, attracted more than a thousand comments, was reworked in a drafting session in March 2026 and was approved unanimously in the formal vote. The enquiry draft ran to 58 pages, the published text runs to 51, and commentary written against the October 2025 draft — a good deal of what is circulating — describes clauses that no longer read the way they did.

Why a new European standard, when ISO/IEC 42001 had been published since December 2023 and a certification market had grown up around it? Because the AI Office concluded, as early as May 2024, that ISO/IEC 42001 was not aligned with the final AI Act text, and the Commission's Joint Research Centre later found it structurally incompatible with the high-risk requirements. ISO/IEC 42001 is an Annex SL management system standard built to ask whether an organisation governs AI responsibly. Article 17 asks something narrower: whether this provider's quality system ensures that each of these specific AI systems complies with a product safety regulation across its life cycle. No amount of control selection from an Annex A menu answers that, and the AI Act does not let the provider choose which obligations apply.

The definition of quality that reverses the customer relationship

The conceptual pivot sits in the terms and definitions. ISO 9000 defines quality as the degree to which inherent characteristics fulfil the requirements of customers and interested parties. EN 18286, at 3.1.19, defines it as the characteristics that fulfil regulatory requirements, including health, safety and fundamental rights. The affected person — the patient, the clinician, the individual whose data trained the model — enters the quality equation as a beneficiary rather than as a stakeholder to be consulted.

Anyone who has worked under ISO 13485 will recognise the move, because ISO 13485 made the same break from ISO 9001 twenty years ago. It is the best reason to expect medtech quality teams to adopt EN 18286 faster than the software industry will.

Two layers inside one standard

The structure divides cleanly. Clauses 4 to 7 and clause 10 form an organisational management system layer covering the quality system itself, management responsibility, planning, support, performance evaluation and improvement. Its nearest relative is ISO/IEC 42001, and if you hold that certificate, or a mature ISO 13485 system, most of this layer is already built.

Clauses 8 and 9 are a different animal. They form a product life cycle layer covering inception, requirements, design, verification and validation, data management, technical documentation, release, post-market monitoring and incident reporting. Their nearest pattern is New Legislative Framework product law, and specifically ISO 13485. This is the half that a generic AI management system does not contain, and where nearly all of the implementation effort will land.

The other structural decision is the scope logic. An ISO 13485 certificate is granted to an organisation for a defined product range at defined sites; EN 18286 anchors the quality system to a declared set of AI systems and their boundaries. Documentation is common to the quality system, evidence is anchored per system. The auditor will not ask to see your procedure and stop there — they will ask which AI systems fall inside the declared scope, then sample the dossier for one of them.

Why the July 2026 timeline reset gives you three years, not a reprieve

The standard arrived in the same fortnight as the largest change to the AI Act since its adoption, and the two events have to be read together.

What Regulation (EU) 2026/1744 actually changed

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was signed on 8 July 2026, published in the Official Journal on 24 July 2026 and entered into force on the third day following publication. It rewrites the third paragraph of Article 113 and splits the high-risk calendar in two. Stand-alone high-risk systems listed in Annex III move from 2 August 2026 to 2 December 2027. High-risk AI that is, or is embedded in, a product covered by the sectoral legislation in Annex I — where medical devices and IVDs sit — moves from 2 August 2027 to 2 August 2028.

Other dates moved with it: the Article 50 transparency obligations still apply from 2 August 2026, with a grace period to 2 December 2026 for marking AI-generated content on systems already on the market, and national regulatory sandboxes moved to 2 August 2027. None of the substantive obligations changed; only the calendar did.

Three years is not generous when measured against the work. A notified body has to be designated under the AI Act as well as under the MDR before it can assess you, and that pipeline is not fast. A dataset assembled in 2022 without a provenance record cannot be retro-documented convincingly. And an AI Act conformity assessment sits inside your MDR certificate cycle, which means the real deadline is not August 2028 but whichever recertification or significant change assessment falls before it.

Why the MDR and the IVDR stayed in Annex I, Section A

The Commission's November 2025 proposal floated moving the MDR and the IVDR from Section A to Section B of Annex I. Because Article 2(2) largely exempts Section B products from the substantive high-risk requirements, that would have made most of the AI Act inapplicable to medical devices. It did not survive the trilogue: the co-legislators agreed on 7 May 2026 that both regulations stay in Section A, and only the Machinery Regulation took the relief. As a compromise, the Commission gained an empowerment to limit specific AI Act requirements by implementing act where the MDR or the IVDR already ensures an equivalent level of protection — a mechanism that may narrow the duplication in due course, but which does not exist yet and cannot be planned around.

The practical consequence is unchanged. If your device requires notified body involvement under the MDR or the IVDR — broadly, MDR Class IIa and above plus the sterile, measuring and reusable surgical Class I subsets, and IVD Class B and above — and it is or contains an AI system, Article 6(1) classifies it as high-risk. There is no self-assessment filter under Article 6(3) for Annex I products; that filter applies only to Annex III use cases.

Article 17 obligation by obligation, and where the evidence sits

Article 17(1) lists thirteen elements, lettered (a) to (m), that a provider's quality system must cover. Read them cold and they look like a quality manual index any certified manufacturer could satisfy from existing procedures. That reading is wrong, and it is the most common error in AI Act readiness assessments. Four of the thirteen have no counterpart in a conventional medical device quality system; the rest exist in some form but were written for a device that does not learn from data, and each needs an extension specific enough to survive sampling.

Clause 4.4 is where a notified body will start reading

Article 17(1)(a) requires a strategy for regulatory compliance, including compliance with conformity assessment procedures and procedures for managing modifications. Article 17(1)(e) requires the technical specifications and standards to be applied and, where harmonised standards are not applied in full or do not cover all the requirements in Chapter III Section 2, the means used instead. EN 18286 collects both into clause 4.4, and this is the architectural heart of the standard.

Clause 4.4.2 requires the provider to identify every essential requirement applicable to each AI system. Clause 4.4.3 requires the provider to select and document, for each of them, the approach used to demonstrate compliance: a harmonised standard cited in the Official Journal, a common specification adopted by implementing act, another standard, or an alternative means with a justification. The result is a controlled document that reads like a compliance matrix and functions as the index to your entire AI Act file.

Almost nobody has this. Quality manuals routinely list the standards a company applies; almost none state which standard demonstrates which requirement for which system. Because clause 4.4 also tells an assessor where everything else is, its absence is not a documentation gap — it is a finding that stops the assessment.

Clause 8.5 turns your datasets into controlled records

Article 17(1)(f) requires systems and procedures for data management covering acquisition, collection, analysis, labelling, storage, filtration, mining, aggregation and retention, for every operation performed before the system is placed on the market. Clause 8.5 operationalises it, and it is the single largest documentation gap in the sector.

The reason is cultural rather than technical. Model development in most medtech companies happens outside the quality system: datasets live in object storage with informal versioning, split ratios are recorded in a notebook, and labelling was done by two clinicians whose instructions were verbal and whose disagreements were settled in a meeting. None of that is reconstructible three years later, which is exactly when the notified body will ask.

Clause 8.5 does not require you to move data science into a document control system. It requires the outputs to be controlled records: a versioned dataset record, a labelling procedure with an inter-rater process, an exclusion log with reasons, and a representativeness assessment against the population declared in the intended purpose. Article 10 sets the substantive criteria — relevance, representativeness, completeness as far as possible and examination for bias — and prEN 18284 will carry the detail.

Clauses 9.4 and 9.5 open a second post-market loop

Article 17(1)(h) imports the post-market monitoring system of Article 72, and Article 17(1)(i) imports the serious incident reporting of Article 73. Both exist in your quality system in MDR form, and both need extending.

A conventional post-market surveillance plan collects complaints, literature, registry data and trend analysis. What it almost never collects is model performance in the field. Clause 9.4 expects real-world performance indicators, subgroup performance where the intended population is heterogeneous, drift detection thresholds and the trigger that opens a retraining or change assessment. Article 72(3) requires the Commission to adopt a monitoring plan template by implementing act, so build the plan so its AI-specific content can be re-cut into whatever arrives.

Serious incident reporting is the subtler problem. The timelines under Article 73 are close enough to MDR Article 87 to be manageable, but the definition is not. A serious incident under the AI Act includes an infringement of Union law obligations intended to protect fundamental rights, and serious harm to property or the environment. Neither triggers an MDR vigilance report. Run the two procedures separately and you will eventually have one event producing two contradictory reportability decisions, with both decisions in the file.

Integrating the standard into an existing ISO 13485 quality system

The good news is that the AI Act anticipated this problem and solved it in the regulation rather than leaving it to the standard.

What Article 17(3) permits, and the trap inside it

Article 17(3) states that where a provider is already subject to quality management system obligations under sectoral Union law, the elements listed in Article 17(1) may form part of that system. EN 18286 is written to be used this way and explicitly acknowledges providers operating a sector-specific quality system such as ISO 13485, permitting integration rather than a parallel structure. There is no requirement to hold a separate certificate, no second management review cycle and no duplicated document control.

The trap is that integration is permitted at the level of the management system, not at the level of the evidence. Folding the AI Act requirements into your existing procedures does not reduce what has to be demonstrated for each AI system; it only means the demonstration happens inside one system rather than two. A quality manual that adds a paragraph saying the company also complies with the AI Act, without the clause 4.4 strategy and the clause 8 and 9 records underneath it, is worse than no integration at all, because it makes a claim the file cannot support.

The delta is seven procedures, not a second management system

A certified manufacturer reusing document control, management review, design control, change control, supplier management, CAPA, internal audit, post-market surveillance, vigilance, competence and usability engineering already carries most of the organisational layer. What has to be built or extended is short and specific: the compliance strategy under 4.4, data management and governance under 8.5, model verification and validation under 8.4, human oversight and transparency content under 8.7, AI post-market monitoring under 9.4, serious incident reporting under 9.5, and extension of the ISO 14971 risk management file to fundamental rights alongside health and safety.

The output side matters as much as the procedural side. Article 11(2) allows the Annex IV technical documentation content to be merged into the documentation required by the sectoral legislation, which for a medical device means the EU MDR technical documentation under Annex II. One file, with the AI Act content identified inside it. Maintaining two technical files for the same device is a choice, not a requirement, and it is a choice that guarantees they will diverge.

Why an ISO/IEC 42001 certificate does not deliver Article 17 conformity

A large consulting market has spent two years selling ISO/IEC 42001 certification as AI Act readiness. It is worth being precise about what that certificate does and does not buy, because the answer is not "nothing".

What it buys is the governance chassis. Scope and interested parties, documented information, management responsibility, planning, support, performance evaluation and improvement map across to EN 18286 with high compatibility, so a mature AI management system leaves the organisational half largely satisfied. The main friction is the scope logic — organisation-anchored in one, AI-system-anchored in the other.

What it does not buy is legal effect. Presumption of conformity under Article 40 flows only from a harmonised standard whose reference has been cited in the Official Journal. ISO/IEC 42001 is not part of the EU harmonisation process, has no Annex ZA, and was never designed to produce one. EN 18286 carries an Annex ZA mapping its clauses to the Article 17 obligations — precisely the artefact an auditor or market surveillance authority will use to test coverage — plus informative annexes mapping the standard to ISO 9001 and the ISO/IEC 42001 Annex A controls, so existing implementations can be leveraged rather than rebuilt. Check the annex lettering against your purchased copy; it moved when the text was trimmed.

The honest position is this. Any consultant telling you that an ISO/IEC 42001 certificate makes you AI Act compliant is selling you a certificate, not a strategy. Any consultant telling you the certificate is worthless is also wrong, and is usually selling you a second project. Keep it, map the clause 8 and 9 delta explicitly, and be able to show the mapping.

Conformity assessment: one notified body, one assessment, two regulations

This is the part that most reassures medical device manufacturers once they understand it, and it is worth stating plainly because a great deal of AI Act commentary written for other sectors gets it wrong.

Article 43(3) provides that for high-risk AI systems covered by the Union harmonisation legislation listed in Annex I Section A, the provider follows the conformity assessment procedure required under that legislation, and the AI Act requirements are assessed as part of it. A notified body notified under both the AI Act and the MDR controls conformity with the AI Act requirements during the same assessment. There is no second CE mark, no second declaration of conformity and no separate AI Act certificate. One assessment, one body, one technical file covering both regimes.

The consequences are practical. Your notified body has to be designated under the AI Act, and if it is not, or is late, you have a supplier problem rather than a documentation problem — one worth raising at your next annual review rather than in 2028. Article 43 also allows a notified body that is not satisfied with the provider's testing to carry out its own. And because the AI Act assessment rides inside the MDR procedure, its substantive requirements will surface in change assessments and recertification audits well before August 2028, because assessors will not want to certify a device in 2027 that they know will be non-conforming a year later.

What EN 18286 deliberately does not do

Three limits are worth stating, because expecting the standard to do more than it does is a reliable way to build the wrong file.

It is not a product conformity assessment procedure. It tells you how the quality system ensures compliance; it does not tell you whether your model is accurate enough, robust enough or secure enough. Those are Chapter III Section 2 requirements, addressed by other standards in the JTC 21 programme: prEN 18228 for the risk management system under Article 9, prEN 18284 for data governance and dataset quality under Article 10, prEN 18229-1 for logging, transparency and human oversight under Articles 12 to 14, prEN 18229-2 for accuracy and robustness under Article 15, and prEN 18282 for cybersecurity. EN 18286 is the hub into which those spokes are assembled, through the clause 4.4 selection record.

It is not a risk management standard, and it is not a substitute for the sectoral quality system. It requires the Article 9 risk management system to be integrated, but it does not replace ISO 14971 and it covers nothing of sterilisation, biocompatibility, clinical evaluation or UDI. It is a layer, not a replacement — which is why the integration question is the first to settle and not the last.

One further caution. EN 18286 is published, but it has not yet been cited in the Official Journal. Until that citation appears, applying it in full does not confer presumption of conformity with Article 17; it confers a well-organised, defensible file. Citation is a Commission decision taken after assessment against the standardisation request, and it is not automatic. Build to the standard now, but do not write presumption of conformity per EN 18286 into your declaration of conformity until the citation exists.

The findings a gap assessment produces first

Across AI-enabled device projects that already hold ISO 13485 certification, the same six gaps recur with enough regularity to be predictable. Two of them will stop an assessment, two will generate a major nonconformity, and two are housekeeping that costs an afternoon once someone notices.

The pattern behind them is consistent. Companies with strong software quality practice — solid IEC 62304 lifecycle records, a maintained software bill of materials, a working change control process — still fail on the data side, because the data side was never inside the quality system to begin with. Companies with strong data science practice fail on the regulatory side, because their evidence is written for a peer reviewer rather than an assessor. The gap assessment that matters is not a checklist against the standard; it is an attempt to reconstruct, from your controlled records alone, how one specific model came to be the model that shipped.

What to do in the next twelve months

Sequence matters more than speed, and the order is not the order of the clauses. Start by declaring the scope: which AI systems fall inside the quality system, with intended purpose, MDR classification, AI Act classification under Article 6(1) and the interfaces you do not control. Most companies discover here that they disagree internally about whether a particular feature is an AI system at all, and that is cheaper to resolve now than in front of an assessor.

Then write the clause 4.4 compliance strategy, even in draft, because it forces the essential requirement inventory that everything else hangs from. Then attack clause 8.5, because dataset documentation is the only gap that gets harder with time. Then extend the post-market monitoring plan, because it is the item most likely to be reviewed at your next MDR surveillance audit. In parallel, put the AI literacy obligation under Article 4 on the training plan: it has applied since 2 February 2025 to providers and deployers regardless of risk class, and it is trivially easy to evidence and trivially easy to have overlooked. Finally, ask your notified body in writing about their AI Act designation status. Their answer is a planning input, and if it is unsatisfactory you want to know while switching is still an option.

Frequently asked questions

Is EN 18286 a harmonised standard?

Not yet, in the legal sense. It is a published European standard developed under a Commission standardisation request with the intention of supporting Article 17, and it contains an Annex ZA mapping to the AI Act. It becomes a harmonised standard, capable of conferring presumption of conformity under Article 40, only when its reference is cited in the Official Journal of the European Union. That is a Commission decision, and it had not been made at the time of writing.

Do we need EN 18286 if we are already ISO 13485 certified?

You need the requirements of Article 17, which are law. EN 18286 is the most efficient route to demonstrating them, and Article 17(3) lets you satisfy those requirements inside your existing ISO 13485 system rather than alongside it. In practice the work is seven procedures and a set of per-system records, not a new management system.

When do AI Act obligations actually apply to our device?

For AI that is or is embedded in an MDR or IVDR device, 2 August 2028, following the change made by Regulation (EU) 2026/1744. For stand-alone high-risk systems under Annex III, 2 December 2027. The transparency obligations in Article 50 and the AI literacy obligation in Article 4 apply already, and your notified body will begin asking about AI Act readiness during MDR audits well before 2028.

Can we certify against EN 18286?

Certification bodies have announced schemes and the standard is written to be auditable, so voluntary third-party certification will be available. Distinguish that from conformity assessment: for an AI-enabled medical device, the assessment with legal effect is the MDR or IVDR conformity assessment under Article 43(3), run by a body notified under both regimes. A voluntary certificate can be useful evidence and a useful discipline; it is not the regulatory pathway.

What happens if we use a third-party model or a general-purpose AI system?

Article 25 can make you the provider of the high-risk system even where you did not build the model — for example if you place it on the market under your own name or trademark, or substantially modify it. You then carry the Article 17 obligations for a system whose training data you do not control, which makes the supplier agreement and the information obtainable from upstream a design constraint rather than a procurement detail. Settle it before design freeze.

How does this interact with FDA expectations?

Not directly, but the underlying evidence overlaps heavily. The IMDRF Good Machine Learning Practice principles sit behind both the FDA's expectations for AI-enabled device software functions and much of what clauses 8 and 9 ask for, and a predetermined change control plan written for the FDA covers a large part of what the AI Act needs for modification management. One coordinated set of AI documentation rather than a per-jurisdiction set is realistic, provided the jurisdiction-specific content is identified rather than blended.

Conclusions

EN 18286 is the first piece of the AI Act that behaves like a standard rather than a policy, and for medical device manufacturers it is unusually approachable, because it was built on the same product-law logic as ISO 13485. The organisational half of it is already on your shelf. The half that is not — the compliance strategy in clause 4.4, dataset control in clause 8.5, model verification and validation, human oversight content, AI-specific post-market monitoring and a second reportability channel — is a defined and finite body of work.

Three things are worth carrying away. The timeline moved to 2 August 2028 but the substance did not, and the real deadline is your next notified body cycle rather than the legal date. Integration under Article 17(3) is permitted at the level of the management system, not at the level of the evidence, so a paragraph in the quality manual is not a strategy. And the standard is published but not yet cited in the Official Journal, so build to it, document against it, and do not claim presumption of conformity until the citation appears.

The AI/ML Medical Device Documentation Kit on MD Regulatory covers the ten documents that populate the clause 8 and 9 evidence layer — lifecycle plan, data governance and bias management, model validation, AI risk management, the Predetermined Change Control Plan, human oversight and transparency, postmarket performance monitoring, the AI-augmented clinical evaluation and the development SOP — all aligned with EU AI Act, FDA, Health Canada, TGA and ANVISA expectations and immediately deployable inside an existing ISO 13485 quality management system.

Related articles: Software as a Medical Device (SaMD) · IEC 62304 Complete Guide · SBOM for Medical Devices · ISO 14971 Risk Management · EU MDR Technical Documentation · EU MDR Post-Market Surveillance · ISO 13485 Complete Guide