EN 18286 is the quality management system (QMS) standard that providers of high-risk AI systems can follow to meet Article 17 of the EU AI Act, and since October 14, 2026, following it carries legal weight. That’s the day the European Commission cited the standard in the Official Journal of the EU, which means an AI provider that conforms to it now benefits from a presumption of conformity with the AI Act’s QMS requirements. It’s the first AI Act harmonized standard to reach that point, and most of the other high-risk obligations depend on the QMS it describes.
Below, we walk through what EN 18286:2026 requires and how it’s organized, how it compares with ISO/IEC 42001, and what a realistic plan looks like before high-risk obligations kick in in December 2027.
What Is EN 18286?
EN 18286:2026, Artificial intelligence – Quality management system for EU AI Act regulatory purposes, is a European Standard that specifies requirements and guidance for defining, implementing and maintaining a quality management system for organizations that provide AI systems. It isn’t tied to any sector, so a hiring platform, a credit-scoring engine and an AI-enabled medical device can all build on it.
Background and Development
The standard was drafted by CEN-CENELEC JTC 21, the joint technical committee responsible for artificial intelligence, under the European Commission Standardisation Request M/593 (later amended by M/613). That request asked Europe’s standards bodies to produce a set of standards covering the requirements the AI Act places on high-risk systems: risk management, data governance, logging, transparency, human oversight, accuracy, robustness, cybersecurity, quality management and conformity assessment.
EN 18286 moved fastest. It entered public enquiry as prEN 18286 on October 30, 2025, making it the first AI Act standard to reach that stage. The enquiry closed at the end of December 2025, comments were worked through in early 2026, and the national standards bodies approved it in a formal vote in July 2026. CEN-CENELEC announced its publication at the end of that month.
Relationship to the EU AI Act
The EU AI Act (Regulation (EU) 2024/1689) tells providers of high-risk AI systems what they must achieve. Article 17 requires a documented QMS, written as policies, procedures and instructions, that covers thirteen specific aspects, from a regulatory compliance strategy to an accountability framework. It doesn’t say how to build one.
That’s where harmonized standards come in. Under Article 40, a high-risk system that conforms to a harmonized standard cited in the Official Journal is presumed to meet the requirements that standard covers. EN 18286 was written from the AI Act outward: its Annex ZA maps the standard’s clauses to Article 17(1), points (a) through (m), and to the first sentence of Article 11(1), which requires technical documentation to be drawn up before a system goes to market and kept up to date.
Current Status (prEN 18286 vs EN 18286:2026)
The standard has gone through three stages, and which one you prepared against matters if you started early.
| Stage | Date | What it means for providers |
|---|---|---|
| prEN 18286 (enquiry draft) | October 2025 to December 2025 | Useful preview, no legal effect |
| EN 18286:2026 (published standard) | July 2026 | Best practice and a strong signal of what regulators expect |
| Cited in the Official Journal | October 14, 2026 | Conformity gives presumption of conformity with Article 17(1) |
The citation came through Commission Implementing Decision (EU) 2026/2274, adopted on October 12, 2026 and in force from October 14.
The final text also differs substantively from the draft. Clauses were renumbered, and the draft’s “nonconformity” vocabulary was replaced with non-compliance, defined as failing to meet applicable regulatory requirements. New duties appeared for uniquely identifying each AI system and each conformity-assessed version, retirement became an explicit life cycle stage, continuous-learning systems got their own governance requirements, and serious-incident reporting deadlines were written into the text. The draft’s environmental-sustainability clause was deleted, and Annex ZA was narrowed: the draft’s mapping to Article 72 on post-market monitoring did not survive.
Important: If your gap assessment was built against the prEN 18286 enquiry draft, redo it against the published text. The clause numbers no longer line up, several requirements are new, and the scope of the presumption of conformity is narrower than the draft suggested.
Let Axipro help you build a business continuity plan that's practical, compliant, and audit-ready.
Schedule Your Free Assessment Today
Scope and Purpose of EN 18286
What EN 18286:2026 Specifies
The word “quality” in EN 18286 doesn’t mean what it means in ISO 9001. Here it means compliance with the applicable regulatory requirements of the AI Act. Customer satisfaction and general product performance aren’t the point. Every process in the standard is there to show that an AI system keeps meeting its legal obligations throughout its life cycle.
Two design choices are worth knowing about. First, the standard has no general continual-improvement obligation of the kind ISO management systems carry; the duty is to maintain the effectiveness of the QMS, evaluated through management review. Second, it requires that a life-cycle-wide risk management system exists but leaves the risk management process itself to a separate harmonized standard, prEN 18228, which is still in development.
Who Must Comply with EN 18286
Strictly speaking, nobody has to use EN 18286. Harmonized standards are voluntary. What isn’t voluntary is the Article 17 obligation to operate a QMS, and EN 18286 is the route that comes with legal certainty attached. Choosing another route means proving, on your own terms, that your system meets every point of Article 17.
The obligation sits with providers of high-risk AI systems: organizations that develop a high-risk system, or have one developed, and place it on the EU market or put it into service under their own name. Location doesn’t matter. A US or Gulf-based SaaS company selling a high-risk AI system into the EU is a provider. High-risk systems fall into two groups: Annex III AI systems used in areas such as biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration and the administration of justice, and AI used as a safety component of products covered by the EU product legislation listed in Annex I, such as medical devices.
AI providers and deployers are treated differently. Deployers, the organizations that use a high-risk system under their own authority, aren’t the addressees of EN 18286. But a deployer becomes a provider under Article 25 if it puts its name or trademark on a high-risk system, makes a substantial modification to one, or changes a system’s intended purpose so that it becomes high-risk. Companies that fine-tune or rebrand third-party models for high-risk use cases should check which side of that line they’re on.
How EN 18286 Supports Article 17 of the EU AI Act
The table below shows where each Article 17(1) requirement lands in the standard’s clause structure. Annex ZA of the standard is the authoritative mapping, including the conditions attached to individual rows.
| Article 17(1) requirement | Where EN 18286 addresses it |
|---|---|
| (a) Regulatory compliance strategy, including modification management | Clause 4 (strategy for regulatory compliance), Clause 9 (modifications) |
| (b) Design, design control and design verification | Clause 8 (design and development) |
| (c) Development, quality control and quality assurance | Clause 8 (life cycle processes) |
| (d) Examination, test and validation procedures | Clause 8 (verification and validation) |
| (e) Technical specifications and standards applied | Clause 4 (identifying regulatory requirements) |
| (f) Data management | Clause 8 (data management) |
| (g) Risk management system under Article 9 | Clause 8 (AI system risk management) |
| (h) Post-market monitoring system | Clause 9 (post-market monitoring) |
| (i) Serious incident reporting | Clause 9 (serious incidents) |
| (j) Communication with authorities, notified bodies and others | Clause 7 (communication) |
| (k) Record-keeping | Clauses 4 and 8 (documented information, product documentation) |
| (l) Resource management, including security of supply | Clause 7 (resources) |
| (m) Accountability framework | Clause 5 (roles, responsibilities and authorities) |
Three parts of Article 17 sit outside the presumption. Article 17(2), which lets the QMS be proportionate to the provider’s size, Article 17(3), which lets providers with a sectoral QMS integrate AI Act requirements into it, and Article 17(4), which covers financial institutions, are not covered by Annex ZA. Those provisions still apply; the standard just doesn’t give you a presumption for them.
Key Terms and Definitions in EN 18286
| Term | What it means in practice |
|---|---|
| Quality | Compliance with the applicable regulatory requirements of the AI Act |
| Non-compliance | Failure to meet an applicable regulatory requirement (replaces the draft’s “nonconformity”) |
| Provider | The organization that develops a high-risk AI system, or has it developed, and places it on the market or puts it into service under its own name |
| Deployer | The organization using a high-risk AI system under its own authority |
| Intended purpose | The use the provider designs the system for, which drives its risk classification |
| Substantial modification | A change after market placement, not pre-determined by the provider, that affects compliance or changes the intended purpose |
| Serious incident | An incident or malfunction leading to death or serious harm to health, serious disruption of critical infrastructure, infringement of fundamental-rights obligations, or serious harm to property or the environment |
| Presumption of conformity | The legal effect of conforming to a harmonized standard cited in the Official Journal |
| Post-market monitoring | The provider’s systematic collection and review of experience from systems already in use |
Structure of EN 18286:2026
Clause-by-Clause Overview
Clauses 1 to 3 cover scope, normative references, and terms and definitions. The requirements live in Clauses 4 to 10, which split into an organization layer, where the QMS itself sits, and a per-AI-system layer covering how each system is built and run.
| Clause | Title | What it covers |
|---|---|---|
| 4 | Quality management system | Establishing the QMS, identifying regulatory requirements, scope, the strategy for regulatory compliance, documented information |
| 5 | Leadership | Top-management commitment, quality policy, roles, responsibilities and authorities |
| 6 | Planning | Risks to the functioning of the QMS itself, quality objectives and plans to meet them |
| 7 | Support | Resources, competence, awareness, and communication, including with authorities and notified bodies |
| 8 | AI system realization | Life cycle processes, AI system risk management, design and development, verification and validation, data management, retirement, identification, continuous learning, product documentation |
| 9 | Operations and control | Placing on the market, support services, supply chain, modifications, post-market monitoring, serious incidents, non-compliance |
| 10 | Performance evaluation | Management review and planning of changes to the QMS |
The clause headings will look familiar to anyone who has worked with ISO 9001 or ISO/IEC 42001, but the substance is product-centric. Clauses 8 and 9 do most of the work, and they’re written around individual AI systems rather than the organization as a whole.
Annexes
| Annex | Purpose |
|---|---|
| Annex A (informative) | Additional guidance supporting the requirements |
| Annex B (informative) | Clause correspondence with EN ISO 9001:2015 |
| Annex C (informative) | Clause correspondence with EN ISO/IEC 42001 |
| Annex ZA (informative) | Relationship between the standard and the AI Act requirements it covers; the basis of the presumption of conformity |
| Annex ZB (informative) | Significant technical changes between prEN 18286 and the published standard |
Worth Knowing: Annexes B and C Map Clauses
Annexes B and C map clauses and subclauses only, not requirements or concepts. They help teams that already run ISO 9001 or ISO/IEC 42001 find their way around. They don’t say those systems already satisfy EN 18286.
Core Requirements of EN 18286
General Requirements
Clause 4 requires the provider to establish and maintain a QMS, identify the regulatory requirements that apply to each AI system it provides, and define the QMS scope. The centerpiece is a strategy for regulatory compliance: a documented plan for how each applicable requirement will be met, which conformity assessment procedure applies, and how modifications will be managed. Where the provider doesn’t apply a harmonized standard in full, the strategy has to say what it uses instead.
Documentation Requirements
The AI Act wants the QMS documented “in a systematic and orderly manner,” and EN 18286 turns that into formal document control: versioning, approval, retention rules, and controlled access to documented information. There’s a practical reason for this. Article 18 of the Act requires providers to keep QMS documentation, technical documentation and conformity records available to national authorities for ten years after a system is placed on the market. A document control system that can’t reproduce last year’s version of a procedure won’t survive that obligation.
Management Responsibility and Leadership
Clause 5 asks top management to own the QMS: commit to it, set a quality policy, and assign roles and authorities. This is where Article 17(1)(m), the accountability framework, gets met. Regulators will expect named owners for regulatory compliance, risk management, post-market monitoring and incident reporting. “The AI team” won’t cut it.
Context of the Organization
Unlike Annex SL standards, EN 18286 doesn’t open with a generic “context of the organization” clause. The context work it asks for is regulatory and specific: which AI systems you provide, what each one’s intended purpose is, which role you hold for each (provider, or deployer that has become a provider), and which requirements of the AI Act and any sectoral legislation apply. For many organizations, building this inventory is the first real piece of work, and it’s harder than it sounds.
Planning and Risk Management
EN 18286 distinguishes two kinds of risk, and confusing them is a common early mistake. Clause 6 deals with risks to the QMS itself: what could stop the system from working, such as key-person dependency or a supplier that can’t provide evidence. The risks AI systems pose to health, safety and fundamental rights are handled separately under the AI system risk management requirements in Clause 8, which implement Article 9 of the Act.
Support and Resources
Clause 7 covers resources, competence, awareness and communication. Two points deserve attention. Article 17(1)(l) specifically mentions security of supply, which for AI providers means compute capacity, third-party models and data sources you depend on. The communication requirements also include structured channels with national competent authorities, market surveillance authorities, notified bodies, customers, and other operators.
Operation: AI System Realization
Clause 8 governs how each AI system is built, from inception through design, development, verification, validation and eventual retirement. It includes data management (acquisition, labeling, storage, filtering, retention and the rest of the operations listed in Article 17(1)(f)), product documentation, and requirements for systems that continue to learn after release. Teams familiar with ISO/IEC 5338, the international standard for AI system life cycle processes, will recognize the shape, but EN 18286 ties each stage to a regulatory requirement.
Operation and Control of AI Systems
Clause 9 picks up once a system is ready to ship: placing it on the market or putting it into service, support services for deployers, control of the supply chain, management of modifications, post-market monitoring, serious-incident reporting and handling of non-compliance. When a system is found not to comply, the standard sets out the remedial options the Act already contemplates: bring it into compliance, withdraw it, disable it or recall it, and inform market surveillance authorities where the system presents a risk.
Performance Evaluation and Improvement
Clause 10 centers on management review and the planning of changes to the QMS. Top management reviews whether the system is still effective, using inputs such as post-market monitoring data, incidents, non-compliance findings and changes in regulation, and decides what has to change. However you gather that input, an internal audit is usually the quickest way to get an honest picture before the review.
The AI System Life-Cycle Under EN 18286
Design and Development Controls
Design starts from the intended purpose. The provider translates regulatory requirements into verifiable system requirements, then defines tests with acceptance criteria that show each one is met. Article 17(1)(d) also expects the provider to define when examination, testing, and validation happen (before, during, and after development) and how often. The artifact that ties all of this together is a traceability matrix linking each legal requirement to a system requirement, a test and a result.
Release and Deployment
Before a high-risk system reaches the market, it must pass conformity assessment. For most Annex III systems, that’s internal control under Annex VI of the Act, which the provider performs itself. Notified bodies come in under Annex VII for certain biometric systems and through the sectoral procedures for Annex I products such as medical devices. Either way, the QMS documentation is what gets examined.
Release also involves the EU declaration of conformity, CE marking, registration in the EU database, and instructions for use for deployers. EN 18286 adds a duty to give each conformity-assessed version a unique reference.
Post-Market Monitoring and Incident Handling
Providers must run a post-market monitoring system under Article 72 that actively collects and analyzes data on how their systems perform once deployed. Serious incident reporting follows Article 73, and EN 18286 writes the deadlines into the QMS: reporting is triggered once a causal link between the AI system and the incident is established or reasonably likely, with outer limits of 15 days in general, 10 days where a person has died, and 2 days for widespread infringements or serious disruption of critical infrastructure.
Important: The final Annex ZA has no row for Article 72. Following EN 18286’s post-market monitoring clauses is good practice, but it doesn’t give you a presumption of conformity with Article 72 itself. Build your monitoring plan against Article 72 and the Commission’s template as well as the standard.
Change Management
The standard expects a clear boundary between changes that count as a substantial modification, which can trigger a new conformity assessment, and changes that don’t. For continuous-learning systems, changes must be pre-determined and documented at design time, then verified, validated and logged as they happen, and reflected in the technical documentation and instructions for use. Under Article 43(4) of the Act, changes pre-determined in the initial conformity assessment don’t count as substantial modifications, so that upfront documentation is what lets a learning system keep improving without dragging you back through conformity assessment.
Traceability and Record-Keeping
EN 18286 requires unique identification of each AI system placed on the market so it stays traceable through the distribution chain. Separately, Articles 12 and 19 of the Act require high-risk systems to log events automatically and providers to retain those logs for at least six months. The QMS has to make sure the records exist, can be found and are kept for the required period, which for QMS and technical documentation is ten years.
AI-Specific Risk Management in EN 18286
The risk management system required by Article 9 is a continuous, iterative process across the whole life cycle. It identifies and evaluates risks to health, safety and fundamental rights from the system’s intended use and reasonably foreseeable misuse, adopts measures to address them, and tests whether those measures work. EN 18286 requires this system to exist and to be integrated into realization and operations. It doesn’t describe the process in depth; that’s the job of prEN 18228, the AI risk management harmonized standard whose public enquiry closed on July 30, 2026.
Until prEN 18228 is finalized and cited, providers have to choose their own method. ISO/IEC 23894 offers useful guidance on AI risk management, but it isn’t a harmonized standard and predates the final AI Act text. Medical device manufacturers can build on their ISO 14971 processes. Whatever method you choose, the evidence has to show that fundamental-rights risks, including bias in training data, were assessed alongside safety risks.
Insider Note: The risk that most AI QMS projects underestimate is supplier risk. If your system relies on a third-party foundation model, an annotation vendor or an external validation lab, EN 18286 still makes you responsible for the evidence. Ask suppliers early what documentation they can actually provide, because “we don’t share that” is a common answer, and it can take weeks to resolve.
EN 18286 vs ISO/IEC 42001
Key Similarities
ISO/IEC 42001 and EN 18286 are both management system standards for AI, both use a Clause 4 to 10 skeleton, and both cover leadership, planning, support, operations and evaluation. An organization running an AI management system (AIMS) under ISO/IEC 42001 already has policies, roles, AI risk assessment, impact assessment and document control in place, and much of that carries over.
Key Differences
The two standards answer different questions. ISO/IEC 42001 asks how an organization governs its use and development of AI in general. EN 18286 asks how a provider demonstrates that each high-risk AI system it places on the EU market complies with the AI Act. European standardization work concluded early on that ISO/IEC 42001 wasn’t aligned closely enough with the final AI Act text to be harmonized as-is, which is why EN 18286 exists at all.
| Dimension | EN 18286:2026 | ISO/IEC 42001:2023 |
|---|---|---|
| Purpose | Regulatory QMS implementing Article 17 of the AI Act | AI governance management system for any organization |
| Focus | Individual AI systems and their life cycle | The organization and its AI activities |
| Meaning of “quality” | Compliance with AI Act requirements | Not the central concept; focus is responsible AI governance |
| Who uses it | Primarily providers of high-risk AI systems | Providers, developers and users of AI |
| Legal effect | Presumption of conformity with Article 17(1) and the first sentence of Article 11(1) | None under the AI Act |
| Certification | No certification scheme required; conformity assessed through AI Act procedures | Accredited third-party certification, three-year cycle |
| AI Act specifics | Serious-incident deadlines, non-compliance remedies, market surveillance notification, system identification | Not covered |
| Improvement model | Maintain effectiveness through management review | Continual improvement |
Presumption of Conformity Considerations
An ISO/IEC 42001 certificate gives no presumption of conformity under the AI Act. EN 18286 does, but only for what Annex ZA covers, and only if you conform to its normative requirements. If you already hold ISO/IEC 42001, the best move is usually to keep it (enterprise buyers increasingly ask for it) and extend the same management system to cover EN 18286, instead of running two systems side by side. Our ISO 42001 certification support covers the AIMS side of that. Companies selling AI agents to enterprises may also get asked about AIUC-1 certification, a separate agent-focused standard that buyers treat as a complement to both.
How to Prepare for EN 18286 Compliance
The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the high-risk deadlines. Obligations for Annex III systems now apply from December 2, 2027, and obligations for AI embedded in Annex I products apply from August 2, 2028. That sounds like plenty of time. It isn’t, because a QMS has to run for a while before it produces the records that prove it works. Our overview of the EU AI Act timeline covers the other dates in play.
Gap Assessment Steps
A useful EN 18286 gap assessment follows a clear sequence:
- Inventory your AI systems and record each one’s intended purpose, risk classification and your role as provider or deployer.
- Confirm which systems are high-risk under Annex III or Annex I, and which conformity assessment route applies to each.
- Map existing management systems (ISO 9001, ISO 13485, ISO/IEC 42001, ISO/IEC 27001) against EN 18286 clause by clause, using Annexes B and C as a starting point only.
- Test the AI-specific requirements that generic systems never cover: the strategy for regulatory compliance, the traceability matrix, data management for training and test sets, serious-incident deadlines, non-compliance handling and system identification.
- Check supplier evidence for every third-party model, dataset and service in the life cycle.
- Prioritize gaps by deadline and effort, and turn them into a remediation plan with owners.
A structured compliance gap analysis against the published text, not the enquiry draft, is the fastest way to know how far you really are from conformity.
Let Axipro help you build a business continuity plan that's practical, compliant, and audit-ready.
Schedule Your Free Assessment Today
Building an AI QMS
Most organizations shouldn’t build an EN 18286 system from scratch. Article 17(3) lets providers already subject to sectoral QMS obligations integrate AI Act requirements into their existing system, and the standard is written to support that. Medical device manufacturers running ISO 13485 quality management systems are the clearest case: extend design controls, data management, post-market surveillance and change control rather than building a second QMS.
For a company that already runs ISO/IEC 42001 or ISO 9001, extending to EN 18286 typically takes around three to six months of focused work. Starting from little more than an information security program, plan on six to twelve months, and longer if your systems retrain frequently or depend on suppliers who can’t produce evidence. The policies are the quick part. The slow parts are the traceability matrix, data management records, and a post-market monitoring system that has actually generated data.
Evidence and Audit Readiness
Whether your conformity assessment is internal or carried out by a notified body, someone will eventually ask to see proof. The evidence that matters most includes the strategy for regulatory compliance, the traceability matrix with test results, data management records for each dataset, risk management files, supplier evaluations, a post-market monitoring plan, an incident procedure that has been rehearsed, management review records, and technical documentation that meets Annex IV of the Act.
One pattern shows up consistently in early AI governance projects: the policy set comes together quickly, and then the work stalls on traceability. Engineering teams usually have plenty of tests. What they rarely have is the thread connecting a specific legal requirement to a specific system requirement, a specific test and a recorded result. Building that thread retroactively for a system already in production is far slower than designing it in, which is the best argument for starting now rather than in late 2027.
Axipro’s EU AI Act compliance and readiness services cover this full path, from AI system inventory and gap assessment to building the QMS, preparing technical documentation and getting evidence ready for conformity assessment.
Pro Tip: Run a tabletop exercise
Run a tabletop exercise on a simulated serious incident before you need the procedure. The 2-day reporting window for critical-infrastructure cases leaves no room to work out who decides whether a causal link is “reasonably likely,” who drafts the report, and who sends it to which authority.
Conclusion
EN 18286:2026 turns Article 17 of the AI Act into an auditable quality management system, and its citation in the Official Journal makes it the clearest route to demonstrating that high-risk AI systems are compliant. It’s narrower than it first appears: its presumption covers Article 17(1) and the first sentence of Article 11(1), not post-market monitoring or the proportionality and integration provisions. It’s also deeper than ISO/IEC 42001 where it counts, at the level of individual systems, incidents and evidence. With Annex III obligations applying from December 2027, anyone who starts their gap assessment now should have a QMS with a real track record by the deadline. Providers that wait will probably have the policies written and not much else.
Frequently Asked Questions
Is a generic ISO 9001 QMS enough for Article 17 compliance?
No. ISO 9001 gives you a sound management system shell, but it says nothing about AI-specific requirements such as data management for training sets, the Article 9 risk management system, serious-incident deadlines, continuous-learning changes or system identification. EN 18286’s Annex B maps its clauses to ISO 9001, which helps you reuse what you have, but the mapping is at clause level only and expressly doesn’t claim the requirements are equivalent.
Who needs an EN 18286 AI QMS?
Any provider placing a high-risk AI system on the EU market or putting one into service, wherever it is based, needs a QMS that meets Article 17, and EN 18286 is the route that carries a presumption of conformity. That includes non-EU companies selling into the EU and deployers that become providers by rebranding, substantially modifying or repurposing a system. Providers of AI systems that aren’t high-risk can use the standard voluntarily, but they aren’t required to operate an Article 17 QMS.
How does EN 18286 relate to technical documentation requirements?
EN 18286 covers the first sentence of Article 11(1): technical documentation has to be drawn up before a system is placed on the market or put into service, and kept up to date. The QMS supplies the processes and records that feed that documentation. The detailed content of the technical documentation, set out in Annex IV of the AI Act, still has to be prepared separately for each system.
When does EN 18286:2026 become applicable?
The standard was published by CEN-CENELEC in July 2026 and cited in the Official Journal on October 14, 2026, so it can be used to claim presumption of conformity now. The underlying obligation to run a QMS applies from December 2, 2027 for Annex III high-risk systems and from August 2, 2028 for high-risk AI in Annex I products, following the Digital Omnibus. Systems already on the market before those dates generally only have to comply once they undergo a significant change in design.
Does EN 18286 certification grant presumption of conformity with the AI Act?
Presumption of conformity comes from conforming to the standard’s normative requirements, not from holding a certificate. The AI Act has its own conformity assessment procedures, internal control under Annex VI or a notified body assessment under Annex VII where required, and those are what lead to the EU declaration of conformity and CE marking. A third-party audit against EN 18286 can be useful as independent assurance, but it doesn’t replace those procedures.
