AI in healthcare: privacy, regulation and ethics in AU/NZ

I ran a multidisciplinary clinic in New Zealand. In all that time I never read the indemnity or liability clauses in a single software contract. Not one. I had no idea what was in them. Sign it, get set up, move on. Avant's checklist of 13 February 2026 names the exact clause I should have read. It's quoted in full further down.

That's how most practice owners buy software. For a booking system, fine. An AI tool holding patient history is a different bet. One of those clauses can shift risk off the vendor and onto you. Your insurance might not follow it there. And the line that should really stop you isn't in the contract at all. It's sitting in your insurance policy.

So this page puts the Australian and New Zealand rules in one spot. What the privacy law says. What RACGP's new AI standard wants from you. What a vendor indemnity clause actually does to you. And where the legal answer stops matching the right answer.

The short version. Do one thing this week. Open your AI vendor's terms and search them for the word "indemnity". Email whatever comes up to your indemnity insurer. Ask, in writing, whether your policy covers it. Everything else here is slower work. That one email closes the widest gap, and almost nobody has checked it.

This isn't legal advice. It names the rules, quotes them, and dates them. What applies to your practice depends on your state, your profession, your insurer and your contracts. Get your own advice before you sign anything or change how you handle patient data.

What this covers, and what it doesn't

The tool choices live elsewhere. Picking a scribe? Start with how to choose an AI scribe. It has the vendor questions and the data residency checks. Already picked one and now you've got to get the team using it? Rolling out an AI scribe covers the consent scripts and the training. After the day to day stuff instead? Start with the guide to AI in healthcare administration.

An AI scribe is software that listens to a consult and writes up the clinical note. A clinician then reads it, fixes it and signs it. It's the AI tool most practices meet first, and most of this page is written with it in mind.

This page is the rules sitting underneath all three.

Australia: what putting patient data into an AI tool triggers

The Privacy Act 1988 and the Australian Privacy Principles already cover your AI tool. Same way they cover anything else that holds personal information. There's no special AI carve-out.

The Australian Privacy Principles are the thirteen rules at the heart of the Privacy Act. They set how you can collect personal information. Then what you're allowed to use it for. Then who you can pass it to, and how you've got to keep it safe. Everyone shortens them to APPs, and each one has a number.

The OAIC has said it about as plainly as a regulator ever does: "Privacy obligations will apply to any personal information input into an AI system, as well as the output data generated by AI (where it contains personal information)" (OAIC, Guidance on privacy and the use of commercially available AI products, 21 October 2024).

Read that twice. What goes in is covered. What comes back out is covered too.

Two things follow for your practice. The first is about purpose. You collected that patient's data to treat them. That was the point of it. APP 6 limits using it for a second purpose. Handing it to a vendor who feeds it into their model is a second purpose. So what your vendor does with your data is a privacy question first and a shopping question second. The OAIC's own advice is to run a Privacy Impact Assessment before you buy, not after.

The second one has a date on it.

What changes on 10 December 2026

New disclosure rules start on 10 December 2026. From that day, a business has to say so in its privacy policy. The trigger, in the OAIC's words, is that it "has arranged for a computer program to make, or do a thing that is substantially and directly related to making, a decision". The second limb: "that decision could reasonably be expected to significantly affect the rights or interests of an individual, and personal information about the individual is used in the operation of the computer program to make the decision" (OAIC, APP 1 guidelines).

In normal words: software makes a decision about a patient, or does most of the work behind one. That decision matters to them. If that's you, your privacy policy has to spell it out.

The OAIC's own example lands right on health: "a decision that affects the individual's access to a significant service or support, such as access to healthcare services."

The rules come from subclauses 1.7 to 1.9 of Schedule 1 to the Privacy Act. The Privacy and Other Legislation Amendment Act 2024 put them there. They bite on decisions made from 10 December 2026, whenever you set your AI up. So a tool you install today that triages or ranks patients is in scope then.

Where does a scribe sit? A scribe drafts a note, a clinician checks it and signs it. That isn't the tool making the call. A tool that sorts who gets seen and when sits a lot closer to the line. If you can't tell which side yours is on, that's the question for your own lawyer.

When the legal answer and the ethical answer come apart

Here's an example of how far apart the two can get.

Back in 2019, Australia's biggest radiology chain went into a joint venture with an AI start-up. The chain is I-Med Radiology Network. The start-up is Harrison.ai. Around 30 million scans went into training a diagnostic tool called Annalise.ai. It's reportedly approved for use in over 40 countries. There's no evidence those patients gave informed consent, and neither company disputed that.

In July 2025 the OAIC ruled that I-Med hadn't breached the Privacy Act. The reason? The data had been de-identified, so it wasn't personal information under the Act any more.

De-identified data is data with the bits stripped out that would let someone work out whose it is. Do that properly and the Privacy Act stops applying. That's why the word carries so much weight here.

An OAIC spokesperson said consent "is always a highly relevant factor". But it is "only required in limited circumstances by the Australian Privacy Principles, and will not always be required when entities use personal information for AI training" (CHOICE, last updated 21 October 2025).

So de-identification decided whether the Privacy Act applied at all. Consent didn't. And the bar for properly de-identified is, in the OAIC's own words on the same page, "context dependent."

Nothing illegal happened here. But I reckon those patients would have assumed their scans could never be used that way. That's the whole problem. The legal answer and the ethical answer came apart.

Which means the risk here isn't a fine. It's your brand, and your standing with the people who already walk through your door. If you're ever making that call, ask whether you could wear patients walking away over it. That's a business call, and the rules won't make it for you.

New Zealand: the Privacy Act 2020 and the Health Information Privacy Code

New Zealand has something Australia doesn't. A code written just for health information.

The Health Information Privacy Code 2020 covers health information about people who can be identified. It binds health agencies. In the Commissioner's words it "takes the place of the information privacy principles (IPPs) for the health sector." It applies to doctors, nurses, dentists, pharmacists, optometrists and other health service providers (Office of the Privacy Commissioner, HIPC 2020).

The Code has been amended twice. The version in force now started on 1 May 2026. The latest amendment brought in a new principle, IPP3A.

IPP3A is worth naming right, because it gets mixed up with the Australian change above. It's a notice rule. Collect someone's personal information from a source other than that person, and you generally have to tell them. That matters for an AI tool that pulls patient data out of a referral or another system. The tool never took it from the patient. It says nothing about automated decisions. It isn't New Zealand's version of the December 2026 Australian duty either. Different rules, different jobs.

New Zealand's official line is cautious. Health NZ guidance for staff and contractors was last reviewed in May 2026. It tells them to keep personal, confidential or sensitive patient data out of unapproved generative AI tools. It also says don't use those tools for clinical decisions or tailored patient advice. The Medical Council of New Zealand finalised its guidance on using AI in patient care on 10 March 2026. Both are quoted with their sources in our AI in healthcare administration guide.

Where Australia and New Zealand genuinely differ

That table is our own read of the sources named on this page. No single one of them makes that claim.

RACGP's F11 standard, in plain English

On 26 August 2026 the RACGP put out the 6th edition of its Standards for general practices. Inside it is Criterion F11, Artificial intelligence. It's the first RACGP accreditation standard to name AI out loud.

Accreditation is the check a general practice passes to show it meets the RACGP Standards. An assessor turns up looking for evidence that you meet each one. But a criterion only binds you once its edition is the one you get assessed against. That bit matters. We come back to it below.

Here's what F11 says, quoted in full (RACGP, Criterion F11).

It opens with a statement written from the patient's side:

I expect that this practice asks for my consent to use artificial intelligence, explains how it will be used to provide me with care, and ensures my safety and privacy.

F11.A Where the practice uses artificial intelligence, it does so safely and securely and consistent with existing standards. The practice:

- facilitates processes for members of the clinical team to obtain and document informed consent from patients when aspects of care will be delivered using AI
- facilitates data deidentification/anonymisation when using AI tools that process patient data
- ensures that identified patient data is not used by AI tools unless its use is clinically necessary, explicitly authorised, and supported by documented governance and consent processes
- discusses the implementation and use of AI with members of the practice team to identify practical implications and training needs
- establishes governance processes for AI use, including accountability and compliance with legislation
- documents processes that support clinical oversight of AI outputs.

And on the clinical team:

Members of the clinical team are accountable for care decisions supported by AI tools.

F11.B The practice assesses and evaluates its use of artificial intelligence. The practice:

- has a process to assess and evaluate the use of AI, including risk mitigation, prior to implementation
- has processes for monitoring,
review, and quality improvement to ensure AI tools deliver safe, high-quality care, with mitigation of any unintended consequences.

F11 talks about vendors too, under "Consideration of third parties":

AI tools may be developed or operated by third-party vendors. Practices need to confirm that: any third-party technology used in patient care (including AI scribes, transcription tools, or decision-support systems) complies with privacy legislation; patients are informed of the involvement of external providers; contracts with vendors address data handling,
consent, and accountability. When AI tools are provided by third parties, practices remain responsible for their safe and appropriate use.

What F11 is actually asking you to do

Strip the standards language out and F11 wants eight things you can point at.

The last two rows are where most practices are thinnest. They're also the two the standard writes about most.

What F11 doesn't do, yet

F11 is published. It isn't what practices get accredited against yet. The Australian Commission on Safety and Quality in Health Care says so flatly. Its words: "Accreditation under the NGPA Scheme currently uses the 5th edition of the Standards." On the newer one: "Information about arrangements for the 6th edition of the Standards will be provided in due course." It also notes that practices "are encouraged to begin implementing the 6th edition". It adds that doing so "is separate from accreditation assessment" (ACSQHC, last updated 26 August 2026).

Two more limits worth saying out loud. F11 is a general practice accreditation standard. It doesn't bind a physiotherapy, osteopathy or other allied health practice. We found no AI criterion in any allied health accreditation standard or board standard in either country. Nor did we find one for New Zealand general practice accreditation.

So treat F11 as a signal, not a rule that's already got you. It's the clearest sign we have of where health rules are heading. Run an allied health practice and want to know what's coming? Watch the medical and physiotherapy bodies. They set the direction the smaller boards follow.

The vendor indemnity clause, explained properly

This is the part I skipped in my own clinic. It's also the part with the sharpest edge on it.

Avant Mutual publishes a checklist for clinics weighing up an AI scribe. One item is about contracts. Here it is in full (Avant, AI scribes: a checklist of things to consider, 13 February 2026):

Are there any disclaimers, warranties and/or indemnity clauses shifting responsibility to the user of the tool and absolving the developer of responsibility?

The law does not require an indemnity clause to be included in a software services contract. Agreeing to a broad indemnity clause may have implications for your Avant insurance policy. Your Avant Practitioner Indemnity Insurance Policy will not cover liability you take on under a contract if you take on liability beyond the general law. If the provider's terms and conditions include an indemnity clause, consider seeking advice before agreeing to it.

What that means in plain words

An indemnity clause is you promising to cover someone else's losses. In an AI vendor's terms it usually runs one way. Something goes wrong with the tool, it costs the vendor money, and you're the one who pays. A data breach. A wrong output. A complaint to a regulator that traces back to the software.

Negligence law already sorts out who's at fault when something goes wrong. An indemnity clause sits on top of that law. It hands you risk you'd never carry otherwise. From the vendor's side, that's the whole point of it.

Now the bit that catches people. Your professional indemnity insurance covers the liability you carry under the general law. Liability you signed up for in a contract is a different animal. Avant says so about its own policy, in the quote above. It won't cover liability you take on under a contract if that liability goes past the general law.

So a broad indemnity clause opens up a gap. On one side is what the vendor's contract asks you to accept. On the other is what your insurer will actually pay out on. You can be fully insured and still be standing in that gap.

One disclosure, which Avant makes on the same page: "Avant has our own scribe tool VoiceBox Scribe however the information in this checklist is general advice and applicable across all platforms." So yes, Avant is a medical defence body and a vendor in this market. The warning is still a point about contract law and policy wording, not a dig at a rival.

AHPRA lands in the same place. It calls this a professional duty for anyone using AI: "holding appropriate professional indemnity insurance arrangements for all aspects of your practice and consulting your provider if you're unsure if AI tools used in your practice are covered" (AHPRA, reviewed 22 August 2024). The national regulator is telling you to go and ask.

What to actually do before you sign

Open the vendor's terms and search them for five words. If that's all the time you've got, read the clauses those words sit in and skip the rest.

Then send those clauses to your indemnity provider. Ask one question in writing: does my policy respond to the liability this clause creates? If the answer is no, you've got a negotiating point with the vendor. It isn't a reason to stop.

The cost of doing this is one email. I know what the cost of not doing it looks like, because I never did it.

Accountability doesn't move to the tool

AHPRA's position holds across every registered profession. The duties you already have still apply, and AI doesn't soften them. In its words: "Regardless of what technology is used in providing healthcare the practitioner remains responsible for delivering safe and quality care... TGA approval of a tool does not change a practitioner's responsibility to apply human oversight and judgment to their use of AI" (AHPRA). The five principles it sets are accountability, understanding, transparency, informed consent, and the ethical and legal issues involved.

On consent, Avant and MIPS got to the same view on their own. They are two separate Australian medical defence bodies, and they say the same thing. Get consent before you use an AI scribe. Cover the recording and the privacy side of it. Verbal or written, either is fine. Get it before each consult, not once at the start. F11 says the same from the accreditation side, and adds that you should write it down.

What patients actually ask, and why your whole team needs the answer

These are the questions I get asked myself, going right back to my own clinic in New Zealand. They're not what the regulator writes about.

Almost nobody worries that AI is going to hurt them. What worries them is the unknown. How is the data used? Who can get at it? How visible is it? Which model is this, and is it connected to OpenAI? Does the data go offshore to be processed, and is that even allowed for a business like yours? What patients fear is their private information getting shared, not that it will be used against them.

That changes what you have to do about it. Whatever you put in place, you've got to understand it well enough to explain it. So does everyone else in the practice. Let's say you're running a scribe that holds a patient's full history. Your front desk needs to be able to say how that data is kept safe and private. In plain words, with no policy document in hand.

You can be doing everything by the book and still lose on this. A patient asks at reception. The answer doesn't land. They tell other people. That becomes a rumour, and the rumour quietly costs you patients. Nobody complains, nothing gets reported, and the bookings just thin out.

It comes down to education and understanding.

Same goes for any tool that talks to patients rather than about them. An AI receptionist answering calls for a clinic holds patient data too. So does conversational AI used for patient messaging. Everything on this page follows them in.

What your team should be able to explain, without a script

• Where the data is stored, and whether it's processed or stored outside Australia or New Zealand.
• Whether the vendor uses your patients' data to train its model, and how you know.
• Who inside the practice can see the AI output, and who outside it can.
• How long the recording or transcript is kept, and what happens to it after that.
• That a person checks anything the tool produces before it goes in the record.
• How a patient says no, and what happens if they do.

Every one of those answers comes from your vendor, in writing, before you go live. Getting them is the work covered in choosing an AI scribe. Teaching them to the team is the work covered in rolling out an AI scribe.

Where to start, and where Opal fits in

Already running a tool? Start with the contract and the insurance question. It's the cheapest gap to close, and the one nobody has looked at.

Still choosing? Get the vendor's answers to the six questions above in writing before the demo ends. Then run a Privacy Impact Assessment. The Australian and New Zealand privacy regulators both recommend one, each on their own. That's about as loud as two regulators ever get.

Run a general practice in Australia? Read F11 in full. Then go through the eight rows in the table above and work out which ones you could evidence today. That gap list is your plan, and you've got time to work through it before accreditation catches up.

We help practices work out which tools fit and what has to be true before they go in. That's what AI strategy and adoption covers. It sits alongside where AI is worth the money and where it isn't. We don't sell software and we take no cut on what we recommend. We also don't give legal advice, and this page isn't it.

Questions I get asked

Patients and practice owners put these to me directly. The last one is about the RACGP, and it comes up every time a practice starts shortlisting tools.

Where does our patient data go, and is it processed offshore?

It depends entirely on the vendor, so ask rather than assume. Australian privacy duties follow the data into the tool and back out again, output included (OAIC). In New Zealand, the Health Information Privacy Code 2020 governs health information (Office of the Privacy Commissioner). Get the answer in writing, covering where data is stored and where it's processed. Those can be two different countries.

Which AI model is behind this tool, and is it connected to OpenAI?

Most clinical AI tools are built on top of a general model from one of a handful of providers. Plenty of vendors will name theirs if you ask. What the deal allows matters more than the name does. Ask whether your data is used to train or improve the model, and get that answer in writing. RACGP's F11 criterion tells practices to confirm two things. First, that third-party technology used in patient care complies with privacy law. Second, that contracts with vendors address data handling, consent and accountability (RACGP).

Who can see my information once it goes into an AI tool?

Your practice, your vendor, and anyone your vendor shares it with under their terms. F11 requires that "patients are informed of the involvement of external providers." So the standard wants you answering this up front, rather than when someone finally asks (RACGP).

Does the RACGP endorse a specific AI tool?

No. Its own fact sheet says "The RACGP does not recommend specific commercial products" and recommends that GPs "apply their own judgement... considering factors such as integration, customisation, security and cost." A vendor that hints at RACGP backing is overstating it.