AI phone reception for NDIS providers: what is actually compliant?

The question we get most often from NDIS providers in Australia: "Can I use an AI phone assistant in a practice that handles participant data?" Short answer: yes, if you set it up correctly. Long answer: there are a few specific things that have to be true, and most off-the-shelf AI assistants aren't built with them in mind.

This is a practical guide. Not legal advice - if you're audited, you'll still want to brief your compliance person. But it's enough to know what to ask for and what to refuse.

The two regulatory layers

NDIS practices operate under two stacked privacy regimes:

1. Privacy Act 1988 (Cth) + the Australian Privacy Principles (APPs). Same rules every business handling personal information has to follow.
2. NDIS Practice Standards + the NDIS Code of Conduct. Specific to providers - things like participant choice, privacy in the way services are delivered, and incident reporting.

Sitting on top of both: the Quality and Safeguards Commission, which can and does audit. Your AI phone reception has to survive both audits.

What an AI phone assistant typically does

To frame the compliance question, let's be specific about what we're automating. A typical AI reception setup for an allied health practice handles:

• Calls when no one can pick up (after hours, during therapy sessions).
• Standard intake questions - participant name, referrer, what kind of session, preferred suburb/clinician.
• Calendar lookup and booking into the next available slot.
• Sending an SMS or email confirmation.
• Escalating anything sensitive or complex to a real staff member.

It does not do: clinical advice, intake assessment, or anything that requires a registered professional. That line stays.

The APP rules that bite hardest

Three of the Australian Privacy Principles do most of the work for an AI reception setup:

APP 1 - Open and transparent management. Your privacy policy has to mention that calls may be handled by an automated system, what data is captured and where it's stored. We always update the privacy policy when we set this up - it's not optional.

APP 3 - Collection of solicited information. Only collect what you actually need. An AI assistant asking for diagnosis details or NDIS plan numbers at the booking stage is over-collecting. Keep the script to: name, contact, service requested, urgency.

APP 11 - Security. Personal information has to be protected from unauthorised access, modification or disclosure. This is the one that disqualifies most consumer AI assistants - if call audio sits unencrypted on a US-based vendor with no signed data processing agreement, you have an APP 11 problem.

What to insist on, technically

If you're evaluating an AI phone setup:

• TLS in transit. Call audio and transcripts must be encrypted when moving between systems.
• At-rest encryption. Stored recordings, transcripts, intake form data - all encrypted on disk.
• Data location disclosure. You should know exactly which countries your participant data is processed and stored in. "Somewhere in the cloud" isn't an answer.
• Audit logs. Every call, who accessed the recording, when. Practice Standards auditors will ask for this.
• Retention policy. How long are call recordings kept? Most practices land on 30-90 days for routine calls, longer only if there's a complaint or clinical reason.
• Right-to-erasure workflow. When a participant asks for their data to be deleted (APP 12), can you actually do it without ringing a vendor?

The NDIS Practice Standards layer

The Practice Standards are mostly about the experience the participant has, not the underlying tech. The relevant points for AI reception:

Choice and control. Participants must have a way to reach a human. An AI assistant that traps callers in a loop or never escalates is a problem. Always offer "press 0 / say 'speak to someone' to reach the team".

Privacy in service delivery. If a participant identifies that they want privacy or doesn't want recordings, the system needs to respect that. Practically: a flag in the participant record that disables recording for them.

Communication accessibility. Plain English, no clinical jargon, slow enough to follow. The voice should sound like a friendly receptionist, not a corporate phone tree.

The pre-deployment checklist

Before we go live for an NDIS provider, we work through this checklist with them:

1. Privacy policy updated to mention automated call handling.
2. Script reviewed - no over-collection, no clinical questions.
3. Recording disclosure at the start of the call ("This call may be recorded for quality and service purposes").
4. Human escalation working - tested from a real phone.
5. Data residency confirmed and documented.
6. Retention policy set and aligned with the rest of the practice's records management.
7. Audit log enabled and tested.
8. One person in the practice trained on how to respond to a data subject request.

If any of those eight points isn't clearly answered, don't go live yet.

The audit conversation, in practice

When a Practice Standards auditor asks about your AI phone reception, what they actually want to hear:

• You know what data it captures and why.
• You can show them the privacy policy update and the call script.
• You can pull a sample audit log entry.
• You can describe how a participant can opt out or reach a human.
• You can tell them how a data deletion request gets handled, end to end.

That conversation should take ten minutes. If it doesn't, your setup needs work before the next audit window.

Bottom line

AI phone reception is compliant for NDIS providers - when it's set up around the Privacy Act, the APPs and the Practice Standards rather than against them. The common failure isn't the AI; it's a vendor that wasn't built for this sector and a practice that didn't update the privacy policy. Fix those two, and the rest is normal good practice.