Before staff connect AI to customer records, map what information can leave each system, who can receive it and what the answer may reveal. A permission check inside your CRM is only one part of that decision.
For Australian businesses, the Office of the Australian Information Commissioner's guidance on commercially available AI products is a useful starting point. It covers both information entered into AI and personal information generated by it. The checklist below turns that guidance into practical questions for a rollout. It is not legal advice or a substitute for assessing your organisation's obligations.
Start with one job, not every connected system
Write down the task staff need help with. "Summarise the latest customer service correspondence" is more useful than "give AI access to customer data". Identify the records that job needs and the people who should be able to ask for them.
Then ask whether personal information is necessary. A process question may be answerable from a policy document without any customer records. A test of the interface can often start with synthetic records. Connecting more data than the job requires creates more decisions to manage without necessarily improving the answer.
Map the whole data flow
Follow a typical question from start to finish. Include retrieval, prompts, model processing, the answer, stored conversation history and logs. For each step, record:
- Which fields or documents can be included, including names, contact details and sensitive information.
- Who can access them: the staff member, administrators, AI providers, support teams and other services.
- Where processing and storage occur, including any overseas disclosure.
- Whether information is retained or used for training, and which terms and settings control that use.
- How correction, deletion and incident handling work across the services involved.
Check the actual product tier and configuration you intend to use. A provider's general privacy statement is not enough to establish the settings of your account. A local or single-tenant application does not, by itself, prove that every model request stays in Australia. Trace the model-provider path too.
Separate access from the purpose of using information
A staff member may be allowed to read a customer record. That does not settle whether using it for a new AI task, or disclosing it to another provider, is appropriate.
The OAIC explains that, for organisations covered by the Privacy Act, APP 6 limits use or disclosure to the primary purpose of collection unless an exception applies. Consent and reasonably expected related secondary uses are among the considerations. Sensitive information needs particular care. Do not turn this into a blanket rule that all AI use requires consent, or that a privacy-policy update automatically permits every use.
Have the person responsible for privacy assess the proposed purpose and data flow before enabling it. The Australian Privacy Principles apply to organisations and agencies the Privacy Act covers; establish your position rather than assuming every business has identical obligations.
Test what the answer reveals
Test with different staff roles, not only an administrator. Include a question that mixes records the user can access with records they cannot. Check the answer and its supporting sources, not just whether a restricted document opens.
Also test generated statements about people. An AI-created opinion, inference or false statement can still be personal information when it concerns an identified or reasonably identifiable person. An answer that invents a customer's circumstances is therefore more than a weak summary.
Keep source references available and define when a person must verify an answer before it influences a decision. For decisions with significant consequences for individuals, a successful chat demonstration is not enough to establish suitability.
Make the rollout rules usable
Give staff clear examples of what they may enter, what they must leave out and when to stop and ask. The OAIC recommends, as best practice, not entering personal information, particularly sensitive information, into publicly available generative AI tools.
Explain where approved work should happen instead. Update relevant notices and policies, and make public-facing AI tools identifiable as AI. Set a route for reporting incorrect answers or accidental disclosures. Rules need training and review; a policy that nobody can apply will not control day-to-day use.
Keep a short decision record
For the first use case, record the task, permitted sources, data recipients, provider settings, staff roles, review points and unresolved risks. Name an owner and decide what changes trigger another review, such as a new provider, feature, connector or category of information.
A privacy impact assessment can help identify and manage risks before deployment. Match its depth to the work and the possible harm. A checklist is a way to organise the assessment, not proof that the system is compliant.
The practical starting point is a defined job, a documented data flow and a tested boundary. Connect the next source only when you can explain why it is needed and how its information will be handled.
Related: Give AI a job, then define its authority and Connect the context before the workflow.