Published by Flowtivity · Reviewed 26 October 2026 · General operational guidance
01 / Define the job before the tool.
“Use AI across the business” is too broad to test. “Draft a handover from completed work notes for one team” gives people something they can evaluate.
Write the current trigger, input, action, reviewer and final destination. Ask the team what causes rework, what information is often missing and which exceptions need judgement. Include the people receiving the output, not only those creating it.
Then ask what kind of change fits. A consistent template may be enough. Defined steps may suit ordinary automation. AI assistance can be useful where interpretation or drafting is involved, with appropriate controls and review.
“The pilot will draft [output] from [approved inputs] for [one team], and [named role] will check it before [consequence].”
02 / Give every team the same starting rules.
Document what information may be used, who can access it and what the AI is permitted to do. Review the provider’s terms and settings, including retention and potential use of data for training. Confirm that document permissions still apply when a new tool makes information easier to retrieve.
The OAIC recommends due diligence when selecting commercial AI products and a privacy-by-design approach. Its guidance also recommends avoiding personal, particularly sensitive, information in publicly available generative AI tools as a matter of best practice. See OAIC guidance.
| Keep common | Check locally |
|---|---|
| Permitted data and access | Which people and systems hold it |
| Human approval requirements | Who owns the review in each team |
| Source quality and maintenance | Which approved details differ by location |
| Escalation and manual fallback | Local contact and handoff arrangements |
03 / Build a pilot brief.
Use this planning aid to make the proposed boundary concrete. The outputs are starting prompts for a discussion with your team. They are not a risk assessment or a recommendation for a particular tool.
A first draft of your pilot boundary.
Change the inputs to explore a starting brief. This tool does not assess your systems or decide whether a use case is safe. Your selections stay in this page.
- Pilot boundary
- Draft replies for one enquiry type using an approved answer library. A person approves every reply.
- Review owner
- Customer service lead; include the person who handles exceptions.
- Data checkpoint
- Use approved public material and check rights, currency and accuracy. Keep credentials and customer records outside the test.
- Evidence to keep
- Compare drafts with approved answers. Record incorrect facts, missing details and the effort needed to review.
- Expansion gate
- Agree acceptance criteria with the owner. Review a sample of real work, document exceptions and keep a manual fallback before routine use.
04 / Agree the evidence before the demo.
Choose examples that represent real work, including awkward cases. A polished demonstration tells you little about a missing attachment, an outdated document or a request the system should refuse.
Agree acceptance criteria with the people accountable for the process. Keep a simple review log: the input, expected behaviour, actual output, issue found and action taken. Measure review effort alongside output quality; a quick draft that needs substantial correction may not improve the workflow.
- Accuracy: Are statements supported by an approved source?
- Completeness: Are the required details present, or explicitly flagged as missing?
- Boundaries: Does the workflow pause when the request is outside scope?
- Usability: Can the reviewer understand and correct the output?
- Recovery: Can a person continue the work when the tool is unavailable?
05 / Decide what travels to the next team.
Review what the pilot actually established. Document the tested task, the limitations and the changes needed. Try a second team with different local conditions before assuming the result applies everywhere.
Keep an accountable owner for the workflow and its source material. Decide how errors are reported, how often results are sampled and what changes require another review. New data, a different model, altered provider terms or a more consequential use can change the assumptions behind the original pilot.
The National AI Centre’s adoption guidance provides foundations and implementation guidance for organisations planning and managing responsible AI adoption. Use those materials to support a proportionate governance process, with specialist advice when needed.
Continue with the defined scope, change the approach and test again, or stop. Each can be a sensible result when supported by evidence.
Sources and further reading
These primary sources inform the governance and privacy considerations in this guide. The workflow examples and planning aid are Flowtivity’s illustrative operational approach.
- OAIC: commercially available AI productsProduct due diligence, personal information, transparency and privacy by design.
- National AI Centre: AI adoption foundationsOrganisational accountability, purpose and managing AI adoption.
- National AI Centre: implementation guidancePractical guidance for putting responsible AI practices into operation.
- business.gov.au: artificial intelligenceAn Australian business introduction to AI adoption and responsibilities.