Most Australian businesses cannot answer a simple question about their AI stack: where is each tool sending your data for processing?

Not where it is stored. Where it is processed. Where the model inference actually happens when a team member pastes a client file, a financial record, or a personal document into an AI tool and hits send.

The answer, for most mainstream AI tools, is the United States or Europe. And for Australian businesses with Privacy Act obligations, that answer has legal weight that most have not yet mapped against their current tool use.

This post gives you a step-by-step AI audit framework. It covers what to audit, how to assess each tool, how to document your findings in a format that satisfies both internal governance requirements and external regulatory scrutiny, and what to do when the audit surfaces exposure you did not know you had.

Why Does an AI Sovereignty Audit Matter for Australian Businesses?

The 2024 Privacy Act amendments created a more enforceable compliance environment for Australian businesses that handle personal information using AI tools. The OAIC's updated guidance on AI clarified that sending personal information to an offshore AI vendor for processing constitutes a cross-border disclosure under APP 8. The entity making that disclosure remains accountable for how the information is handled, even when the processing happens on infrastructure they do not control.

Two things make this immediately practical rather than theoretical.

First, the penalties are real. Serious or repeated privacy interference now carries civil penalties of up to $50 million, or three times the benefit gained, or 30 percent of adjusted turnover — whichever is highest. The new statutory tort introduced by the 2024 amendments also gives individuals a direct right of action for serious privacy invasions, without waiting for the OAIC to act.

Second, most businesses have not mapped their AI exposure. The OAIC data breach notification statistics show over 1,000 notifications in the second half of 2024. A meaningful proportion involve third-party systems — precisely the exposure profile that an ungoverned AI tool stack creates.

The AI audit is the process that closes this gap. It is also the first deliverable most boards will ask for once they understand the regulatory environment.

Sunburnt AI holds a board advisory connection with Responsible AI Australia, which has engaged directly with OAIC consultation processes on AI governance. The consistent finding from that engagement: most Australian SMBs have not done this audit. They have bought tools. They have not mapped risk.

What Should an AI Audit Cover?

A complete AI sovereignty audit covers five areas:

Tool inventory. Every AI tool in use across the business, including tools used informally by individual team members without IT approval or management knowledge.

Data flow mapping. For each tool, what data does it access or receive, where is that data sent for processing, and what happens to it after processing.

Vendor sovereignty assessment. For each vendor, where is their infrastructure located, what law governs the services agreement, and what data protection commitments do they make contractually.

Exposure scoring. Based on the data types involved and the vendor sovereignty position, what is the Privacy Act exposure level for each tool, and what is the aggregate exposure across the stack.

Remediation register. What actions are required to close the gaps identified, in what priority order, and by when.

This audit does not replace legal advice. Businesses with complex privacy obligations or significant exposure identified in the audit should engage a privacy lawyer to advise on specific remediation steps. The audit framework gives you the facts. Legal advice tells you what to do with them.

Step 1 — Inventory Your AI Tools

The starting point is a complete list of every AI tool in use in the business. This is harder than it sounds. Shadow AI — tools used by individual team members without formal approval — is common in Australian workplaces. Research consistently shows that between 30 and 60 percent of AI tool use in organisations is informal and outside IT governance.

How to build the inventory:

Send a brief, non-judgmental survey to every team member asking: what AI tools do you use for work tasks, either regularly or occasionally? Include: the tool name, what you use it for, and whether you have entered any client or company information into it.

Supplement the survey with a review of your organisation's browser extension policies, SaaS subscription billing records, and any IT-managed software lists. Cross-reference these sources to build a complete picture.

What to capture for each tool:

• Tool name and vendor

• Category (writing assistant, meeting transcription, document analysis, workflow automation, scheduling, industry-specific)

• Who uses it (roles, not names)

• What it is used for (specific task description)

• Whether client, employee, or other personal information has been entered into it

• Whether it is formally approved or informally adopted

Do not pre-judge which tools are a problem at this stage. The goal is completeness. Exclusion at this stage creates gaps in the audit that undermine its usefulness.

If you want a structured starting point for this assessment, the X-Ray Workshop includes an AI tool inventory as part of the workflow mapping process. It surfaces informal AI use that surveys alone miss, because it maps actual workflow practices rather than relying on self-reporting.

Step 2 — Map Data Flows for Each Tool

For each tool in your inventory, answer three questions:

What data does it receive? Classify the data type: non-personal business data (internal documents, templates, public information), personal information about employees, personal information about clients or customers, sensitive information (health, financial, immigration status, legal matter details), or a combination.

Where is it processed? This is the sovereignty question. The answer is not where the data is stored. It is where model inference happens — where the data is sent when the tool runs an AI task. For most mainstream tools, this means the vendor's cloud infrastructure. You need to know in which country or countries that infrastructure sits.

How to find out:

1. Check the vendor's privacy policy and data processing addendum. Look for language about data processing locations, cross-border transfers, and sub-processors.

2. Check the vendor's trust centre or security documentation (most enterprise SaaS vendors publish one).

3. If unclear, email the vendor's privacy team directly and ask: in which country is personal information processed during model inference? Keep a record of the response.

What happens to it after processing? Is the data retained by the vendor for model training? For how long? Is it used to improve the product? What are the deletion rights?

Document each finding in your audit register (Step 5 format below). Do not skip tools where the answer is unclear — an unclear answer is itself a finding.

Step 3 — Assess Vendor Sovereignty Position

For each vendor, assess their sovereignty position across three dimensions.

Processing location. Is model inference performed on Australian infrastructure? On infrastructure in a country with adequate data protection laws (EU, UK)? Or on infrastructure in the United States or another jurisdiction without adequacy findings under Australian privacy law?

Contractual protections. Does your agreement with the vendor include data processing terms that require them to handle personal information in a way that is at least equivalent to the Australian Privacy Principles? A standard SaaS terms of service does not provide this. An enterprise data processing agreement (DPA) or data processing addendum might — but you need to check. The absence of APP-equivalent contractual protections is an APP 8 compliance gap for any offshore processing.

Accountability and jurisdiction. Is the vendor an Australian company, subject to Australian law and answerable to Australian regulators? Or is it a US or European company, operating under terms governed by their home jurisdiction? The accountability chain matters when something goes wrong.

Score each vendor on these three dimensions using a simple traffic light system: Green (Australian infrastructure and law), Amber (offshore but with adequate contractual protections), Red (offshore with no adequate contractual protections or unclear position).

Most businesses that complete this step discover they have more Red vendors than they expected. That is a normal finding. The audit is designed to surface it, not to avoid it.

Step 4 — Score Your Exposure

Combine the data flow information from Step 2 with the vendor sovereignty assessment from Step 3 to produce an exposure score for each tool.

Use this matrix:

Critical exposure means you have sensitive personal information being processed by a vendor with no adequate contractual protections and likely offshore infrastructure. This is the situation that requires immediate action — either moving to a compliant vendor, obtaining client consent, or ceasing the use of the tool for tasks involving that data type.

High exposure means you have personal information being processed offshore without adequate contractual protections. This requires remediation, likely within the next quarter.

Medium exposure means you have personal information being processed offshore with some contractual protections, but those protections may not fully satisfy APP 8 requirements. Legal review recommended.

Low exposure means either the data is non-personal, or the vendor is Australian-hosted and accountable under Australian law.

Aggregate the scores across your tool stack to produce an overall exposure profile for the business.

If your audit produces Critical or High exposure findings and you are uncertain about the remediation path, the Sovereign AI Trust Framework gives you the five-pillar assessment model that maps directly onto the remediation priorities.

Step 5 — Produce the Audit Register

The output of your audit is a formal register. It has six columns:

1. Tool name and vendor

2. Data type processed (classify using the categories from Step 2)

3. Processing location (country or region, with source — e.g., "US — AWS us-east-1, confirmed in vendor DPA")

4. Contractual protections (DPA in place: Yes/No/Unknown; APP-equivalent terms: Yes/No/Unknown)

5. Exposure score (Critical / High / Medium / Low, from Step 4)

6. Remediation action and timeline (what needs to happen, who owns it, by when)

The register should be dated, version-controlled, and reviewed at least quarterly. AI tool use in organisations changes fast — new tools are adopted, existing tools update their infrastructure, and vendor agreements change. The register is not a one-time exercise. It is a living governance document.

Present the register to your board or leadership team alongside a brief narrative summary covering: total tools audited, exposure distribution, immediate actions required, and the ongoing review cadence. This is the governance artefact that demonstrates the organisation is taking its Privacy Act obligations seriously.

What Do You Do When the Audit Finds a Problem?

Three actions, in order of urgency.

For Critical exposure: Stop using the tool for tasks involving sensitive personal information immediately, pending remediation. If cessation is not operationally feasible, document the specific risk, seek legal advice on your disclosure obligations, and implement the fastest available alternative. For most regulated Australian businesses, the fastest available alternative is Australian-hosted AI infrastructure with an audit log.

For High exposure: Initiate vendor conversations about a DPA or equivalent contractual protections within 30 days. If the vendor cannot provide APP-equivalent terms, plan migration to a compliant alternative within 90 days. In the interim, restrict the data types the tool is used with to reduce exposure.

For Medium exposure: Review the existing contractual terms with the vendor. Identify what protections are missing and whether they can be supplemented by negotiation. Queue for the next legal review cycle.

The structural solution for regulated Australian businesses with multiple High or Critical findings is not to manage each tool individually. It is to move AI infrastructure to a platform that is Australian-hosted, governed, and audit-logged by design — eliminating the cross-border processing exposure at the architecture level rather than the tool-by-tool negotiation level.

Download the Sovereign AI Trust Framework to map your audit findings against the five-pillar compliance model and identify which remediation path fits your business.

FAQ

How do I audit my AI tools for Privacy Act compliance in Australia?

Start with a complete inventory of every AI tool in use across the business, including informal use by individual team members. For each tool, map what data it processes and where processing happens. Assess each vendor's sovereignty position: processing location, contractual protections, and legal jurisdiction. Score the exposure for each tool based on data type and vendor position, and produce a formal register with remediation actions and timelines. Review the register quarterly.

What should an AI sovereignty audit cover for an Australian business?

A complete AI sovereignty audit covers five areas: tool inventory (including shadow AI), data flow mapping for each tool, vendor sovereignty assessment (processing location, contractual protections, legal jurisdiction), exposure scoring by data type and vendor position, and a remediation register with priority actions and timelines. For regulated businesses, the audit should also assess whether current AI use satisfies the OAIC's guidance on APP 8 cross-border disclosure obligations.

How do I know if my AI vendor processes data offshore?

Check the vendor's privacy policy, data processing addendum, and trust centre documentation. Look for explicit statements about processing locations and sub-processors. If unclear, email the vendor's privacy team directly and ask: in which country is personal information processed during model inference? If they cannot give you a clear answer, treat the processing location as unknown — which is itself a compliance concern — and factor that into your exposure assessment.

Conclusion

An AI audit is not a one-day exercise. For a 20 to 50-person regulated Australian business with five to fifteen AI tools in use, a thorough audit takes two to four weeks from inventory to completed register. It requires input from legal, IT, and senior management. It will almost certainly surface exposure that nobody knew existed.

That is the point. The audit produces a register that closes the information gap between what leadership believes is happening with AI data and what is actually happening. For Privacy Act compliance, for board governance, and for the client relationships that depend on data being handled with care, that register is the foundation.

The Sovereign AI Trust Framework gives you the five-pillar assessment model that structures the vendor evaluation step of the audit and maps directly onto the remediation priorities.

Download the Sovereign AI Trust Framework and use it alongside this audit process to produce a governance position your board can act on.