Before an AI workflow touches customer records or sends anything outside your business, three responsibilities need names beside them: approving the action, stopping the workflow and recovering unfinished work. “The team will monitor it” leaves too much unresolved when an alert arrives or the usual reviewer is away.
For Australian businesses connecting AI to everyday operations, a useful ownership checklist goes beyond checking the quality of generated text. It explains what the system may do, where a person must intervene and how work returns to a known state after a problem.
Separate permission from a promising result
A convincing draft does not authorise its next step. Reading an enquiry, preparing a response, changing a record and sending an email are different actions. Agree which ones the workflow can perform independently.
Start with one process and list its permitted inputs, outputs and destinations. If the task only needs to prepare a summary, access to publish content or send messages should not be part of its ordinary operating scope.
Our guide to choosing your first business AI workflow helps select that initial process. The next step is assigning responsibility for its boundaries.
This is not just a theoretical distinction. In a published research incident report, OpenAI describes an internal agent reaching an external chatbot through a gap in network restrictions. The incident occurred on 20 September 2026; the report shows an update date of 25 September. It concerns an internal research environment, not evidence that the same incident occurred in an Australian business's account.
Name the decision owner and the backup
For each approval point, record who can make the decision and what evidence they need. The reviewer should see the original request, the relevant business information and the proposed action together.
Use a short responsibility record:
- Workflow owner: maintains the scope, access and operating instructions.
- Approver and backup: decide whether the proposed business action may proceed.
- Incident owner: can stop execution, assess unfinished work and authorise recovery.
Responsibility record to copy
Fill in one row for each approval point. The example row is hypothetical.
| Action | Owner | Backup | Approval evidence | Stop trigger | Stop method | Recovery rule |
|---|---|---|---|---|---|---|
| Send a quote draft to a customer (example) | Office manager | Director | Original enquiry, price list line items and draft side by side | Price not found, or customer asked for something outside the service list | Turn off the send step; item stays in the review queue | Check whether a quote was already sent before retrying; resume from the last completed step |
| (your action) |
One person may hold several roles in a small business. What matters is that the responsibilities are explicit and the backup has the necessary access. Include working hours and an escalation route; an unattended queue should not silently turn into automatic approval.
For customer pricing, our quote-draft approval workflow explains the evidence a reviewer should receive before a quote is sent.
Define what makes the workflow pause
Write down the exceptions that require a person: missing information, conflicting source records, an unexpected destination or a request outside the agreed service. Decide what the customer and staff see while the item waits.
A pause needs an actual operating behaviour. Depending on the system, that could mean holding an item in a review queue or preventing the next external action. Ask the implementer to demonstrate it with test data.
OpenAI's report also describes a gap between an alert being acknowledged and the affected run being stopped. The business lesson we draw is straightforward: checking that somebody receives a warning is different from checking that the stop mechanism works. This is our implementation recommendation, not a claim that a particular product guarantees containment.
Test recovery before an incident
Stopping work is only half the plan. Identify which records were changed, which messages were sent and which items remain incomplete before anything is retried.
Keep enough processing history to answer those questions without collecting unnecessary customer information. A failed final step does not necessarily mean earlier steps failed too.
For example, imagine a maintenance business whose workflow creates an enquiry record, prepares a job summary and then alerts a coordinator. If the alert fails, rerunning everything could create a second enquiry. The recovery route should recognise the completed record and resume the appropriate step.
That is a hypothetical example. Our guide to preventing duplicate leads in Airtable and Make explores the separate question of recognising repeated events.
Run a handover exercise
Before expanding access, ask the backup person to handle a test exception without help from the builder. Use these checks:
| Check | Pass looks like | If it fails |
|---|---|---|
| Find the original request | Located in under five minutes without asking the builder | Add a link or ID to the record; fix access |
| Say what happened | States which steps finished and which did not | Add clearer status labels or a history view |
| Pause the process | The next external action does not run after the pause | Fix the stop mechanism, then repeat the test |
| Check what was already sent or changed | Lists the records and messages affected | Keep a simple log of outputs per run |
| Recover without duplicates | Resumes from the last completed step with no second record or message | Add a duplicate check before retrying |
| Explain the next action | Writes the next step in one or two sentences | Update the operating instructions |
Record any missing access, unclear instructions or ambiguous status labels. Repeat the exercise after a material change to the workflow. A checklist is useful only when the controls and people behind it can perform the agreed steps.
DonutLabs' AI business integration service can help map these responsibilities around a defined process. Bring one workflow, representative exceptions and the people who currently make its decisions.
