The first draft AI Act QMS standard for consultation: what prEN 18286 signals for providers, users and regulators
prEN 18286 sets out how a provider's quality management system should work to meet the AI Act's Article 17 across the full AI lifecycle. It turns legal duties into implementable governance, lifecycle and evidentiary controls that can be audited.
Once adopted as a harmonised standard and cited in the Official Journal, meeting its normative requirements will give providers a presumption of conformity for the covered essential requirements. Until then, it's guidance with real practical value and a preview of what notified bodies and authorities will expect.
Timing matters. Issued for CEN enquiry on 30 October 2025 with consultation through 22 January 2026, this is the first AI Act standard to reach public review. Legal and product teams now have the earliest dependable view of the controls likely to be required, even if wording still evolves.
For reference, see the AI Act in the Official Journal and the Commission's model for harmonised standards:
What prEN 18286 covers: scope, status and audience
The draft standard defines, implements, maintains and improves a provider's QMS with one objective: meet applicable regulatory requirements through the AI lifecycle while protecting health, safety and fundamental rights. "Quality" here means regulatory compliance and protection, not customer satisfaction.
It applies to any provider placing an AI system on the EU market or putting one into service, regardless of size or location. You can integrate it into sector QMS (e.g., medical devices, automotive) if those systems are updated to include these controls.
Status: prEN submitted to CEN enquiry (public consultation). It is not yet a European Standard and may change. Presumption of conformity will apply only after citation in the Official Journal.
Key concepts (fast refresher)
- Harmonised standard: Once cited, following it gives a rebuttable assumption you meet matching legal duties.
- Presumption of conformity: Burden of proof shifts in your favour when you use a cited standard.
- Essential requirements: Legal duties across risk, data, transparency, oversight, accuracy, cybersecurity, documentation, records and post-market monitoring.
- Annex ZA: The map between clauses of the standard and AI Act obligations. This is what auditors will lean on.
- Common specifications: Binding Commission rules used when standards are absent or incomplete; record any justified alternatives.
- Annex SL: ISO's shared structure that lets you integrate ISO 9001 and ISO/IEC 42001 with minimal duplication.
- New Legislative Framework: EU product safety model linking roles, standards and conformity assessment.
- Conformity assessment: Internal control (Annex VI) or third-party (Annex VII), using your QMS and technical docs as the evidence base.
Why it matters now to in-house legal teams
- It operationalises Article 17: Direct mapping to strategy, design and development, V&V, technical specs, data governance, post-market monitoring, serious incidents, documentation, roles and suppliers.
- It is evidence-led: Documentation must be version-controlled, traceable and auditor-ready, including retention and control rules.
- It mandates cross-functional controls: Top management accountability, competence, supplier control, change management (including predetermined changes), post-market monitoring and incident reporting with strict timelines.
Where prEN 18286 sits in the AI Act standards ecosystem
This is the top-level QMS framework that the topic-specific standards plug into. Expect cross-references and dependencies.
- Risk management: prEN 18228 (Article 9) integrated into clauses 8.1, 9.3, 9.4.5.
- Data quality and bias: prEN 18284 (datasets) and prEN 18283 (bias) implement Article 10; see clauses 8.5 and 4.4.3.
- Trust and performance: prEN 18229 Parts 1-2 cover transparency, human oversight, accuracy, robustness; referenced in clause 8.4.1.
- Cybersecurity: prEN 18282 supports Article 15; see clause 4.4.2(g).
- Logging and monitoring: prEN ISO/IEC 24970 supports traceability and post-market monitoring; see clauses 9.1.1 and 9.4.4.
Core requirements you should see in your QMS
Governance and strategy (clause 4)
- Define QMS scope and boundaries; adopt a written regulatory compliance strategy across the lifecycle.
- Select measures to demonstrate compliance. Prioritise harmonised standards or common specifications and justify any alternatives, documenting coverage gaps.
Documentation and evidence (clause 4.5)
- Auditor-facing documentation, version-controlled and traceable, maintained in an EU-official language.
- Explain process interactions; control operational evidence, retention and external references.
Management responsibility and planning (clauses 5-6)
- Top management sets policy, resources and accountability (including for risk management and state-of-the-art monitoring).
- Define roles and authorities; set measurable objectives tied to Article 17 duties.
Support, competence and communications (clause 7)
- Resource and competence models reflect intended purpose, foreseeable misuse, technology, data types and accessibility impacts.
- Procedures for communications with authorities, notified bodies, other operators and deployers, including reasoned requests and non-conformity notices.
Lifecycle controls (clause 8)
- Translate regulation into requirements: Turn legal and risk controls into verifiable design inputs (transparency, human oversight, accuracy, robustness, cybersecurity, data governance, record keeping). Keep them reviewable and current.
- Verification and validation: Plans with acceptance criteria and reproducibility. Validate before placing on the market or putting into service, including non-substantial modifications.
- Data management: Govern acquisition, preparation, labelling, storage, filtering, aggregation, retention and decommissioning.
- Environmental sustainability: Identify impacts and support deployers with relevant information.
- Technical documentation and instructions for use: Auditor-ready technical files and clear deployer instructions covering integration, installation, deployment and post-market roles.
- Fundamental rights consultation: Structured engagement with affected persons and interested parties, with outcomes feeding into design and risk controls.
Operations, supply chain, change and monitoring (clause 9)
- Deployment and support: Version traceability linked to documentation and logs; use a software bill of materials where appropriate; enable deployer feedback loops.
- Supplier control: Evaluate, select, monitor and re-evaluate suppliers of components, data and services based on regulatory capability; communicate quality, competence, security by design and disclosure expectations; define acceptance and verification, including on-site where needed.
- Change management: Control planned and unintended changes; determine substantial vs non-substantial modifications. For continuous learning, document predetermined changes (description, versions, procedures, acceptance criteria, cumulative impact) and reflect them in instructions for use.
- Post-market monitoring: Proactive, systematic, proportionate to risk, with clear triggers for corrective action and deployer participation where required.
- Serious incidents: Report immediately or within 2 days for critical infrastructure, within 10 days for death, within 15 days otherwise. Allow provisional reporting followed by complete files, with root-cause analyses and corrective actions.
Integration with ISO 9001 and ISO/IEC 42001
Annex C maps to ISO 9001. The structure is familiar-policy, objectives, resources, operations, performance, improvement-but "quality" here means legal conformity and protection of rights. Evidence is regulator-facing and lifecycle controls are AI-specific.
Annex D maps to ISO/IEC 42001. 42001 provides an AI management system; prEN 18286 adds EU regulatory depth such as serious incident reporting, post-market monitoring and technical documentation tied to Article 17.
Why the standard takes a product-centric approach
It aligns with the EU's New Legislative Framework. The unit of conformity is each AI system. Expect tighter traceability from legal requirements to system requirements and tests, closer versioning-to-documentation links, and lifecycle controls applied per system inside one corporate QMS.
Article 17 to clause mapping (quick reference)
- QMS required: Clauses 4.1-4.4, 5.1, 5.3.1-5.3.3
- (a) Strategy for compliance: Clauses 4.4, 9.3.1-9.3.3
- (b) Design & development controls: Clauses 8.3.1-8.3.2
- (c) Verification: Clause 8.4.1
- (d) Validation: Clause 8.4.2
- (e) Selecting technical specs: Clause 4.4.3
- (f) Data management: Clause 8.5
- (g) Risk management system: Clause 8.1 (use prEN 18228)
- (h) Post-market monitoring: Clause 9.4
- (i) Serious incident reporting: Clause 9.5
- (j) Communications with authorities/operators: Clause 7.3
- (k) Technical docs & instructions: Clauses 4.5, 8.7
- (l) Resources & suppliers: Clauses 7.1, 9.2
- (m) Roles, responsibilities, authority: Clauses 5.3.1-5.3.3
Action plan for in-house counsel
- Set governance and scope: Identify the provider per system; define QMS scope across subsidiaries, JVs and outsourced roles. Assign top-management accountability for the QMS and risk management.
- Build a regulatory register: Track applicable AI Act requirements and standards. Record your selected technical specifications, the coverage they provide and any gaps.
- Enforce documentation discipline: Procedure for language, versioning, retention, traceability and central storage. Use standard templates for technical documentation and instructions for use.
- Embed lifecycle controls: Require an "AI system requirements" spec mapped to essential requirements with traceability to V&V plans and acceptance criteria, including foreseeable misuse and human oversight.
- Strengthen supply chain controls: Update due diligence and contracts to include competence, security by design, vulnerability disclosure, audit/verification rights, data provenance and participation in post-market monitoring.
- Tighten change management: Define substantial vs non-substantial modifications and set predetermined change procedures for continuous learning systems.
- Operationalise monitoring and incidents: Implement post-market monitoring with clear triggers and deploy prEN ISO/IEC 24970 logging where appropriate. Test escalation and reporting timelines.
- Build competence: Role-based training for legal, product, engineering and support on AI Act duties, rights risks, bias, accessibility and documentation discipline. Run a cross-functional gap assessment against clauses 4-10 and Annex ZA.
Common pitfalls to avoid
- Positioning the QMS as an IT project rather than a provider-wide governance system led by top management.
- Weak document control (language, versioning, retention, traceability) that breaks audit-readiness.
- Skipping the conversion of legal duties into verifiable system requirements and testable acceptance criteria.
- Supplier blind spots across models, datasets and testing services; fix with risk-based controls and contractual obligations aligned to clause 9.2.
- Uncontrolled changes and missing predetermined change documentation for continuous learning systems.
- Passive post-market monitoring instead of planned, systematic tracking with KPIs and triggers.
- No audit rehearsal. Run internal "red team" audits focused on documentation, supplier files, change logs and incident reporting.
Sector considerations and alignment
If you already run a sector QMS (e.g., ISO 13485), layer in AI-specific regulatory controls: fundamental rights consultation, post-market monitoring, serious incident reporting and data governance. Align hazard definitions, risk criteria and incident taxonomies across regimes to avoid conflicts.
What authorities and auditors will expect to see
- QMS manual, scope, policy, objectives and process map.
- Regulatory register and selection/justification of technical specifications.
- Competency matrices and training records.
- Supplier evaluation, monitoring and verification records.
- Risk management files per AI system.
- System requirements, design/development reviews, V&V plans, test procedures and results.
- Technical documentation and instructions for use per system.
- Change logs, impact assessments and predetermined change records.
- Post-market monitoring plan, KPIs, logs, feedback and corrective actions.
- Serious incident investigations, reports, root-cause and remedial records.
- Management reviews and continual improvement actions.
How this interfaces with conformity assessment
For Annex VI internal control, verify your QMS meets Article 17 and your technical documentation evidences conformity. For Annex VII third-party assessment, expect notified bodies to assess your QMS against Article 17, review surveillance, and evaluate proposed changes. In both routes, your QMS and technical files carry the proof.
Next steps
Treat prEN 18286 as the blueprint to align legal, engineering and product around a single, auditable system. Implemented well, it shortens audits, clarifies supplier expectations, disciplines change and turns post-market monitoring into continuous assurance.
If you plan structured training for legal and product teams, consider curating role-based programs to accelerate adoption. A practical starting point is here: Courses by job.
Your membership also unlocks:
