The Human–AI Delegation Framework

1. Define the outcome and the accountable owner

Begin with the service someone needs, not with a list of things a model can generate. Specify who receives the result, what counts as acceptable completion and who is accountable if it is wrong. A workflow can cross several departments without losing its overall owner.

Write a short process charter: trigger, end point, customer or user, accountable owner, agreed scope and constraints. Record the current problem in observable terms, such as repeated rework or unresolved approvals. Do not assume that a faster individual task improves the whole process.

2. Map the work as it actually happens

Walk through representative items with the people doing the work. Include informal checks, queues, hand-offs and exceptions that are missing from the formal procedure. Distinguish an information task from a decision and from an action that changes a system or affects another person.

For each step record its inputs, source of truth, output, performer, decision owner, waiting time and failure modes. Mark where information is confidential or personal and where an external system is involved. This AS-IS map is the baseline against which a proposed change can be evaluated.

3. Choose a delegation mode for each step

These modes describe an allocation of authority, not a maturity ladder. More autonomy is not inherently better. Different steps in the same workflow may need different modes.

4. Write the delegation record

A useful instruction states more than the desired output. Before implementation, complete the following record for each AI-enabled step:

• Purpose and owner: the intended outcome and the person accountable for it.
• Allowed inputs: approved sources, data categories and access limits.
• Allowed actions: the exact tools and operations permitted, including any volume or spending limits.
• Decision rights: what the agent may propose, what it may execute and what needs human approval.
• Evidence: the sources and checks a reviewer needs before accepting an output.
• Exceptions: the events that stop execution and the person or queue that receives them.
• Recovery: how to correct a change, resume manual work and suspend the agent’s access.
• Review: evaluation criteria, version owner and the next review point.

Make approval usable: the reviewer must see what will happen, the relevant source information and the consequence of accepting it. An unexplained “approve” button is weak oversight.

5. Test a controlled workflow before expanding it

Start with a small, bounded pilot. Use synthetic or appropriately minimised examples first, then representative authorised cases once the controls are agreed. Include incomplete records, contradictory sources, unusual requests and instructions hidden in external content. Treat retrieved material as information rather than authority to change the task.

Agree the acceptable error severity, escalation conditions and stop criteria in advance. Check whether permissions actually prevent prohibited actions. Exercise the manual fallback and make sure someone owns the exception queue. A successful demonstration on one clean example is not acceptance testing.

6. Evaluate the whole service

Compare like-for-like work over a defined baseline and pilot period. Record changes in volume, complexity, staffing or systems that could explain a difference. Use a comparison group where feasible and describe limitations rather than presenting a before-and-after change as causal proof.

• Quality: measure accepted outputs and error severity, including the cost of corrections.
• Lead time: follow elapsed time from request to accepted outcome, not just model response time.
• Cost-to-serve: include staff effort, review, model usage, tool subscriptions and maintenance.
• Exceptions: report both the escalation rate and how quickly exceptions are resolved.
• Oversight burden: track review minutes and interruption patterns; automation can relocate work.
• User outcomes: assess whether people can complete the task and obtain a useful, accessible result.

Keep hypotheses, observations and interpretation separate. If evidence is insufficient, extend the test or narrow the claim. Retire a pilot that cannot meet its agreed controls or service objectives.

Illustrative example: a customer enquiry

Scenario, not a client result. A small service team receives enquiries that require information from an approved service catalogue. Today, staff read each message, locate the relevant material, draft a reply and ask a manager about exceptions.

1. A person sets the catalogue and defines the types of enquiry in scope.
2. AI classifies the message and drafts a response using that catalogue. It may not invent prices, make commitments or use unrelated customer records.
3. A staff member sees the draft and source material, corrects it where necessary and approves sending.
4. Complaints, unclear requests and requests outside the catalogue go to the designated owner.
5. The team compares response quality, total resolution time and review effort with its baseline. Any move towards bounded sending needs a new permissions decision and evaluation.

The design separates preparation from external action. It remains useful even if the eventual decision is to keep every response under human approval.

Product evidence and its limits

Sanctuary HR is a group product described publicly as live and in active development. Its published candidate workflow distinguishes profile and application preparation from the candidate’s responsibility for final submission. This provides a concrete context for discussing delegation boundaries; it does not validate this framework or establish hiring, productivity or financial outcomes.

Sources and further reading

The external risk reference below informs the governance context. The delegation modes and record are Sanctuary’s proposed synthesis, not a quotation or an endorsed standard.

• National Institute of Standards and Technology: AI Risk Management Framework. An external risk-management reference, distinct from Sanctuary’s proposed process method.
• UK AI adoption in 2026: workflow integration, not access, will shape SME productivity — Farzad Momeni, 19 September 2026. Sanctuary analysis; consult the article’s original references for the underlying evidence.
• UK SMEs should set data boundaries before scaling AI — Farzad Momeni, 29 August 2026. Sanctuary analysis; consult the article’s original references for the underlying evidence.
• UK AI Adoption: Why Management Capability Matters Beyond Course Volume — Farzad Momeni, 27 August 2026. Sanctuary analysis; consult the article’s original references for the underlying evidence.

Original publication dates and named authors belong to the linked articles. Their analysis and forecasts should be read separately from the evidence they cite. No statistics from those articles are presented here as proof of this service’s results.