A staff member wants help replying to a customer. Copying the whole email into an assistant seems like the quickest way to get a useful draft. The message may also contain a name, contact details and information about the customer’s situation.
Before making that a routine workflow, the business needs to understand more than the quality of the reply. It needs to know what is being shared and what the tool does with it.
What information does the task actually need?
Our recommendation is to begin a test with a made-up enquiry or an appropriately de-identified example. Keep only the details needed to test the task. Removing a name alone may not remove the ability to identify someone, so consider the rest of the message too.
The OAIC recommends, as good practice, avoiding personal and especially sensitive information in publicly available generative AI tools. Its guidance also discusses supplier suitability, human oversight and data handling. Read the OAIC’s guidance on commercially available AI products.
Whether specific privacy obligations apply depends on the business and activity. This is a practical planning guide, not a determination of your legal obligations.
Is this the right product and plan?
A familiar brand name does not tell you which terms apply to the product your team is using. Our recommendation is to check the exact account and subscription, the settings available to administrators and the supplier’s current documentation.
The decision record can stay short: which task the tool supports, which information is allowed, who approved it and who owns the review. A free personal account and a managed business arrangement should not be treated as interchangeable without checking their terms.
These are questions to investigate, not assumed features of any particular supplier. If the answers are unclear, pause that part of the workflow while you check them.
Who checks the draft?
For a customer reply, name the person responsible for checking the facts, tone and proposed action. They need to notice when the draft promises something the business cannot provide, uses the wrong price or misunderstands the customer’s request.
Australian government guidance recommends checking AI outputs and matching oversight to the risk of the use. See business.gov.au’s advice. Our recommendation is to make that review an explicit workflow step rather than relying on someone to remember it.
What should the team be allowed to do?
Start with a few clear, practical rules. Here is an example to adapt after assessing your tools and obligations:
Use approved tools for the agreed task. Keep customer information out of unapproved tools. Check drafts before sending them. Raise unexpected results with the person responsible for the workflow.
This is a starter for discussion, not a complete AI policy. A business handling health, financial, employee or other sensitive information may need more detailed advice and controls.
What happens when something goes wrong?
Walk through an ordinary mistake before rollout. A draft has the wrong date. A message is sent to the wrong review queue. A connection fails. Who sees the problem, who can stop the workflow and how is the correction recorded?
Our practical recommendation is to test the normal path and the exception path together. Keep the first pilot small enough that someone can inspect the results. Then agree what will be monitored and who will respond as the tools or business process change.
A useful first step
Choose one task your team wants help with and list the information it needs. Check the product terms and the review arrangement before sharing real customer data. You can assess the idea without turning the whole inbox into an experiment.
