prEN 18228 — Practical Risk Management Requirements for AI Systems

Draft 2026 | Aligned with EU AI Act Regulation 2024/1689 | For Providers Implementing High-Risk AI Compliance

Introduction — Why This Matters in Practice

0.1 General | 0.2 Fundamental Rights in Real AI Projects

0.1 General — What You Actually Need to Do

In practice, you must build a living Risk Management System (RMS) that runs from the first idea for an AI system all the way through retirement. This is not a one-time report — it is an ongoing process you document, review quarterly, and update whenever the AI changes or new risks appear.

Real-world example: A bank building an AI credit-scoring tool must run the full RMS from day one of data collection, through model training, deployment, and every model update. They keep one central “Risk Management File” that auditors can request at any time.

0.2 Fundamental Rights — How to Protect Them Day-to-Day

Every high-risk AI system can interfere with rights in the EU Charter (privacy, non-discrimination, dignity, access to justice, etc.). You must explicitly map every identified risk to one or more Charter articles and show how you reduce that interference to an acceptable level.

Practical action: For a hiring AI, list the exact Charter rights at risk (e.g., Article 21 non-discrimination, Article 23 equality). Then document the mitigation steps (diverse training data, human oversight, appeal process) and the residual risk level after mitigation.

1. Scope — What This Means in Practice

Clause Details — How to Apply It

In practice you must:

  • Apply this RMS to every AI system you place on the EU market or put into service that is classified as high-risk under Annex III of the EU AI Act.
  • Cover the entire lifecycle: from initial data collection and model design, through training, testing, deployment, continuous monitoring, updates, and eventual decommissioning.
  • Include risks to health, safety, and fundamental rights — not just technical failures.
Example: An autonomous vehicle AI provider must manage risks from sensor failure (safety) all the way to biased object detection that could discriminate against certain road users (fundamental rights). The RMS must cover both.

2. Normative References — Documents You Must Have

Clause Details — What to Do

In practice you need immediate access to:

  • EU AI Act (Regulation (EU) 2024/1689) — especially Articles 8–15 and Annex III
  • prEN 18286 (AI Quality Management System) — to integrate risk management into your QMS
  • ISO/IEC 42001 (AI Management System) — for broader alignment with management capability
  • EU Charter of Fundamental Rights + prEN 18228 Annex C guidance
  • ISO 31000 (Risk Management) and IEC 31010 (Risk Assessment Techniques)
Tip: Keep a “Regulatory Register” (see Clause 4) that lists exactly which articles of the AI Act each risk control satisfies. This becomes your conformity evidence.

3. Terms and Definitions — Practical Meanings You Use Every Day

Clause Details — Key Terms in Action

Key terms you will use daily:

  • Risk = combination of the probability of harm occurring and the severity of that harm (to health, safety or fundamental rights).
  • Residual Risk = the risk that remains after you have applied all reasonable controls. You must document why it is acceptable.
  • Hazardous Situation = a circumstance in which people, property or the environment are exposed to one or more hazards.
  • Provider = the organisation that develops the AI system and places it on the market or puts it into service.
Example: In a medical diagnosis AI, a “hazard” might be “incorrect diagnosis”. A “risk scenario” is “narrow training data + rare disease”. The “residual risk” after mitigation might be “1 in 10,000 false negatives” — which you accept only after showing it is lower than human doctor error rates.

4. Context of the Organisation — How to Establish It in Practice

4.1 Establishing the Context | 4.2 Interested Parties | 4.3 Scope of the RMS

4.1 Establishing the Context — What You Do

At the start of every new AI project (and at least annually), run a structured workshop with technical, legal, ethics and business teams to list all internal and external issues that affect risk. Document them in your Risk Management File.

Practical output: A one-page “Context Statement” that includes regulatory environment, data sources, deployment countries, user groups (including vulnerable populations), and known past incidents in similar systems.

4.2 Interested Parties — Who You Must Talk To

Identify and engage all relevant stakeholders: end-users, regulators, affected communities, internal teams, and external experts (e.g., civil society for fundamental rights issues).

Action: Hold at least one stakeholder consultation per major release. Record who was consulted, what concerns were raised, and how you addressed them.

4.3 Scope of the Risk Management System — Setting Boundaries

Clearly define which AI systems, versions, and lifecycle stages are covered by this RMS. Exclude low-risk systems only with documented justification.

Example: “This RMS covers our AI recruitment tool v2.3 and all future minor updates. It does not cover the internal chatbot used only by HR staff.”

5. Leadership — What Top Management Must Actually Do

5.1 Leadership & Commitment | 5.2 Risk Policy | 5.3 Roles & Responsibilities

5.1 Leadership and Commitment — Visible Actions

Top management must personally approve the risk policy, allocate budget and people for risk work, and attend at least one risk review per quarter. They must also ensure the RMS is integrated into existing product development and quality processes.

Evidence: Signed risk policy + quarterly risk dashboard presented to the board + budget line for risk tooling and external experts.

5.2 Risk Policy — Writing One That Works

Write a short, clear policy (1–2 pages) that states your risk appetite, commitment to fundamental rights, and requirement that all residual risks are reduced to ALARP (As Low As Reasonably Practicable).

Example statement: “We will not deploy any high-risk AI system where residual risks to fundamental rights remain above the level that would be acceptable for a comparable non-AI process.”

5.3 Roles, Responsibilities and Authorities

Appoint a Risk Owner for each AI system (usually the Product Owner or AI Lead). Give them authority to stop deployment if risks are unacceptable. Maintain a RACI matrix and competence records.

6. Planning — Running the Risk Process Every Day

6.1 Risk Assessment | 6.2 Risk Treatment | 6.3 Risk Acceptance Criteria

6.1 Risk Assessment — The 4-Step Process You Follow

  1. Identify all hazards and risk scenarios (use the hazard list in Annex B and real-world incident data).
  2. Estimate probability and severity (use the severity tables in Annex C for fundamental rights).
  3. Evaluate whether the risk is acceptable before and after controls.
  4. Document everything in the Risk Management File with traceability to the AI system version.
Tool: Use a risk matrix (probability × severity) with separate columns for safety and fundamental rights. Review it at every sprint or development gate.

6.2 Risk Treatment — The Hierarchy You Must Follow

Apply controls in this order (highest to lowest effectiveness):

  1. Inherently safe design (e.g., remove the risky feature entirely)
  2. Protective measures (technical controls, human oversight loops)
  3. Information for users / instructions / warnings
Example: For a biased hiring AI — first try to remove the biased feature; if not possible, add re-weighting + mandatory human review of top candidates; finally add clear warnings to recruiters.

6.3 Risk Acceptance Criteria — How You Decide “Good Enough”

Define clear, documented criteria before you start any project. Residual risks affecting fundamental rights should normally be reduced to the lowest practicable level. Risks that remain high must be escalated to top management for formal acceptance.

7. Support — Resources, Competence & Communication You Need

7.1 Resources | 7.2 Competence | 7.3 Awareness | 7.4 Communication

7.1 Resources — What You Must Budget For

Allocate dedicated budget and people for risk assessment tooling, external ethics/legal review, real-world testing, and post-market monitoring infrastructure.

7.2 Competence — Who Must Be Trained

Everyone involved in AI development, testing, deployment and monitoring must have documented training on risk management, bias detection, fundamental rights, and the specific hazards of the AI system they work on. Keep training records for at least 5 years.

7.3–7.4 Awareness & Communication

Run regular awareness sessions (at least annually) and maintain clear channels so any employee can raise a risk concern without fear. Publish a summary risk report to external stakeholders when required by the AI Act.

8. Operation — Implementing Controls Across the AI Lifecycle

8.1 Operational Planning | 8.2 Risk Treatment Implementation

8.1 Operational Planning and Control

Embed risk checkpoints into your existing development process (requirements, design, training, testing, deployment, monitoring). At each gate, require a signed risk assessment update before moving forward.

8.2 Risk Treatment Implementation — Making It Real

Actually build and test the chosen controls. For high-risk systems this includes:

  • Real-world condition testing (not just lab data)
  • Adversarial testing for cybersecurity and robustness
  • Human oversight mechanisms that actually work under time pressure
  • Clear user instructions and appeal processes
Example: Before launching a medical AI, run it on real hospital data for 3 months with human doctors in the loop, measure performance per demographic group, and only then decide on deployment.

9. Performance Evaluation — Proving It Actually Works

9.1 Monitoring & Measurement | 9.2 Internal Audit | 9.3 Management Review

9.1 Monitoring, Measurement, Analysis and Evaluation

Define KPIs (e.g., residual risk score trend, number of incidents per 10,000 uses, bias metrics per protected group, time to close risk actions). Review them monthly and after every significant incident or model update.

9.2 Internal Audit

Conduct at least one internal audit per year covering the entire RMS. Use independent auditors (can be internal but not the people who run the RMS daily). Document findings and corrective actions.

9.3 Management Review

Top management must review the RMS at least quarterly. Inputs: risk dashboard, audit results, incidents, regulatory changes, resource needs. Outputs: decisions, resource allocations, policy updates — all documented.

10. Improvement — Fixing Problems and Getting Better

10.1 Nonconformity & Corrective Action | 10.2 Continual Improvement

10.1 Nonconformity and Corrective Action

When something goes wrong (a risk was missed, a control failed, or an incident occurred), you must:

  1. Investigate root cause within 30 days
  2. Update the risk assessment and treatment plan
  3. Implement corrective actions and verify effectiveness
  4. Communicate lessons learned across the organisation

10.2 Continual Improvement

After every major release, every significant incident, and at least annually, review the entire RMS and ask: “What can we do better?” Update processes, tools, training and criteria accordingly. Keep a living improvement log.

Final practical reminder: The goal is a living system that demonstrably reduces real harm to people. Regulators and auditors will look for evidence that you actually use it, not just that it exists on paper.
Back to Home