A row of stone slabs, each crossed by a lit channel that passes through a checkpointA row of stone slabs, each crossed by a lit channel that passes through a checkpoint

1. Who is accountable for the outcome?

Name the business owner and the people responsible for technical operation, risk acceptance and approval. Avoid assigning accountability to “the AI team” without stating which person can make which decision.

The operating owner should understand both the intended benefit and the consequences of failure.

2. What information may the system use?

Define approved sources, access boundaries and prohibited inputs. Record retention and provider conditions relevant to the use case. Establish how access is removed and how outdated material is identified.

These are architecture and operating questions as well as policy questions. Seek qualified advice for legal obligations that apply to the specific organisation and data.

3. What evidence permits release?

Specify evaluation cases, quality criteria and unacceptable outcomes before viewing the results. Include representative failures and the effect of human review. Record limitations rather than converting a favourable demonstration into a general reliability claim.

An independent reviewer should be able to understand how the release decision was reached.

4. Which actions require human approval?

Distinguish suggestions from actions that change records, send communications or affect people. State the thresholds for approval and the boundaries the system cannot cross.

Review must happen before a consequential action when reversal is impractical; an audit trail afterwards is not an equivalent control.

5. What happens when it fails?

Define who can pause the workflow, which fallback remains available and how an incident is investigated. Test those steps before relying on them. Capture enough evidence to understand an event without indiscriminately retaining sensitive content.

Recovery should be an operating procedure, not a promise that the model will improve.

6. What triggers reassessment?

Changes to models, prompts, source data, permissions or business processes may change the risk profile. Define which changes require renewed evaluation and approval.

Review the benefit as well as the risk. A controlled system that no longer solves a worthwhile problem still needs an investment decision.

Further reading

This is Theory Y’s practical interpretation, not a reproduction of a standard or a claim of certification.