Why should a person approve what an AI changes?

Change approval means an AI may propose a change to a system, but only a person can apply it. It is one form of human in the loop.

The terms describe how close a person stands to the decision. In the loop, a person takes part in each decision before it takes effect. On the loop, the system acts on its own while a person watches and can step in. Out of the loop, nobody looks. Approval keeps a person in the loop at one point only: before a running system changes.

Not on every answer. A question answered by an assistant changes nothing, and the person who asked is already its reviewer. They read it, check where it came from and decide what to do. A gate in front of each answer only slows the reading down.

Approval belongs where an AI writes to something other people rely on: configuration, code, schemas, access rules, scheduled tasks, migrations that rewrite records. Those changes outlast the conversation, reach other users and can be hard to undo. A simple test: if a person would need a change ticket to do it, an AI needs an approval.

Meta draws the same line in its Agents Rule of Two (October 2025). An agent that reads untrusted input, reaches sensitive systems and can change state “should not be permitted to operate autonomously and at a minimum requires supervision”. An admin assistant has all three by definition.

An approval is only as good as what the reviewer was shown. Four things at least:

• The diff. The exact lines that will change, file by file. A summary written by the same assistant is a claim, not evidence.
• What it will reach. Which endpoints, tasks or users the change touches, and whether it rewrites stored records.
• Who asked, and why. The request in the requester’s own words, so the reviewer can judge whether the change answers it.
• That it was checked. It builds against the live configuration, and its tests ran.

The approval then has to bind to that version. If the diff changes after the review opened, the approval must not carry over to the new one.

The EU AI Act sets this out for high-risk systems. Article 14 requires that they “can be effectively overseen by natural persons during the period in which they are in use”. The people assigned must be able to override or reverse the output. They must also stay aware of relying on it too much, which the Act calls automation bias.

An assistant that edits the configuration of an internal tool is usually not a high-risk system under the Act. The article is still a useful checklist for any AI that changes things.

The NIST AI Risk Management Framework is voluntary and says the same in management terms. Its core asks that “Processes for human oversight are defined, assessed, and documented”. It also asks organizations to define roles and responsibilities for overseeing AI systems.

IBM’s explainer adds the accountability point. Once a person approves or overrides an output, responsibility no longer rests on the model or its developers alone.

• A prompt before every command trains people to click yes. Ask once, for the finished change, and make that review count.
• The reviewer reads the assistant’s account of the change instead of the change.
• The approval floats: it is given to one version, and a later one is applied.
• The assistant runs as a service account with more access than the reviewer. The review then guards nothing the account could not do anyway.
• Silence counts as consent: a change applies after a timeout, or when nobody objects.
• Nothing can be undone. An approved change that turns out wrong needs a way back, the same as a change made by hand.

Ask these of any AI that can change your systems, and of its vendor:

1. What can it change without a person? For a running system, the answer should be nothing.
2. What exactly does the reviewer approve: a summary, or the diff?
3. Is the approval bound to that diff, so a later change needs a new one?
4. Whose permissions does it work with: its own, or those of the person in the chat?
5. Where is the record of who approved what, and can a change be rolled back like one made by hand?

Sudo is the admin assistant in Curiosity Studio. You ask in plain words. He edits the configuration in a sandbox of his own: endpoints, AI tools, agents, schemas and tasks, as files. Every changed file is built against your deployment and staged as one commit. Then Sudo stops.

The commit waits on a review screen until an administrator approves or discards it. The approval is bound to that commit: if Sudo stages a newer one while the review is open, the review refuses to apply. Sudo asks once, at the end, not before each command. He reads with the permissions of the administrator in the chat, never elevated ones. For an administrator who may only read, he drafts the change and cannot stage it.

An approved change is one entry in your configuration history, under the approver’s name, in the same history as a change made by hand. His sandbox runs inside Studio, on your own infrastructure, with the model you choose (see what is sovereign AI?). Our paper An AI admin you can approve is for the people who decide, and Working with Sudo for the people who review.