Do not enter personal, sensitive, confidential, legally privileged, payment, credential, or security information into a public AI tool unless the organisation has explicitly approved the product, account, purpose, and data handling. When in doubt, stop and ask.
The fastest way to create an AI privacy problem is to let each employee decide for themselves what is safe to paste.
Businesses need a short, practical rule that covers both the information and the tool.
Start with the public-tool rule
A publicly available AI tool is not automatically approved for business data because it is well known, free, or easy to access.
As a default, prohibit these categories from unapproved public AI tools:
- Customer, patient, employee, applicant, or supplier personal information.
- Sensitive information such as health, biometric, racial, religious, political, or sexual information.
- Passwords, API keys, security questions, access tokens, or recovery codes.
- Card numbers, bank details, tax identifiers, or identity documents.
- Confidential contracts, pricing, negotiations, board papers, or acquisition material.
- Legal advice, privileged communications, or active dispute material.
- Proprietary code, designs, formulas, models, or trade secrets.
- Information covered by client confidentiality or professional obligations.
- Data that would create harm if exposed or used in the wrong context.
This is a starting point, not a complete legal assessment.
Australian privacy obligations still apply
The OAIC guidance on commercially available AI products explains that privacy obligations can apply to personal information entered into AI and to personal information generated in the output.
The OAIC recommends, as a matter of best practice, that organisations do not enter personal information—and particularly sensitive information—into publicly available generative AI tools because of the significant and complex privacy risks.
The business should understand:
- Why the information was collected.
- Whether this AI use is permitted for that purpose.
- Who receives or can access the data.
- Where it is processed and stored.
- Whether it may be retained or used to improve a service.
- Whether information is disclosed outside Australia.
- Whether deletion or access requests can be supported.
Do not rely on an employee ticking a terms box to answer those questions.
De-identification is useful but not magical
Removing a name may not remove identity.
Consider whether a person can be recognised from:
- An exact address or location.
- A rare job or medical condition.
- Dates and incident details.
- A customer number or partial identifier.
- A small team or unusual complaint.
- Several harmless-looking fields combined.
If the task does not require real details, replace them with synthetic examples. If it does require them, use an approved environment and process.
Separate data classes from tool classes
Create a simple matrix:
| Data class | Public tool | Approved business workspace | Approved specialist system |
|---|---|---|---|
| Public marketing copy | Allowed | Allowed | Usually not needed |
| Internal non-confidential process notes | De-identify and check policy | Usually allowed | As required |
| Personal information | Prohibited by default | Only approved use cases | Only approved use cases |
| Sensitive, privileged, credential, payment, or secret data | Prohibited | Highly restricted | Purpose-built controls required |
The exact settings depend on the business and provider. Review them rather than assuming every paid plan behaves the same way.
Give staff a safe alternative
A ban without a usable alternative encourages shadow AI.
Provide:
- An approved business account.
- A list of approved use cases.
- A safe prompt library using synthetic examples.
- A de-identification guide.
- A contact for unusual requests.
- A process for proposing a new tool or use case.
Then train people with examples from their actual work.
Use a five-question pause
Before entering information into AI, ask:
- Is a person identifiable directly or indirectly?
- Is the information confidential, privileged, secret, financial, or security-related?
- Is this specific tool and account approved for this data?
- Is AI use consistent with why the data was collected and what people were told?
- Would I be comfortable explaining this data flow to the affected customer or employee?
If any answer is unclear, pause.
Review the output too
AI can generate or infer personal information even when the prompt was not intended to do so. Check outputs for:
- Invented personal details.
- Sensitive inferences.
- Data copied from an attached document.
- Confidential material carried into a later draft.
- Content going to the wrong recipient.
Privacy is an input, processing, and output issue.
Make the rule operational
Add the data rule to your AI policy, onboarding, project instructions, approved-tool register, and AI review checklist.
Rising Tide’s AI consulting helps teams turn broad privacy concerns into approved workflows staff can actually follow. Obtain legal or privacy advice for obligations specific to your organisation.