EN 18286:2026 for the AI Act: What the Standard Asks You to Do

On 14 October 2026, the Official Journal of the European Union published the first harmonised standard that supports the AI Act. It is EN 18286:2026, a quality management system standard for providers of high-risk AI systems, and for the first time providers have a published document to point to when a regulator asks how they comply. The catch is that it covers much less than most headlines suggest. This article explains what the standard asks you to do, which parts of the AI Act it actually presumes you comply with, which parts it leaves to you, and how it relates to the ISO/IEC 42001 certificate many organisations already hold. For the wider regulation, see our EU AI Act complete compliance guide.

“The useful question is not ‘Does this standard make us compliant?’ It is ‘What does it help us demonstrate, and what do we still need to prove?’ That distinction should drive the implementation.” Alexis Hirschhorn

What is EN 18286:2026, and what does it actually cover?

EN 18286:2026 is a quality management system (QMS) standard for providers of high-risk AI systems. If you follow it, the AI Act presumes that your QMS meets Article 17(1) points (a) to (m) and the first sentence of Article 11(1). It does not cover Article 17(2), 17(3) or 17(4), and it does not cover the technical requirements in Section 2 of the Act, with the narrow exception described below. It has no certificate of its own. You demonstrate conformity inside the AI Act conformity assessment, and the standard gives you the management system that makes that assessment possible.

When did EN 18286:2026 take effect, and when do the high-risk deadlines apply?

You will see 19 October in some articles. That is the date of the Commission's announcement, not the date of publication in the Official Journal. CEN-CENELEC approved the standard earlier, on 12 July 2026, and marked its publication in late July.

Does EN 18286:2026 apply to me if I am a provider, a deployer or a model supplier?

The standard is written for providers of high-risk AI systems. A provider is the organisation that develops a system, or has one developed, and places it on the market or puts it into service under its own name. Deployers, meaning organisations that use a high-risk system someone else built, are not covered. Providers of general-purpose AI models are not covered either, as the standard's definition of provider excludes them. If you supply a model that other companies build high-risk systems on, the standard will still reach you indirectly, because your downstream customers will ask for information through the supply chain clause (9.3) and through the agreements required by Article 25(4).

Which Article 17 points get the presumption of conformity, and which conditions apply?

The presumption covers the Article 17 quality management system, point by point, for points (a) to (m). It also covers the first sentence of Article 11(1), which requires technical documentation. Article 17(2) is not covered, which is the proportionality rule that lets you scale the QMS to your size and risk. Article 17(3), which allows integration into an existing sectoral QMS, is not covered either. Article 17(4), the deemed-compliance route for financial institutions, is not covered in full. Only points (g), (h) and (i) remain relevant there.

Four rows carry conditions, and the conditions matter in practice. Point (g) on risk management only presumes conformity if your risk management actually complies with Article 9, and no harmonised standard for Article 9 exists yet. The Article 11(1) row only presumes conformity if your technical file contains every Annex IV item. On our reading, the simplified documentation that the Omnibus introduced for SMEs does not carry that presumption, so an SME that uses the simplified file should not assume it keeps the presumption. A fourth condition is that the standard, as Annex ZA puts it, does not as such guarantee that all requirements are met. The presumption also lasts only as long as the standard stays referenced in the Official Journal, so it is worth checking that reference from time to time.

In short, the standard gives you a strong presumption for the management system around your AI, and a much weaker one for the technical content inside it.

“A policy tells me what should happen. For a specific AI system, I want to see what did happen: which risks were identified, what was tested, who accepted the residual risk and what changed before release.” Alexis Hirschhorn

What does EN 18286:2026 require providers to do, clause by clause?

Most of the work falls into a handful of areas. The first is a documented regulatory compliance strategy (clause 4.4), set per system or per family of systems. It has to explain how you meet each essential requirement and which conformity route applies. For most organisations this is the largest single gap, because it is specific to each system and cannot be copied from a generic policy.

Second, you keep a regulatory register (4.2) that identifies the requirements applying to each system across its life cycle and sets review triggers. Third, each high-risk system needs its own risk management file (8.2) that meets Article 9. An enterprise risk register does not satisfy this on its own. Fourth, the standard sets out how you design, verify and validate the system (8.3 and 8.4), how you manage data (8.5), how you control the life cycle (8.1) and how you keep systems traceable through versions (8.7). For the risk method behind clause 8.2, see our ISO 31000 practitioner guide for Switzerland.

Fifth, you maintain the technical documentation in full, following Annex IV (8.9.2). Sixth, you monitor the system after release (9.5), tied to Article 72, and you run a serious incident procedure (9.6) that meets the Article 73 clocks. Many summaries tie the 2-day clock to death, which is a mistake that is easy to avoid once you check the text.

Seventh, you control changes (9.4) and decide, with a documented test, whether a change is substantial enough to trigger a new conformity assessment. Eighth, you manage suppliers (9.3), including the model and data suppliers you depend on. Ninth, you handle non-compliance (9.7), with corrective action, withdrawal and recall, and a path to notify the authorities. Finally, management has to review the QMS at planned intervals (10.1) and be accountable for it (5.3). Clause numbers have shifted since the public enquiry draft, so check any template against the final text before you rely on it.

What will an auditor ask to see under EN 18286:2026?

Where should EN 18286 evidence live, so an auditor finds it in minutes?

Most of the evidence in the table above already exists somewhere in your organisation. The problem is usually that it sits in five places, with five owners and five version histories, and auditors notice that quickly. The practical answer is one register per AI system, with the strategy, risk file, supplier evidence, incidents and corrective actions linked to that record rather than stored beside it. Acuna GRC's AI Governance module works on that model: each AI system has one record, and its impact assessment, overseers, incidents and linked issues hang off it.

The register does not write your Annex IV file for you, and it does not certify conformity with any law or standard. What it does is show the gaps while there is still time to close them. A system without an approved impact assessment, a supplier whose evidence has expired and an incident that has not yet been notified are all flagged until someone fixes them. If you want to test this table against your own register, the Acuna GRC platform shows the same model in practice.

Is ISO/IEC 42001 enough for EN 18286:2026, or do I need both?

If you hold an ISO/IEC 42001 certificate, you already have part of the structure in place. Both standards share a clause 4 to 10 skeleton, and that is useful. The differences are where the work sits.

ISO/IEC 42001 is a better base for organisation-wide governance. EN 18286 is a better test of whether one specific system has its regulatory file in order. Most providers will need both. Use the 42001 management system as the spine, then add a per-system file for each high-risk system. A 42001 certificate does not give you a presumption of conformity, and it does not produce the per-system files that EN 18286 asks for. For the 42001 side, see our ISO 42001 implementation playbook and our guide to extending an ISO 27001 ISMS into an AI management system.

If you already run an ISO 13485 quality system for medical devices, Article 17(3) lets you integrate the AI Act QMS into it. That integration is legal, but Annex ZA places 17(3) outside the presumption. You will need to show with your own evidence that the integrated system meets Article 17(1). Medical device AI falls under Annex I, which applies from 2 August 2028.

Which national authorities will enforce the AI Act, and where are they in the process?

“Knowing which authority may contact you is only half the preparation. The other half is knowing who inside your organisation will respond, which evidence they will provide and how quickly they can retrieve it.” Alexis Hirschhorn

Does the AI Act apply to Swiss companies, and what is Switzerland doing about AI rules?

Switzerland has no AI-specific law yet. The Federal Chancellery says the government is working on an AI bill, and it expects a draft for consultation by the end of 2026. Other sources point to the first half of 2027, so check the current timing with the Federal Office of Justice before you plan around it. The AI Act still reaches Swiss companies. If you place a high-risk system on the EU market, or your system's output is used in the EU, you are a provider under the Act wherever you are established. Under Article 22, you then need an EU authorised representative, appointed by written mandate before the system is placed on the market. The revised Swiss Federal Act on Data Protection (FADP) applies separately to any Swiss personal data you process.

“For a Swiss company, I would start with where the system is marketed and where its outputs are used, not just where the company is registered. Establish the scope first; then work through the obligations.” Alexis Hirschhorn

Swiss financial institutions need extra care. The Article 17(4) deeming rule refers to Union financial services law, so a FINMA-supervised bank acting as a provider is likely to need the full Article 17 QMS. That is our reading, and counsel should confirm it. FINMA Guidance 08/2024 already expects an inventory, clear responsibilities, testing and independent review, and those expectations map well onto clauses 4.3, 5.3, 8.4 and 10.1. For the financial sector angle, see our ISO 27001 guide for Swiss FinTechs and our DORA guide.

How do I know if my EN 18286:2026 management system is audit-ready?

Most organisations sit between the first and second levels today. The question is how quickly they can reach the third. For what auditors actually check, see our ISO 42001 audit evidence playbook and our ISO 19011:2026 guide for auditors.

How would a Swiss credit-scoring provider implement EN 18286:2026, step by step?

To make this concrete, take a fictional company, HelvetiScore AG in Zurich. It provides a creditworthiness scoring model that a consumer lender in Lyon uses. Under Annex III point 5(b), this is a high-risk system with obligations applying from 2 December 2027. The company already holds ISO/IEC 42001 and ISO/IEC 27001 certificates and is not supervised by FINMA. Its first step is scope. The output is used in the EU, so HelvetiScore is a provider under the AI Act and must appoint an EU authorised representative under Article 22. The second step is the route. Annex III point 5 means internal control under Annex VI, with no notified body involved (Article 43(2)).

The third step is a gap analysis against the rows of Annex ZA, not against the clause mapping in the standard's Annex C, which only matches clauses. HelvetiScore expects gaps in the 4.4 strategy, the Annex IV technical file, and the post-market, incident, and non-compliance clauses (9.4 to 9.7). The fourth step is a matrix that shows how each essential requirement is met. Article 17 is covered by the standard, but Articles 9, 10 and 12 to 15 rely on other means, such as the 42001 risk process, the 27001 and 27090 controls for security, and bias testing. For the security side, see our ISO/IEC 27090 guide.

The data protection side is handled by the lender, which is the controller and needs its own DPIA. HelvetiScore supplies the data documentation described in clause 8.5. A FADP impact assessment is only needed if the company processes Swiss personal data. The fifth step is a separate, signed proportionality memo under Article 17(2), because the standard does not cover that point. The final step is the document set: the strategy, the Annex IV file, the post-market monitoring plan, an incident playbook with the 15, 10 and 2 day clocks, an Article 25(4) agreement with any foundation model supplier, and the EU declaration of conformity.

What mistakes cause EN 18286:2026 audit findings, and how do I avoid them?

The most common mistake is treating the standard as a certificate. There is no EN 18286 certificate, and a vendor who sells one is selling something else. The second is assuming the presumption covers everything in Article 17. It covers the listed points, and some of those only under conditions. The third is using an enterprise risk register in place of a per-system Article 9 file. The fourth is claiming the presumption while using the simplified SME version of Annex IV. The fifth is using clause numbers from an old draft.

Frequently asked questions about EN 18286:2026 and the AI Act

When did the presumption of conformity start?

It started on 14 October 2026, the date of publication in the Official Journal. The 19 October date in some articles refers to the Commission's announcement.

Is EN 18286 mandatory?

No. Harmonised standards are voluntary. If you do not use one, you can still show conformity with Article 17 by other means, but then you carry the full burden of proving it.

Does following EN 18286 make my AI system compliant?

No. The presumption covers the quality management system rules in Article 17 and a few related points, not the product itself. The technical requirements in Section 2 still need their own evidence.

Is there an EN 18286 certificate?

No. Conformity is shown within the AI Act conformity assessment. ISO/IEC 42001 is certifiable, but it does not give a presumption of conformity.

Does EN 18286 cover providers of general-purpose AI models?

No. Those providers are excluded from the standard's definition of provider. Downstream providers reach the model through supply chain controls and the Article 25(4) agreements.

Does it apply to Swiss companies?

Yes, if the system is placed on the EU market or its output is used in the EU. Swiss providers then need an EU authorised representative under Article 22.

Can a biometric provider avoid a notified body with EN 18286?

Not on its own. Internal control under Article 43(1) depends on harmonised standards that cover the Section 2 requirements, and none of those is cited yet. Biometric providers should plan for a notified body assessment.

Can the presumption be lost?

Yes. It lasts only while the standard stays referenced in the Official Journal. If the reference is restricted or withdrawn, the presumption falls away, so monitor the Official Journal.

Where can I train on ISO/IEC 42001, the AI Act and ISO/IEC 27090 to build this system?

If you want to build the QMS yourself, the ISO 42001 Lead Implementer course is the natural starting point, the ISO 42001 Lead Auditor course prepares you to test one, and the Certified EU AI Governance Professional course covers the regulatory side in more depth.

About the author. Alexis Hirschhorn is a Management Systems Certified Lead Auditor and an expert in information and cyber security, cloud security, risk management and governance. Alexis consults for large multinationals, government entities and international organisations.