How to Communicate AI Risk to Boards and Stakeholders Under ISO/IEC 23894

Mapping the three activities to one reporting cycle

ISO/IEC 23894:2023 gives guidance on how organizations that develop, produce, deploy or use AI products, systems and services can manage AI-specific risk. It also describes processes for integrating risk management into AI-related activities and functions. For a risk leader, the practical consequence is that board reporting should be an output of the risk management process, not a separate document assembled at the end of a quarter.

Three activities carry that output. Communication and consultation determine who needs which information and how their input shapes the risk picture. Monitoring and review determine whether treatments continue to work once systems are in use. Recording and reporting produce the durable record that boards, auditors and regulators rely on. Treating them as connected matches the NIST AI RMF, where GOVERN 4.2 links documenting the risks and impacts of AI technology with communicating about those impacts more broadly.

The common failure is uneven coverage. Teams often do the recording and little of the consultation, or report treatment decisions without any monitoring data behind them. A useful first exercise is to list your current board and committee reports and mark which of the three activities each one actually supports.

What each audience needs

Boards need enough information to judge risk appetite, treatment effectiveness and accountability. In practice that means the declared tolerance for each material AI use, the current residual position against it, the status of treatments, and any incidents that changed the picture. The NIST AIRC Playbook suggests that boards of directors or advisory committees have defined roles in AI risk management and that management can declare risk tolerances and take an active role. Reports framed against declared tolerances give the board something concrete to accept, challenge or send back.

Other stakeholders need different cuts of the same record. Business owners need treatment status and the operating constraints that follow from it. Legal and compliance functions need the documented basis for each reported position. Internal audit needs the underlying evidence. End users and domain experts, who should be consulted on measurement, need to see how their input was used.

Incident reporting should be a separate stream. NIST MANAGE 4.3 addresses communicating incidents and errors to relevant parties, which implies a route that does not wait for the periodic cycle. Define the internal and external escalation paths in advance, as the Playbook suggests, and state which conditions send an AI incident to the board.

For EU-exposed organizations, timelines also belong in the report. As of November 2026, Commission pages give 2 December 2027 as the application date for high-risk AI rules for stand-alone systems and 2 August 2028 for systems embedded in products. The Commission proposed the Digital Omnibus on AI on 19 November 2025 to delay those rules. Plan against these dates, and confirm the adopted text before fixing compliance timelines.

Expressing risk, treatment and residual risk in decision-ready terms

A board paper should let a director decide something. For each material AI use, state the risk in a sentence, the tolerance it is measured against, the treatments applied, the residual position after treatment, and the decision requested: accept, fund further treatment, restrict the use, or stop it.

A short risk register extract per system is usually enough, provided each row carries the deployment context. NIST MEASURE 4.1 ties measurement to deployment context, so a metric reported without the system and use it came from is hard to interpret. Pair the extract with a small set of key risk indicators, each with an owner and a threshold that triggers escalation. Choose indicators that can be observed, such as the number of requests blocked or sent for human approval, rather than indicators that restate a policy.

The main tradeoff is breadth against clarity. A register covering every AI use will overwhelm a board, so report material uses in full and summarize the rest by exception. Keep the detailed register available to auditors and reviewers, and make clear which view the board is seeing.

Reporting on policy intent versus evidence of enforced behavior

Many reported risk positions describe intentions: a policy says sensitive data must not leave a boundary, or that high-impact actions need human approval. Those statements document the treatment. They do not show that the treatment operated. A board asked to accept a residual risk is entitled to know which of the two it is being given.

A practical rule is to label each control-effectiveness statement as either intent or evidenced. An evidenced statement points to records created at the point of execution, identifying the system, the use context, the policy applied and the outcome of each interaction or tool call. These records should be kept separate from the policy text so that the two can be compared. NIST GOVERN 4.2 and the Playbook's emphasis on documented, transparent processes support keeping a documented basis behind any reported position.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each interaction or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval, and enforcement generates audit-ready evidence of the decision made. Because policy is enforced at runtime, not reviewed after the fact, the counts of allowed, redacted, blocked and escalated actions can feed key risk indicators directly. The scope is individual interactions and tool calls. Trussed does not trace model lineage or dataset provenance, so those topics need separate reporting if your risk register includes them.

The evidence is mapped to frameworks including the EU AI Act and NIST, which helps when the same record has to answer to an internal audit, a regulator and a board committee.