AI implementation
Who owns an AI workflow after launch? A register for Australian businesses
Amulet's recommended approach is that a named person in your business owns the workflow after launch, including the authority to pause it. A vendor or partner can run parts of it, such as product settings, monitoring or tuning, but the business decision stays with you. Give each duty a decider, a doer, evidence that it is happening and a review trigger. The register in this guide applies this to nine duties.
The AI pilot acceptance checklist ends in a decision to proceed, revise or stop. This guide assumes the answer was proceed. Someone then has to run the workflow, watch it, change it and be able to switch it off. The register is Amulet's recommended approach for the first months after launch. It is not a standard, a regulation or a service level, and it is not legal advice.
Ownership is more than one job
The business decision stays with the business. Amulet's published scope for a document-to-draft workflow has the workflow owner define "required fields, exception rules and the person allowed to approve a draft", and then says "Your team keeps responsibility for the business decision." A vendor or partner can advise, but under that scope the decision stays with your team.
Running the product is a separate job. Where the workflow sits inside a vendor's software, the vendor usually runs the product, and your IT support or administrator holds the access and settings. A vendor's safeguards are not the whole answer, though. The OAIC's guidance on commercially available AI products says developers may put mitigations in place but "these will not be foolproof", and that "Your business will need to implement its own processes to ensure the use of AI complies with your privacy obligations". That guidance is about the privacy duties of organisations covered by the Privacy Act. Amulet's reasoning extends the point to quality: a vendor's controls do not replace your own checks.
Caring for the workflow belongs to nobody unless someone is named: checking outputs, tuning rules, keeping records current and deciding when to stop. The same guidance says due diligence should not be a "set and forget" approach, and that "Regular reviews of the performance of the AI product itself, training of staff and monitoring should be conducted throughout the entire AI product lifecycle".
The responsibilities register
Amulet's recommended approach is to fill in one row per duty before go-live and to reopen a row when its review trigger fires. "Decides" is the person who can say yes or no. "Does the work" is whoever performs the duty, which may be a vendor or partner. "Evidence" is something you could show a colleague or a successor, such as a log, a list or a dated note. "Review trigger" is the event that should make you reopen the row. Behind every role, write a real name and a backup.
Own, review and monitor (rows 1 to 3)
| Duty | Decides | Does the work | Evidence it is happening | Review trigger |
|---|---|---|---|---|
| 1. Accountable business owner | A director or senior operating leader names the owner. | The owner, with a named deputy. | Owner and deputy written into the register. Dated sign-off of each scope change and each review. | The owner changes role or leaves. The workflow takes on new documents, systems or decisions. |
| 2. Day-to-day reviewer and exception queue | The owner names a reviewer and a backup. The reviewer decides each item: accept, return or redirect. | The reviewer. A vendor or partner should not clear the queue for you. | A queue log showing items waiting, how long they have waited, and what was returned and why. | Items wait past the limit the owner set. No cover when the reviewer is away. Nearly every item is approved while review time shrinks. |
| 3. Quality monitoring and periodic output checks | The owner sets what acceptable means, starting from the pilot's acceptance criteria. | A second person, or the reviewer on a separate pass, samples approved outputs against the source documents. A partner can prepare the sample and the report if its scope includes that. | A dated sample log: what was checked, what was wrong, what changed as a result. | A sample misses the agreed measure. A new document type or supplier format appears. A vendor or connected system changes. |
Change, pause and protect (rows 4 to 6)
| Duty | Decides | Does the work | Evidence it is happening | Review trigger |
|---|---|---|---|---|
| 4. Change control for prompts, models, versions, rules and connected systems | The owner approves each change. IT support, the vendor or a partner advises. | Whoever holds the configuration: your IT support, the vendor for native settings, or a partner if its scope includes it. | A change log: what changed, why, who approved it, which test cases were re-run and how to roll it back. | Any change to a prompt, model, version, rule or connected system, including one a vendor announces. |
| 5. Incidents and authority to pause | The owner and the deputy can pause on their own authority, with no approval step. | Whoever holds the switch or the access, named in advance. | A written pause procedure that has been tried once. An incident record with the reason, the approver and what was held. | A wrong output reaches someone outside the business. Personal information goes somewhere it should not. Exceptions spike. A vendor reports an incident. |
| 6. Access, data handling and vendor terms | The owner, with whoever looks after privacy and security in your business. | IT support or an administrator for access. The vendor for what its product does with your data. A partner for any integration it built. | A dated review of who has access. A note of what the vendor's terms and settings allow for your inputs and outputs. | Vendor terms or settings change. A new integration is added. A new kind of information flows in. Staff join or leave. |
Teach, record and exit (rows 7 to 9)
| Duty | Decides | Does the work | Evidence it is happening | Review trigger |
|---|---|---|---|---|
| 7. Staff guidance | The owner. | The owner or a trainer. The vendor or partner can supply product notes. | A short note of permitted and prohibited uses, and a list of who has read it and when. | New starters. A workflow change. A review finds misuse or over-reliance. |
| 8. Documentation and records | The owner. | The reviewer keeps it current. A partner can draft it during handover. | A current description of the trigger, approved inputs, expected output, exception path, human roles and acceptance criteria. Records that show which outputs were AI-assisted. | Every change. Each periodic review. |
| 9. Exit and handover | The owner decides whether to continue, change, pause or end the workflow. | The partner or vendor hands over. Your IT support or the owner keeps the copy. | A written exit note: where data and configuration live, who holds administrator access, how to export, and how to return to the manual process. | Contract renewal. A partner or vendor ends or changes its service. The workflow stops earning its keep. |
Set the review cadence before go-live and write it down. As a starting point, which is a judgement and not a benchmark, check weekly for the first month and move to monthly if the sample checks hold. Choose a rhythm the owner will keep, because a slow review that happens beats a fast one that does not.
In a small business the same person will fill several rows. That is workable with a deputy, provided the person who samples outputs is not the only person who approves them.
Where the rows come from
Rows 2, 3, 6 and 7 have counterparts in the OAIC guidance for organisations covered by the Privacy Act. Its ongoing assurance section lists "internal policies for the use of AI which clearly define the permitted and prohibited uses" (row 7) and says to "provide for regular audits or monitoring of the output of the product and its use by the organisation" (row 3). On human oversight (row 2) it says: "It is important that a human user should be responsible for verifying the accuracy of any personal information obtained through AI, and can overturn decisions made." On vendor access to data (row 6) it says: "you should understand whether the service terms provide the developer with access to data which your organisation inputs or generates when using the AI".
Rows 1, 4, 5, 8 and 9 are Amulet's own design. Row 2 borrows its verbs from Amulet's capabilities page, which describes the review step this way: "A person accepts, returns or redirects the work before it is treated as complete." Row 8 reuses the design elements listed on the same page: "Define the trigger, approved inputs, expected output, exception path, human roles, integration assumptions and acceptance criteria for one useful job." After launch, that description has to stay current.
A hypothetical filled example
This is an illustration, not a case study. A trade supplier uses an AI-assisted workflow that turns purchase requests into draft purchase orders, and a person approves each draft before release. The roles and limits in these five rows are invented for the example, so set your own.
| Row | Named role (hypothetical) | Rule the owner sets (hypothetical) |
|---|---|---|
| 1. Owner | Operations manager. The finance lead is the deputy. | Reads a one-page summary each month and signs any scope change. |
| 2. Reviewer and queue | Purchasing coordinator. The warehouse supervisor is the backup. | An item unresolved for two working days goes to the operations manager. |
| 3. Quality checks | Finance lead, who does not approve drafts. | Compares a sample of approved drafts with the original requests each fortnight and logs the result. The owner sizes the sample to the volume. |
| 4. Change control | Operations manager approves. IT support applies the change. | Nothing goes live until the pilot's test cases are re-run and the result is filed. |
| 5. Pause | Operations manager or finance lead. | Switch off intake and route requests to the manual process the same day. |
The shape matters more than the numbers: every row names a person with cover, a way to see that the duty is being done, and an event that reopens it. The test cases in row 4 are the ones from your go-live decision, which the pilot acceptance checklist sets out.
Choosing an operating model
No option below is right for every business. The table is Amulet's recommended way to compare five options by when each fits and what it does not remove. None of them removes the business decision.
| Option | Fits when | Who runs it day to day | What it does not remove |
|---|---|---|---|
| In-house with a named owner | Volume is modest, a reviewer has time, and your IT support can manage access and settings. | Your owner and reviewer, with IT support. | The sampling and change-control rows still need a person each. One person knowing how it works is a risk of its own. |
| The vendor's native features and support | Software you already have does the job, so there is nothing to build. | The vendor runs the product. You run review, sampling and the pause decision. | The business decision, your own checks, and the need to notice when the vendor changes features, terms or settings. |
| An implementation partner hands over and exits | You have an owner and a reviewer ready, and the handover is documented and tested before the partner leaves. | Your team, after handover. | Tuning and change: nobody does them unless you arrange it. Knowledge leaves with the partner unless it is written down. |
| An ongoing support or improvement arrangement with a partner | Inputs, rules or connected systems change often, or nobody in-house can evaluate and tune the workflow. | Your reviewer still clears the queue. The partner does the work its written scope names. | The owner, the exception queue, the pause authority and the business decision. It also adds a dependency you should plan to exit. |
| Keep or return to the manual process | Review time stays high, exceptions dominate, or nobody can take ownership. | Your team, as before. | The manual process still needs an owner and capacity. If you switch the AI-assisted path off later, the way back must be written down. |
If you cannot name a reviewer with cover and a person who can pause the workflow, that is a reason to delay go-live or keep the manual process, not to launch and hope.
The native and no-build path
Check the tools you already have first. Amulet's document-to-draft page says: "If your purchasing or accounting system already supports document capture, draft records and approval rules, test that path before commissioning software." Its caveat: "Availability depends on your product, plan and configuration." For a small volume, the page says "a shared intake folder, a draft template and a named reviewer may be enough". It also says: "A valid outcome of discovery is to configure an existing tool, simplify the process or not build." If a native feature does the job, rows 1 to 9 still apply, though they may get shorter because the vendor holds more of the configuration. The owner, reviewer, sampling, pause authority and exit note do not disappear.
What Amulet's public pages say about ongoing support
Amulet's public pages describe support in narrow terms. On the AI Business BEEP page, the fourth step reads: "Where useful, Amulet supports adoption, evaluation and measured tuning after the agreed capability meets its operating boundary." The capabilities page describes its pilot and improve step as: "Test with representative information and named reviewers, launch under supervision, monitor the agreed workflow and improve it within a defined operating scope." Those pages state no price or service level, and this guide does not either. If a partner proposes ongoing support, ask for its scope in writing and check it row by row. Which duties will the partner do, and what evidence will it hand over for each? Anything left over stays with you.
The document-to-draft demonstration lists "monitoring and support" among the things outside that demonstration, so it is not evidence of how any operating arrangement works.
For supplier questions, including who owns, supports and can change the system, see How to choose an AI implementation partner in Australia. Reviewer time, sampling and the exit all cost something, and the AI implementation cost worksheet separates cash from staff effort so you can compare these options over the same operating period.
Where it fails without a named owner
These are illustrative scenarios built from the register, not reported incidents. The remedies are Amulet's recommended approach.
Nobody owns the exception queue
Amulet's capabilities page describes the design intent: "An unresolved item stays held until a named reviewer decides what happens next." If no named reviewer exists, the hold has no end. Items pile up, or whoever is nearest clears them to keep work moving, which removes the point of holding them. Row 2 addresses this. Name the reviewer and a backup, and have the owner set how long an item may wait.
A vendor changes a model, a version or its terms
Suppose a vendor updates the model behind a feature your workflow relies on, or revises how it handles your inputs. Nobody in your business decided to change anything, yet outputs or data flows may have moved. Rows 4 and 6 cover this: treat a vendor-announced change as a change, re-run your test cases before relying on it, and re-read your data settings. The OAIC guidance says: "you should understand whether the service terms provide the developer with access to data which your organisation inputs or generates when using the AI". It also notes: "The accuracy and reliability of an AI model is vulnerable to deterioration over time."
Reviewers stop checking properly
Output that is usually right invites less checking. The OAIC guidance includes a hypothetical embedded assistant whose errors increase as its underlying processes and training data become outdated, and warns that without oversight "there is a risk that staff will come to over-rely on the assistant and overestimate its accuracy". Rows 3 and 7 respond to this: a second person samples approved outputs against source documents, and the staff note tells reviewers what to look for. Treat approvals that speed up while sample errors rise as a trigger to review.
An incident needs a pause
A wrong draft reaches a supplier. Who can stop the workflow, and how long does that take to arrange? If the answer involves a vendor ticket or a meeting, the authority in row 5 is missing. Amulet's published example of an implementation decision record, on the BEEP page, lists recovery and evidence as "Stop safely, retain inputs, record the reason, approver and authorised output." Use that as a template for your own pause procedure: stop intake, keep what came in, write down why, who approved the pause and what output is still authorised.
The partner leaves
Partners leave, on schedule or not. The BEEP page says "A review can end with a no-go, a process change, an internal build or another delivery partner." Amulet's view is that a handover to someone else is a normal event, not a failure. What breaks is a handover where the knowledge sits in one person's head: prompts, rules, the reasons for earlier changes and administrator access. Rows 4, 8 and 9 cover this with a change log, current documentation and an exit note. Ask for them as deliverables of any implementation, and have a named person in your business read them before the partner goes.
Privacy duties that continue after launch
If your business is covered by the Privacy Act and personal information goes into or comes out of the workflow, the OAIC's guidance for commercially available AI products is relevant. It says: "If your organisation is covered by the Privacy Act, you will need to understand your obligations under the APPs when using AI." Whether the Act covers your business is a question for your own adviser, and this guide does not answer it.
Treat the guidance as one input. It says that it "is not intended to be a comprehensive overview of all relevant privacy risks and obligations that apply to the use of AI" and that it "does not address considerations from other regulatory regimes that may apply to the use of AI systems". It is regulator guidance on privacy obligations, not general AI regulation, and it is not an operating model for a workflow. Its ongoing points land in rows 2, 3, 6 and 7 of the register, as set out above.
Five questions to answer by name before sign-off
Amulet's recommended pre-sign-off test is to answer each of these with a person's name.
- Who can pause the workflow today, without asking anyone, and how?
- Who clears the exception queue when the usual reviewer is away?
- Where is the change log, and who approves the next change?
- What do the vendor's terms and settings allow for your inputs and outputs, and who watches for changes?
- If the vendor or partner stopped tomorrow, who holds the access and configuration, and what is the way back to the manual process?
An answer such as "IT" or "the vendor" is a gap. Each answer should be a person.
What this guide does not establish
It does not survey how many businesses use each operating model or what any model costs, and it does not review any vendor's current documentation. Nothing here says what a particular product's logs, administrator controls or support terms offer. Check that with the vendor, in writing, for your plan. The register is reasoned design from Amulet's published scope and one regulator's guidance, not the result of a study or a field trial. The cadence and limits are starting points to adjust to volume and consequence.
Next step
If your workflow is close to go-live and some rows have no name against them, discuss your first AI workflow with Amulet. Bring the workflow, who reviews it today and which of the nine rows you cannot fill. Amulet's published process starts with a problem-fit call and treats implementation as a separate decision: "Implementation remains a separate go or no-go commitment."
Sources
A practical next step
Put AI to work with the operating boundary visible.
Approvals, evidence and the rollout path should be mapped to the real workflow.
Discuss your first AI workflow