If you're deploying high-risk AI systems in the EU, you need a quality management system (QMS) that aligns with Article 17 of the AI Act. EN 18286:2026 is the only standard that provides presumption of conformity with these requirements. Here's a working template you can adapt to your organization.
Purpose of This Template
This template translates EN 18286:2026's quality management system requirements into a structure your team can implement. It's designed for providers of high-risk AI systems who need to demonstrate compliance with Article 17 before the AI Act's high-risk provisions take effect.
Unlike ISO/IEC 42001, which covers AI management broadly, EN 18286 focuses specifically on lifecycle requirements for high-risk systems. It's built to layer on top of your existing QMS, whether that's ISO 9001, ISO/IEC 42001, or a sector-specific standard like ISO 13485 for medical devices.
The presumption of conformity is significant: if you implement this standard correctly, regulators will assume you've met Article 17's requirements. Your audit becomes a verification of implementation, not a debate about interpretation.
Prerequisites
Before customizing this template, ensure you have:
Existing QMS foundation: EN 18286 is designed to extend, not replace. If you're running ISO 9001 or ISO/IEC 42001, you'll map new requirements into existing processes. If you don't have a QMS yet, you'll need to build core elements like document control, corrective action, and management review alongside the AI-specific components.
High-risk classification documentation: You need a defensible record showing why your system qualifies as high-risk under Annex III. This template assumes you've already made that determination.
Lifecycle process ownership: EN 18286 organizes requirements around the AI system lifecycle, not organizational functions. Identify who owns design, data management, training, validation, deployment, and monitoring for each system.
Integration authority: If you're in a regulated sector, you need sign-off to integrate this QMS with your existing sectoral management system. EN 18286 explicitly allows this, but your compliance team needs to approve the mapping.
The Template
# QUALITY MANAGEMENT SYSTEM FOR HIGH-RISK AI
# Article 17 Compliance via EN 18286:2026
## 1. SCOPE AND APPLICATION
### 1.1 Covered Systems
- System identifier: [unique ID]
- High-risk classification basis: [Annex III reference]
- Intended purpose: [specific use case]
- Deployment context: [operational environment]
### 1.2 QMS Integration Point
☐ Layered on ISO/IEC 42001
☐ Layered on ISO 9001
☐ Layered on sectoral QMS: [specify standard]
☐ Standalone implementation
## 2. LIFECYCLE PROCESS CONTROLS
### 2.1 Design and Development
**Process owner**: [name/role]
**Design inputs documented**:
- Technical specifications aligned to intended purpose
- Performance requirements with measurable thresholds
- Known limitations and foreseeable misuse scenarios
- Cybersecurity and data protection requirements
**Design verification checkpoints**:
- [ ] Architecture review against technical specifications
- [ ] Risk assessment covering Article 9 safety requirements
- [ ] Bias assessment per ISO/IEC TR 24027 framework
- [ ] Explainability evaluation per ISO/IEC TS 6254
**Design [validation evidence](/glossary/validation-evidence)**:
- [ ] Representative user testing in deployment environment
- [ ] Edge case performance documentation
- [ ] Failure mode analysis with mitigation controls
### 2.2 Data Management
**Process owner**: [name/role]
**Training data governance**:
- Data source documentation with provenance records
- [Annotation Quality](/glossary/annotation-quality) standards and validator qualifications
- Bias detection protocol: [specify method]
- Data retention policy aligned to Article 17(1)(e)
**Data validation gates**:
- [ ] Statistical representativeness check
- [ ] Protected attribute distribution analysis
- [ ] Data quality metrics per ISO/IEC 5259
- [ ] Privacy review per Article 10 requirements
### 2.3 Model Training and Validation
**Process owner**: [name/role]
**Training controls**:
- Hyperparameter selection rationale
- Training/validation/test split methodology
- Stopping criteria with performance thresholds
- Version control for model artifacts and training code
**Validation protocol**:
- [ ] Performance testing against design specifications
- [ ] [Robustness Testing](/glossary/robustness-testing) with adversarial examples
- [ ] Subgroup performance analysis
- [ ] Explainability verification
- [ ] Independent validation by [specify role/team]
**Validation Evidence requirements**:
- Test dataset characteristics and representativeness
- Performance metrics by demographic subgroup
- Failure case analysis with root cause documentation
- Comparison to baseline or predecessor model
### 2.4 Deployment and Integration
**Process owner**: [name/role]
**Pre-deployment checklist**:
- [ ] [Technical Documentation (Annex IV)](/glossary/technical-documentation-annex-iv) complete
- [ ] [Instructions for use](/glossary/instructions-for-use) finalized and reviewed
- [ ] Integration testing in production environment
- [ ] Rollback procedure documented and tested
- [ ] Monitoring infrastructure operational
**Human oversight implementation**:
- Oversight role definition per Article 14
- Override mechanism tested and documented
- Training records for oversight personnel
- Escalation protocol for edge cases
### 2.5 Post-Market Monitoring
**Process owner**: [name/role]
**Monitoring plan**:
- Performance metrics tracked: [list specific metrics]
- Monitoring frequency: [specify cadence]
- Alert thresholds for performance degradation
- Incident classification criteria
- Serious incident reporting procedure per Article 73
**Continuous evaluation**:
- [ ] Quarterly performance review against baseline
- [ ] Annual bias audit with demographic breakdown
- [ ] Data drift detection and response protocol
- [ ] User feedback collection and analysis
## 3. RISK MANAGEMENT INTEGRATION
### 3.1 Risk Assessment Cadence
- Initial risk assessment: [date/milestone]
- Reassessment triggers:
- Material system modification
- Performance degradation beyond threshold
- Serious incident occurrence
- Regulatory guidance update
### 3.2 Risk Mitigation Documentation
For each identified risk:
- Risk description and likelihood/impact rating
- Mitigation control with implementation evidence
- Residual risk acceptance authority
- Monitoring plan for control effectiveness
## 4. DOCUMENT AND RECORD CONTROL
### 4.1 Technical Documentation (Annex IV)
**Document owner**: [name/role]
**Review frequency**: [specify]
Required sections maintained:
- [ ] General description of AI system
- [ ] Detailed design specifications
- [ ] Data governance documentation
- [ ] Training methodology and results
- [ ] Validation and Validation Evidence
- [ ] Risk management records
- [ ] Post-market monitoring plan and results
### 4.2 Version Control
- Model versioning scheme: [describe]
- Documentation version linkage to model version
- Change log requirements for material modifications
- Retention period: [specify, minimum per Article 17(1)(h)]
## 5. COMPETENCE AND TRAINING
### 5.1 Required Competencies
**AI system development team**:
- Technical competence in [specify ML/AI methods]
- Regulatory awareness: [EU AI Act](/glossary/eu-ai-act) Articles 8-15
- Bias detection and mitigation methods
- Explainability techniques
**Validation team**:
- Independent from development (organizational separation)
- Statistical validation methods
- Domain expertise in [specify application area]
- Adversarial testing techniques
**Human oversight personnel**:
- System operation and limitations
- Override procedure and escalation protocol
- Incident recognition and reporting
### 5.2 Training Records
- [ ] Initial competency assessment
- [ ] Regulatory training completion
- [ ] Annual refresher training
- [ ] Competency verification for critical roles
## 6. MANAGEMENT REVIEW
### 6.1 Review Frequency
Minimum: [specify, typically quarterly for high-risk systems]
### 6.2 Review Inputs
- Post-market monitoring results
- Serious incidents and corrective actions
- Validation findings and performance trends
- Regulatory developments and guidance updates
- Resource adequacy for QMS maintenance
### 6.3 Review Outputs
- QMS improvement actions with owners and deadlines
- Resource allocation decisions
- Risk acceptance or mitigation adjustments
- Strategic decisions on system modifications or retirement
## 7. CORRECTIVE AND PREVENTIVE ACTION
### 7.1 Nonconformity Management
**Trigger events**:
- Performance below specified threshold
- Validation finding requiring [remediation](/glossary/remediation)
- Serious incident per Article 73
- Audit finding from internal or external review
**Response protocol**:
1. Immediate containment action
2. [Root cause analysis](/glossary/root-cause-analysis) within [specify timeframe]
3. Corrective action plan with verification
4. Effectiveness review after implementation
5. Documentation update to prevent recurrence
### 7.2 Continuous Improvement
- Lessons learned process from incidents
- Proactive risk identification from monitoring trends
- Benchmarking against updated standards or guidance
- Feedback integration from users and oversight personnel
## 8. SUPPLIER AND THIRD-PARTY MANAGEMENT
### 8.1 AI Component Procurement
For externally sourced components (models, datasets, tools):
- [ ] Supplier quality assessment
- [ ] Technical specification alignment verification
- [ ] Intellectual property and license review
- [ ] Integration testing and validation
- [ ] Ongoing supplier performance monitoring
### 8.2 Transparency Requirements
- Component documentation from supplier
- Known limitations and failure modes
- Update and support commitments
- Incident notification obligations
---
**Document Control**
Version: [X.X]
Effective date: [date]
Next review: [date]
Approved by: [name, title]
Customization Steps
Start with your existing QMS structure. If you're already running ISO 9001, map EN 18286's lifecycle requirements into your existing process framework. Don't create parallel systems, extend what you have. For example, your existing design control procedure can absorb the AI-specific design verification checkpoints.
Specify your metrics early. The template uses placeholders like "performance thresholds" and "alert criteria." Replace these with actual numbers based on your validation results. If your facial recognition system validated at 94% accuracy across demographic groups, that becomes your monitoring baseline. If accuracy drops below 92%, you've triggered a reassessment.
Define independence for validation. Article 17 requires validation activities to be "appropriate and independent." If you're a small team, independence might mean a different engineer reviews the validation protocol. In larger organizations, it means a separate validation team with no reporting line to development. Document your independence model explicitly.
Integrate sectoral requirements. If you're in medical devices, financial services, or automotive, you already have QMS obligations. EN 18286 allows you to run one integrated system. Map the AI-specific requirements to your existing sectoral controls. For example, your ISO 13485 design verification can incorporate bias assessment as an additional verification activity.
Calibrate monitoring frequency to risk. A credit scoring model with daily decisions needs daily monitoring. A diagnostic aid used weekly can be monitored monthly. Match your cadence to the volume and consequence of decisions.
Document your integration decisions. The template asks whether you're layering on ISO/IEC 42001, ISO 9001, or a sectoral standard. This isn't just administrative, it affects your audit scope. If you claim integration with ISO 9001, auditors will verify that your AI controls actually connect to your existing management review, corrective action, and document control processes.
Validation Steps
Internal audit first. Before you claim conformity with EN 18286, run an internal audit against the standard's requirements. Use the template as your checklist. Look for gaps where you have a process described but no implementation evidence.
Test your corrective action loop. Inject a simulated performance degradation event. Does your monitoring detect it? Does the alert reach the right owner? Can you execute root cause analysis and corrective action within your documented timeframes? If the loop doesn't work in simulation, it won't work when a real incident occurs.
Verify independence claims. If you've documented that validation is independent, prove it. Show organizational charts, reporting lines, and evidence that validators didn't participate in development decisions. Regulators will check this.
Review your Technical Documentation (Annex IV) against the QMS. Your QMS describes processes; your technical documentation describes the specific system. They must align. If your QMS says you conduct quarterly bias audits, your technical documentation should show the results of those audits.
Conduct a management review using the template. Schedule a management review meeting and work through Section 6 of the template. If you can't populate the review inputs with real data, you haven't implemented the monitoring and measurement processes yet.
External gap assessment. Before you rely on presumption of conformity, consider an external gap assessment against EN 18286. A third-party reviewer can identify interpretation issues you've missed. This isn't required, but it reduces your risk when enforcement begins.
The standard is published. The clock is running. If you start implementation now, you'll have a defensible QMS in place before high-risk AI requirements take effect. If you wait, you'll be building compliance infrastructure under regulatory pressure.
