Why must data preparation come before AI deployment?

AI tools that access your business data do not apply new access controls — they inherit your existing ones. Microsoft 365 Copilot presents only data each user can already access. If permissions are overly broad or sensitive data is poorly classified, the AI will surface that content instantly through natural language queries. Cleaning up permissions and applying sensitivity labels before deployment closes that exposure.

What does Australian law require when deploying AI tools?

Under Australia's Privacy Act 1988 and the Notifiable Data Breaches scheme, privacy obligations apply to any personal information input into an AI system and to AI-generated output that contains personal information. In early 2025, a contractor uploading health records into an AI tool caused a notifiable data breach in Australia. Businesses must establish AI use policies, review vendor data handling practices, and ensure sensitive data cannot be inadvertently submitted to AI systems.

How should businesses classify and protect data before enabling AI tools?

The recommended sequence is: permissions cleanup first, then sensitivity labels, then DLP policy configuration, then AI enablement. In Microsoft 365, sensitivity labels control whether content can be included in AI-generated responses. Businesses should start with three to four labels (Public, Internal, Confidential, Highly Confidential), run DLP policies in audit mode for 60 days before enforcement, and use Microsoft Purview to prevent AI tools from processing content with specific labels.

What vendor due diligence is needed before adopting an AI tool?

Before deploying any AI product, businesses should confirm where data is processed and stored, whether prompt or customer data is used to train the vendor's models, whether the vendor holds ISO 27001 or a comparable security certification, and what the vendor's breach notification obligations are. Sensitive data submitted to offshore AI tools may trigger cross-border disclosure obligations under the Australian Privacy Principles.

Securing Sensitive Data Before Deploying AI Tools

IT administrator reviewing sensitivity labels and data permissions in Microsoft Purview before securing data before AI deployment

AI tools are arriving in Australian businesses quickly, and most teams are keen to get started. The instinct is reasonable: the productivity gains are real, and the tools are increasingly accessible. What often gets skipped, however, is the data preparation work that needs to happen first. Deploying an AI tool into an environment where sensitive data is poorly classified, over-shared, or ungoverned does not make that data safer. It makes it much easier to surface.

This article covers what secure AI deployment actually requires, why the Australian regulatory environment makes preparation non-negotiable, and the practical steps businesses should take before turning any AI tool on for staff.

Why data preparation must come before AI deployment

AI tools that access your business data do not apply new access controls. They inherit your existing ones. Microsoft 365 Copilot, for example, presents only data that each individual user can access, using the same underlying controls for data access used in other Microsoft 365 services. That sounds reassuring until you consider what those existing controls actually look like in most SME environments: SharePoint sites shared with whole departments, stale permissions from staff who left years ago, and documents sitting in folders that far more people can reach than anyone intended.

Before AI tools, the barrier to stumbling into sensitive data was friction. Copilot removes that friction. Every licensed user gets an AI assistant that searches across all content they have access to via the Microsoft Graph. A user can type “show me our Q3 acquisition targets” and the tool surfaces every matching document their permissions allow, classified or not, governed or not. The data was already accessible. The AI simply made it instantly and effortlessly findable.

This is not a flaw in the AI tool. It is the correct behaviour of a productivity tool doing what it was designed to do. The responsibility sits with the business to clean up its data environment before that capability goes live.

What the Australian regulatory environment requires

Australian businesses deploying AI tools face clear obligations under the Privacy Act 1988 and the Notifiable Data Breaches (NDB) scheme. Privacy obligations apply to any personal information input into an AI system, as well as the output data generated by AI where it contains personal information. That scope is broader than many businesses realise: it covers what staff type into AI prompts and what the AI generates in response.

In early 2025, a contractor working for an Australian organisation uploaded personal information, including names, contact details, and health records, into an AI system. This led to a serious data spill and was considered a notifiable data breach. That incident is now cited directly in guidance from the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC). It illustrates that AI-related breaches are not hypothetical. They are happening now, in Australia, in organisations that had not thought carefully enough about what data their staff were feeding into AI tools.

The Office of the Australian Information Commissioner (OAIC) recorded 532 notifiable data breaches in the first half of 2025, each incident affecting an average of more than 10,000 individuals. A significant increase in data breaches caused by human error accounted for 37% of all data breaches in that period. AI tools, without proper governance in place, create new and faster pathways for exactly this kind of human error.

The OAIC has also published specific guidance on the use of commercially available AI products. Organisations must take particular care with sensitive information, which generally requires consent to be handled. Many photographs or recordings of individuals, including artificially generated ones, contain sensitive information and may not be able to be used as input data for AI systems without the individual’s consent. For businesses in professional services, health, legal, and finance, this guidance is directly relevant to everyday workflows.

How to classify and protect data before AI goes live

Sensitivity labelling is the foundation of secure AI deployment in a Microsoft 365 environment. Microsoft 365 permissions answer one question: “Can this user see this content?” Sensitivity labels answer a different question: “Should this content be included in an AI-generated response?” These are fundamentally different questions. Labels are the mechanism that tells Microsoft Purview, DLP (Data Loss Prevention) policies, and AI tools how to treat each piece of content. Without labels, the AI has no guardrails.

The sequence matters. A safer and faster implementation sequence is: permissions cleanup, then sensitivity labels, then DLP tuning, then AI enablement. This order aligns with real-world AI risk patterns, where oversharing is usually the primary exposure pathway. Applying labels to a SharePoint environment that still has broad legacy permissions simply layers classification on top of an unresolved access problem.

Practical steps for data preparation before AI deployment include:

Audit all SharePoint sites, OneDrive folders, and Teams channels for permissions that are wider than necessary, focusing on “everyone” links, stale guest accounts, and large distribution-group access.
Remove or expire permissions that no longer serve a business purpose. Remove stale members from privileged Microsoft 365 groups and Teams. Expire or revoke old anonymous or organisation-wide links where business value no longer exists.
Deploy a compact sensitivity label taxonomy. Working SMB implementations commonly succeed with three to four labels, not large taxonomies. Public, Internal, Confidential, and Highly Confidential is a practical starting point.
Configure DLP policies in audit mode before enforcement. A 60-day DLP audit window is a common practical baseline before switching to enforcement mode. This surfaces where sensitive information actually lives without disrupting staff workflows.
Use Microsoft Purview to create DLP policies that prevent AI tools from processing content with specific sensitivity labels, so even if a user can technically access a document, the AI will not include it in summaries or responses.

What AI tools can access and what they cannot

Understanding how AI tools interact with your data helps set realistic expectations for what preparation is needed. Information protection policies in Microsoft 365 restrict Copilot access based on sensitivity labels and DLP conditions. When encryption is applied correctly, Copilot can only summarise or reference content that the user is authorised to access. When encryption is applied, the user must have appropriate usage rights for Copilot to interact with the content.

Double Key Encryption (DKE) is intended for the most sensitive data subject to the strictest protection requirements. Copilot and agents cannot access data protected by DKE, and items protected by DKE will not be returned by Copilot. For businesses handling genuinely restricted information, such as legal advice, board materials, or health records, DKE offers a strong technical control that sits outside the AI’s reach entirely.

For third-party AI tools outside the Microsoft ecosystem, the control model is different. Employees interact with generative AI systems using natural language, which means they routinely paste proprietary code, confidential documents, customer data, and strategic plans into AI prompts. Unlike Microsoft 365 Copilot, which inherits your existing access controls, external AI tools often have no connection to your permission model at all. An internal AI policy that defines what data staff are permitted to paste or upload into external tools is not optional; it is a baseline governance requirement.

Building an AI use policy that staff will actually follow

Technical controls protect data from accidental exposure. An AI use policy protects it from deliberate but uninformed choices. To reduce the risk of AI-related data leaks and privacy breaches, businesses should review internal data management, protection, and governance practices, identify and secure sensitive and proprietary information, and clearly define what data cannot be uploaded into AI platforms and systems.

A practical AI use policy for an SME does not need to be long. It should answer five questions for staff:

Which AI tools are approved for use, and which are not.
What categories of information must never be entered into an AI prompt, such as client personal data, financial records, health information, and legal advice.
How to handle AI-generated outputs before sharing them externally, including a requirement to verify accuracy.
Who to contact if staff are unsure whether a task is appropriate for AI.
What constitutes a reportable data incident if AI is involved in a potential exposure.

The ACSC guidance outlines steps businesses can take to securely use AI in their operations, and recommends applying that advice alongside the Essential Eight framework to help secure the AI environment. The Essential Eight controls, particularly application control, patching, and restricting administrative privileges, provide a meaningful baseline that complements AI-specific governance.

Vendor due diligence before adopting any AI tool

Choosing an AI tool is not only a productivity decision. It is a data-handling decision. Sensitive data used to prompt AI models could inadvertently leave the jurisdiction, breaching Australian Privacy Principles (APPs) or industry-specific compliance frameworks. Before deploying any AI product, businesses should ask their vendor four questions:

Where is data processed and stored? If the vendor’s infrastructure is offshore, consider whether that creates a cross-border disclosure obligation under APP 8 of the Privacy Act.
Is customer or prompt data used to train the vendor’s models? Microsoft 365 Copilot does not use prompts, responses, or data accessed through Microsoft Graph to train foundation models. Not all vendors offer the same commitment.
Does the vendor hold ISO 27001 certification or a comparable security standard? This is a reasonable baseline for any tool handling business data.
What are the vendor’s breach notification obligations and timelines if your data is involved in an incident?

The ACSC’s AI guidance emphasises that responsible AI adoption is not just a technical exercise, but also a strategic imperative that impacts legal, ethical, reputational, and operational aspects of a business. Vendor due diligence is part of that strategic responsibility, not a box-ticking exercise.

A short readiness check before AI goes live

Before enabling any AI tool for staff, run through these five questions:

Have you audited SharePoint, OneDrive, and Teams permissions and revoked access that is broader than necessary?
Have you deployed sensitivity labels covering at least your most sensitive data categories, and confirmed DLP policies reference those labels?
Have you reviewed the AI vendor’s data handling, storage location, and training data policies?
Have you written and communicated an AI use policy that tells staff what they can and cannot submit to AI tools?
Do you have a data breach response plan that covers an AI-related incident, including OAIC notification obligations?

If any of these five questions does not have a clear yes, that gap should be closed before the AI tool goes live. The preparation work takes time, but it is substantially less costly than managing a notifiable data breach after deployment.

Where do we start?

We help Australian businesses get their data environment ready for AI, from permissions audits and sensitivity labelling to AI use policies and vendor assessments. If you are planning to deploy Microsoft 365 Copilot or any AI tool and want to make sure your data is protected first, get in touch with the TTA team. We can also help you understand how Microsoft 365 Copilot fits into a governed, secure Microsoft 365 environment, or assess your overall IT security posture before you take the next step with AI.