ISO/IEC 23894 is guidance, not a set of requirements. It tells an organisation how to fold AI-specific risk into the ISO 31000 risk management process, mirroring that standard’s clause structure, and you cannot be certified against it. It gives guidance for managing AI risk across the organisation. It does not settle whether a particular model is safe enough for a particular task. Questions about grid contingency screening, the risk tier of a medical triage tool, defect classification on an inspection line or automated topic tagging in an archive each need evidence specific to their domain. Sub-processor obligations under GDPR are a separate matter again: they are terms the controller–processor contract must contain.

What ISO/IEC 23894 asks an organisation to do about AI risk

ISO/IEC 23894 is written to be used alongside ISO 31000:2018. Wherever it extends that guidance, it cites the matching ISO 31000 clause and then adds the AI-specific material. It has three main parts: Clause 4 on principles, Clause 5 on the framework for building risk management into the organisation’s activities, and Clause 6 on processes (communicating and consulting, establishing context, then assessing, treating, monitoring, reviewing, recording and reporting risk).

The AI-specific additions are broad and unspecific. The standard asks organisations to look at the whole system and its effect on stakeholders, and to set up structures that pick up emerging AI risks, trends and uses. It advises developers to track how their systems are used after release, and suggests users keep records of use over the system’s lifetime. On transparency, it says the mechanisms should be chosen to suit each stakeholder’s needs.

The European Commission’s Joint Research Centre (JRC), in its analysis of the preliminary AI Act standardisation work plan, called ISO/IEC 23894 “a high level, non-prescriptive standard, providing guidance instead of concrete requirements”. The same analysis found the implementation specifications in these ISO/IEC risk documents, 23894 among them, limited and not prescriptive. The standard supplies the process structure. The content has to come from the domain.

One 2026 overview of AI Act risk management lists 23894 next to 42001 under the heading “certifiable”. We do not follow it. The standard describes itself as guidance, and both a 2025 global governance overview and the JRC treat it as guidance.

How ISO/IEC 23894 relates to ISO/IEC 42001 and the NIST AI Risk Management Framework

ISO/IEC 42001 is a certifiable AI management system standard covering policies, procedures and accountable people across all of an organisation’s AI activity. NIST’s AI RMF is voluntary. It is organised into four functions (Govern, Map, Measure, Manage), and use-case Profiles adapt it to a specific setting, risk tolerance and set of resources. ISO/IEC 23894 is non-certifiable guidance on AI-specific risk management.

What it is	Guidance on managing AI-specific risk, built on ISO 31000	AI management system standard	Voluntary framework for building trustworthiness into AI
Certifiable	No	Yes	No formal external validation route; relies on self-assessment
Style	Part of an ISO suite that sets procedures, policies and documentation	Same ISO suite approach	Specifies outcomes and leaves the methods to each organisation
Fit with the EU AI Act	Its risk definition centres on organisational objectives, not harm to individuals	Similar organisational focus; considers individual impacts only optionally	Operates mainly within US federal policy, without formal recognition in hard law

The NIST-to-23894 clause crosswalk

A published crosswalk maps each AI RMF function to ISO/IEC 23894:2023 clauses.

GOVERN	5.2 leadership and commitment; 5.3 integration; 5.4 design (all sub-clauses, including roles, resources, communication); 5.6 evaluation; 6.1 general
MAP	5.4.1 understanding the organisation and its context; 6.3.2 to 6.3.4 scope, context and risk criteria; 6.4.2 risk identification (assets, risk sources, events, consequences); 6.4.3 risk analysis; 6.7 recording and reporting
MEASURE	5.7 improvement; 6.3.4 defining risk criteria; 6.4.2.5 identification of controls; 6.4.3.2 and 6.4.3.3 consequence and likelihood; 6.4.4 risk evaluation; 6.6 monitoring and review; 6.7
MANAGE	5.5 implementation; 5.6 evaluation; 5.7 improvement; 6.5.2 and 6.5.3 risk treatment options and plans; 6.6; 6.7
No NIST counterpart	6.2 communication and consultation

The unmapped clause is worth noticing. Communication and consultation with stakeholders appears in 23894 as its own process step, and the standard argues that organisations should seek dialogue with diverse internal and external groups because AI can affect stakeholders so widely. A team that maps its NIST work onto 23894 will find that step missing and has to add it.

Why following ISO/IEC 23894 doesn’t settle domain-specific risk

One reason is a difference in what counts as risk. The JRC points out that in ISO/IEC documents, risk refers to broad organisational objectives, including the AI system’s own objectives such as its performance. The AI Act defines risk as the negative impact a system could have on individuals and society. The JRC concludes that the methods for making a product work as intended are not necessarily the methods for making sure it harms no one. A later JRC policy brief says the same: existing international standardisation tends to protect the objectives of organisations using AI, and standards supporting the AI Act should focus on risks to individuals.

The second reason is that acceptable thresholds depend heavily on the application. The JRC expects acceptable robustness thresholds to come from vertical standardisation, because they depend so heavily on the application. A 2025 overview of global AI regulation found that current risk frameworks tell organisations what to measure but not how, so each company ends up building its own approach. The authors of the AI Hazard Management framework describe existing guidelines as staying “on a relatively abstract level”, which makes them hard to put into practice.

A 23894-compliant risk register can therefore be complete and still say nothing about whether a graph neural network misses critical contingencies, or whether a triage tool’s sensitivity holds up across patient subgroups. Those answers sit in different places for each domain, as the next sections show.

Explainable, auditable classification: four domains, four different answers

Grid contingency screening, medical triage classification, industrial defect inspection and archival topic tagging each get their own answer below.

TechnoLynx can build the engineering behind these decisions as part of its AI governance and trust work. For a grid screening GNN, that means framing which contingency calls need an explanation, implementing a graph explainability method on the model, validating its output against known topology and engineer judgement, and deploying it next to the screening model for ongoing audit. For defect inspection, it means training and validating a classifier against the agreed defect taxonomy on the target hardware, with a process for keeping the taxonomy and the model in sync. For topic tagging, it is adjacent work: integrating a review gate that shows a confidence score for each tag and validating it against archivist feedback.

Can a graph neural network tell protection engineers why it flagged a contingency?

Post-hoc graph explainers pick out the grid edges that most influenced a model’s prediction, which a benchmark compares against known cascading edges. The stakes are clear. NERC regulations require US power systems to stay stable for all N-1 contingencies, and heuristic or machine-learning screening offers no rigorous guarantee, so it could mark a critical contingency as feasible. Critical infrastructure is also an Annex III high-risk area under the EU AI Act where the AI is a safety component in electricity supply.

The PowerGraph benchmark (NeurIPS 2024) found gradient-based methods gave the most faithful explanations on its power grid datasets: Integrated Gradients and Saliency on the three IEEE datasets, Occlusion and GradCAM on the UK dataset. GraphFramEx (Amara et al., 2022) found shallow techniques such as personalized PageRank scored best on synthetic benchmarks, while gradient-based methods were best once graph structure was complex and nodes carried meaningful features. Fidelity varies with the method and the grid, so it should be measured on your own topology before anyone relies on it.

High test accuracy also is not proof of correctness. A 2019 study verifying neural networks for power system security found a three-layer classifier reaching 98.3% test accuracy, yet for 4.2% of test samples an input change of only 0.1% was enough to flip the classification. When the GNN and the rule-based tool disagree, the explanation gives an engineer what the GNN relied on to compare with the physics. It does not decide which tool is right. Reconciling every disagreement over a shared contingency set is a benchmarking-methodology question, and the miss-rate evidence a reliability auditor expects is a separate exercise again.

Which published rubric can we cite to justify the risk tier we assigned?

Cite the rubric written for your jurisdiction and domain, map your system against it item by item, and keep the mapping on file. A bespoke justification is much weaker. These are the candidates in the sources:

• EU AI Act Article 6 and Annex III. A system is high-risk if it is a safety component of a product, or is itself a product, under Annex I legislation that requires third-party conformity assessment, or if it falls under an Annex III use case. Annex III includes emergency healthcare patient triage systems.
• The Article 6 derogation. An Annex III system is not high-risk where it poses no significant risk of harm, for example because it performs a narrow procedural task or a preparatory task. A provider who relies on this must document the assessment before placing the system on the market and hand it over on request. The Commission’s classification guidelines add practical examples of systems on each side of the line.
• IMDRF SaMD categorisation. The SaMD definition statement records the medical purpose (treat, diagnose, drive or inform clinical management) and how serious the condition is (critical, serious, non-serious), and the manufacturer uses those factors to determine the category. IMDRF’s software characterisation guidance adds features, including a spectrum of autonomy and three levels of explainability, from logic that is explained and evaluable to black box.
• Canada’s Algorithmic Impact Assessment. The Treasury Board tool is a mandatory questionnaire of 65 risk questions and 41 mitigation questions that sets a system’s impact level. An older academic summary gives 51 and 34 questions across Levels I to IV. Cite the Treasury Board page, since it is the primary and current source.

For medical triage, precedent devices can also be cited. The FDA 510(k) summary for Aidoc’s BriefCase (K220709) states that the subject and predicate devices differ only in how the algorithm was trained. It reports a blinded study of 342 cases from five US sites with sensitivity of 91.3% and specificity of 85.6%. The De Novo decision for Viz.ai ContaCT (DEN170073) sets special controls, including test datasets with enough cases from important subgroups to characterise performance within each, and labelling of situations where the device may fail. Two limits apply. A rubric-based rationale is only as strong as the rubric’s fit to your system, and IMDRF itself declines to assign one “correct” universal category to any device. How deep validation should go once a tier is set is covered in scoping validation depth from risk tiering to evidence packs.

Defect classes that map one-to-one onto the agreed taxonomy

When inspectors have to explain a reject decision, we would pick a conventional supervised classifier trained and validated directly against the agreed defect taxonomy over an unconstrained generative model. Each output is then a taxonomy label, so the decision can be traced back. The EU AI Act’s Annex IV technical documentation lists “the main classification choices” and the design rationale among its required contents, which makes the label set itself something to document. We found no published study on keeping the taxonomy synchronised, so this point is our judgement. As new defect types appear, keeping the class list aligned needs a defined governance and update process, not a one-off mapping. Gaps will open between releases, and the process has to catch them.

How do we show an approver why an item was tagged, and when should a confidence score send it to manual review?

Show the evidence behind each tag alongside the tag, and route any item below a validated confidence threshold to a human reviewer instead of publishing it automatically. For high-risk systems, overseers must be able to interpret the output, stay aware of automation bias, and disregard or override the result. The ICO and Alan Turing Institute guidance on explaining AI decisions covers how to explain outputs to the people affected.

Guo et al. (ICML 2017) found that modern neural networks are poorly calibrated, so their confidence values do not reliably match the probability of being correct. Calibrate the scores against labelled data before using them for routing. The JRC also notes that many explainability techniques lack reliability and a standard evaluation framework, and that the link between explanations and automation bias is under-explored.

What evidence must be attached to a classification decision so an auditor can retrace it?

Under the EU AI Act, the artefacts an auditor can retrace a decision from are named:

• Design rationale and classification choices, including assumptions about the people the system will be used on (Annex IV).
• Metrics for accuracy, robustness and discriminatory impact, plus test logs and reports dated and signed by the responsible persons (Annex IV).
• Accuracy for specific persons or groups as well as overall, matching the FDA’s subgroup expectation in DEN170073.
• The technical measures that help deployers interpret outputs, assessed against Article 14.
• Automatic event logs across the system’s lifetime, enough to identify risk situations and support post-market monitoring (Article 12).
• A documented rationale for model selection, which the AI Hazard Management framework recommends for unquantifiable procedural hazards.

Approval-grade evidence of this kind is an engineering output. It is built for non-engineers such as auditors and compliance owners to read, defend and sign against. Producing those artefacts is not the same as legal sign-off or certification. Turning them into a package that survives review is the subject of building an audit-ready model documentation and approval package.

Can ISO/IEC 23894 settle sub-processor and GDPR obligations?

No. Sub-processor duties are contract terms required by law. The ICO’s guidance on UK GDPR Article 28 lists terms the controller–processor contract must contain, including the conditions for using sub-processors and provision for audits and inspections. The processor must also supply all the information needed to show it has met its Article 28 obligations, and must allow audits by the controller or an appointed auditor.

Enforcement is split as well. AI Act matters go to the AI Office and GDPR breaches go to data protection authorities, and the 2025 governance overview found the two regimes impose overlapping obligations that are hard to implement together. Engineering supplies technical inputs, such as the security measures Article 32 requires of processors. Whether a sub-processor contract meets the law is a question for legal counsel.

Where the specific requirements will come from

The gap between 23894’s organisational process and the system-level evidence auditors ask for will narrow, but not quickly, and not through 23894 itself. The JRC expected a European deliverable, the Check List for AI Risk Management (CLAIRM), to set more granular requirements with specific risk sources, harms and countermeasures. Once published in the Official Journal, harmonised standards give providers of high-risk systems a presumption of conformity. Even then, the JRC expects application-specific thresholds to come from vertical standardisation. Whether you have addressed the domain questions is shown by the domain evidence: a faithful explainer on your grid topology, a tier mapped to a named rubric, a classifier pinned to your taxonomy, and review thresholds based on calibrated scores.