Three questions before an AI application touches real work

What evidence supports release, what authority does the application hold, and how will the team recover when it goes wrong?

23 October 2026 · MGCA group · English

1. What evidence supports the intended task?

Start with a bounded task and a representative set of examples. Include difficult inputs, missing information, conflicting sources and cases where the correct response is to decline or escalate. Compare with the existing process or a simple baseline. A single impressive demonstration cannot establish reliable behaviour across the workload.

Measure the whole workflow

A model score is only part of the release decision. Check source selection, permission filtering, tool choice, output validation, latency and the effect of human review. Record failure categories and their operational consequences. A small average improvement can hide a serious regression in an important minority of cases.

2. What authority does the application actually hold?

List each connected tool and the actions it can perform. Distinguish reading from changing records, sending communications or committing a transaction. Enforce permissions in the receiving system and give the application only the access required for its task. A prompt asking the model to behave carefully does not replace that boundary.

Define approval and escalation points

Make consequential actions visible before execution where the workflow requires review. Show the target, proposed change and evidence a reviewer needs. Specify what happens if approval is refused or expires. Avoid a design in which a failed approval silently falls back to a broader credential or a less controlled route.

3. How will the team recover?

Plan for wrong outputs, inappropriate actions, dependency failures and configuration changes. Keep a way to disable consequential tools while preserving investigation evidence. Define who owns incident decisions, how affected records are identified and whether an action can be reversed. Some actions require correction and communication rather than a technical rollback.

Release a controlled service

Record the evaluated configuration, its permissions, known limitations and the operating owner. Monitor the failure categories that mattered in testing, and define when a change needs reevaluation. The release decision should explain why the service is useful within its boundaries and how the organisation will respond when those boundaries are tested.