Find out where your AI is allowed to run.

A neutral synthetic constraint set. It is not a recommendation, and no organisation's actual position is described here.

• Information sensitivity — Highly restricted: damaging to people, safety or national interest
• Personal or customer data — Personal information about customers or staff
• Contractual restrictions on disclosure — Some customer contracts restrict disclosure or sub-processing
• Overseas handling — Permitted only to named countries
• Retention constraint — Must be deletable on request, with evidence
• Training constraint — Content must not be used to train or improve any model
• Network requirement — Controlled egress only; private interconnect acceptable
• Latency requirement — Sub-second at the point of use
• Workload variability — Peaky, with long idle periods
• Integration reach — Systems reachable only from inside our own network
• Model and IP control — Must control the model and its weights
• Portability and exit — Must be able to move supplier within a defined period
• Operating capability — Some platform capability, no AI infrastructure experience
• Capital or operating preference — Either, if the case is made

Candidates that remain

1. Enterprise tenancy or dedicated managed capacity — Nothing you stated logically excludes dedicated managed capacity, which is the usual answer where isolation is required but ownership is not.
2. Australian-region hosted deployment — Nothing you stated logically excludes a region-bound hosted deployment. Note that a region commitment on its own is a statement about where compute runs, not about who can reach it.
3. Customer-controlled private cloud — Nothing you stated logically excludes a private cloud deployment, which keeps the control boundary yours without a capital purchase.
4. Customer-owned or on-premise deployment — Nothing you stated excludes an owned deployment. It is the only pattern where the asset and the weights are both yours.

Screened out, and why

1. Managed SaaS — You stated the model and its weights must be under your control. In this pattern the provider holds them.
2. Hosted model API — You stated the model and its weights must be under your control. In this pattern the provider holds them.

Questions that remain open

Every constraint in this example was stated.

Evidence to request from a supplier

1. Where processing, storage, logging, backups, telemetry, support access and any sub-processors are located, in writing. A region commitment covers compute; it frequently does not cover the rest.
2. The provider's current written position on whether your inputs and outputs are used to train or improve any model, whether it differs by plan, and how a change of position would be notified.
3. What deletion is actually available: what is deleted, from where, on what timescale, whether logs and backups are included, and what evidence of deletion you receive.
4. Whether private interconnect is available on the plan you would buy, and what egress to the public internet remains after it is in place.
5. Measured end-to-end latency from where your users or systems actually sit, at your payload sizes, at peak. Not the provider's published figure.
6. How this system would reach systems that are only addressable from inside your network: an agent, a private link, or a relay you operate, and what that component can see.
7. Whether your customer contracts permit this disclosure and this sub-processing chain. This is a question for whoever holds those contracts, and it is frequently answered too late.
8. What leaves with you at exit: data in a usable format, prompts and configuration, evaluation sets, and whether any of it is only meaningful inside the supplier's product.
9. Who would operate this: patching, capacity, incidents, model updates and evaluation. An owned or self-managed deployment is an operating commitment, not only a purchase.
10. Whether the utilisation justifies dedicated capacity. Hardware sized for a peak that arrives rarely is idle capital, and a peaky workload is the usual argument against owning it.
11. Whether a privacy impact assessment is required before this proceeds, and who is accountable for completing it.

These are the only rules that remove a candidate. A pattern that is not removed by one of them survives, which is a statement about logic rather than about suitability.

Why the rules are this narrow

The distinction most often blurred

1. It gives no legal advice and no compliance opinion. It does not say that an option satisfies any privacy principle, any contract or any regulatory obligation, and it deliberately avoids the phrases that would imply it.
2. A surviving pattern is a candidate, not an approved option. Survival means no published rule excluded it on the facts you entered.
3. It does not know your obligations. Whether overseas handling is permitted, and to where, is a question about your own circumstances, your contracts and the law that applies to you. Where you marked it unestablished, it stays a question.
4. Data residency alone establishes nothing about security or compliance. It establishes where information is. Who can reach it, under what controls, and whether the disclosure is permitted are separate questions.
5. It does not size or cost anything. Cost is the self-hosted cost calculator; feasibility of serving the load is the capacity planner.
6. It does not assess suppliers. It tells you what to ask them, which is the procurement pack.

• Multi-tenant — many customers served from shared infrastructure, separated logically. The default for managed applications and hosted model APIs.
• Dedicated or single-tenant capacity — capacity contracted to you alone, inside a provider's environment. Isolation, not ownership.
• Private cloud — cloud infrastructure your organisation holds the account for, inside your own network and identity boundary. The control boundary is yours; the hardware is rented.
• On-premise or customer-owned — hardware your organisation owns, in your facility or a colocation space you contract. The only pattern where both the asset and the weights can be yours.
• Cross-border disclosure — sending personal information to a recipient outside the country. Carries specific obligations in Australia; the OAIC publishes guidance on what they are.
• Sub-processor — a third party your supplier uses that can reach your material. The list changes, and how you are told when it changes is a contract question.
• Private interconnect — a network path to a provider that does not traverse the public internet. Availability depends on the plan you buy.

These are the publishers' own current pages, cited because they are the authoritative statement of obligations this tool deliberately does not interpret for you. No text from them is reproduced here.

1. Office of the Australian Information Commissioner, APP Guidelines chapter 8: APP 8 cross-border disclosure of personal information. Updated 3 October 2025.
2. Office of the Australian Information Commissioner, Guidance on privacy and the use of commercially available AI products. Published 21 October 2024, updated 17 January 2025.
3. National AI Centre, Guidance for AI adoption: implementation guidance. Part of the Essential AI practices.
4. National AI Centre, Guidance for AI adoption: foundations. Part of the Essential AI practices.

Primary sources last reviewed 27 September 2026. These are the publishers’ own pages; they are quoted nowhere on this site and nothing here restates them as a requirement that applies to you.