AI Quality Management for the EU AI Act: From Regulatory Requirements to Evidence

Artificial intelligence compliance is becoming increasingly important as organizations move from experimentation to real-world deployment.

For organizations developing or providing AI systems, compliance cannot be treated as a final documentation exercise. It needs to become part of how the organization manages the AI system throughout its lifecycle.

This is where a quality management system (QMS) becomes particularly valuable.

A well-designed AI quality management system connects regulatory requirements with governance, risk management, development, data management, verification and validation, post-market monitoring, incident management and continual improvement.

One of the most important ideas emerging from the evolving European AI regulatory and standardization landscape is that AI compliance should be approached as a management system rather than a collection of isolated documents.

This article explores that approach and explains the key elements of an AI quality management system for EU AI Act regulatory purposes.

What is an AI Quality Management System?

A quality management system provides the organizational structure needed to consistently control processes and demonstrate that requirements are being met.

For AI systems, this means extending traditional quality thinking into areas such as:

• AI governance

• Regulatory compliance

• AI risk management

• Data governance

• AI system development

• Verification and validation

• Technical documentation

• Human oversight

• Post-market monitoring

• Incident management

• Change management

• Continuous improvement

The objective is not simply to produce more documentation.

The objective is to create a system in which an organization can answer four fundamental questions:

What requirements apply?

What controls have we implemented?

What evidence demonstrates that the controls work?

What happens when something changes or goes wrong?

This creates a continuous compliance cycle:

Regulation → Risk → Controls → Evidence → Monitoring → Improvement

1. Start with the regulatory requirements

An effective QMS begins with understanding what regulatory requirements apply to the organization and its AI systems.

This requires more than simply identifying the EU AI Act.

Organizations may also need to consider other applicable legislation, standards, contractual requirements, sector-specific requirements and organizational policies.

The first step is therefore to establish a clear regulatory framework.

A practical regulatory register can help identify:

• Applicable regulatory requirements

• Relevant AI Act obligations

• Applicable standards

• Conformity assessment requirements

• Data protection requirements

• Cybersecurity requirements

• Sector-specific obligations

• Relevant guidance and technical specifications

The regulatory environment should also be reviewed periodically.

AI technology changes quickly, and regulatory requirements, standards and guidance can change as well.

A compliance system therefore needs a mechanism for identifying and evaluating regulatory changes.

2. Define the scope of the QMS

Before implementing processes, an organization needs to understand what is actually inside the quality management system.

The scope should consider:

• Which AI systems are covered

• Their intended purposes

• Relevant organizational activities

• Lifecycle stages

• Development activities

• Deployment activities

• Post-market activities

• External suppliers and third parties

• Applicable regulatory requirements

A clear scope prevents an important problem:

responsibility gaps.

If nobody knows whether a particular AI system, supplier, dataset or lifecycle activity falls within the QMS, compliance responsibilities can easily become unclear.

The scope should therefore be documented and periodically reviewed when the organization, technology or regulatory environment changes.

3. Build a regulatory compliance strategy

The compliance strategy is one of the most important elements of the overall system.

It acts as the bridge between regulatory requirements and practical implementation.

Instead of asking:

"What documents do we need?"

a stronger question is:

"How will we demonstrate that the applicable requirements have been addressed?"

A compliance strategy can connect:

Requirement → Control → Responsibility → Evidence

For example:

Regulatory areaPossible QMS responseRisk managementRisk-management process and recordsData governanceData requirements and controlled data lifecycleTechnical documentationStructured technical documentationRecord keepingControlled logs and recordsHuman oversightDefined responsibilities and oversight mechanismsAccuracy and robustnessVerification, validation and monitoringCybersecuritySecurity controls and evidencePost-market monitoringMonitoring plan and feedback process

This approach makes compliance much more systematic.

4. Risk management should be continuous

AI risk management should not be treated as a single risk assessment performed before deployment.

AI systems operate in changing environments.

Their users can change.

Their data can change.

Their performance can change.

The surrounding regulatory environment can change.

New risks can also emerge after deployment.

A practical AI risk-management cycle therefore looks like this:

Identify

Identify potential hazards, harms, affected persons, intended use and reasonably foreseeable misuse.

Evaluate

Assess and prioritize relevant risks.

Control

Implement appropriate measures to reduce or control those risks.

Monitor

Collect information from testing, operation, users, complaints, incidents and other relevant sources.

Reassess

Determine whether new information changes the risk picture.

Improve

Update controls, documentation, processes or the AI system where necessary.

This creates a continuous loop:

Identify → Evaluate → Control → Monitor → Reassess → Improve

Risk management should also remain connected to the rest of the QMS.

A risk identified during post-market monitoring, for example, may require:

• A new risk assessment

• A change to the AI system

• Additional verification

• Updated technical documentation

• Updated instructions

• Corrective action

• Additional monitoring

5. Quality needs to be built into the AI lifecycle

One of the strongest approaches to AI quality is to introduce quality controls throughout the lifecycle rather than checking compliance only before release.

A simplified AI lifecycle can be viewed as:

Intended purpose → Requirements → Design → Data → Testing → Deployment → Monitoring → Change

Each stage creates quality and regulatory questions.

Intended purpose

What is the AI system supposed to do?

In what environment?

For which users?

Under which conditions?

What could reasonably be expected to happen during use?

Understanding intended purpose provides an important foundation for subsequent risk management and requirements.

Requirements

AI system requirements should be defined in a way that allows them to be evaluated.

Requirements can relate to:

• Performance

• Safety

• Reliability

• Data

• Transparency

• Human oversight

• Security

• Accuracy

• Robustness

• Regulatory compliance

Requirements should be reviewed and controlled throughout development.

Design and development

Development processes should include appropriate controls for:

• Design decisions

• Reviews

• Risk controls

• Data

• System architecture

• Dependencies

• Testing

• Verification

• Validation

• Documentation

The objective is to make development traceable and repeatable.

6. Data is part of the quality system

AI systems depend heavily on data.

Consequently, data should not be treated simply as an engineering resource.

It should be managed as part of the quality lifecycle.

Depending on the system, this may include controls for:

• Data requirements

• Data acquisition

• Data collection

• Data quality

• Data analysis

• Labelling

• Filtering

• Aggregation

• Storage

• Retention

• Data processing

• Data governance

The important principle is traceability.

An organization should be able to understand:

What data was used?

Why was it used?

How was it processed?

What controls were applied?

What evidence demonstrates that the data-management process was appropriate?

This becomes particularly important when data can influence the performance or risk profile of an AI system.

7. Verification and validation

Verification and validation provide objective evidence that requirements have been addressed.

Although these concepts are closely related, they should not be treated as interchangeable.

A simplified distinction is:

Verification:
Did we meet the specified requirements?

Validation:
Does the system meet the requirements for its intended purpose?

Testing should therefore be planned rather than performed as an isolated final activity.

Evidence may include:

• Test plans

• Test protocols

• Test results

• Validation reports

• Performance evaluations

• Acceptance criteria

• Traceability records

• Review records

• Approval records

The level of testing should be appropriate to the AI system, its intended purpose and its risks.

8. Continuous-learning AI requires additional attention

Some AI systems can change their behaviour through learning or predefined mechanisms.

This creates an additional quality challenge.

Organizations need to understand:

• What can change?

• Why can it change?

• Which changes are predetermined?

• What effect could those changes have?

• How are changes monitored?

• How are changes recorded?

• When is additional verification or validation required?

A useful principle is:

If the AI system can change, the QMS needs to understand and control that change.

Change should therefore be connected to:

Change → Impact assessment → Risk → Verification/validation → Approval → Documentation → Monitoring

9. Documentation should create evidence, not paperwork

Technical documentation and quality records have an important role in demonstrating compliance.

However, documentation should not become an objective in itself.

The real objective is evidence.

Good documentation should make it possible to understand:

• What was decided

• Why it was decided

• Who approved it

• What requirements were considered

• What risks were identified

• What controls were implemented

• What testing was performed

• What results were obtained

• What changed

• What happened after deployment

This creates traceability.

A useful way to think about AI compliance documentation is:

Requirement → Decision → Implementation → Test → Evidence → Approval

10. Governance and responsibilities

AI compliance cannot belong to one department alone.

Depending on the organization, different functions may have different responsibilities.

Top management

Provides direction, resources and oversight.

Regulatory / Compliance

Interprets applicable requirements and supports the compliance strategy.

Quality

Maintains QMS processes, audits, corrective actions and effectiveness monitoring.

Risk management

Coordinates identification, evaluation and control of AI risks.

Engineering / Product

Implements the AI system and its technical controls.

Data / AI Governance

Supports data governance and AI-specific controls.

Post-market / Regulatory

Handles feedback, monitoring, complaints and incidents.

The exact organizational structure will vary.

The important point is that responsibility and authority should be clear.

One of the most common weaknesses in compliance systems is:

Everyone is involved, but nobody is clearly accountable.

11. Supplier and third-party control

Modern AI systems rarely operate in complete isolation.

Organizations may rely on:

• Cloud providers

• AI models

• Data suppliers

• Software components

• APIs

• External development teams

• Infrastructure providers

• Monitoring services

This means supplier management can become part of AI compliance.

The organization should understand:

• What is being supplied?

• How critical is it?

• What risks does it introduce?

• What requirements apply?

• How is the supplier evaluated?

• How is performance monitored?

• What happens when the supplier changes its product or service?

The degree of control should reflect the potential impact of the supplied component or service.

12. Post-market monitoring

One of the most important concepts in AI quality management is that compliance does not end at deployment.

Once an AI system is used in the real world, organizations can receive new information.

Sources may include:

• User feedback

• Complaints

• Performance data

• System logs

• Monitoring results

• Incidents

• Security events

• Changes in the operating environment

• Information from deployers

• External regulatory information

This information should be evaluated.

A simple post-market loop is:

Signals → Assess → Act

Signals

Collect relevant information.

Assess

Determine whether the information represents a new or increased risk, performance problem or compliance issue.

Act

Take appropriate action.

This could include:

• Corrective action

• Additional monitoring

• System modification

• Documentation updates

• User communication

• Additional testing

• Reporting

• Withdrawal or disabling where required

Post-market monitoring therefore connects directly back into the QMS.

13. Serious incidents and non-compliance

A mature AI quality system needs predefined processes for dealing with serious incidents and non-compliance.

The organization should know:

• How an issue is detected

• Who receives the initial report

• Who evaluates the issue

• How it is escalated

• Who makes decisions

• What authorities may need to be contacted

• How corrective actions are implemented

• How effectiveness is evaluated

• What records must be maintained

The response should not depend entirely on improvisation.

A controlled process helps ensure that significant events are handled consistently.

14. Change management

AI systems evolve.

Organizations change.

Regulations change.

Suppliers change.

Data changes.

Therefore, change management becomes a critical component of AI compliance.

A change-management process should consider:

What is changing?

Why is it changing?

What could the change affect?

Does it introduce new risks?

Does existing documentation remain valid?

Is additional verification or validation necessary?

Who needs to approve the change?

What evidence needs to be retained?

This is particularly important when modifications could affect the AI system's performance, intended purpose, risk profile or regulatory compliance.

15. Management review closes the loop

A QMS should not simply generate records.

Management needs to evaluate whether the system is actually working.

Management review can consider:

• QMS performance

• Quality objectives

• Audit results

• Risk information

• Post-market monitoring

• Complaints

• Incidents

• Corrective actions

• Regulatory changes

• Changes to standards

• Resource needs

• Opportunities for improvement

The output should be decisions and actions.

This creates a management feedback loop:

Performance → Review → Decision → Action → Improvement

Without this feedback loop, a QMS can become static.

16. What does good AI compliance look like?

A mature AI quality management system should make it possible to demonstrate a clear connection between requirements and evidence.

For example:

Regulatory requirement

↓

Risk

↓

Control

↓

Implementation

↓

Verification / validation

↓

Evidence

↓

Post-market monitoring

↓

Management review

↓

Improvement

This is much stronger than maintaining separate documents that are not connected.

The real strength of a QMS comes from the relationships between its processes.

17. A practical AI compliance maturity model

Organizations can also think about their maturity in stages.

Level 1 — Reactive

Documents exist, but processes are inconsistent.

Level 2 — Defined

Core processes and responsibilities are documented.

Level 3 — Controlled

Evidence, reviews and quality gates are consistently applied.

Level 4 — Integrated

Risk, lifecycle, post-market and QMS processes work together.

Level 5 — Adaptive

Real-world evidence drives continuous improvement and controlled change.

The objective should not be to create more paperwork.

The objective should be:

Repeatable + Risk-based + Auditable + Effective

18. The five principles to remember

If you remember only five things about AI quality management, remember these:

1. Governance

AI compliance needs clear ownership, authority and accountability.

2. Risk

AI risk management needs to evolve throughout the lifecycle.

3. Lifecycle

Quality controls should be integrated from intended purpose through post-market monitoring.

4. Evidence

Organizations need objective evidence demonstrating that requirements have been addressed.

5. Improvement

Monitoring, incidents, audits and management reviews should drive controlled improvement.

Conclusion

AI compliance should not be viewed simply as a regulatory documentation exercise.

It is a management challenge.

Organizations need to understand what requirements apply, establish responsibilities, identify and control risks, integrate quality throughout the AI lifecycle, manage data, generate objective evidence, monitor real-world performance and respond effectively when circumstances change.

A quality management approach provides the structure for doing this consistently.

The most useful mental model is simple:

Regulation → Risk → Control → Evidence → Monitoring → Improvement

This creates a continuous connection between regulatory expectations and the way an AI system is actually developed, deployed and managed.

For organizations working toward trustworthy and compliant AI, the question is therefore not only:

"Are we compliant?"

A stronger question is:

"Can we demonstrate, through our processes and evidence, how we achieve and maintain compliance throughout the AI lifecycle?"

That is where AI quality management becomes a practical tool for trustworthy AI.

About this guide

This article is an independent educational resource developed from key concepts studied in EN 18286:2026 and related AI quality-management principles.

It is intended to support professionals working in:

• AI Compliance

• AI Governance

• Quality Assurance

• Regulatory Affairs

• AI Risk Management

• Medical-device AI

• Health AI

• AI Product Development

It does not reproduce the official standard and should not be considered a substitute for the licensed standard, applicable legislation, regulatory guidance or professional legal advice.