Artifact GuideEU

EU AI Act Standards and quality management

Use EN 18286:2026 to organise provider quality-management procedures and keep evidence that they work for each high-risk system.

Its legal effect covers specified requirements only. Check the cited edition, Annex ZA conditions and duties that still need separate evidence.

Author
Sorena AI
Published
Oct 16, 2026
Updated
Oct 21, 2026
Overview

EN 18286:2026 is a voluntary for a provider's (QMS). Its Official Journal citation took effect on 14 October 2026. If you use it, record the legal requirement, standard clause, coverage condition, procedure and evidence for each claim.

Section 1

Check the citation and its limits

Decision (EU) 2026/2274 cites EN 18286:2026 in the Official Journal. The Commission adopted the decision on 12 October 2026; publication and legal effect followed on 14 October. The earlier July publication announcement by the standards body did not create that legal effect.

The covers only the requirements mapped by the standard.

The citation neither changes the Act's application dates nor creates a provider certification deadline. Record the applicable legal duties separately. Applying the standard does not by itself satisfy every AI Act requirement, complete conformity assessment or decide whether a notified body is required.

Section 2

Check the conditions in Annex ZA

Annex ZA is the table linking standard clauses to legal requirements and coverage conditions. It maps the first sentence of Article 11(1) to clause 8.9.2 only if the technical file contains every Annex IV element. It does not cover all of Article 11.

For the first sentence of Article 17(1), it identifies the quality-management, leadership, planning, lifecycle and review clauses. Check and implement each legal requirement individually, using the complete table.

Coverage of the first part of Article 17(1)'s second sentence is conditional on documenting at least all aspects in Article 17(1)(a)-(m), using the clauses identified in Annex ZA. Article 17(1)(g)'s risk-management coverage is conditional on an Article 9-compliant risk management system.

Article 17(2), (3) and (4) are not covered. Assess proportionality under paragraph 2 separately, including the rigour and protection required regardless of organisational size. Where relevant, document how existing sectoral quality-management obligations accommodate Article 17 under paragraph 3, and assess the financial-institution governance provision and its exceptions under paragraph 4.

Section 3

Link Article 17 procedures to evidence

Use this selected clause map to connect Article 17 procedures to records. Copy the complete applicable mapping and conditions from Annex ZA into your own register. The record examples below are practical suggestions, not prescribed forms.

  • 17(1)(a), regulatory strategy: selected clauses 4.4.1 and 9.4. Keep the intended purpose, selected assessment route and modification decisions.
  • 17(1)(b), design controls: selected clauses 8.3.2 and 8.4.2. Link approved requirements, specifications, design reviews and verification results.
  • 17(1)(c), development and quality assurance: selected clauses 8.3.2.4, 8.4.3.1 and 9.7.3. Retain records of design-control execution, validation conclusions and corrective-action results.
  • 17(1)(d), examinations and testing: selected clauses 8.1.3 and 8.4.3.1. Record test frequency, acceptance criteria, results and validation decisions.
  • 17(1)(e), technical specifications: 4.4.3. List applied standards and the measures proving requirements that those standards leave uncovered.
  • 17(1)(f), data management: 8.5. Keep dataset provenance, collection, labelling, filtering, storage and retention records as applicable.
  • 17(1)(g), risk management: 8.2. Link the Article 9-compliant system, risk evaluations and implemented controls; check the Annex ZA condition explicitly.
  • 17(1)(h), post-market monitoring: 9.1 and 9.5. Link system identifiers, the monitoring plan, gathered feedback and action decisions.
  • 17(1)(i), serious-incident reporting: 9.6.1 and 9.6.2.1. Keep escalation, investigation and authority-reporting records against the applicable legal deadlines.
  • 17(1)(j), communications: 7.3 and 9.7.2.2. Identify contacts and retain authority, notified-body and operator communications.
  • 17(1)(k), records: selected clauses 4.5, 8.7 and 8.9.2. Connect controlled documents, instructions and monitoring information to system versions.
  • 17(1)(l), resources and supply: 7.1, 7.2 and 9.3. Retain competence evidence, supplier evaluations and acceptance checks.
  • 17(1)(m), accountability: 5.1, 5.3 and 7.4. Record management responsibilities, decision authority and personnel awareness.
Section 4

Apply procedures from design to retirement

Under clauses 4-7, define the systems, intended purposes and applicable law. Assign decision authority and competent staff, set measurable quality objectives and control documents. Assess risks to the management process, such as losing records, separately from risks caused by the AI system.

During design, translate obligations into approved, verifiable system requirements. Under clause 8, connect specifications to verification and intended-purpose validation. Record test conditions, dataset and software versions, acceptance criteria and conclusions. Complete validation before market release or putting into service; link the results to current technical documentation and instructions.

For operation, apply clause 9 supplier controls, system identification, monitoring, incident escalation and corrective action. Record why a modification is or is not substantial, its risk consequences and any new assessment required. For continuous-learning systems, document predetermined changes, their validation, change logs and instructions.

Plan retirement measures and tell deployers what they must do.

Use clause 10 management reviews to examine effectiveness, monitoring results and changes in law or standards. Record decisions, resources, owners and completed changes. Review the QMS when a serious-incident investigation finds its measures inadequate.

Section 5

Reuse ISO processes after checking the differences

Annexes B and C compare the standard's clause structure with EN ISO 9001:2015 and EN ISO/IEC 42001:2026. They show structural correspondence, not equivalent requirements or concepts. An ISO certificate or matching clause number cannot establish conformity with EN 18286 or the whole AI Act.

As a recommended integration method, reuse controlled documents, role assignments, supplier reviews and management meetings where they meet the specific requirement. Add the regulatory strategy and AI-system evidence that remain missing. Record the edition and scope of any existing ISO system before accepting its records.

Section 6

Keep a standards coverage register

For each system and version, record the legal requirement, standard edition, Official Journal reference and status, complete applicable Annex ZA mapping, condition, procedure owner, execution record, remaining gap and approval. Copy the mapping from the standard. Attach the Annex IV completeness check for Article 11 and the Article 9 assessment for Article 17(1)(g).

Assess Article 17(2)-(4) separately.

Use the technical-documentation and provider-evidence templates for records and the conformity assessment guide for assessment boundaries. EN 18286 alone does not establish the full Section 2 coverage needed for the Article 43 biometrics internal-control conditions; check the high-risk route selector before deciding the assessment route.

Assign an owner to review the latest Official Journal list and relevant standards changes. Annex ZA limits continued presumption to the period during which the reference remains published. Record each review, assess changed coverage and update affected procedures, system evidence and assessment decisions.

Primary sources

References and citations

cencenelec.eu
Referenced sections
  • Official public identification of the standard and its Article 17 purpose. Consult the standard's Annex ZA for the detailed correspondence and conditions.
eur-lex.europa.eu
Referenced sections
  • Legal procedure categories. Selected clause references follow EN 18286:2026 Annex ZA; evidence suggestions are working examples.
Show all related guides (34)

EU AI Act serious incident reporting steps

Check serious-incident harm, preserve evidence and choose the reporting deadline and recipient for high-risk AI systems and systemic-risk GPAI models.

EU AI Act timeline and phased deadlines

See which AI Act rules apply now and what comes next. Check high-risk dates, older-model transitions and the difference between legal and standards dates.

EU AI Act vs ISO/IEC 42001

Compare AI Act legal duties with ISO/IEC 42001 management-system requirements. See which records can be reused and what certification does and does not cover.

EU AI Act vs NIST AI RMF

Compare AI Act legal duties with the voluntary NIST AI RMF. Map risk records to specific requirements and identify legal steps that need separate evidence.

EU AI Act: Check whether the Act applies

Use five checks to establish AI Act scope, exclusions, your role, risk categories and evidence for the decision.

EU AI Act: Choose a high-risk assessment route

Choose between provider-run internal control, notified-body assessment and a product-law procedure before release.

EU AI Act: Classify a tool before approval

Classify an AI tool or model before purchase or release. Check EU scope, prohibited uses, high-risk rules, transparency and GPAI duties.

EU AI Act: Compliance checklist

Check each AI tool, decide which duties apply, and give every action an owner and evidence link.

EU AI Act: Conformity assessment

Some high-risk systems use a provider-run assessment. Others need an authorised independent assessor or a product-law assessment.

EU AI Act: Does it apply to you?

Check whether the AI Act applies to your system or model, identify your provider or deployer role, and keep evidence for the decision.

EU AI Act: Duties for general-purpose AI models

Check GPAI provider duties for documentation, integrator information, copyright and training summaries, plus extra requirements for systemic-risk models.

EU AI Act: High-risk requirements

High-risk providers must meet system requirements before supply. Deployers must use and monitor the system under the provider's instructions.

EU AI Act: High-risk system checklist

Check the system's risk controls, data, documentation, logs, instructions, human oversight and testing before release.

EU AI Act: Is your use case high-risk?

Find high-risk AI examples in recruitment, banking, education, healthcare, public services and products. Check Article 6 conditions and exceptions.

EU AI Act: Plan your compliance work

Build a compliance plan for each AI tool: your role, the duties that apply, the evidence needed and the person responsible.

EU AI Act: Technical file and evidence templates

Build the technical file and provider records for a high-risk AI system, with owners and evidence links for each field.

EU AI Act: When must you disclose AI?

Check Article 50 chatbot notices, synthetic-output marking, biometric notices, deepfake disclosures and public-interest text exceptions.

EU AI Act: Which AI uses are banned?

Check Article 5 prohibited AI practices, the narrow exceptions, evidence to retain and the new content prohibitions from 2 December 2026.

Are you the provider or the deployer? | EU AI Act

Check provider, deployer, importer and distributor roles, when changes create provider duties, and how model and system responsibilities differ.

Do you need a notified body? | EU AI Act

Find the assessment route for high-risk AI, when a notified body is required, and which declaration, CE-marking and registration records you need.

Does this tool count as AI? | EU AI Act

Check whether software counts as AI, how models differ from systems, when embedded AI is high-risk, and which scope and role evidence to keep.

How do you monitor AI after release? | EU AI Act

Understand high-risk AI monitoring under Article 72: the provider plan, deployer feedback, logs, corrective action, incidents and change reviews.

Is this industry use high-risk? | EU AI Act

See which industry AI uses fall under Annex III, when Article 6(3) can apply, and what providers must document and register.

What belongs in the technical file? | EU AI Act

See what Article 11 and Annex IV require in high-risk AI technical documentation, from system identity and testing to monitoring and retention.

What must general-purpose model providers do? | EU AI Act

Check general-purpose model duties, systemic-risk classification, open-source conditions, copyright, training summaries, incidents and application dates.

When must you disclose AI use? | EU AI Act

Check AI interaction notices, technical content marking, biometric notices, deepfake and text disclosures, exceptions, accessibility and deadlines.

When must you report a serious incident? | EU AI Act

Check serious-incident outcomes, reporting roles, 15-, 10- and two-day deadlines, authority recipients, corrective action and the separate model route.

Who needs a rights impact assessment? | EU AI Act

Check who needs an Article 27 fundamental rights impact assessment, what it must cover, and how privacy assessments, notification and registration fit.