An AI support vendor that hosts its application in Sydney can still send your customers' messages to a model running in Virginia. Data residency for AI is not one question, it is three: where data is stored, where it is processed, and which sub-processors see it.

Australian data residency for AI customer support is the requirement that personal information handled by an AI agent (chat transcripts, voice recordings, account data, identity documents) is stored, processed, and disclosed in line with the Privacy Act 1988, the Australian Privacy Principles, and, for regulated entities, APRA and ASIC obligations. The hard part in 2026 is that AI support introduces a model layer (the LLM) that often sits offshore even when the application database does not.

• Data residency splits into storage, processing, and sub-processor disclosure. A vendor can satisfy one and fail the other two.

• The Privacy Act and Australian Privacy Principles do not ban offshore transfer outright. APP 8 lets you transfer overseas if you take reasonable steps to ensure the recipient handles the data consistently with the APPs, and it can leave you accountable for what that recipient does.

• For APRA-regulated entities, CPS 234 (information security) and CPS 230 (operational risk, effective from 1 July 2025) extend obligations to your material service providers, including AI vendors.

• The model layer is the part buyers most often miss. Ask where inference runs and whether your data is used to train shared models.

• This guide is general information about how to evaluate vendors, not legal advice. Confirm your specific obligations with your privacy and compliance teams.

Last updated: June 2026

When an Australian bank, insurer, or fintech evaluates an AI customer support platform, data residency is usually one of the first questions and one of the most poorly answered. The vendor says "we are hosted in Australia" and the buyer ticks the box. That answer is incomplete because AI support is not a single system. It is an application, a database, a set of integrations, and a large language model, and each of those can live in a different country. This guide breaks the question into the parts that actually matter under Australian law, explains what offshore transfer does and does not require, and lists the questions to put to any vendor before you sign. It also explains, honestly, how Lorikeet supports these obligations and where the limits are.

What Australian Data Residency Means for AI Customer Support

Data residency is the requirement, or commercial preference, that data is kept within a specified jurisdiction. For Australian AI customer support it means personal information collected during a support interaction stays subject to Australian law and, where required by contract or regulation, physically remains in Australian data centres. Residency is related to but distinct from data sovereignty (which concerns whose laws govern the data) and data localisation (a hard legal requirement to keep data in-country, which Australia largely does not impose on private-sector personal information).

The reason it gets complicated for AI is that a support interaction touches several systems in sequence. A customer message arrives, the application stores it, the platform sends relevant context to a large language model to generate a reply, integrations pull account data from a CRM or core banking system, and the whole exchange is logged. Each hop is a point where data can cross a border. Treating "data residency" as a single yes or no answer is the most common mistake buyers make.

Storage: Where data is held at rest, including the transcript database, voice recordings, attachments, and logs.

Processing: Where data is operated on in transit, most importantly where the LLM runs inference on the content of a conversation.

Sub-processors: The third parties a vendor relies on (model providers, cloud hosts, telephony, transcription) that may also see the data.

Lorikeet is an AI customer support platform built for complex and regulated businesses, including financial services, fintech, healthtech, and insurance. It offers a separate Australian instance with data residency in Australia, instance isolation between customers, and contractual no-train terms with its model providers. The sections below explain what each of those means in practice and how to verify them.

The Legal Framework: Privacy Act, APPs, and APRA

Three regimes shape data residency for Australian AI support. The Privacy Act and its Australian Privacy Principles apply to most organisations handling personal information. APRA prudential standards apply to banks, insurers, and superannuation entities. ASIC and sector rules sit on top for licensed financial services. You may be subject to one, two, or all three.

The Privacy Act 1988 and the Australian Privacy Principles

The Privacy Act governs how organisations collect, use, store, and disclose personal information. The thirteen Australian Privacy Principles are the operative rules. For AI support the principles that matter most are APP 6 (use and disclosure), APP 8 (cross-border disclosure), APP 11 (security of personal information), and the data breach notification scheme. The Privacy Act has been under active reform, with the Privacy and Other Legislation Amendment Act 2024 introducing changes including a statutory tort for serious invasions of privacy and stronger enforcement, so treat the current text as the floor and check for amendments in force at your evaluation date.

APP 8 and Cross-Border Disclosure

APP 8 is the principle most relevant to offshore model processing. It does not prohibit sending personal information overseas. It requires that, before disclosing personal information to an overseas recipient, you take reasonable steps to ensure the recipient does not breach the APPs in relation to that information. Under the accountability approach in section 16C, if the overseas recipient mishandles the data, the disclosing Australian organisation can be treated as responsible for that act. In plain terms, sending conversation content to an offshore LLM is a cross-border disclosure, and you remain accountable for it. This is exactly why where the model runs is a residency question, not a footnote.

APRA CPS 234 and CPS 230

If you are an APRA-regulated entity, CPS 234 requires you to maintain information security capability commensurate with the threats, and it explicitly extends to information assets managed by third parties, including AI vendors. You must be able to demonstrate the vendor's security controls, not just assert them. CPS 230, the operational risk management standard effective from 1 July 2025, adds requirements for managing material service providers, including a register, service-level expectations, and the ability to continue operations through a provider disruption. An offshore AI dependency that you cannot see into is a CPS 234 and CPS 230 problem, regardless of what the Privacy Act allows.

Storage vs Processing vs Sub-Processors

This is the distinction that separates a real residency posture from a marketing claim. A vendor can answer "yes, we are in Australia" truthfully about one of these layers while the other two route offshore.

Storage: Where Data Sits at Rest

Storage residency is the easiest to verify and the one vendors lead with. Ask which cloud region hosts the application database, transcripts, voice recordings, attachments, and audit logs. "Hosted on AWS Sydney (ap-southeast-2)" is a concrete answer. Confirm that backups and disaster-recovery replicas also stay in-region, because a backup replicated to Singapore is still a cross-border transfer. Confirm how long data is retained and whether you control deletion.

Processing: Where the Model Runs

Processing is where most AI residency claims quietly break. To generate a reply, the platform sends conversation content to a large language model. If that model runs in a United States region, your customer's message has crossed a border for processing even though the database never left Sydney. Ask explicitly: when the AI generates a response, in which region does inference run? Some model providers offer regional inference endpoints; some do not. If the vendor cannot tell you where inference happens, they cannot honestly claim Australian processing residency.

Sub-Processors: Who Else Sees the Data

Sub-processors are the third parties in the chain: the LLM providers, the cloud host, the voice transcription engine, the telephony carrier, error-monitoring tools. Each is a potential cross-border disclosure and each is in scope for APP 8 and CPS 234. Ask for the current sub-processor list, the function each performs, the region each operates in, and whether you are notified before a new one is added. A vendor that cannot produce this list on request is not ready for a regulated buyer.

Voice deserves a specific note because it adds sub-processors that chat does not. A voice interaction can touch a telephony carrier, a speech-to-text engine, a text-to-speech voice provider, and the LLM, each potentially in a different region. A recording that is transcribed offshore is a cross-border disclosure of the recording and the transcript both. If voice is part of your deployment, ask the residency questions about each voice-specific provider, not just the application, because the voice path is often where an otherwise onshore setup leaks across a border.

Offshore Transfer: What APP 8 Actually Requires

It is worth being precise here because the law is more permissive than the procurement instinct, and the obligation is more demanding than the marketing.

APP 8 does not ban offshore transfer. Plenty of compliant Australian organisations use offshore cloud and AI services. What APP 8 requires is that you take reasonable steps to ensure the overseas recipient handles the information consistently with the APPs, and the accountability provision means you wear the consequences if they do not. Reasonable steps typically include contractual commitments binding the recipient to APP-consistent handling, due diligence on the recipient's security posture, and, increasingly, a documented assessment of the transfer.

There are narrow alternatives. APP 8 allows transfer where the recipient is subject to a law or binding scheme substantially similar to the APPs, or where the individual consents after being informed that APP 8 will not apply. Consent is fragile at support scale and substantial-similarity findings are limited, so for most AI support deployments the practical path is either keeping processing onshore or doing the APP 8 reasonable-steps work properly for the offshore parts. The point is that offshore is a choice with obligations attached, not a disqualifier and not a free pass.

There is also a difference between disclosure and use by a contracted service provider. Some arrangements are structured so that a cloud or AI provider holds the data only to provide the service back to you, under binding contractual restrictions, rather than for its own purposes. How that is characterised affects your APP 8 analysis and your records. This is precisely the kind of nuance to work through with your privacy adviser using the vendor's actual contract terms, not a summary, because the wording determines whether the reasonable-steps obligation is met and whether the accountability provision bites.

A practical way to handle the assessment is to document, for each hop in the data path, the recipient, the jurisdiction, the purpose, the contractual protections, and whether a no-train restriction applies. That document does double duty: it satisfies the reasonable-steps evidencing under APP 8 and feeds straight into the material service provider register that CPS 230 expects. Building it once, at evaluation time, is far cheaper than reconstructing it during an incident or an examination.

Healthcare Data: Where the Model Runs vs Where Data Is Stored

For healthcare support, the gap between where data is stored and where the model runs matters more than anywhere else, because a routine support conversation usually contains health information. The OAIC's guidelines on key concepts list appointment and billing details, and prescriptions and other pharmaceutical purchases, as examples of health information, and health information is part of the Privacy Act's definition of sensitive information. A question about a delayed refill or a bill is therefore sensitive information, even when nothing clinical is discussed. Four checks follow from that.

1. Treat the Model Location as Its Own APP 8 Question

A Sydney database does not settle where a patient's message goes when the model drafts a reply. The OAIC's APP 8 guidelines say an entity discloses personal information when it makes it accessible outside the entity and releases the subsequent handling of it from its effective control, while routing information in transit through overseas servers would usually be a use rather than a disclosure. Where it is a disclosure, APP 8.1 requires reasonable steps before the information goes to the overseas recipient, and section 16C makes you accountable for what that recipient does. The same guidelines say more rigorous steps may be required where the information is sensitive information. For a healthcare deployment, the due diligence on an offshore model provider therefore goes up, not down: ask where inference runs, under what contract, and with what retention.

2. Check Whether My Health Record Information Is in Scope

Most patient support conversations have nothing to do with the My Health Record system, but if yours do, the rules are stricter than APP 8. Section 77 of the My Health Records Act 2012 says the System Operator, a registered repository operator, a registered portal operator or a registered contracted service provider that holds records for the purposes of the My Health Record system, or has access to information relating to such records, must not hold or take those records outside Australia, must not process or handle the information relating to them outside Australia, and must not cause or permit another person to do so. Contravention is an offence and also carries a civil penalty. Because the section covers processing and handling, not only storage, an offshore model endpoint is not something reasonable steps can fix in that context. If your organisation holds one of those registered roles, confirm with your compliance team whether section 77 reaches your support data before you configure any AI vendor.

3. Know When FIRB Conditions Apply

FIRB does not regulate which support software you buy. It screens foreign investment, and it becomes relevant to AI support only when a foreign investment in your organisation carries conditions about data. The Treasury's Guidance Note 8 on national security describes the health sector as holding significant amounts of sensitive Australian patient data, and encourages foreign persons to seek approval for investments in a business with access to bulk sensitive personal information of over 100,000 Australian residents, listing medical and psychological information among the examples. Guidance Note 11 says conditions on sensitive data may include restrictions on the location of data storage and access. If your organisation operates under such conditions, read them before you choose where AI support data is stored and processed, because a vendor's default region may not satisfy them.

4. Read What the Vendor Publishes, Then Ask About Inference

Lorikeet's pricing page lists data residency as USA on the Start and Scale plans and custom on Signature, and lists zero data retention by third party inference providers on every plan. Its trust page says production runs on Google Cloud Platform with US primary hosting and that data storage residency is available in Australia and the EU. Neither page states an Australian location for model inference, so for a healthcare deployment ask Lorikeet, as you would any vendor, to confirm in writing where inference runs for your configuration and which plan the residency you need sits on.

As with the rest of this guide, this section is general information, not legal advice.

What to Ask AI Support Vendors About Data Residency

A demo is designed to look reassuring. These questions are designed to surface where the data actually goes. Put them in writing and keep the answers, because under CPS 234 you may need to evidence them.

• In which cloud region is our data stored at rest, including transcripts, voice recordings, attachments, backups, and audit logs?

• When the AI generates a reply, in which region does model inference run, and is an Australian inference endpoint available?

• Can you provide a separate Australian instance, and is our data isolated from other customers at the storage and tenancy level?

• What is your current sub-processor list, what region does each operate in, and how are we notified before a new one is added?

• Do you have contractual no-train terms with your model providers, so our conversation data is never used to train shared models?

• How is personal information redacted or minimised before it reaches the model layer?

• Can you supply your SOC 2 report and evidence of controls so we can meet our CPS 234 third-party obligations?

• What are your data retention and deletion controls, and can we trigger deletion on demand?

How Lorikeet Supports Australian Data Residency

Lorikeet is used by complex and regulated businesses, and Australian residency is a requirement we are built to support rather than retrofit. Here is how, stated honestly, including where the responsibility stays with you.

A Separate Australian Instance

Lorikeet offers a separate Australian instance so that data storage stays in Australia rather than defaulting to a United States region. This addresses the storage layer described above and keeps transcripts, recordings, and logs subject to Australian hosting. During evaluation, confirm with our team which specific components run in-region for your configuration, because integrations you connect (your CRM, your telephony) have their own residency that sits with you.

Instance Isolation

Customer environments are isolated from one another, so your data is not commingled with another organisation's in shared storage or configuration. Isolation supports both your APP 11 security obligations and the third-party assurance work required under CPS 234. It is one input to your security assessment, not a substitute for doing that assessment.

No-Train Contractual Terms

Lorikeet holds contractual no-train agreements with its model providers, which means conversation data passed to the LLM layer is not used to train those providers' shared models. For a regulated buyer this is a material point: it narrows the disclosure to processing-for-response only, which is far easier to reason about under APP 8 than open-ended training use.

Defence in Depth Around the Data

Beyond residency, Lorikeet wraps the AI in pre-launch adversarial simulation, inbound message checks, outbound guardrails, and post-interaction quality assurance, with PII redaction and role-based access control. The platform is SOC 2 compliant and supports GDPR-aligned handling. These controls support your obligations under the APPs and APRA standards. They do not replace your own compliance assessment, and we are clear about that. Lorikeet supports your obligations; it does not discharge them for you, and no vendor honestly can.

The Honest Limit

Residency posture depends on configuration. If you connect an offshore CRM, route voice through an offshore carrier, or choose a model endpoint outside Australia for a capability that is only available there, data can still cross a border at that hop, and that part is a decision you and your compliance team own. The right way to use this guide is to map every hop in your intended setup and confirm each one, rather than relying on a single "hosted in Australia" statement from any vendor, including us.

If you are evaluating AI customer support against Australian residency and APRA obligations, talk to Lorikeet about a separate Australian instance and bring your privacy and compliance questions to the first call.

Key Takeaways

• Data residency for AI support is three questions, not one: storage at rest, processing (where the model runs), and sub-processor disclosure. Verify all three.

• The model layer is where claims usually break. A Sydney-hosted database does not mean Australian processing if inference runs offshore.

• APP 8 allows offshore transfer but holds you accountable for what the overseas recipient does, so offshore processing is a choice with obligations, not a footnote.

• APRA CPS 234 and CPS 230 extend your obligations to your AI vendor as a material service provider, so you must be able to evidence its controls.

• Lorikeet supports Australian residency with a separate Australian instance, instance isolation, and no-train contractual terms, but configuration and your own compliance assessment remain your responsibility.

This article is general information, not legal advice. Confirm your obligations with qualified privacy and compliance advisers and with the current text of the Privacy Act and applicable APRA standards.