# Risk Management System: [High-risk AI system name] [version]

> Risk management system record for the provider of a high-risk AI system,
> organised on Article 9 of the EU Artificial Intelligence Act (Regulation
> (EU) 2024/1689, as amended by Regulation (EU) 2026/1744, the "Digital
> Omnibus on AI", OJ L of 24 July 2026). Article 9 asks for a continuous,
> iterative process that runs across the whole lifecycle: identify and
> analyse risks, estimate and evaluate them, take in post-market data, adopt
> measures, judge residual risk and test. Under the amended Article 113 the
> high-risk requirements apply from 2 December 2027 for Annex III systems
> and from 2 August 2028 for systems covered by Annex I; check the
> consolidated text for the dates that apply to you. Replace every
> `[bracketed]` value and every row marked *Example*. This is a
> documentation format, not legal advice; check the current official text
> and a qualified professional.

<!--
Guidance: How to use this template
- Use this record as the risk management file that Article 17(1)(g) points
  to from the quality management system and that Annex IV section 5 of the
  technical documentation summarises. Keep one record per high-risk system
  (or per system family that shares an intended purpose).
- Fill sections 1 and 2 first: the intended purpose and the context of use
  decide which risks are in scope. Then set the criteria in section 3
  before you score anything, so the scoring cannot be bent to fit a
  release date.
- Article 9 is about risks to health, safety and fundamental rights. Keep
  business risks (cost, reputation, delivery) in the corporate risk
  register, not here.
- Treat the record as live. Each post-market signal, incident, retraining
  or change of intended purpose re-enters the loop in section 4.
- The worked example throughout is a fictional creditworthiness model
  (Annex III, access to essential private services). Replace it with your
  own system; keep the IDs consistent if you copy rows.
-->

## Document control

<!-- Guidance: The record must identify exactly which system version and intended purpose it covers, who owns the process, and when it was last reviewed. -->

| Field | Value |
|---|---|
| Document ID | [RMS-AISYS-001] |
| AI system name and version | [Name] [version] *(Example: Quillmere Affordability Scorer 3.1)* |
| Provider | [Legal name, address] *(Example: Quillmere Analytics, a fictional provider)* |
| High-risk basis | [Annex III area and point / Annex I legislation] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Risk process owner | [@risk-owner] |
| Approvers / reviewers | [@head-of-ai], [@qms-manager], [@legal], [@fundamental-rights-reviewer] |
| Classification | [Confidential] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Linked records | [Technical documentation TD-AISYS-001], [QMS manual QMS-AISYS-001], [Post-market monitoring plan], [Instructions for use] |
| Retention | *Example:* kept with the QMS documentation for 10 years after placing on the market (Article 18) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Risk process owner | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Head of AI engineering | [@name] | [Decision] | YYYY-MM-DD |
| Quality management representative | [@name] | [Decision] | YYYY-MM-DD |
| Accountable executive (residual risk acceptance) | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record what triggered each revision (design stage, test result, post-market signal, incident, change). The trigger history is evidence that the process is iterative. -->

| Version | Date | Author | Trigger | Change summary |
|---|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Design stage | First hazard identification |
| 1.0 | YYYY-MM-DD | [@name] | Pre-release testing | *Example:* Baseline after test report TR-QAS-012 |
| 1.1 | YYYY-MM-DD | [@name] | Post-market signal | *Example:* Added RMS-H-008 after a deployer complaint trend |

## Contents

<!-- Guidance: Sections 3 to 8 follow the steps of Article 9(2) to 9(8); section 9 covers Article 9(9) and section 10 covers Article 9(10). -->

1. [Scope and intended purpose](#1-scope-and-intended-purpose)
2. [Context of use and affected persons](#2-context-of-use-and-affected-persons)
3. [Risk criteria and acceptability](#3-risk-criteria-and-acceptability)
4. [Process, roles and lifecycle triggers](#4-process-roles-and-lifecycle-triggers)
5. [Risk identification and analysis](#5-risk-identification-and-analysis)
6. [Risk estimation and evaluation](#6-risk-estimation-and-evaluation)
7. [Risk control measures](#7-risk-control-measures)
8. [Testing against predefined metrics](#8-testing-against-predefined-metrics)
9. [Minors and vulnerable groups](#9-minors-and-vulnerable-groups)
10. [Residual risk and overall acceptance](#10-residual-risk-and-overall-acceptance)
11. [Integration with other requirements and processes](#11-integration-with-other-requirements-and-processes)
12. [Post-market feedback and review](#12-post-market-feedback-and-review)
13. [Traceability matrix](#13-traceability-matrix)
14. [Glossary and references](#14-glossary-and-references)

## 1. Scope and intended purpose

<!-- Guidance: Article 9(2)(a) ties risk identification to the intended purpose. State the purpose precisely enough that a reviewer can tell what counts as misuse. Pitfall: a vague purpose ("supports lending decisions") makes every risk either in scope or out of scope at will. -->

| Item | Description |
|---|---|
| Intended purpose | [Task, decision supported, deployers, affected persons] |
| High-risk classification | [Annex III point or Annex I product, with the reasoning record] |
| System boundary | [Components inside the record: model, data pipelines, user interface, logging] |
| Excluded from this record | [Components covered elsewhere, with the reference] |
| Lifecycle stage at this revision | [Design / Development / Validation / On the market / Withdrawal] |
| Versions covered | [Model and software versions] |

*Example:* "Quillmere Affordability Scorer 3.1 estimates the probability that a
consumer loan applicant falls 90 days into arrears within 24 months and
produces a score band with reason codes. Loan officers of deploying lenders
in the EU use it to decide whether to approve, refer or decline unsecured
personal loans up to EUR 25 000. Affected persons: loan applicants. The
system does not set prices and does not decide alone; every decline is
reviewed by a loan officer."

### 1.1 Reasonably foreseeable misuse

List uses outside the intended purpose that a reasonable provider would
expect to happen, because Article 9(2)(b) asks you to evaluate them too.

| ID | Foreseeable misuse | Why it is foreseeable | Handled in |
|---|---|---|---|
| MIS-01 *(Example)* | Using the score to screen job candidates or tenants | Lenders share tools with HR or property teams in the same group | RMS-H-005 |
| MIS-02 *(Example)* | Running the model on mortgage applications outside its validated range | Same interface, larger product catalogue | RMS-H-006 |
| MIS-03 *(Example)* | Treating the score band as the final decision | Workload pressure on loan officers | RMS-H-002 |
| [MIS-nn] | [Misuse] | [Reason] | [Hazard ID] |

## 2. Context of use and affected persons

<!-- Guidance: Article 9(5) asks you to take account of the deployer's technical knowledge, experience, education and training, and the context in which the system is expected to be used. Describe them here so the measures in section 7 can be judged against reality. -->

| Factor | Description |
|---|---|
| Deployers | *Example:* Retail lenders and credit unions in four EU Member States |
| Operators of the system | *Example:* Loan officers with credit training; no data science background |
| Expected training | *Example:* Two-hour onboarding module plus annual refresher, supplied by the provider |
| Setting | *Example:* Branch and call-centre decisions, target time per file 12 minutes |
| Affected persons | *Example:* Applicants aged 18 and over, including first-time borrowers and people in financial difficulty |
| Rights at stake | *Example:* Non-discrimination, protection of personal data, access to essential services, consumer protection |
| Other systems in the decision | *Example:* Credit bureau data, lender affordability rules, fraud screening |

## 3. Risk criteria and acceptability

<!-- Guidance: Fix the scales and the acceptance rule before scoring. Article 9(5) requires that the residual risk of each hazard, and the overall residual risk, is judged acceptable. Write down who may accept which band. -->

### 3.1 Severity scale

| Level | Name | Description for this system |
|---|---|---|
| S1 | Negligible | Minor inconvenience, corrected at once |
| S2 | Minor | Short delay or extra paperwork for an applicant |
| S3 | Moderate | Wrong outcome for an applicant that is correctable on appeal |
| S4 | Major | Wrong or discriminatory outcome affecting access to credit, hard to detect |
| S5 | Severe | Systematic harm to a group, or serious financial harm such as over-indebtedness |

### 3.2 Likelihood scale

| Level | Name | Description |
|---|---|---|
| L1 | Rare | Not expected in the system lifetime |
| L2 | Unlikely | Could occur a few times across all deployers per year |
| L3 | Possible | Expected monthly across deployers |
| L4 | Likely | Expected weekly |
| L5 | Almost certain | Expected in daily use |

### 3.3 Risk score and acceptance rule

Risk score is severity level multiplied by likelihood level (1 to 25).

| Band | Score | Acceptance rule |
|---|---|---|
| Low | 1 to 4 | Acceptable; monitor |
| Medium | 5 to 9 | Acceptable when every feasible design measure is applied; record the reasoning |
| High | 10 to 14 | Acceptable only with a documented benefit justification and sign-off by the accountable executive |
| Critical | 15 to 25 | Not acceptable; the system must not be released with this residual risk |

The *Example* scale is illustrative. Set your own bands with legal and
domain input and justify them in the record.

## 4. Process, roles and lifecycle triggers

<!-- Guidance: Article 9(1) and 9(2) require the system to be established, implemented, documented and maintained, and reviewed and updated systematically. Show the loop and the events that restart it. -->

The diagram shows the loop this record follows. Each trigger in 4.2 sends
the record back to identification.

```mermaid
flowchart TD
  A["1. Intended purpose and context"] --> B["2. Identify and analyse risks (Art. 9(2)(a))"]
  B --> C["3. Estimate and evaluate, incl. misuse (Art. 9(2)(b))"]
  C --> D["4. Adopt control measures (Art. 9(2)(d), 9(5))"]
  D --> E["5. Test against predefined metrics (Art. 9(6) to 9(8))"]
  E --> F{"Residual risk acceptable?"}
  F -- "No" --> D
  F -- "Yes" --> G["6. Release and inform deployers (Art. 13)"]
  G --> H["7. Post-market data (Art. 9(2)(c), Art. 72)"]
  H --> B
```

### 4.1 Roles

| Role | Responsibility | Person |
|---|---|---|
| Risk process owner | Runs the process, keeps this record, calls reviews | [@name] |
| System owner | Decides on measures and release | [@name] |
| ML and data leads | Technical analysis, testing, data measures | [@name] |
| Fundamental rights reviewer | Reviews rights and discrimination risks | [@name] |
| Domain expert | *Example:* Credit risk officer with consumer lending experience | [@name] |
| Accountable executive | Accepts High residual risk and the overall residual risk | [@name] |

### 4.2 Review triggers

| Trigger | Action | Deadline |
|---|---|---|
| Planned review | Full review of sections 5 to 10 | *Example:* every 6 months |
| Retraining or model change | Re-run section 8 tests; check hazards affected | Before release of the change |
| Change of intended purpose or new deployer sector | Restart at section 1 | Before the change |
| Post-market threshold breach (section 12) | Targeted review of the hazards linked to the indicator | *Example:* 10 working days |
| Serious incident (Article 73) | Root cause, update hazards and measures | In parallel with the incident report |
| New harmonised standard or guidance | Gap check of criteria and methods | *Example:* within 3 months of publication |

## 5. Risk identification and analysis

<!-- Guidance: Article 9(2)(a) covers known and reasonably foreseeable risks to health, safety and fundamental rights when the system is used as intended. Article 9(3) limits the scope to risks that design, development or adequate technical information can reasonably reduce or remove. Use several sources so you do not only list what the team already worried about. -->

### 5.1 Sources used

| Source | Used for | Reference |
|---|---|---|
| Structured workshop with deployer staff | Use-context hazards, automation bias | [Minutes ref] |
| Fundamental rights impact assessments of deployers (where shared) | Rights at stake | [Ref] |
| Data analysis of training and test sets | Representation gaps, proxies | [Datasheet ref] |
| Incident databases and literature | Known failure modes of credit models | [Ref] |
| Threat model | Security-driven risks (poisoning, manipulation) | [Threat model ref] |
| Complaints and appeals data from the previous version | Real harms observed | [Ref] |

### 5.2 Hazard register

| ID | Hazard | Cause or mechanism | Affected persons | Right or interest | Use type |
|---|---|---|---|---|---|
| RMS-H-001 *(Example)* | Lower approval for applicants aged 18 to 24 not explained by repayment risk | Thin credit files read as high risk; proxy features | Young applicants | Non-discrimination, access to credit | Intended use |
| RMS-H-002 *(Example)* | Loan officers accept score bands without review | Automation bias, time pressure | All applicants | Effective human review | Intended use, MIS-03 |
| RMS-H-003 *(Example)* | Accuracy falls after a change in interest rates or employment patterns | Data drift | All applicants | Access to credit, consumer protection | Intended use |
| RMS-H-004 *(Example)* | Manipulated income documents lift scores | Adversarial input through broker channel | Applicants, lenders | Protection from over-indebtedness | Misuse by third parties |
| RMS-H-005 *(Example)* | Score used for job or tenant screening | Repurposing by deployer group | Job seekers, tenants | Non-discrimination, data protection | MIS-01 |
| RMS-H-006 *(Example)* | Score applied to mortgages outside validated range | Product catalogue confusion | Mortgage applicants | Consumer protection | MIS-02 |
| RMS-H-007 *(Example)* | Approval of applicants already in financial difficulty | Missing signals of recent hardship | Vulnerable applicants | Protection from over-indebtedness | Intended use |
| [RMS-H-nnn] | [Hazard] | [Cause] | [Persons] | [Right] | [Intended / misuse] |

## 6. Risk estimation and evaluation

<!-- Guidance: Article 9(2)(b) asks for estimation and evaluation under intended use and reasonably foreseeable misuse. Score before measures (initial) here; residual scores go in section 10. Write the evidence behind each likelihood, not only the number. -->

| ID | Severity | Likelihood | Initial score | Band | Evidence for the estimate |
|---|---|---|---|---|---|
| RMS-H-001 *(Example)* | S4 | L4 | 16 | Critical | Selection rate ratio 0.70 for ages 18 to 24 in TR-QAS-009 (section 8.2) |
| RMS-H-002 *(Example)* | S4 | L3 | 12 | High | Pilot logs: 97% of declines confirmed in under 60 seconds |
| RMS-H-003 *(Example)* | S3 | L4 | 12 | High | Back-test over two past rate cycles showed AUC loss of 0.05 |
| RMS-H-004 *(Example)* | S3 | L3 | 9 | Medium | Two fraud cases a quarter reported by pilot lenders |
| RMS-H-005 *(Example)* | S4 | L2 | 8 | Medium | One request for HR use received in the pilot year |
| RMS-H-006 *(Example)* | S3 | L3 | 9 | Medium | Shared interface; no technical block on product type in v3.0 |
| RMS-H-007 *(Example)* | S5 | L3 | 15 | Critical | Bureau data lags hardship events by up to 60 days |
| [RMS-H-nnn] | [S] | [L] | [S x L] | [Band] | [Evidence] |

## 7. Risk control measures

<!-- Guidance: Article 9(5) sets the order of preference: first remove or reduce risk through design and development, then mitigation and control for what remains, then information under Article 13 and, where appropriate, training for deployers. Article 9(4) asks you to consider how the requirements of the section interact. Record the measure type so a reviewer can see the order was followed. -->

| Measure ID | Hazard | Measure | Type (Design / Control / Information or training) | Verified by | Owner | Status |
|---|---|---|---|---|---|---|
| RMS-M-001 *(Example)* | RMS-H-001 | Remove account-age features; add rent and utility payment history where the applicant consents | Design | TR-QAS-012 | [@ml-lead] | Done |
| RMS-M-002 *(Example)* | RMS-H-001 | Group selection rate monitoring with alert below 0.80 | Control | Monitoring spec PMM-QAS-01 | [@ops] | Done |
| RMS-M-003 *(Example)* | RMS-H-002 | Decline requires the officer to open the reason codes and confirm one of three review outcomes | Design | Usability test UT-QAS-04 | [@product] | Done |
| RMS-M-004 *(Example)* | RMS-H-002 | Deployer training on automation bias; instructions for use section on oversight | Information or training | Training records | [@enablement] | Done |
| RMS-M-005 *(Example)* | RMS-H-003 | Monthly drift indicators; retraining within the predetermined change plan | Control | PMM-QAS-01 | [@ml-lead] | Done |
| RMS-M-006 *(Example)* | RMS-H-004 | Document authenticity check before scoring; out-of-range income flagged for manual review | Design | Security test ST-QAS-03 | [@security] | Done |
| RMS-M-007 *(Example)* | RMS-H-005 | Contract clause limiting use to credit decisions; API rejects non-credit product codes | Design | Contract template, API test | [@legal], [@eng] | Done |
| RMS-M-008 *(Example)* | RMS-H-006 | Hard block on secured lending product codes | Design | API test AT-QAS-17 | [@eng] | Done |
| RMS-M-009 *(Example)* | RMS-H-007 | Open-banking affordability signals with consent; hardship flag forces referral | Design | TR-QAS-012 | [@ml-lead] | Done |
| [RMS-M-nnn] | [Hazard] | [Measure] | [Type] | [Evidence] | [@owner] | [Status] |

### 7.1 Interaction between measures

[Record where a measure for one requirement affects another. Example: "RMS-M-001 removed
two features and lowered overall AUC from 0.79 to 0.78; the accuracy
threshold in 8.1 is still met. RMS-M-009 adds personal data; the data
protection impact assessment was updated and data minimisation reviewed."]

## 8. Testing against predefined metrics

<!-- Guidance: Article 9(6) to 9(8): test to find the most appropriate measures and to show the system performs consistently for its intended purpose. Test during development as appropriate and in any case before placing on the market, against metrics and probabilistic thresholds defined in advance. Article 9(7) allows testing in real-world conditions under Article 60. Pitfall: thresholds chosen after seeing the results. -->

### 8.1 Predefined metrics and thresholds

| Metric | Threshold (set YYYY-MM-DD, before testing) | Rationale | Hazards |
|---|---|---|---|
| AUC on held-out test set | *Example:* lower bound of 95% CI at least 0.75 | Matches the scorecard it replaces | RMS-H-003 |
| Selection rate ratio, each age band against the highest | *Example:* point estimate at least 0.80 and lower 95% bound at least 0.75 | Adverse impact screening used by deployers | RMS-H-001 |
| Expected calibration error | *Example:* at most 0.03 | Score bands must mean the same arrears risk for every group | RMS-H-001, RMS-H-007 |
| Decline review rate (officer opened reason codes) | *Example:* at least 95% of declines | Evidence that oversight happens | RMS-H-002 |
| Manipulated-document detection rate on red-team set | *Example:* at least 90% | Fraud channel risk | RMS-H-004 |

### 8.2 Worked result *(Example)*

Test set: 18 000 applications from the validation period, by age band.
Ratio = approval rate of the band divided by the highest band rate. The 95%
interval uses the log risk ratio method.

| Age band | Applicants | Approvals before RMS-M-001 | Rate | Ratio (95% CI) | Approvals after RMS-M-001 | Rate | Ratio (95% CI) |
|---|---|---|---|---|---|---|---|
| 18 to 24 | 1 500 | 630 | 0.420 | 0.700 (0.658 to 0.744) | 750 | 0.500 | 0.833 (0.791 to 0.878) |
| 25 to 54 | 12 000 | 7 200 | 0.600 | 1.000 (reference) | 7 200 | 0.600 | 1.000 (reference) |
| 55 and over | 4 500 | 2 520 | 0.560 | 0.933 (0.906 to 0.962) | 2 520 | 0.560 | 0.933 (0.906 to 0.962) |
| Total | 18 000 | 10 350 | 0.575 | | 10 470 | 0.582 | |

Before the measure the 18 to 24 band failed both conditions (0.700 below
0.80). After it, the point estimate is 0.833 and the lower bound 0.791,
so the threshold in 8.1 is met. Overall AUC moved from 0.79 to 0.78
(lower bound 0.77), still above 0.75.

### 8.3 Test log

| Test ID | Date | Phase | Data or setting | Metrics | Result | Report |
|---|---|---|---|---|---|---|
| TR-QAS-009 *(Example)* | YYYY-MM-DD | Development | Held-out test set | All in 8.1 | Fail: age ratio | [Link] |
| TR-QAS-012 *(Example)* | YYYY-MM-DD | Pre-release | Held-out test set | All in 8.1 | Pass | [Link] |
| RWT-QAS-01 *(Example)* | YYYY-MM-DD | Real-world testing under Article 60 plan | Two lenders, 8 weeks | Review rate, ratio | [Result] | [Link] |
| [ID] | YYYY-MM-DD | [Phase] | [Data] | [Metrics] | [Result] | [Link] |

## 9. Minors and vulnerable groups

<!-- Guidance: Article 9(9) asks the provider to consider whether the system, given its intended purpose, is likely to have an adverse impact on persons under 18 and, as appropriate, other vulnerable groups. Record the answer even when it is "not likely", with the reason. -->

| Group | Likely adverse impact? | Reasoning | Hazards and measures |
|---|---|---|---|
| Persons under 18 | *Example:* Not likely | Lenders verify age 18 and over before scoring; the API rejects records with age under 18 | API test AT-QAS-05 |
| People in financial difficulty | *Example:* Likely | Credit can deepen hardship | RMS-H-007, RMS-M-009 |
| People with limited digital or language skills | *Example:* Possible | Reason codes may not be understood | Plain-language reason codes, instructions for use |
| [Group] | [Yes / No / Possible] | [Reasoning] | [IDs] |

## 10. Residual risk and overall acceptance

<!-- Guidance: Article 9(5): judge the residual risk of each hazard and the overall residual risk. Write why the residual level is acceptable in light of the benefit and the state of the art, and who accepted it. -->

| ID | Measures | Residual severity | Residual likelihood | Residual score | Band | Accepted by | Justification |
|---|---|---|---|---|---|---|---|
| RMS-H-001 *(Example)* | RMS-M-001, RMS-M-002 | S4 | L2 | 8 | Medium | [@risk-owner] | Ratio meets threshold; monitored monthly |
| RMS-H-002 *(Example)* | RMS-M-003, RMS-M-004 | S4 | L2 | 8 | Medium | [@risk-owner] | Review rate 98% in real-world test |
| RMS-H-003 *(Example)* | RMS-M-005 | S3 | L2 | 6 | Medium | [@risk-owner] | Drift alerts tested on past rate cycles |
| RMS-H-004 *(Example)* | RMS-M-006 | S3 | L2 | 6 | Medium | [@risk-owner] | Detection 93% on red-team set |
| RMS-H-005 *(Example)* | RMS-M-007 | S4 | L1 | 4 | Low | [@risk-owner] | Technical and contractual block |
| RMS-H-006 *(Example)* | RMS-M-008 | S3 | L1 | 3 | Low | [@risk-owner] | Hard block tested |
| RMS-H-007 *(Example)* | RMS-M-009 | S5 | L2 | 10 | High | [@accountable-executive] | Benefit: faster access to small loans; hardship referral in place; reviewed quarterly |
| [ID] | [Measures] | [S] | [L] | [Score] | [Band] | [@name] | [Reason] |

### 10.1 Overall residual risk statement

[Summarise the overall judgement. Example: "Of seven hazards, none remains
Critical, one is High (RMS-H-007, accepted with conditions), four are
Medium and two are Low. Considering the benefits for applicants and the
current state of the art for consumer credit scoring, the overall residual
risk is judged acceptable for release of version 3.1. Residual risks are
communicated to deployers in the instructions for use, section 'Known
limitations'."]

| Decision | Value |
|---|---|
| Overall residual risk | [Acceptable / Not acceptable] |
| Conditions | [List] |
| Communicated to deployers in | [Instructions for use reference] |
| Accepted by | [@accountable-executive], YYYY-MM-DD |

## 11. Integration with other requirements and processes

<!-- Guidance: Article 9(4) asks you to consider the combined effect of the high-risk requirements. Article 9(10) lets providers already subject to internal risk management under other Union law integrate these steps into that process. Show the links so nothing is assessed twice or not at all. -->

| Requirement or process | Link to this record |
|---|---|
| Article 10 data and data governance | Data measures (RMS-M-001, RMS-M-009) and bias examination results |
| Article 11 and Annex IV technical documentation | Annex IV section 5 summarises this record |
| Article 12 record-keeping | Logs feed indicators in section 12 |
| Article 13 transparency and instructions for use | Residual risks and limitations listed for deployers |
| Article 14 human oversight | RMS-M-003, RMS-M-004 |
| Article 15 accuracy, robustness and cybersecurity | Section 8 metrics, RMS-M-006 |
| Article 17 quality management system | Procedure for risk management, point (g) |
| Article 72 post-market monitoring | Section 12 |
| Article 73 serious incident reporting | Review trigger in 4.2 |
| Sector risk management | *Example:* lender model risk policy of deployers; provider internal model risk framework |
| Data protection impact assessment | [Reference and date] |

Related templates: `ai-data/ai-act-technical-documentation`,
`ai-data/ai-act-quality-management-system`,
`ai-data/ai-act-instructions-for-use`, `ai-data/human-oversight-design`,
`ai-data/bias-profile-7003`, `ai-data/datasheet-for-datasets`,
`ai-data/ai-post-market-monitoring`, `ai-data/ai-incident-report`,
`ai-data/ai-risk-assessment`, `ai-data/ai-act-fria`.

## 12. Post-market feedback and review

<!-- Guidance: Article 9(2)(c) requires evaluation of other risks that may emerge, based on data from the post-market monitoring system under Article 72. Name the indicators, thresholds and the hazards they feed. -->

| Indicator | Source | Threshold | Feeds hazard | Review action |
|---|---|---|---|---|
| Selection rate ratio by age band, monthly | Scoring logs | *Example:* below 0.80 in any month | RMS-H-001 | Targeted review in 10 working days |
| Decline review rate | Interface logs | *Example:* below 95% for any deployer | RMS-H-002 | Deployer contact, training refresh |
| Population stability index of key inputs | Scoring logs | *Example:* above 0.25 | RMS-H-003 | Drift investigation |
| Confirmed fraud cases through broker channel | Deployer reports | *Example:* more than 3 a quarter | RMS-H-004 | Security review |
| Complaints and appeals overturned | Deployer feedback | *Example:* overturn rate above 15% | All | Root cause analysis |
| [Indicator] | [Source] | [Threshold] | [Hazard] | [Action] |

### 12.1 Review log

| Date | Trigger | Hazards reviewed | Outcome | New revision |
|---|---|---|---|---|
| YYYY-MM-DD | *Example:* Planned 6-month review | All | No change in bands | 1.1 |
| YYYY-MM-DD | [Trigger] | [IDs] | [Outcome] | [Version] |

## 13. Traceability matrix

<!-- Guidance: Each hazard should trace to at least one measure, one verification and one monitoring indicator. A hazard without a verification is not controlled. -->

| Hazard | Measures | Verification | Monitoring indicator | Residual band |
|---|---|---|---|---|
| RMS-H-001 *(Example)* | RMS-M-001, RMS-M-002 | TR-QAS-012 | Selection rate ratio | Medium |
| RMS-H-002 *(Example)* | RMS-M-003, RMS-M-004 | UT-QAS-04, RWT-QAS-01 | Decline review rate | Medium |
| RMS-H-003 *(Example)* | RMS-M-005 | Back-test report | Population stability index | Medium |
| RMS-H-004 *(Example)* | RMS-M-006 | ST-QAS-03 | Confirmed fraud cases | Medium |
| RMS-H-005 *(Example)* | RMS-M-007 | API test | Complaints | Low |
| RMS-H-006 *(Example)* | RMS-M-008 | AT-QAS-17 | Complaints | Low |
| RMS-H-007 *(Example)* | RMS-M-009 | TR-QAS-012 | Complaints and appeals | High |

## 14. Glossary and references

<!-- Guidance: Define terms as used in this record and list the sources with dates, so a reviewer can check them. -->

| Term | Meaning in this record |
|---|---|
| Hazard | A potential source of harm to health, safety or fundamental rights |
| Risk | The combination of how likely harm is and how severe it would be |
| Residual risk | Risk that remains after control measures |
| Reasonably foreseeable misuse | Use outside the intended purpose that can be expected from human behaviour or interaction with other systems |
| Selection rate ratio | Approval rate of a group divided by the rate of the group with the highest rate |
| Predefined metric | A metric and threshold fixed and recorded before the test it is used for |

References (checked October 2026; check the current versions):

- Regulation (EU) 2024/1689, Articles 9, 13, 17, 60, 72, 73 and Annex IV:
  https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), OJ L of 24 July 2026,
  in force 27 July 2026; consult the Official Journal for the amending text.
- prEN 18228, AI risk management (CEN-CENELEC JTC 21), a draft harmonised
  standard for Article 9, in comment resolution as reported in September
  2026; not yet cited in the Official Journal.
- ISO/IEC 23894:2023, AI guidance on risk management, cited by name only:
  https://www.iso.org/standard/77304.html
- ISO/IEC 42001:2023, AI management system, cited by name only:
  https://www.iso.org/standard/81230.html

## Standard and licence note

Based on Regulation (EU) 2024/1689 (the Artificial Intelligence Act) as
amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI), Article 9,
risk management system for high-risk AI systems, with links to Articles 13,
17, 60, 72 and 73. EU legislative texts are free to reuse; this template
summarises the paragraphs in original wording and reproduces no text of the
Regulation. ISO/IEC 23894 and ISO/IEC 42001 are paid standards cited by name
only. Official text: ISO and IEC, purchase or licensed access:
https://www.iso.org/standard/77304.html. The worked example, the provider
and every figure in it are fictional. Check the consolidated text on
EUR-Lex and current Commission guidance; this is a documentation format, not
legal advice. Template licence: MIT.