ISO/IEC 23894: What the AI Risk Management Standard Asks You to Produce

ISO/IEC 23894:2023 is 26 pages, and it is not a certifiable standard. Both facts get discovered late, usually by someone who has been asked to "get us 23894 certified" and finds there is no certification to get. The document is guidance on applying risk management to artificial intelligence, published by ISO/IEC JTC 1/SC 42, and its structure is inherited directly from ISO 31000:2018.

That inheritance is the useful part. If your organization already runs an ISO 31000 risk process, 23894 tells you which parts of it break when the subject is an AI system, and what to add. I want to walk what the standard actually asks for, how it sits against ISO/IEC 42001 and the NIST AI RMF, and which of its expectations a runtime control on AI traffic can produce evidence for.

Structure inherited from ISO 31000

The standard follows the 31000 skeleton: principles, framework, process. The process clauses are where the work is, and they run in the familiar order. Establish scope, context, and criteria. Identify risk. Analyze risk. Evaluate risk. Treat risk. Then monitoring and review, and recording and reporting, running across all of it.

Three annexes carry the AI-specific content. Annex A maps the 31000 principles onto AI concerns. Annex B lists risk sources particular to AI systems. Annex C maps risk to organizational objectives such as fairness, security, privacy, and transparency.

Annex B is the section people actually read twice. It names risk sources including the level of automation, lack of transparency and explainability, complexity of the system, machine learning specifics such as data quality and drift, system hardware issues, system lifecycle considerations, technology readiness, and security and privacy exposure. Each of those is a prompt for the risk identification workshop rather than a control to implement.

The certification question

ISO/IEC 23894 gives guidance. ISO/IEC 42001:2023 specifies requirements for an AI management system and is the one an accredited body audits and certifies against.

The two are designed to be used together. Clause 6.1 of 42001 requires actions to address risks and opportunities, and 42001 points at 23894 for the method. So the practical pattern is 42001 as the certifiable frame and 23894 as the risk methodology that fills its risk clauses. If your goal is a certificate on the wall, ISO 42001 implementation is the project, and 23894 is a document you use inside it.

The same relationship holds against the NIST AI RMF, which is voluntary US guidance organized around Govern, Map, Measure, and Manage. NIST's four functions and ISO's process clauses cover largely the same ground in different vocabulary, and organizations operating on both sides of the Atlantic typically pick one as the internal system of record and maintain a crosswalk. The functions are broken out in NIST AI RMF explained.

Where the standard gets operational

Two clauses ask for something a policy document cannot satisfy on its own.

Monitoring and review expects that risk controls are watched over time and that changes in the system or its context trigger reassessment. For an AI system, the context changes constantly. A team swaps the model version behind an internal assistant, a new provider gets added, a service starts sending a data class nobody assessed. Monitoring here means observing actual system behavior in production, not re-reading last quarter's assessment.

Recording and reporting expects that the risk management process leaves records: what was assessed, what was decided, what was implemented, and what the system did afterward. The first three are documents. The fourth is telemetry, and it is where most implementations turn thin. A control described in a risk treatment plan and never evidenced in operation is an assertion an auditor has no way to test.

That gap is the honest reason to care about runtime records in an ISO context. A treatment plan that says "sensitive customer data is not sent to external models" is a claim. A per-request record showing which identity called which model, what class of content the prompt carried, which policy version applied, and what the decision was converts the claim into something checkable. The regulation-by-regulation view is in AI audit trail requirements by regulation.

Mapping Annex B risk sources to enforceable controls

Not every Annex B risk source has an operational control at the AI request layer, and pretending otherwise is how mapping documents lose credibility. Data quality, drift, and technology readiness are model and data lifecycle concerns, addressed in training pipelines and evaluation suites. Hardware issues belong to infrastructure.

Three of them do land on the request path. Level of automation maps to whether an autonomous caller is authorized per action or handed a session grant it spends unattended. Security and privacy maps to what content leaves for a model and under which identity. Lack of transparency maps partly to the record: an opaque model still produces an inspectable interaction history if something outside the application writes one.

I would rather hand an assessor a mapping that marks eight of eleven risk sources as out of scope for a given control and evidences the other three properly. Mappings that claim full coverage get read as marketing, and they invite exactly the follow-up question the author was avoiding.

A minimal 23894 working set

For a team starting from a 31000 process that already works:

Step 1 defeats more programs than the other five combined. An inventory built from interviews misses the endpoints nobody mentioned, and an inventory built from observed traffic finds them. The shadow AI numbers make the point: 86% of IT leaders report being completely blind to employee AI interactions, and 78% of employees use unauthorized AI tools at work (Cloud Radix). A risk register assembled without that visibility is a register of the systems people remembered.

DeepInspect

This is the gap DeepInspect closes. ISO/IEC 23894 asks for monitoring and records that describe what AI systems actually did, and DeepInspect sits inline on the HTTP path between authenticated users or agents and any LLM, which is where that behavior is observable.

Every request that traverses DeepInspect is bound to a verified caller identity, classified against your own data classes, and evaluated against identity-aware policy, with a deterministic fail-closed decision before the call reaches the provider. The same pass produces the inventory that step 1 needs, because every model endpoint in use appears in the record whether or not anyone declared it. Each decision commits a signed audit record on a write path the calling application never controls, which is the evidence an assessor can test a treatment claim against. DeepInspect covers the AI traffic layer and leaves data quality, drift, and model evaluation to the pipelines that own them. If you are building an ISO 42001 management system and the risk treatments have no runtime evidence behind them, let's talk today.