Does your AI tool send customer data overseas? What to check first

Follow one real task through every service

“Does this tool store data in Australia?” is a useful question, but it is not a complete assessment. An AI workflow might involve a form, an automation connector, a model provider, a log store and a support team. Each can handle a different copy of the information. Start with a fictional or suitably minimised example of the task. Write down exactly which fields leave each system, which organisation receives them, where processing occurs and who can access the result. Include prompts, attachments, outputs, error logs and saved conversation history.

Keep readingApprove tools in a short register

Distinguish location from control

OAIC guidance distinguishes use within an entity's effective control from disclosure outside that control. Its APP 8 guidance says providing personal information to an overseas contractor is a disclosure in most circumstances. The specific arrangement matters; a hosting location alone does not settle that legal question. First establish whether your organisation is covered by the relevant privacy obligations, then assess the actual data flow and contracts. Do not assume that accepting a vendor's standard terms or selecting an Australian region automatically resolves overseas handling.

Put these questions to the vendor

Ask for answers that apply to the exact product, plan and configuration being purchased. Consumer chat accounts, enterprise services and API products may have different terms.

Save the dated answers and relevant terms. A screenshot of a setting is useful configuration evidence; it is not evidence of every contractual commitment.

• Which organisations and subprocessors can receive inputs, outputs and logs, and in which countries?
• Are customer inputs or outputs used for model training, and can that setting be controlled for this product?
• How long is each copy retained, including abuse-monitoring logs and support records?
• Who can access it for support, and what authorisation and access records exist?
• What deletion, export, incident-notification and contract-exit processes are available?

Worked example: an enquiry-summary assistant

A business wants a daily summary of new enquiries. The first design sends full emails and attachments to several tools even though the summary only needs service type, suburb and next action. The owner removes unnecessary fields and uses an internal reference instead of a customer's full details where feasible. Next, the owner traces the remaining fields through the connector and model service, checks the applicable vendor terms and sets an appropriate retention process. Reducing the input helps, but it does not by itself establish that the remaining information is anonymous or that every privacy obligation is met.

Match permissions to the assessed task

If the workflow only needs to summarise selected enquiries, avoid giving it unrestricted access to every mailbox and document library. Check whether it can read a limited folder or receive a controlled extract instead. Require approval before it sends, changes or exports customer records. Use an accountable owner for the connection and a tested revocation path. Record what happens to stored prompts, logs and outputs after access is revoked; stopping future access does not necessarily delete earlier copies.

Keep readingSee how the same rule applies to tracking tools

Recheck when the workflow changes

OAIC's AI-products guidance calls for ongoing due diligence rather than a set-and-forget approach. Reassess when you add attachments, switch products, enable a connector, change a plan or start using outputs for a new purpose. Keep the data-flow map beside the workflow's permissions and test record. That makes it possible to answer a practical question later: which services received this category of customer information, under which settings and terms?