An organisation uses artificial intelligence to anticipate failures. The system recommends postponing a maintenance intervention. The auditor's question begins at the next step: what turns that output into an authorised decision about a critical asset?

The example is hypothetical. It allows us to examine the boundary between a tool that informs and a system that is allowed to act. That boundary needs an accountable person, operational limits and evidence that survives the decision.

Specify what is being delegated

I would examine the entire path. Who defines the objective, what information the system receives and who turns its recommendation into an order. If it can act directly, which permissions enable it to do so and which prevent it from exceeding its role.

The same model can summarise a document or intervene in a process on which an essential service depends. The consequences and the evidence needed change. The tool's commercial description does not, on its own, describe its actual use.

The NIST AI Risk Management Framework organises risk management into four functions: govern, map, measure and manage. I use it as a reference to connect context, assessment and responsibilities; not as a checklist that allows control to be declared merely because documents have been completed.

Reconstruct the decision with protected evidence

To review the postponement of maintenance, I would look for the data available at the time, its provenance, the condition of the equipment and the system version. Also, subsequent authorisations, modifications and exceptions.

Information security runs through that reconstruction. Records need access controls, protection against tampering and retention appropriate to their purpose. Accumulating sensitive information without a criterion of necessity also creates exposure.

Could another competent person reconstruct what happened? If any part depends on memories, isolated screenshots or explanations that cannot be checked, that limitation must be stated.

Verify that someone can intervene in time

A name in a procedure identifies a formal responsibility. To examine its effectiveness, I would ask for a demonstration of what that person sees, what they can modify and how long it takes them to stop or correct the action. Intervention must fit within the time available before the consequence occurs.

The joint guidance from CISA, ASD’s ACSC and other agencies on AI in operational technology recommends limiting active control without human involvement, validating models and having mechanisms for reverting to conventional automation or manual control. These are technical guidelines for OT environments, not a universal obligation.

In the example, I would examine a controlled test of an incorrect recommendation: how it is detected, how intervention takes place and what happens to the operation. A visible stop button does not allow us to conclude that this entire path works.

Examine quality, continuity and change

A test with stable data may tell us little about degraded sensors, incomplete information or a provider that changes the model. I would review which variations were tested, which results were accepted and which changes require the assessment to be repeated.

Keeping a service running does not justify maintaining an unsafe condition. The continuity alternative needs its own limits and tests appropriate to its context. In critical infrastructure, a conclusion requires sector-specific knowledge and operational evidence that a public publication does not provide.

Measure efficiency within the life cycle

The circular economy adds another question to the same case: does postponing the intervention extend useful life without shifting the cost to a later failure, higher consumption or premature replacement?

The Ellen MacArthur Foundation studies the potential of AI to support design, circular business models and the infrastructure needed to close material loops. That potential does not substantiate the environmental outcome of a specific application.

My analysis proposes comparing a baseline with observed results: useful life, resources consumed, parts recovered and waste generated. The resources required by the digital solution must also be considered. A partial improvement deserves to be described within that scope, without presenting it as a circular transformation of the entire system.

Examine future scenarios with explicit limitations

The discussion of singularity can broaden the horizon of the questions. It does not establish a verifiable date or demonstrate that an organisation has lost control of its AI.

The International AI Safety Report 2026 distinguishes future loss-of-control scenarios from current failures and acknowledges uncertainty about their likelihood. At its evidence cut-off, observed capabilities had not reached the level required for those scenarios.

The practical application is to review access, permissions and the criticality of the environment today. Preparation can draw on scenarios; an audit conclusion must draw on evidence from the system examined.

What this analysis allows us to conclude

Before expanding a tool's autonomy, an organisation should be able to show the path of a decision: purpose, data, permissions, intervention, consequences and review. A stage it cannot demonstrate sets a limit on the trust it can place in the system.

This text proposes audit questions based on public sources. It does not assess an organisation, determine conformity with a standard or constitute certification. The examples are hypothetical; a real case requires an agreed scope, technical competence and specific evidence.