What Australian teams should check before using overseas AI

Most Australian organisations picked up generative AI the way they picked up every other SaaS tool: someone signed up, it was useful, and the governance questions came later. For a lot of teams, later is now. Legal, risk and security are being asked to sign off on tools that are already in daily use, and the first thing they want to know is where the data goes.

“Overseas” is not automatically a problem. Plenty of organisations can and do use offshore services lawfully. The point is that an overseas AI service raises a specific set of questions, and you should have written answers to them before staff start pasting in client files.

Where the prompt is processed, not just where it’s stored

Vendors often describe data residency in terms of storage: conversations at rest sit in an Australian region. That is useful, but a prompt also has to be processed by the model, and inference can happen somewhere else. Ask both questions separately and get the answers in the contract or the vendor’s documentation, with a date. “Australian data centres” on a sales slide doesn’t tell you where inference runs.

Ask too about the parts around the model: embeddings, search indexes, abuse monitoring, support tooling, telemetry and backups. Each of these can sit with a different sub-processor in a different country.

Who can compel access

The US CLOUD Act amended the Stored Communications Act so that a US provider must disclose data in its “possession, custody, or control” in response to valid legal process, regardless of whether the data is located inside or outside the United States (18 U.S.C. § 2713). The statute gives providers a limited path to challenge some orders, but your confidentiality clause with the vendor can’t override a lawful order the vendor is bound by.

So the ownership of the provider matters, not just the location of the server. A US-headquartered company running an Australian region is still a US provider. Whether that risk is acceptable depends on what you put in the tool, and it is a decision for your organisation to make knowingly.

What the rules actually say

For Commonwealth entities, the clearest current statement is PSPF Policy Advisory 001-2025 (7 October 2025). It confirms OFFICIAL information can be used with generative AI, provided entities only give access to products hosted on Hosting Certification Framework providers, OpenAI or Anthropic, or ones that have had a foreign ownership, control or influence (FOCI) risk assessment. Entities must still follow the PSPF technology authorisation process. The DTA’s staff guidance on public generative AI is blunter: OFFICIAL: Sensitive and above must not go into public generative AI tools.

The ISM doesn’t contain a blanket “keep it onshore” control. What it does say, in ISM-1570, is that outsourced cloud services handling non-classified, OFFICIAL: Sensitive, PROTECTED or SECRET data should have an IRAP assessment against a recent ISM at least every 24 months. That is an assessment of the service itself, so it’s worth asking the AI vendor for theirs.

Private-sector organisations work under different rules. Under the Privacy Act, APP 8 and section 16C can make you accountable for how an overseas recipient handles personal information you disclose to it. The OAIC’s guidance notes that giving data to an overseas contractor can be a “use” rather than a “disclosure” if your contract keeps effective control, which is one more reason to read the vendor’s terms closely. APRA-regulated entities also have CPS 234’s third-party requirements and APRA’s 30 April 2026 letter on AI to consider.

None of this amounts to “overseas AI is non-compliant”. It amounts to “you need to know, and be able to show, what happens to the data”.

Questions to put to any AI vendor

1. Where does inference run, and where are prompts, outputs, files, indexes, logs and backups stored? Is that a contractual commitment?
2. Which sub-processors touch prompt content, and in which countries?
3. Is any customer data used to train or improve models? Is that off by default, and is it in the contract rather than a settings toggle?
4. How long are prompts and outputs kept, including in abuse-monitoring or invocation logs, and can you delete them?
5. Which vendor staff can read your content, under what approval, and will you be told when they do?
6. Can you get prompt-level audit logs out into your own SIEM, and where are those logs held?
7. What has been independently assessed (IRAP, ISO 27001, SOC 2), what was the scope, and how old is the report?
8. What does the contract say about breach notification and liability caps?

Question 5 is the one most often skipped. Most vendors, including us, can access customer content for support, so the useful question is how that access is controlled and whether you can see it.

Where K9 fits

K9 AI runs its models on Amazon Bedrock in Sydney (ap-southeast-2), with no cross-region routing, and stores conversations, files, search indexes, audit logs and backups in Sydney. Requests reach the model under K9’s AWS account, so Mistral AI and NVIDIA don’t receive your prompts, though prompt content can still identify your organisation. It isn’t a zero-offshore service: subscription billing runs through Stripe outside Australia, and optional web search sends search terms to external providers. K9 support staff can access content when needed, and users can see when that happened and why. The full sub-processor list is on our Trust Centre, and we’d rather you check it against the questions above than take this paragraph on trust.

Frequently asked questions

Does the ISM require AI services to be hosted in Australia?

There is no single ISM control that says all government data must stay onshore. Hosting decisions for Commonwealth entities come mainly from the PSPF, the Hosting Certification Framework and the agency's own risk assessment, and ISM-1570 expects outsourced cloud services handling non-classified to SECRET data to have a current IRAP assessment.

Can a private company send personal information to an overseas AI provider?

Often yes, but APP 8 and section 16C of the Privacy Act may make you accountable for how the overseas recipient handles it. The OAIC's APP 8 guidance explains when giving data to an overseas contractor is a 'use' rather than a 'disclosure', which depends on how much control your contract keeps.

Does an Australian data centre mean the CLOUD Act doesn't apply?

Not necessarily. The CLOUD Act reaches data in the possession, custody or control of a US provider wherever it is stored, so the provider's ownership matters as much as the server's location.