Assessing AI
Two assessments, one AI system: a worked example under ISO 42001.
ISO/IEC 42001 asks for two separate pieces of analysis: a risk assessment (clause 6.1.2) and an impact assessment of the AI system itself (clause 6.1.4). Described in the abstract, they blur together. Run on one realistic system, the split is plain: one weighs threats to what the organisation is trying to achieve, the other traces consequences for the people the system touches.
Back to ISO 42001 services01 · The example
Meet the claims-triage model
Illustrative throughout: a mid-sized health insurer, not a client.
The insurer uses a machine-learning model to sort incoming claims. Claims with a low score are paid quickly; high scorers go to an investigator. The model learned from years of past claims and the results of earlier investigations, and staff can override any score.
02 · Risk side
The risk side: what could stop the insurer reaching its aims?
The guidance standard here is ISO/IEC 23894, built on the ISO 31000 pattern.
- Fix the yardsticks first. The insurer decides how it will score likelihood and consequence, and what level it can live with, before judging any single item.
- List what could hurt the business. Fraud slipping through after the input data shifts; a regulator challenging denials nobody can explain; a library update quietly changing model behaviour.
- Score and rank. Every item is rated on the agreed scales, and the ranking decides where effort goes.
- Pick a response. Reduce, avoid, share or accept. Any response that needs a control is matched to an Annex A control or to one of the insurer's own.
- Sign for what is left. Whatever remains after treatment is accepted by someone with the authority to do so, and the date goes in the register.
| Register entry | Consequence for the insurer | Treatment | Annex A link |
|---|---|---|---|
| Input data shifts after a new claim form | Fraud losses climb unnoticed | Drift alerts and a monthly score review | A.6.2.6 |
| Denials cannot be explained | Regulatory challenge and complaint costs | Reason codes shown to the investigator | A.8.2 |
| Unvetted library update | Silent change in model behaviour | Pinned versions and release testing | A.4.4, A.6.2.4 |
Illustrative entries that show the shape of a register, not a complete one.
03 · Impact side
The impact side: what does a triage decision do to people?
The guidance standard here is ISO/IEC 42005.
This time the starting point is not the insurer's objectives but the people on the receiving end. The assessment names them, works through how the system could affect them, and records what softens the harm.
| Who is affected | How the system could affect them | What reduces it |
|---|---|---|
| Claimants in rural districts | Past claims there were investigated more often, so the model may flag them more and delay money for medical bills | Score comparisons by region; a person reviews any hold beyond a set limit |
| Claimants with limited literacy | Cannot tell why a claim was held, so cannot contest it | Plain-language hold letters and a phone line to a person |
| Investigators | Lean on the score and stop using their own judgement | Training, plus regular checks on how often they override |
| Policyholders at large | Trust in fair claims handling erodes if flagging looks arbitrary | A published summary of how triage works |
04 · Side by side
What each assessment leaves on file
Two records with different owners, linked to each other but never merged.
Risk assessment
Organisation-wide
- Entries in the AI risk register
- Scores on the agreed scales
- Treatment choices with named risk owners
- Leftover risk accepted and dated
- Inputs to the Statement of Applicability
Impact assessment
This system, in this setting
- Affected people and groups, named
- Possible harms, described in their terms
- Severity reasoning
- Mitigations and who approved them
- Harms that also threaten the insurer, passed to the register
The rural-delay harm shows how they connect: once it produces complaints and regulator interest, it becomes a business risk too, and appears in both records, each describing it from its own side.
05 · When to reopen
Events that reopen an assessment
A calendar review is the floor. These events should not wait for it.
- Retraining or a replacement modelBoth sides. New behaviour can bring new harms and new threats at once.
- A new data source or claim formMainly the risk side, through drift and data quality.
- A new group of users or claimantsMainly the impact side: different people, different possible harms.
- A complaint, incident or regulator letterBoth sides, starting with whatever the event exposed.
- Monitoring shows override or flag rates movingBoth sides, because something in the system or in how it is used has changed.
06 · Neighbouring assessments
Other assessments the same system may need
Each answers to a different rulebook. Share the inputs; keep the outputs apart.
| Assessment | Rulebook | Starts when | Centre of gravity |
|---|---|---|---|
| Data protection impact assessment (DPIA) | GDPR Article 35 | Processing of personal data is likely to pose a high risk to people | Rights and freedoms tied to personal data |
| Fundamental rights impact assessment (FRIA) | EU AI Act Article 27 | Certain deployers bring a high-risk AI system into use | Fundamental rights of people affected in the EU |
| Periodic data protection impact assessment | India's DPDP Act, 2023, section 10 | The government notifies an organisation as a Significant Data Fiduciary | Rights of the people whose data is processed |
| AI system impact assessment | ISO/IEC 42001 clause 6.1.4 | Every AI system inside the AIMS scope | Individuals, groups and society, whether or not personal data is used |
Sources: ISO/IEC 42001:2023 clauses 6.1.2, 6.1.3 and 6.1.4 and Annex A numbering as publicly listed; ISO's public pages for ISO/IEC 23894:2023 and ISO/IEC 42005; GDPR Article 35; Regulation (EU) 2024/1689 (the EU AI Act), Article 27; the Digital Personal Data Protection Act, 2023, section 10. The insurer and every row about it are illustrative.
Questions from teams running their first assessments
Our risk team wants one combined template. Will that pass an audit?
It can, if the two outputs stay distinguishable.
Auditors look for a risk assessment and an impact assessment and will ask to see each. A shared intake form is fine. What fails is a blended record where nobody can separate business risk from harm to people, or where the impact half is left empty.
Who should run the impact side?
The system owner, with people who know the affected groups.
Engineers know the model; they rarely know how a held claim lands on a family waiting to pay a hospital. Bring in customer-facing staff and privacy colleagues and, where practical, voices from the groups affected.
We already have a DPIA. Can we reuse it?
As an input, yes.
A DPIA centres on harms that flow from personal data. Reuse its system description and data map, then add what it leaves out, such as unequal service quality or eroding trust, which can occur without any personal data in play.
How fine should our likelihood scale be?
Fine enough that two people score alike.
Commonly three to five levels, each with a written description. The real test is consistency: two assessors given the same item should reach the same score most of the time.
Run both assessments on one system first.
An ISO 42001 readiness assessment works one of your AI systems through both sides and leaves you templates the rest can follow.