ISO/IEC 42001: An AI Policy Needs Someone Who Can Act on It

20 Oct

2026

By Jonathan Anthony Burkett

Reporting and original analysis | October 20, 2026

A statement about responsible artificial intelligence can be easy to approve and difficult to use. A colleague encounters an unexpected output, a customer questions a result or a process changes after an update. At that moment, the useful question is not only whether the organization has expressed good intentions. It is whether someone knows what to do, has the authority to do it and can explain the decision afterward. That is where a policy begins to meet the work it is supposed to guide.

The public ISO description of ISO/IEC 42001:2023 identifies it as a management-system standard for organizations developing, providing or using AI-based products and services. It concerns establishing, maintaining and improving an organizational system for managing AI. The published description gives a useful starting point for analysis. The discussion below is an original operational example, not a clause-by-clause interpretation, certification assessment or claim that a named organization meets the standard.

Start with one process that people can describe

Imagine a small publishing team using an AI tool to help prepare summaries for an internal catalog. This is a hypothetical example. Before debating the tool in the abstract, the team could describe the actual process. What information is entered? What output is produced? Who checks it? Where is the accepted summary used? A clear description makes it possible to discuss a particular activity instead of treating every use of AI as the same decision.

The description should include what remains outside the process. Perhaps the tool is used for an internal draft but is not authorized to publish directly. Perhaps a particular class of material is excluded. Naming those limits gives colleagues something concrete to follow. An instruction to use good judgment is less helpful if different people understand the permitted purpose differently and have no shared place to resolve the disagreement.

A process description can also reveal an assumption hidden inside the word review. One colleague may think review means checking spelling. Another may believe it includes verifying every factual claim against source material. Until the difference is made explicit, both may believe they are following the same policy. The purpose of describing the work is to expose such differences before an error makes them visible in a less manageable way.

Responsibility needs a route through the organization

The NIST AI Risk Management Framework's published core treats governance as a continuing concern across AI risk management. Its GOVERN 2.1 addresses clear roles, responsibilities and communication, while GOVERN 2.3 assigns executive leadership responsibility for risk decisions. The page identifies this material as part of the 2023 framework and notes that an update is in progress. These are existing public resources, not a newly announced standard or a completed new edition.

In the hypothetical catalog team, that suggests several practical questions. Who can stop an incorrect summary from moving further? Who decides whether the tool may be used again after a problem? Who can authorize a change to the process? Assigning every task to a reviewer without giving that reviewer a route to a decision can create an appearance of oversight while leaving the important choice elsewhere and undefined.

The person responsible for a decision also needs relevant information. A report that merely says the tool made a mistake may be too vague to act on. An example, its source, the point at which it was noticed and its possible reach can make the question clearer. The aim is a usable account, proportionate to the situation. Producing a large document is not the same as supplying the detail necessary for someone to make a timely decision.

Make a concern easy to raise before it becomes a verdict

A colleague should not need to prove the cause of a problem before being allowed to report an observation. In the example, an editor may notice that a summary adds an unsupported claim. They can record that mismatch without knowing whether it arose from the input, a model change or the way the task was framed. Investigating the cause is a further step. The initial report should preserve what was seen without filling the gap with a confident guess.

The team can decide where that report goes and how it is acknowledged. If reports disappear into an unmonitored channel, people may stop knowing whether the process is being reviewed at all. A practical response identifies the next action and who is taking it. It need not promise an instant resolution. It should make the concern traceable enough that another colleague is not forced to rediscover the same issue from the beginning.

Feedback from the people using an output also matters. A catalog entry may be technically well formed and still fail its purpose because a reader cannot understand it. That observation is different from a factual error, and it deserves an appropriate response. A useful review process leaves room for several kinds of failure rather than measuring success only through the checks that happen to be easiest to count.

Revisit the arrangement when the work changes

An AI-assisted process is not necessarily identical after a supplier update, a new type of input or a wider audience. In the example, moving from internal drafts to public summaries would change the use being considered. The earlier discussion should not silently become permission for every expansion. Recording the change gives the team a chance to ask whether its review, authority and communication arrangements still fit.

The same attention belongs to ending a use. A team may decide that an activity is no longer worthwhile or that a simpler process serves it better. It should know how to stop using the tool, handle remaining work and tell affected colleagues. Responsible management includes the ability to withdraw from an arrangement without leaving people uncertain about which instructions still apply. Continuing by default is itself a decision, even when nobody formally announces it.

ISO's public description and NIST's framework direct attention toward management rather than a single impressive output. The practical lesson of this hypothetical case is similarly organizational. A policy becomes more credible when people can describe the work, identify a decision-maker and raise a concern that leads somewhere. An AI system does not take responsibility for the organization using it. People still need arrangements that let them notice, decide, explain and change what happens next.

Illustrative stock photograph: A person taking notes illustrates organizational work; no company, certification or AI system is depicted. Barbara Olsen / Pexels. Source photograph; Pexels license.

#upstormed #jonathananthonyburkett #jonathanburkett #ISO42001 #AIGovernance #ResponsibleAI