AHAI article

Why you should not paste client information into public AI tools

A plain-English explanation of why identifiable client information should not be entered into public AI tools, and what can happen when it leaves your control.

Most allied health professionals have heard the warning by now:

Don’t put confidential client information into AI tools.

It is good advice. But the information often ends there, without explaining why this is a risk or what the consequences might be.

That is a problem, because when people do not understand the reason behind the rule, they may underestimate it. If they do not understand the problem, they may also apply the wrong solution.

1. The common advice

In allied health, client information is often sensitive. It may include health details, disability information, family circumstances, school or workplace information, NDIS details, reports, referrals, photos, audio, transcripts, and clinical observations.

That information needs careful handling. But in the world of AI tools, what does that mean?

The usual advice is simple: do not paste confidential or identifiable client information into public AI tools.

This includes public chatbots, free AI writing tools, browser-based assistants, transcription tools, note-taking tools, and AI features built into everyday software.

The concern is especially strong when the tool has not been approved by the clinic, school, university, health service, or organisation.

2. Why the advice often does not land

“Don’t paste confidential information” can sound too broad.

A clinician might think:

“I removed the client’s name, so it should be fine.”

A practice owner might think:

“These tools are everywhere now. They must be secure enough.”

A team member might think:

“I’m only asking for help with wording. I’m not asking it to make a clinical decision.”

These are common assumptions. They are also incomplete.

The privacy issue starts when identifiable information leaves the professional setting and is sent into another company’s system. The person using the tool may not know where the information is stored, who can review it, whether it is kept in logs or backups, whether it is processed overseas, or whether it can be used to improve the service.

That loss of control is the problem.

3. What actually happens when you paste information into a public AI tool

When you type into a public AI tool, the text usually does not stay on your device.

It is sent to servers run by the AI provider. Those servers may be outside Australia. The text may be processed, stored, logged, reviewed for safety or quality, kept in backups, or handled by other companies that support the AI service.

Some tools may use prompts and responses to improve their systems. Some allow users to turn that off. Some business or enterprise products offer stronger privacy protections. The details vary by product, account type, settings, and terms of use.

A public AI chat should not be treated like a private clinical note.

A clinical note sits inside a system chosen for clinical work. It should have access controls, privacy expectations, contracts, and professional rules around it.

A public AI tool may sit under different privacy terms, different retention settings, different staff access rules, and different overseas processing arrangements.

That difference matters.

4. The risk is not just that the AI might repeat it later

Many people imagine the risk like this:

“If I paste a client’s details into AI, maybe the AI will repeat those details to another user.”

That can happen in some situations, especially when information is used to train or fine-tune AI models. AI systems can sometimes memorise parts of information they have seen. Researchers have also shown that some systems can leak information under certain conditions.

But this is not the only risk, and it is not usually the most immediate one for everyday clinical use.

A more practical risk is disclosure.

If you paste identifiable client information into a public AI tool, you may have shared that information with an external company. It may be stored in that company’s systems. It may sit in your chat history. It may be included in technical logs. It may be reviewed by people working for, or contracted by, the provider. It may pass through other vendors that help run the service. It may be kept in backups for a period of time. It may be processed in another country.

Each of these pathways creates a different kind of privacy problem.

If the information is stored in the AI provider’s systems, it is no longer only held in the clinical or workplace system chosen for that purpose. The clinic may not control how long it is kept, who can access it, or how deletion works.

If it remains in chat history, it may be visible to anyone with access to that account or device. This matters where staff use shared logins, browser sync, personal accounts, screenshots, or shared chat links.

If it is included in technical logs, the information may be copied into background records used to run, monitor, secure, or debug the service. These logs are not usually visible to the user, but they may still contain parts of prompts or uploaded material.

If people working for the provider or its contractors can review conversations, then identifiable health information may be seen by people outside the client’s care team. Even if review is limited and controlled, it may still be a disclosure the client did not expect.

If the information passes through other vendors, the number of organisations involved increases. Cloud hosting, security, analytics, support, and infrastructure providers may all play a role in running the service. Each extra party makes it harder for the clinician or practice to understand where the information went and what rules apply.

If the information is kept in backups, it may not disappear immediately even if a chat is deleted. Backups are designed to preserve data after errors, failures, or incidents. That can be useful for security and reliability, but it also means deletion may be less simple than it appears.

If the information is processed overseas, Australian privacy obligations may still apply to the clinician or organisation that disclosed it. Overseas processing can also raise questions about which country’s laws, vendors, security standards, and access rules apply.

Australian privacy law does not simply say that every health record must always stay in Australia. But sending health information overseas can trigger extra privacy obligations, and some health systems, contracts, government programs, workplace policies, or approved software arrangements may require Australian storage or tighter controls. For example, My Health Record states that its data is stored in Australia. A public AI tool should not be assumed to meet those kinds of requirements unless it has been properly assessed.

There are also account-level risks. A shared clinic login, browser sync, screenshots, copied outputs, shared chat links, or a compromised password could expose information that should never have been there.

An email example helps.

If a clinician accidentally emails a client report to the wrong external address, the main concern is not that the email system will “learn” the report and repeat it to the world. The concern is simpler: the report has left the clinic and gone somewhere it should not have gone.

Public AI tools can create a similar issue. The chat box feels private, but the information may have moved into a third-party system.

You do not need to prove that a person read the information for there to be a privacy concern. For health information, sending identifiable details to the wrong place is still a breach of privacy and patient trust.

5. Why removing the name is not enough

Removing a name is a useful first step. It is not the same as de-identifying information.

A person can still be recognised through context.

For example:

“A 14-year-old student at a small regional high school with a recent spinal cord injury is returning to class next term. Their mother is worried about fatigue, pressure care, and wheelchair access.”

There is no name in that example. But in a small community, the person may be obvious.

Another example:

“An adult client from a two-person accounting firm in Bendigo has recently been diagnosed with Parkinson’s and is worried about handwriting and work performance.”

Again, no name. But the combination of location, workplace type, diagnosis, and functional concern may be enough to identify the person.

This is called re-identification. It means a person can be recognised even after obvious details have been removed.

Allied health work often includes rich context. Home setup, school participation, workplace duties, funding arrangements, family supports, functional goals, and clinical history can all point back to a real person.

A simple test helps:

Could someone who knows the client, family, workplace, school, or local community recognise this person from the prompt?

If the answer is yes, the information is still too identifiable for a public AI tool.

Changing the task is often safer than lightly editing the details. Instead of asking AI to work on a real client’s situation, ask for a fictional example, a general handout, a checklist, draft wording, or a broad explanation.

Before using an AI tool, it helps to pause at the point where information is about to be pasted, uploaded, dictated, or transcribed.

AHAI has a free checklist for this: Before You Paste Into AI.

Use it to check what information is involved, whether a person could be identified, what task you are asking AI to do, what the tool may do with the data, and who needs to review the output.

Download the free checklist

Related reading: What not to paste into ChatGPT or other AI tools and When sensitive information goes into the wrong AI tool.

Information sources

This article is informed by current OAIC guidance on commercially available AI products, OAIC guidance on APP 8 cross-border disclosure, and Australian Digital Health Agency information about My Health Record.