How to Deploy an AI Phone Receptionist Without Breaching Privacy

Before an AI answers the practice phone, do seven things: list every decision the tool makes, tell callers at the start of the call that they are speaking to an AI and that the call is recorded, put the 000 line first, send anything clinical to a person, test the tool against the automated decision-making duty that starts on 10 December 2026, get the vendor's data terms in writing, and train staff to log problems. The practice, not the vendor, stays responsible for all of it. The wider picture on AI privacy in healthcare is in AI privacy compliance for healthcare practices, and this guide sits in our healthcare privacy and cyber security pillar.

Before you begin

Have these open before you start:

• The vendor's privacy policy, terms and conditions, and any data processing agreement or sub-processor list, each with its date. If a page shows no date, record the date you read it.
• A demo recording or transcript of a real call flow, so you can hear what the tool actually says.
• Your practice's privacy policy, collection notice, triage policy and after-hours arrangements.
• Your AI acceptable use policy, which will hold the tool's settings and the training record you build in Step 7.

One piece of context. RACGP F11 counts "patient engagement platforms" and "administrative automation" as AI tools, so an AI receptionist counts too. F11 applies only to practices that use AI, and it is not yet assessed: accreditation still uses the 5th edition of the Standards, with no transition date announced as at 30 September 2026, per the ACSQHC status page. Treat this as preparation, not accreditation paperwork; the F11 evidence file as a whole is in how to meet RACGP F11. The consult-room counterpart is how to assess an AI scribe for privacy compliance.

Step 1: List what the tool does and every decision it makes

Write down every function the tool performs and every decision it makes. Product pages for these tools, read on 26 September 2026 and re-checked on 30 September 2026, describe AI receptionists that answer calls 24 hours a day, handle several calls at once, identify callers, book, reschedule and cancel appointments directly in the practice management software, answer questions from the practice's booking and website information, transfer calls to reception with a summary of the conversation so far, speak several languages, and send SMS recalls and reminders that reply to patients and make bookings. Check your own tool against that list. Every function either collects information, makes a decision, or both. Recordings and transcripts are collected too: one vendor's privacy policy lists "recordings and transcripts of interactions with the AI virtual receptionist, including voice inputs" among what it collects. When the tool identifies a caller, RACGP CG2.A applies: "The practice uses a minimum of three approved patient identifiers to correctly match each patient to their patient health record." The approved identifiers are name (family and given names together are one identifier), date of birth, address, Medicare or DVA number, and individual phone number. CG2 says correct identification is needed when "the practice communicates with a patient over the telephone or electronically".

The table below is our suggested format. It is not a regulator's form. The cells are prompts to answer for your own tool, not facts about any product.

The "What it decides" column feeds Step 4, and the triage row feeds Step 5.

Step 2: Check the recording and interception law before the first call

Two bodies of law govern recording calls, and neither has been tested against an AI agent answering a practice's own line. The Commonwealth Telecommunications (Interception and Access) Act 1979 defines interception in s 6(1) as listening to or recording a communication in its passage over a telecommunications system "without the knowledge of the person making the communication", and s 7(1) prohibits intercepting "a communication passing over a telecommunications system". Our reading is that this turns on the caller's knowledge, which is why the greeting tells the caller at the start that the call is answered by an AI and recorded. State listening-device law is a separate test, below. Get your own legal or medical defence organisation advice.

State listening device law sits on top. Section 7(1)(b) of the NSW Surveillance Devices Act 2007 prohibits knowingly using a listening device "to record a private conversation to which the person is a party", with a maximum penalty of "500 penalty units (in the case of a corporation) or 100 penalty units or 5 years imprisonment, or both (in any other case)". Exceptions under s 7(3) apply where "all of the principal parties to the conversation consent, expressly or impliedly", or where a principal party consents and the recording is "reasonably necessary for the protection of the lawful interests of that principal party" or "is not made for the purpose of communicating or publishing the conversation, or a report of the conversation, to persons who are not parties to the conversation".

The states split. Our AI scribe patient consent form carries a state and territory table, checked against each Act on 24 September 2026: NSW, WA, South Australia, Tasmania and the ACT require each principal party's consent to record a private conversation, subject to narrow exceptions, while in Victoria, Queensland and the NT a participant may record but each makes it an offence to pass the record on without every party's consent unless an exception applies. Whether a state Act treats an AI voice agent as "being a party" to the call, or a phone call as a "private conversation", is untested. Tell every caller at the start, before any health information is given, and offer a way to reach a person (press a key or say "staff"). Consent given with no way to reach a person is harder to defend.

Step 3: Write the greeting and the privacy notice (APP 5)

APP 5.1 requires notification "at or before the time or, if that is not practicable, as soon as practicable after" collection, and the OAIC's APP guidelines chapter 5 say that where "personal information is collected by telephone", reasonable steps include "explaining the APP 5 matters to the individual at the commencement of the call (perhaps following a template script or using an automated message)". The OAIC's guidance on commercially available AI products adds two things for AI: "you should make sure that individuals are made aware that they are interacting with an AI system rather than a human", and "If the AI system developer has access to personal information processed through the system, this is a disclosure that should be included in an APP 5 notice." Then RACGP PP2.B: "The practice communication systems advise consumers to call 000 in case of an emergency", and its guidance says "When receiving calls, reception staff must first ask if the matter is an emergency and never put the caller on hold before asking this." Applied to the AI, 000 comes first, before the privacy notice.

The APP 5.2 matters your notice must cover: your identity and contact details; the fact and circumstances of collection where the person may not be aware of it; whether collection is required or authorised by law; the purposes; the main consequences if not collected; who you usually disclose this kind of information to; that the privacy policy explains access, correction and complaints; and whether overseas disclosure is likely and, if so, the countries where practicable.

The three scripts below are our suggested wording, built from APP 5.2, OAIC para 5.6 and PP2.B. They are not regulator text. Fill the placeholders from your vendor's written terms (Step 6) and have your privacy officer check them.

Script A: the opening greeting

"Thank you for calling [practice name]. If this is an emergency, hang up and call triple zero now. You are speaking with [assistant name], an AI assistant. This call is recorded and transcribed so we can manage your booking or pass your request to our team. Some of the services that run this assistant are located [in Australia / overseas, including in [countries]]. To speak to a person at any time, say 'staff' or press [key]. Our privacy policy at [web address] explains how we handle your information, how to access or correct it, and how to complain."

Every placeholder comes from the vendor's written answers in Step 6.

Script B: the short refresher

"You are speaking with [practice name]'s AI assistant, and this call is recorded. If this is an emergency, hang up and call triple zero. Say 'staff' at any time to speak to a person."

OAIC para 5.5 allows a layered notice, "from a full explanation to a brief refresher". Whether a refresher is enough for a given caller is the practice's judgement under APP 5's "reasonable steps"; a caller who has not heard the full greeting before should hear Script A.

Script C: the privacy policy paragraph

"AI phone assistant. When you call [practice name], your call may be answered by [assistant name], an automated AI assistant provided by [vendor name]. It collects your name, date of birth, phone number, the reason for your call and any appointment details, and it records and transcribes the call. We use this information to identify you, book, change or cancel appointments, answer questions about our services, and pass your call or message to our staff. [Vendor name] and the service providers it uses to run the assistant [store / process] this information [in Australia / in [countries]]. [Vendor name] [does / does not] use call recordings or transcripts to improve its products. We keep call recordings for [period] and transcripts for [period]. The assistant does not give medical advice and does not assess how urgent your health concern is; anything clinical or urgent is passed to our staff. You can ask to speak to a person at any time during the call."

If Step 4 finds the assistant in scope, add a section like this to the privacy policy from 10 December 2026. It is our wording, following APP 1.8 and the heading the OAIC's worked examples use:

"Decisions made by computer programs. Our AI phone assistant uses your name, date of birth, phone number and the reason for your call [and any health information you give it] to make these kinds of decisions on its own: [for example, which appointment times you are offered]. It also helps our staff make these kinds of decisions: [for example, whether your call goes to a staff member first]."

APP 1.8 asks for three things: the kinds of personal information used, the kinds of decisions the program makes on its own, and the kinds it substantially and directly helps with. The OAIC's guidance adds that a policy should make clear where health information is used in a program's decisions. Adapt Script C into your privacy policy and patient data collection notice; the automated decision-making section goes in the privacy policy, because APP 1.7 is a privacy policy duty.

One vendor's practice terms also require the practice to "clearly disclose the use of the AI Receptionist service" on its website "in close proximity to its contact information", so check whether your contract imposes a website notice.

Step 4: Decide whether the 10 December 2026 automated decision-making duty applies

From 10 December 2026, your privacy policy may need to disclose that the receptionist makes automated decisions. The date is already law: APPs 1.7 to 1.9, inserted by the Privacy and Other Legislation Amendment Act 2024, Schedule 1, Part 15, item 88, take effect on 10 December 2026 as tranche 1 of Privacy Act reform, not a proposal. The duty reads:

"1.7 Without limiting subclause 1.3, the APP privacy policy of an APP entity must contain the information covered by subclause 1.8 if: (a) the entity has arranged for a computer program to make, or do a thing that is substantially and directly related to making, a decision; and (b) the decision could reasonably be expected to significantly affect the rights or interests of an individual; and (c) personal information about the individual is used in the operation of the computer program to make the decision or do the thing that is substantially and directly related to making the decision."

Two parts of APP 1.9 do the load-bearing work: "(a) making a decision includes refusing or failing to make a decision", and among the examples of decisions that may affect rights or interests, "(iii) a decision that affects the individual's access to a significant service or support", counted whether adverse or beneficial. Item 89 extends the duty to decisions made from that date regardless of when the arrangement or the information first arose, so a tool already running on 10 December 2026 is covered.

Run each Step 1 decision through the three limbs, with the OAIC's guidance beside you: it was published on 30 September 2026 as an update to its APP guidelines chapter 1, with a fact sheet and a flowchart. Answering a practice-hours question uses no personal information in a decision about the caller; on our reading, it fails limb (c). A tool that books, declines, prioritises or routes callers by urgency, or decides which appointment type or clinician a caller can have, needs close testing.

The OAIC gives "access to healthcare services" as an example of access to a significant service or support, and its fact sheet lists "computer programs used to prioritise the provision of health or disability services to individuals" among decisions that would generally be in scope. Its first worked example is a health and aged care provider whose spreadsheet ranks people for appointments: in scope, and still in scope if staff use the ranking to decide whom not to contact. A person checking the output does not settle it either: "a decision may be within scope of the APP 1.7-1.9 transparency obligation even where a computer program output does not replace the entire decision-making process or is subject to human review." Record the answer and the reason for every function.

The guidance does not mention AI receptionists, so where a particular booking or routing function falls is still our reading. It does say how to treat the doubt. The fact sheet says entities "in doubt of whether their use of a computer program falls within the scope of the transparency obligation should take a cautious approach and include information in their APP privacy policy", and the OAIC "generally expects" the obligation to remain "with the APP entity who is using personal information to make a decision", which here is the practice rather than the vendor. For the penalties, see the 10 December 2026 ADM deadline; the definition is at automated decision-making.

Step 5: Send anything clinical to a person, and write it into the triage policy

Anything clinical goes to a person, and the triage policy must say so in terms. RACGP PP9.A says "The practice has a triage system for prioritising patient care", and the practice "prioritises patients according to their urgency of need" with "a member of the clinical team who has primary responsibility for training the practice team in triage". At least one vendor's contract forbids using its receptionist for triage or urgent calls: its practice terms say the practice "must not use the AI Communication Services for urgent, emergency or time-critical communications, or for the provision of clinical advice or triage", that the services "do not constitute clinical advice", and that the practice must "ensure that suitably qualified staff are available to review, manage and, where necessary, intervene in or take over communications". Read the contract before letting the tool sort callers by urgency.

Add these to your triage policy (our recommendation, not regulator text):

Scope. The tasks the AI may do, and that it does not assess urgency, give clinical advice or decide whether a caller needs to be seen, unless the practice has deliberately chosen a triage tool, tested it, checked its contract and classified it under Step 4.

The emergency line first. 000 before anything else, per PP2.B and the greeting in Step 3.

Clinical words mean a person. Any mention of symptoms, medication, results, self-harm, safety or an urgent need transfers to the staff member on duty, and the practice lists who that is each day.

When no one can take the transfer. After hours and busy periods: the message the AI gives and the numbers it offers, consistent with the practice's after-hours arrangements.

When the AI is down. The fallback to a person or a recorded message, and who switches the AI off.

The triage lead reviews samples. The clinical team member responsible under PP9.A reviews a sample of transferred and non-transferred calls.

One boundary: if a tool goes further and suggests a clinical diagnosis or treatment, it raises a separate medical device question about clinical decision support software, covered at the TGA's clinical decision support amendments from 1 November 2026. Clinical triage is the term to use in the policy.

Step 6: Get the vendor's answers in writing

The practice answers for the vendor's data handling, so get the terms in writing before signing. Under APP 8.1 of the Privacy Act 1988, before disclosing personal information to an overseas recipient the entity "must take such steps as are reasonable in the circumstances to ensure that the overseas recipient does not breach the Australian Privacy Principles (other than Australian Privacy Principle 1) in relation to the information", and under s 16C(2) the recipient's act is taken "to have been done, or engaged in, by the APP entity" and "to be a breach of those Australian Privacy Principles by the APP entity". The marketing page is not the answer. One vendor's product page says "Patient details and bookings are managed within [the vendor's] secure platform"; its privacy policy says it "may disclose limited personal information to third party service providers located outside of Australia in connection with the operation and functionality of its AI Virtual Receptionist". A second vendor's article (10 July 2026) lists "Recordings, transcripts, and patient details processed and stored on Australian infrastructure, not shipped offshore by default" as what a compliant setup means; its privacy policy (13 April 2026) says nothing about call data. Read the legal page, and record its date.

Send these questions in writing and note where each answer was found:

Four of these deserve comment.

Training use. One vendor's privacy policy says it collects caller information "to improve the accuracy and functionality of the AI virtual receptionist through analytics and performance monitoring", while a separate section of the same policy says "No patient data is used to train, develop, or improve any of our AI models." Another vendor's terms say client data is used for "delivering our services, processing payments, and improving our platform". Ask whether "improving" includes the recordings and transcripts, and whether it can be switched off.

Retention. One vendor's terms keep all call records and transcripts for the life of the agreement, say recordings "can be deleted after 180 days upon request", and delete client data 30 days after termination; another's privacy policy retains personal information "for as long as reasonably necessary". APP 11.2 requires destruction or de-identification of information no longer needed, so set your own retention and put it in the contract and the privacy policy; transcripts holding clinical content, on our reading, are part of what the practice must manage as a record.

Sub-processors. Ask for the list of every provider that receives call audio, transcripts or caller details, with each one's country, and a promise of notice before a new one is added.

Breach notice. Under s 26WH(2)(b), an entity that suspects an eligible data breach must complete its assessment within 30 days of becoming aware, so ask the vendor to notify you of a suspected breach within a fixed number of days, to meet your own clock under our notifiable data breach response guide. Put the answers into a third-party data sharing agreement, and run a privacy impact assessment first.

Step 7: Train the team and log AI incidents

Staff who work alongside the AI need training, and AI incidents need a log. RACGP F4 says: "If the practice uses artificial intelligence (AI) tools, training needs to: include information about the safe and effective use of these systems; support the practice team to understand the purpose, limitations, and appropriate use of AI tools; reinforce the importance of clinical oversight and judgement when interacting with AI-generated outputs." The OAIC's para 5.5 adds that staff should be trained to understand their obligation to take reasonable steps to notify under APP 5.

Reception staff specifically need to know, in our list: what the AI tells callers and why; how a transfer arrives and what the summary shows; checking the three identifiers on every transferred call per CG2.A; correcting a wrong booking; what to do when a caller complains about the AI or asks for their recording; and how to switch the AI off.

For incidents, RACGP CG7 says: "If the practice uses artificial intelligence (AI) tools, its incident management process needs to include steps for identifying, documenting, and responding to AI-related issues. Identifying AI-related issues must not rely solely on feedback or complaints." Its examples are "incorrect or misleading outputs; system failures or outages; breaches of privacy or data handling protocols; clinician or patient concerns about safety or appropriateness; unexpected changes in AI behaviour after updates to the software." Reception-AI examples of each, ours: a booking in the wrong patient's record or with the wrong clinician; a caller describing chest pain who was not transferred; the AI down during opening hours; a transcript sent to the wrong place; the AI's wording changing after a vendor update.

For ongoing monitoring, F11 suggests the practice could collect structured team feedback, monitor consumer feedback and complaints, track technical support requests, measure how often AI-assisted and clinician-only processes are each used, and review updates and changes to AI systems. The AI register, training record and approved-tool settings live in your AI acceptable use policy.

What good looks like

A practice that has done the seven steps holds a small file: the decision inventory from Step 1, the legal or MDO note on recording from Step 2, the three scripts as used, the Step 4 classification with reasons for every function, the updated triage policy, the vendor's written answers with their dates, the training record and the incident log.

Four mistakes to avoid:

Letting the AI sort callers by urgency without reading the contract. At least one vendor's contract forbids triage and urgent use outright.

Putting the privacy notice before the 000 line. PP2.B puts the emergency question first, and its guidance is explicit that staff "must first ask if the matter is an emergency". The greeting follows the same order.

Taking the product page's word on data location. One vendor's product page said patient details are managed within "[the vendor's] secure platform" (read 30 September 2026); its privacy policy listed overseas service providers. A second vendor's article (10 July 2026) said data is "processed and stored on Australian infrastructure, not shipped offshore by default", while its privacy policy (13 April 2026) said nothing about call data. Only the written data terms count.

Treating 10 December 2026 as a vendor problem. APP 1.7(a) says the duty sits with the entity that "arranged for a computer program to make" the decision. That is the practice.

Run Step 1 on the tool you are being pitched, and send the Step 6 questions before you sign anything.

Two documents carry most of this into daily use. The triage policy template holds the escalation rules, the triage lead and the red flags from Step 5, so the AI's limits sit in the same document as reception's. The AI acceptable use policy records the approved tool, its settings, the named responsible person and the training record from Step 7.

Frequently asked questions

Do we have to tell callers they are talking to an AI?

Yes. The OAIC says "you should make sure that individuals are made aware that they are interacting with an AI system rather than a human". APP 5 requires reasonable steps to notify at or before collection, and the OAIC's example of a reasonable step is explaining the APP 5 matters at the start of the call. Script A does both, with the 000 line first.

What should an AI receptionist say at the start of a call?

000 first, per PP2.B: if this is an emergency, hang up and call triple zero. Then that the caller is speaking to an AI, that the call is recorded and transcribed, where the information goes, how to reach a person, and where the privacy policy is. Script A is model wording for all of it.

Is it legal for an AI receptionist to record patient calls?

It depends on telling callers and on state law. The Telecommunications (Interception and Access) Act definition turns on the caller's knowledge, and NSW s 7 requires every principal party's consent to record a private conversation unless an exception applies. Neither has been tested for an AI agent answering a practice line. Get legal or MDO advice before the first call.

Can an AI receptionist triage patients?

No, not by default. PP9.A puts triage training with a member of the clinical team, and at least one vendor's contract forbids using its receptionist for triage or urgent calls. If a practice deliberately chooses a triage tool, it must check the contract permits it, test the escalation paths and classify the tool under the Step 4 ADM duty.

Does the automated decision-making duty apply to an AI receptionist?

It may, from 10 December 2026, where the tool uses a caller's personal information to make or substantially assist a decision affecting access to care, such as declining or prioritising a booking. The OAIC's guidance of 30 September 2026 lists programs that "prioritise the provision of health or disability services to individuals" as generally in scope, and tells entities in doubt to take a cautious approach. Classify each function and record your reasons.

Can call recordings be stored overseas?

Yes, if APP 8.1 is met: reasonable steps to ensure the overseas recipient does not breach the APPs, with the practice answering for the recipient's acts under s 16C. The APP 5 notice and privacy policy must say whether overseas disclosure is likely and, where practicable, the countries involved.

Does RACGP F11 apply to an AI phone receptionist?

Yes, if the practice uses one. F11 lists patient engagement platforms and administrative automation among AI tools, and requires practices to inform patients how these tools use their health information. F11 is not yet assessed, as accreditation still uses the 5th edition of the Standards as at 30 September 2026.

Last reviewed 30 September 2026