EN 18286: What It Is and How It Fits with the AI Act

What is EN 18286:2026?

EN 18286:2026 is a European standard entitled:

Artificial intelligence — Quality management system for EU AI Act regulatory purposes.

Its purpose is to provide requirements and guidance for defining, implementing and maintaining a quality management system related to artificial intelligence systems.

Its orientation is clearly regulatory.

It is not presented as a general standard for good AI governance.

It is designed to support a quality management system connected to the requirements of the AI Act.

This places it particularly close to the obligations that apply to providers of high-risk AI systems.

Why this standard has been developed

The AI Act does more than require certain technical characteristics from particular systems.

It also requires an organisational structure capable of maintaining compliance.

A system may be technically adequate at a given point in time.

That does not mean it will remain so when it:

• changes
• incorporates new data
• is updated
• changes supplier
• experiences incidents
• is assigned a different intended purpose
• presents new risks.

This is why the Regulation includes requirements concerning processes, responsibilities, documentation, monitoring and improvement.

Quality is no longer only a feature of the product.

It is also a matter of management.

What Article 17 of the AI Act requires

Article 17 requires providers of high-risk AI systems to put a quality management system in place.

That system must be documented in a systematic and orderly manner through policies, procedures and instructions.

The matters it should address include:

• a regulatory compliance strategy
• conformity assessment procedures
• change management
• design
• development
• quality control
• testing
• validation
• data management
• risk management
• post-market monitoring
• incident management
• communication with authorities
• documentation
• record keeping
• responsibilities
• resources.

The scope is broad.

It is not simply a matter of having a quality manual.

There must be a system capable of sustaining the AI system's conformity throughout its lifecycle.

Who it primarily affects

The Article 17 obligation is directed at:

providers of high-risk AI systems.

That distinction matters.

It should not be assumed that every business using an AI tool needs to implement EN 18286.

The organisation must first establish:

• which system is involved
• how it is classified
• which role the organisation holds
• which obligations apply.

A provider and a deployer are not the same. The guide to AI governance roles and responsibilities helps distinguish internal accountability from legal operator roles.

An organisation using a third-party system may still have important obligations under the AI Act.

That does not automatically mean it takes on the provider's Article 17 obligation.

This is why AI Act classification and role identification should come before controls are implemented. It is also important to determine whether the system is a high-risk AI system.

What a quality management system should cover

A quality management system designed for AI Act purposes needs to connect several areas.

It can be viewed as a sequence:

requirements → processes → controls → evidence → monitoring → improvement.

Identifying legal requirements is not enough.

They need to be translated into real processes.

For example, where a risk management requirement applies, the organisation needs to define:

• who carries out the assessment
• when it takes place
• which method is used
• which decisions may be made
• which records are retained
• when it is reviewed.

Quality depends on those decisions being carried out consistently.

Regulatory strategy and conformity assessment

One of the central elements of Article 17 is the regulatory compliance strategy.

This means connecting the management system with questions such as:

• which requirements apply?
• how will conformity be demonstrated?
• which conformity assessment procedure is required?
• which documented information must be maintained?
• how will changes be managed?
• who has authority to approve them?

Conformity should not appear only at the end of development.

It needs to be built into the process.

A seemingly minor change may alter the system's:

• intended purpose
• operation
• risk
• documentation
• previous assessment.

Change management is therefore essential.

Design, development, testing and validation

The quality management system also needs to control how the system is designed and developed.

This may include:

• specifications
• requirements
• design reviews
• development controls
• testing
• validation
• acceptance criteria
• modifications.

Testing should not be limited to checking whether the system produces an output.

It should also be related to applicable requirements.

Depending on the system, relevant considerations may include:

• accuracy
• robustness
• consistency
• security
• expected behaviour
• possible effects on people.

Quality is built during development.

It is not added at the end.

Risk and data management

The AI Act directly links high-risk systems with risk management.

The quality management system must integrate that process.

Risk assessment should not be a one-off exercise that is then filed away.

It needs to connect with:

• design
• testing
• controls
• changes
• monitoring
• incidents.

Data also has an important role.

Depending on the system, controls may be needed for:

• origin
• quality
• representativeness
• preparation
• governance
• traceability.

Risk and data should form part of the lifecycle. This can be connected to the organisation's AI risk management and, where appropriate, an AI impact assessment.

Responsibilities, resources and suppliers

A management system needs named responsibilities.

It should be able to answer questions such as:

• who approves?
• who designs?
• who validates?
• who manages risk?
• who maintains documentation?
• who monitors performance?
• who manages incidents?
• who communicates with authorities?

It also needs sufficient resources, including:

• people
• competence
• tools
• time
• infrastructure.

Suppliers and other third parties may also be critical.

Where a significant part of the system depends on external components, the organisation needs to manage that dependency.

Outsourcing does not remove the need for control.

Documentation, records and evidence

Conformity must be capable of being demonstrated.

Documentation and records are therefore a central part of the system.

Evidence may relate to:

• requirements
• decisions
• design
• testing
• risks
• data
• controls
• changes
• incidents
• suppliers
• monitoring
• corrective action.

The practical question is:

can we reconstruct why a decision was made and which evidence shows that it was carried out?

Traceability reduces reliance on explanations created afterwards.

Evidence should already exist as a natural result of the process. A maintained AI register and inventory helps connect systems, owners, classification and documented information.

Monitoring and post-market activities

The work does not end when the system reaches the market or enters service.

Systems can change.

Their context of use can change as well.

The model therefore needs monitoring mechanisms, which may include:

• metrics
• monitoring
• feedback
• incidents
• complaints
• changes
• reviews
• corrective action.

The information obtained should feed back into the management system.

An incident should not end with its immediate resolution.

It should also lead to the question:

do we need to change the process that allowed this to happen?

That is where continual improvement begins.

EN 18286 and ISO/IEC 42001: where they connect

EN 18286 and ISO/IEC 42001 do not pursue exactly the same purpose.

They do, however, share important areas, including:

• governance
• responsibilities
• risk
• processes
• controls
• documentation
• competence
• monitoring
• improvement.

An organisation with an AIMS based on ISO/IEC 42001 may already have developed part of the required organisational infrastructure.

For example:

• policy
• responsibilities
• risk processes
• audit
• evidence management
• continual improvement.

This can make integration easier.

It should not, however, be assumed that ISO/IEC 42001 certification automatically satisfies every regulatory requirement of the AI Act.

EN 18286 and ISO/IEC 42001: where they differ

The main difference lies in purpose.

ISO/IEC 42001 establishes an AI management system within an organisation.

Its scope is broad.

It may be applied by organisations that:

• develop
• provide
• use

AI systems.

EN 18286 is more specifically oriented towards:

quality management for EU AI Act regulatory purposes.

This gives particular prominence to matters such as:

• regulatory compliance
• conformity assessment
• regulatory documentation
• the lifecycle of high-risk systems
• post-market monitoring
• provider responsibilities.

Therefore:

ISO/IEC 42001 and EN 18286 can complement one another, but they should not be treated as equivalent. The comparison between ISO 42001 and the AI Act explains why a management system and a legal obligation perform different functions.

How EN 18286 can fit into an AI governance model

An organisation does not necessarily need to build entirely separate management systems.

Processes may be integrated within an AI governance framework.

Governance

A common framework for roles and responsibilities.

Inventory

A single source of AI systems and classifications.

Risk

A consistent method adapted where specific requirements apply.

Evidence

A shared repository with traceability.

Suppliers

A common third-party assessment process.

Incidents

An integrated model for communication and escalation.

Audit

A coordinated assurance programme.

Integration can reduce duplication.

But the organisation must retain the ability to demonstrate which requirement each process addresses.

What an organisation should do now

Before implementing EN 18286, an organisation should answer several questions.

1. Which systems exist?

Create or review the inventory.

2. How are they classified?

Determine whether any high-risk systems exist.

3. Which role does the organisation hold?

Provider, deployer or another operator.

4. Which obligations apply?

Not every system and role has the same obligations.

5. Which processes already exist?

For example:

• ISO 9001
• ISO/IEC 27001
• ISO/IEC 42001
• risk management
• compliance
• development
• quality assurance.

6. Which gaps remain?

Compare existing processes with applicable obligations.

7. How should they be integrated?

Avoid creating duplicate procedures where an existing process can be extended in a controlled way.

The aim should not be to accumulate management systems.

It should be to build a coherent model capable of demonstrating control.

EN 18286 brings quality management closer to operational AI Act compliance

The AI Act does not only require certain systems to meet technical requirements.

It also requires the responsible organisations to be capable of maintaining conformity over time.

EN 18286 provides a structure for turning that obligation into manageable processes.

That means connecting:

requirements, people, processes, controls, documentation, evidence and monitoring.

For organisations already working with ISO/IEC 42001, the challenge is unlikely to be starting from scratch.

It will be understanding what can be integrated and what needs a specific regulatory layer.

References

• EN 18286:2026 — Artificial intelligence — Quality management system for EU AI Act regulatory purposes.
• Regulation (EU) 2024/1689 — Artificial Intelligence Act.
• Article 16 — Obligations of providers of high-risk AI systems.
• Article 17 — Quality management system.
• ISO/IEC 42001:2023 — Artificial intelligence management system.
• ISO/IEC 23894:2023 — Guidance on AI-related risk management.