Appearance
Operationalizing EN 18286 in Modulos
This page is the rollout playbook for EN 18286:2026 in Modulos. It assumes you are oriented on the standard itself, its clause structure and its Annex ZA scope (see the framework overview), and covers the OFF-19 / MFF-19 template split, the clause-to-Requirement map, the Control estate, and what the 1.0.26 template upgrade changed. Facts on this page reflect Modulos templates 1.0.26.
Recommended project structure (OFF-19 org + MFF-19 per AI system)
- One organization project with
OFF-19attached. This holds the quality management system itself: regulatory-requirement identification, QMS scope, the strategy for regulatory compliance, documented information, leadership and roles, planning, support, serious-incident reporting, non-compliance handling, and management review. - One AI-application project per AI system in the QMS scope, with
MFF-19attached. Each holds that system's realization and operations evidence: life cycle processes, risk management, design and development, verification and validation, data management, retirement, identification, continuous learning, product documentation, placing on the market and putting into service, support services, supply chain, modifications, and post-market monitoring.
OFF-19 carries 13 Requirements (ORF-410–ORF-422) with 37 distinct mapped Controls; MFF-19 carries 11 Requirements (MRF-380–MRF-388, MRF-448, MRF-449) with 46 distinct mapped Controls. Both templates carry the Standard label and the en18286-qms icon that distinguishes published ENs from prEN drafts.
The two templates are not parallel checklists; they are two coupled loops running at different speeds. The organization project runs the QMS itself, and each application project runs one AI system's realization cycle inside it:
EN 18286 in operation
Two coupled loops: the QMS, and each AI system.
Organization · OFF-19the slow loop — runs the QMS
4.4Compliance strategy
→
6.2Quality objectives
→
10.1Management review
→
10.2Planning of changes
Loop
Changes flow down
Reviewed changes re-enter realization — 10.2 → 8
Signals flow up
Monitoring feeds performance evaluation (9.5 → 10); an incident investigation finding the QMS inadequate forces an extra review (9.6 → 10.1); a substantial modification triggers the process-review check (10.2.2)
Per AI system · MFF-19the fast loop — one per system in scope
8.3Design & development
→
8.4Verify & validate
→
9.1Place on market
→
9.5Monitor
→
9.4Modify
Loop
The standard carries no continual-improvement clause; effectiveness is maintained by the coupling — operation reports upward into performance evaluation, and reviewed changes descend back into realization.
Organization Requirements (OFF-19)
| Requirement | Name | EN 18286 clauses |
|---|---|---|
ORF-410 | Quality management system — general | 4.1 |
ORF-411 | Identifying regulatory requirements | 4.2 |
ORF-412 | Scope of the quality management system | 4.3 |
ORF-413 | Strategy for regulatory compliance | 4.4 |
ORF-414 | Documented information | 4.5 |
ORF-415 | Management responsibility | 5.1 |
ORF-416 | Quality policy | 5.2 |
ORF-417 | Roles, responsibilities and authorities | 5.3 |
ORF-418 | Planning — QMS risks, quality objectives | 6.1, 6.2 |
ORF-419 | Support — resources, competence, communication | 7.1–7.4 |
ORF-420 | Reporting serious incidents | 9.6 |
ORF-421 | Non-compliance and corrective action | 9.7 |
ORF-422 | Performance evaluation — review and planning of changes | 10.1, 10.2 |
Application Requirements (MFF-19)
| Requirement | Name | EN 18286 clauses |
|---|---|---|
MRF-380 | Determining life cycle stages and realization processes | 8.1 |
MRF-381 | Actions to address risks (risk management system) | 8.2 |
MRF-382 | Inception, design and development | 8.3 |
MRF-383 | Verification and validation | 8.4 |
MRF-384 | Data management | 8.5 |
MRF-385 | Support services, modifications and continuous learning | 9.2, 9.4, 8.8 |
MRF-386 | Supply chain | 9.3 |
MRF-387 | Post-market monitoring | 9.5 |
MRF-388 | Product documentation (technical documentation and instructions for use) | 8.9 |
MRF-448 | Identification and traceability of AI systems | 8.7, 9.1 |
MRF-449 | Retirement of AI systems | 8.6 |
Each Requirement's detail text records the clause references and its Annex ZA Table ZA.1 rows, so the presumption trail is auditable from inside the project.
The Control estate: broad reuse plus EN-specific overlays
Most of the 83 distinct Controls are reused from the platform's existing estates: the EU AI Act lifecycle, verification, data, documentation, post-market monitoring and retirement families on the application side, and, on the organization side, management-system and governance controls (policy, objectives, leadership, internal audit, documented information) that other platform frameworks also map. Evidence recorded on a shared Control serves every framework that maps it; the practical reuse partner is the EU AI Act estate, where 28 of MFF-19's 46 Controls arrive already shared. Direct overlap with the ISO 42001 templates is limited to the documented-information family; EN 18286 vs ISO/IEC 42001 quantifies the split.
Fifteen overlay Controls carry what only this standard demands:
| Control | Name | Carries |
|---|---|---|
MCF-620 | Supplier evaluation, selection and monitoring | Clause 9.3 supplier lifecycle |
MCF-622 | Design and development requirements control | Clause 8.3 requirements review, specifications, design controls |
MCF-623 | AI system version control and substantial-modification review | Clauses 8.7, 9.1 and 9.4: version references, identification at placing on the market or putting into service, substantial-modification review |
MCF-668 | Continuous-learning change governance | Clause 8.8: pre-determined changes, per-change verification, change logging |
MCF-669 | Retirement communication to deployers | Clause 8.6: the deployer-measure notice and its evidence |
OCF-321 | Regulatory compliance strategy | Clause 4.4 strategy artifact, including measures documentation |
OCF-322 | Serious incident reporting procedure and timelines | Clause 9.6: the 2/10/15-day deadlines, deployer reporting and use suspension |
OCF-323 | Resources for the quality management system | Clause 7.1 |
OCF-324 | Regulatory and risk accountability roles | Clause 5.3 named top-management accountabilities |
OCF-325 | QMS-functioning risk planning | Clause 6.1 |
OCF-326 | QMS management review and change control | Clauses 10.1 and 10.2 |
OCF-327 | Quality objectives and planning | Clause 6.2 |
OCF-328 | QMS competence determination and evidence | Clause 7.2 |
OCF-329 | Authority information provision process | Clause 7.3.2.4 compliance-demonstration pipeline |
OCF-371 | Non-compliance detection and market corrective action | Clause 9.7: detection, the remedial menu, market-surveillance notification |
What the 1.0.26 upgrade changed (prEN → EN)
Templates 1.0.26 moved the pair from the enquiry draft to the approved standard. Every Requirement was re-verified clause by clause against the final text, and the Annex ZA sections re-derived from the final Table ZA.1. The substantive deltas:
- Added
MRF-448(identification and traceability, clauses 8.7 + 9.1) andMRF-449(retirement, clause 8.6). - Removed the draft's environmental-sustainability Requirement; the clause was deleted from the final standard.
- Added Controls
MCF-668(continuous-learning change governance),MCF-669(retirement communication to deployers), andOCF-371(non-compliance detection and market corrective action, with the bring-into-compliance / withdraw / disable / recall menu). - Serious-incident deadlines made explicit in
OCF-322: reporting triggers on an established or reasonably plausible causal link, with outer limits counted from awareness of 2 days (critical infrastructure), 10 days (death) and 15 days (all other cases), and a provisional report permitted ahead of the complete one. - Vocabulary: the templates follow the final standard's "non-compliance" (non-fulfilment of applicable regulatory requirements) in place of the draft's "nonconformity".
Projects running the prEN-era templates adopt the changes through the normal framework-update flow (Project → Settings → Frameworks); treat the update as a scope change and review the new Requirements before absorbing it.
Evidencing Requirements
EN 18286 Requirements follow the standard platform pattern. Controls change status directly on the Control detail page, through a confirmation dialog with a mandatory comment that lands in the Control's Comments and Logs. When all linked Controls reach a final status, the Requirement shows ready to be reviewed: the signal for the Requirement Owner to review the completed work and mark the Requirement Fulfilled, recording the rationale in the Requirement's Comments. Duties that do not apply to the system at hand are handled at the Control layer with rationale; MCF-668 (continuous-learning change governance), for example, only bites where an AI system actually keeps learning after being placed on the market or put into service. Note that its parent Requirement MRF-385 also carries support services and modifications, so the Requirement itself stays in scope.
Common pitfalls
- Claiming presumption of conformity today. The standard is approved but not yet cited in the Official Journal; until citation there is no presumption, and after citation it covers only the Annex ZA rows, on their conditions.
- Assuming Annex ZA covers everything Article 17 touches. Articles 17(2)–(4) are expressly not covered, and there is no Article 72 row. Post-market monitoring duties under Article 72 need their own compliance trail.
- Duplicating the QMS on the application side. The system itself (clauses 4–7, 9.6–10) lives once, on
OFF-19. Application projects hold per-system realization evidence, not a second copy of the policy layer. - Treating the ISO/IEC 42001 correspondence as equivalence. Annex C maps clauses and subclauses only, not requirements and concepts. The shared Control estate gives reuse; it does not make one framework's fulfillment the other's.
Related pages
EN 18286 overview
The standard, its Annex ZA scope, and what changed from the draft
Harmonized standards overview
Presumption of conformity mechanics and the JTC 21 pipeline
Frameworks in Modulos
Attaching, versioning, freezing and updating framework templates
Operating model
How Projects, Requirements, Controls and Evidence fit together
Source attribution
EN 18286:2026, Artificial intelligence — Quality management system for EU AI Act regulatory purposes, prepared by CEN/CLC/JTC 21 and approved by CEN/CENELEC on 12 July 2026. This page describes how Modulos maps the standard's duties to platform surfaces through the OFF-19 and MFF-19 templates as of templates 1.0.26; the duties themselves are in the published standard.
Disclaimer
This page is for general informational purposes and does not constitute legal advice.