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.
Document control
| 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
| 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
1. Scope and intended purpose
| 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
| 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
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
The diagram shows the loop this record follows. Each trigger in 4.2 sends
the record back to identification.
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
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
| 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
| 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
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
| 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
| 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
| 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
| 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
| 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
| 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.