Your AI runs in Sydney. Three things that still go wrong.

The first question every board asks about AI is where the data goes. For most Australian businesses the answer is now straightforward. Azure OpenAI, AWS Bedrock and Google Vertex all run in Australian regions, and enterprise agreements commit that your prompts and documents are not used to train the models.

So the AI runs in Sydney, the data stays in your tenancy, and the box is ticked.

That is the easy part. In the private AI projects we see stall, the problem is almost never the region. It is one of three things that the "keep it onshore" conversation does not cover.

1. An Australian region is a setting, not a guarantee

Creating your AI resource in Australia East or ap-southeast-2 does not by itself mean every request is processed there.

Both major platforms offer deployment options that route requests across regions for capacity or price. They are often the default for the newest models, because those models arrive in the larger US and European regions first. A team that picks the newest model for a pilot can end up on a global or cross-region deployment without anyone making that choice on purpose.

What to check:

• The deployment type of every model endpoint, not just the region of the resource.
• Whether the model you want is available on a regional deployment in Australia today, or only through a global one.
• What happens when the model you are using is retired and replaced.

None of this is hard. It just has to be checked per endpoint, and checked again when models change.

2. Private AI can still show people what they should not see

A private assistant connected to SharePoint, OneDrive or a document store usually respects existing permissions. If a user can open a file, the assistant can use it in an answer. That sounds safe until you look at the permissions.

Most organisations have years of sharing debt: sites open to "everyone", sharing links that never expired, former contractors still in groups, sensitive files with no label and no owner. Concentric AI's analysis of over 550 million records found an average of 802,000 files per organisation at risk from oversharing, broken permissions and wrong classification.

Before AI, finding those files took effort. After AI, anyone can ask "what are the salary bands for the leadership team?" and get an answer built from a spreadsheet they were technically allowed to open and never knew existed.

The AI did not create the access. It removed the friction that was hiding it.

What to check:

• Run a permissions review on the sites and folders you plan to connect, starting with HR, finance, legal and board material.
• Exclude repositories that hold regulated or sensitive data until they are cleaned up.
• If you build your own retrieval layer rather than using Copilot, make sure it checks the user's permissions at query time, not only when documents are indexed.

3. Accuracy drifts after launch

Pilots usually run on a few hundred curated documents and work well. Production connects tens of thousands of real ones: three versions of the same policy, the 2021 price list next to the 2026 one, procedures for a system that was decommissioned last year.

Retrieval then surfaces the wrong passage, and the model writes a confident, well-formatted answer from it. Users trust it because it "uses our data". The first sign of trouble is usually a complaint.

Most of the fix is in the documents, not the model:

• Remove duplicates and superseded versions before indexing. This tends to improve accuracy more than any tuning.
• Give documents owners, dates and status, so retrieval can prefer the current, approved version.
• Build a test set of real questions with known correct answers, including awkward and out-of-scope ones, and run it after every change to documents, prompts or models.
• Watch what users ask. Questions that get poor answers point to gaps in the documents, not just the AI.

An assistant that is right 95% of the time in week one and 80% of the time in month four has not broken. Its data has moved underneath it.

Before you go live: a short checklist

1. Every model endpoint is on a deployment type that matches your data residency position.
2. Connected repositories have had a permissions review, and sensitive ones are excluded or cleaned.
3. Retrieval checks the user's permissions at query time.
4. Superseded and duplicate documents are removed, and the rest have owners and dates.
5. A test set of real questions runs after every change, with results recorded.
6. Someone owns the assistant's accuracy after launch, not just its delivery.

One more thing for Australian businesses

From 10 December 2026, if an AI system makes, or substantially helps make, decisions that could significantly affect people, your privacy policy has to describe it under APPs 1.7 to 1.9. An internal knowledge assistant usually will not meet that threshold. One that triages complaints, scores applications or recommends outcomes for customers might. It belongs in your decision inventory either way, so counsel can make the call.

Where Hezico fits

We set up private AI inside your own Azure or AWS tenancy, connected to your own documents, with permissions and governance in place from the start. Where an assistant is already live and its accuracy is slipping, we fix the data layer underneath it.

A fixed-scope two-week pilot gets one use case running properly, with the test set, the permissions review and the deployment checks done. Then you decide whether to expand.

---

Sources

• Concentric AI data risk research, as reported by Compare the Cloud, "How to stop Microsoft Copilot surfacing confidential data to the wrong people", 2026.
• Strac, "Microsoft Copilot data privacy: what it sees and keeps", 2026.
• Shelf, "Why enterprise RAG fails: the data layer problem", 2026.
• Team400, "Azure OpenAI Service vs direct OpenAI API for enterprise in 2026", 13 May 2026.
• OAIC, APP 1.7 to 1.9 transparency obligation fact sheet.