The Secure AI Buyer's Guide for Australian Organisations

Most AI buying decisions get framed as “which model is best”. For a business, that’s the wrong question. The model will change three times before your contract is up. The question that actually matters is: can we trust this with our data, and will it still be worth paying for in two years?

This guide is how we’d answer that on your behalf. It’s written for Australian organisations (businesses, government teams, health providers, not-for-profits) that have to weigh real obligations, not just features. Read it through before your next vendor call, or save it as a PDF and bring it to the meeting.

Pair this with the AI Vendor & Tool Evaluation Scorecard, which turns the questions below into a sheet you can score side by side.

1. Start with what the data actually is

Before you look at a single vendor, sort the data the tool will touch into three buckets:

• Open: already public, or harmless if it leaked. Marketing copy, published prices.
• Sensitive: commercially or personally damaging if exposed. Customer records, contracts, financials, staff details, anything covered by privacy law.
• Restricted: regulated, classified, or contractually fenced. Health records, government information, data you’re bound to keep onshore.

The bucket sets the rules. A tool that’s perfectly fine for drafting blog posts on open data may be completely unsuitable for restricted records. Most bad AI decisions come from applying “open data” thinking to sensitive or restricted data.

2. Understand the three deployment models

Almost every AI offering is one of three shapes. The difference is where your data goes and who can see it.

There’s no universally “right” answer. There’s a right answer for each bucket of data. Plenty of organisations run a public API for general productivity and a private deployment for the regulated workload. That’s not indecision; it’s correct.

3. The data questions that actually matter

Vendor security pages are written to reassure, not to inform. Ask these directly and get the answers in writing:

• Do you train your models on our data or prompts? The answer you want is no, or only with explicit opt-in. “We may use data to improve our services” is a yes in disguise.
• How long do you retain our inputs and outputs, and can we set it to zero?
• Where is the data processed and stored: which country, which region?
• Who are your sub-processors? The vendor may be fine and their fourth-party AI provider may not be. Follow the chain.
• Can we delete everything on request, and do you confirm it?
• What happens to our data when we leave? Export format, deletion timeline, proof.

If a vendor can’t answer these crisply, that is your answer.

4. The Australian context

Australian organisations carry obligations that change the calculus:

• The Privacy Act 1988 and the Australian Privacy Principles govern how you collect, use, disclose and secure personal information, including when you hand it to an AI vendor. You remain accountable for it even when a third party processes it.
• Reforms are tightening. The direction of travel is more accountability for automated decision-making and clearer transparency duties, not less. Buying as if the rules will loosen is a bad bet.
• Data residency matters for many sectors. Government, health, and some contractual arrangements expect data to stay onshore. “Global cloud, region unspecified” is a red flag for restricted data.
• Sovereignty goes beyond residency. It’s about who has jurisdiction over the data, not just where the server sits. A locally hosted service owned by a foreign entity may still be reachable under foreign law.

You don’t need to be a lawyer to ask “where does this data live, and whose laws reach it?”, but you do need to ask.

5. Security basics, verified not assumed

For anything touching sensitive or restricted data, confirm the fundamentals:

• Access control: role-based access, SSO, and the ability to see who touched what.
• Audit logging: a real, exportable record of access and actions.
• Encryption: in transit and at rest, as a baseline, not a premium add-on.
• Independent assurance: SOC 2 Type II or ISO 27001 certification, and a recent penetration test they’ll show evidence of.
• Tenancy isolation: for cloud, how your data is separated from other customers'.

Ask for the artefacts. A serious vendor has them ready; a hesitant one is telling you something.

6. The value question

Security gets you a tool you can use. Value is whether you should pay for it.

• Don’t buy capability you can’t operate. A sovereign on-prem model you have no one to run is worse than a well-governed SaaS you can.
• Price the whole thing. Licences are the visible cost. Integration, change management, oversight, and the staff time to review outputs are the real total.
• Watch for lock-in. Proprietary formats, un-exportable history, and pricing that balloons with usage are how a cheap pilot becomes an expensive dependency.
• Demand a measurable outcome. “It boosts productivity” is not a result. “It cuts invoice processing from six minutes to ninety seconds, checked by a human” is.

A short buyer’s checklist

Before you sign, you should be able to tick every one of these:

• We’ve classified the data this tool will touch.
• We’ve matched the deployment model to the most sensitive bucket.
• We have written answers on training, retention, residency and sub-processors.
• We’ve seen real security assurance, not just a marketing page.
• We know the total cost, including the human oversight.
• We can leave (export our data and have it deleted) without a fight.
• There’s a specific, measurable outcome we’re buying.

If you can’t tick one, that’s not a reason to panic; it’s the next question to ask. The whole point of buying AI well is that the awkward questions get raised before the contract, not after the breach.

When you want a second set of eyes on a specific proposal, that’s exactly the kind of thing a discovery call is for, and if the workload is genuinely sensitive, our Private & Sovereign AI work is built around keeping it that way.