AI privacy questions to ask before you sign anything

Most Australian small businesses don't read the terms before signing up to a new SaaS tool. That's not a criticism — it's just reality. The terms are long, the font is small, and the free trial expires in 14 days. So you click Accept, connect your Google Workspace, and get on with it.

That's fine for a project management tool that holds your to-do lists. It's a different calculation when the tool is processing your client records, patient intake forms, supplier contracts, or staff communications — which is exactly what most AI-adjacent tools are now doing, often without it being obvious.

This post is a practical checklist. Four questions to ask any AI vendor before you commit, plus the contract language worth demanding. None of it requires a lawyer to understand. All of it applies to a typical Australian owner-operator or small team right now.

Does the Privacy Act 1988 actually apply to your business?

The Privacy Act 1988 and its Australian Privacy Principles apply to businesses with an annual turnover above $3 million, as well as certain other categories — health service providers being the most common exception for small operators. If your turnover is under $3 million and you're not a health provider, the Act does not directly bind you. That doesn't mean the privacy questions in this post stop mattering.

Your clients and patients may be covered entities themselves. A recruiter under $3M turnover who handles candidate records for a large corporate client may well find its client's privacy obligations passed down to it by contract. A small allied health practice is a health service provider regardless of revenue — the $3M threshold doesn't exempt it.

And practically speaking, clients increasingly ask about data handling before they hand anything over — especially in professional services, healthcare, and government-adjacent work. The vendor questions below are worth asking whether or not the Act technically binds you, because they're what your own clients will eventually ask you.

Where does the data actually go, and does it leave Australia?

Ask the vendor directly: in which country or countries is your data stored and processed? The answer you want is AWS Sydney (ap-southeast-2), Azure Australia East, or an equivalent local region — not "we use world-class cloud infrastructure" or "data is encrypted in transit." Those phrases don't answer the question.

Data residency matters for a specific set of Australian industries. Healthcare providers operating under APP 8 need to think carefully about cross-border disclosure. Government suppliers often face contractual requirements around where data is processed. Legal and accounting firms handling client files have confidentiality obligations that can interact with offshore data flows in messy ways.

The honest answer from many AI vendors is that some processing happens in the US — either because their model inference runs there or because their US-based sub-processors handle parts of the pipeline. That may be acceptable depending on your industry and client agreements, but you should know it before you sign, not after a breach notification lands in your inbox. We covered the mechanics of where business data actually travels in more detail in where your business data goes when you use AI — worth reading alongside this one.

Is your data being used to train their models?

This is the question most people forget to ask, and it matters more than almost any other clause. Some vendors use customer data to improve or fine-tune their models. If your client records, invoices, or intake forms are feeding a model that will later respond to someone else's queries, that is a material fact about how your data is being used.

The good news is that most paid business and enterprise tiers now exclude your data from training, usually in the contract itself. The bad news is that free and low-cost tiers are often opted in to training by default, and the wording in the terms is rarely obvious about this.

What to look for: search the terms for "train", "improve", "model", and "aggregate". Look for whether the opt-out requires you to actively submit a form or whether it's handled by a setting in the dashboard. And check whether opting out is available at your pricing tier — some vendors reserve it for enterprise contracts only.

If the vendor can't give you a clear yes-or-no answer on training data use, assume the answer is yes. "We may use data to improve our services" is not the same as "your data is not used to train models." The distinction matters and any vendor worth using should be able to spell it out.

Who are their sub-processors, and what do they have access to?

A sub-processor is any third party that the vendor shares your data with to deliver the service. Every meaningful AI platform has them — cloud hosts, inference providers, logging tools, customer support platforms. The question isn't whether they exist; it's whether you can find out who they are and what they touch.

Reputable vendors publish a sub-processor list, either in the terms themselves or at a dedicated URL they commit to updating when they add new sub-processors. Ask for it. If the vendor doesn't have one, that tells you something about how seriously they take data governance.

Pay particular attention to sub-processors that have access to unencrypted data — typically the inference layer (the bit that actually reads and processes your content) and the logging layer (which often stores request and response pairs for debugging). Storage-layer sub-processors are usually less exposed. The ones that see the actual text of your documents are the ones worth scrutinising.

For Australian businesses, the sub-processor list also tells you whether your data is leaving the country via a third-party route even if the primary vendor claims local hosting. A vendor hosted in Sydney that routes inference through a US-based LLM API is still sending your data offshore. That's worth knowing.

What does their breach notification process look like?

Under the Notifiable Data Breaches scheme — which applies to entities covered by the Privacy Act 1988 — an eligible data breach must be reported to the Office of the Australian Information Commissioner and affected individuals as soon as practicable. The 30 days people often quote is the time allowed to assess a suspected breach, not a deadline for telling anyone. If you're a covered entity and a vendor breach exposes your client records, expect the notification to be yours to make — only one of you needs to notify, and the OAIC generally looks to the business closest to the affected individuals.

That means you need to know how fast a vendor will tell you about a breach, and what "tell you" means in practice. An email to your registered address three weeks after the event is not the same as a direct contact to your named account manager within 72 hours. Ask specifically: what is your incident response SLA, how will you notify us, and will you provide enough detail for us to make our own notification assessment?

If the vendor's answer is "we'll post an update to our status page," that is not a satisfactory answer for a business processing client personal information. A status page update is fine for a server outage. It is not fine for a data breach affecting your clients. Push for a written commitment to direct notification within a specified timeframe, and get it in the contract, not just a verbal assurance during a sales call.

What contract clauses are actually worth demanding?

Most AI vendors offer standard terms that were written to protect them, not you. That's not unusual — it's how every SaaS contract starts. The question is which clauses you can realistically push back on, especially as a small business without a legal team.

1. Data processing agreement (DPA). Ask for a separate DPA that specifies how your data is handled, what it can be used for, how long it's retained, and how it's deleted when you leave. Many vendors have these sitting ready — they just don't volunteer them during signup.

2. Training data exclusion. If training-data opt-out isn't the default, ask for it to be written into the DPA explicitly. "Vendor will not use Customer data to train, fine-tune, or improve its models" is the language to look for. Vague references to "aggregated and de-identified data" are weaker and worth questioning.

3. Sub-processor notification. Ask for a clause requiring the vendor to notify you before adding new sub-processors that will have access to your data, with enough lead time to object or exit if needed. Thirty days' notice is reasonable. Some vendors offer this; many don't, but it's worth asking.

4. Data deletion on exit. Confirm that your data will be deleted — not just archived — within a specified period after you close the account, and that you can request written confirmation of deletion. Some vendors retain data for 90 days after account closure; others longer. Know the timeline before you commit.

5. Jurisdiction and governing law. Check which country's law governs disputes. A contract governed by Delaware law is harder to enforce from Melbourne than one governed by Victorian or NSW law. For most small businesses this is unlikely to matter in practice, but if you're processing sensitive client records and things go wrong, you want the dispute to happen somewhere you can actually participate in.

If a vendor refuses every one of these requests, that's useful information. The vendors worth using — especially for anything touching client personal information — will have DPAs ready, will be able to answer the training-data question clearly, and won't treat basic data governance as a negotiating tactic. For businesses building custom workflows where these questions come up early in the design process, thinking through AI automation with data residency baked in from the start is usually cleaner than retrofitting it later.

The honest version of what this checklist is for

This isn't about making AI tools too hard to use. Most of the vendors worth using can answer these questions without much difficulty — because they've built their products to handle them. The checklist is mostly useful for filtering out the ones that can't, before you're six months in with client data inside a platform you now can't exit cleanly.

The practical upshot: spend thirty minutes on the vendor's terms and DPA before you connect anything that touches client records. Ask the four questions above, in writing, before you sign. If the answers are clear and reasonable, proceed. If they're vague, deflecting, or "we'll follow up on that," that's the answer you needed.