What is shadow AI, and how do you bring it under control?

Somewhere in your organisation this week, someone pasted a customer’s email into a public chatbot, someone else had an AI note-taker on customer calls and another person used a frontier model to vibe code. A lot of this is happening on personal subscriptions that nobody in IT knows about. 

That’s shadow AI: staff using AI tools at work that aren’t approved or controlled. And it’s the worst-kept secret across Australian organisations right now. 

The reason why makes a lot of sense. It seems like every month, a new AI tool is best-in-class for a specific use case – and the use cases just keep growing. The rapidly changing AI landscape is feeding AI FOMO. Employees, anxious about whether their skillsets will stay relevant in an AI-first future, are taking AI adoption and innovation at work into their own hands.   

For the most part, shadow AI users aren’t doing the wrong thing per se. Most know what they shouldn’t paste into an unsanctioned tool but that doesn’t mean shadow AI is harmless. After all, as a technology or risk leader, you can’t manage the risk of AI if you don’t know it’s in use. So, do you know every tool your people are using? If not, now’s the time to find out.  

Ideally, keep it simple and do what you’ve always done with an unknown: identify what’s in use, assess which of it’s worth cracking down on and control the rest. That’s AI risk management, and the good news is that there are specific Australian obligations that govern it.

What is shadow AI?

Shadow AI is any AI tool, feature or service used for work without the organisation approving it or knowing it’s in use. It’s just the AI version of shadow IT, which has been around forever. New tools change how work gets done, and people adopt them before the IT policy catches up. 

The difference this time is speed. Shadow AI only needs one person and a browser tab – no credit card or IT ticket. That means it can go completely unnoticed by traditional shadow IT detection methods.   

Also worth noting is that it turns up in more places than chatbots. Developers wiring an AI API into an internal script to meet a tight deadline. Teams building a workflow in a free tool because the approved one took six weeks to get through procurement. Those are just two examples, and a variation of them exists in almost every organisation today.  

Shadow AI isn’t all personal employee accounts either. A growing share of it exists within approved tools – going under the radar as a result. Over the last few years, software vendors have added AI features such as writing and design assistants, meeting summarisers and data agents. Amid more widespread AI hype, a lot of these arrived in an update without much fanfare outside of a vendor webinar no decision-maker attended. If nobody in your organisation decided to turn it on after checking what it can access, that’s still shadow AI. 

How common is shadow AI? Jobs and Skills Australia’s Our Gen AI Transition report (August 2025) cites two Australian surveys from 2024. Deloitte Access Economics found about 27% of workers were using generative AI secretly at work, and Fusion Digital Agency found 21% of white-collar workers were. A Salesforce and YouGov survey of 1,293 Australians, run in May 2026 and published in June, put it higher: 56% of workers who use AI on the job rely on tools their employer didn’t provide or approve. Each survey sampled a different group, so the figures aren’t directly comparable. But they still all tell you the same thing. Shadow AI use is now a normal way of working. When your organisation can’t meet employees’ demands for the tools they think they need to do their jobs, they’ll reach for their own. Yet in the case of AI, unmet demand doesn’t mean the security implications go away.

What risks does shadow AI create?

Shadow AI risks come in three kinds: data leaving the organisation, an incomplete risk register and decisions informed by unreviewed output. 

Shadow AI risk 1: data leaves the building, and sometimes the country.

Whatever goes into a prompt goes to a third party. Depending on the tool and its settings, that data can be stored, read by a human or used to train a model. 

 If sensitive data like customer records, source code, board papers and an unsigned contract end up in a shadow AI tool, that’s a problem, especially if your organisation has data privacy expectations. Data sovereignty obligations matter here too. If an AI tool is owned by an overseas company, your data could end up in that company’s jurisdiction, even if the tool itself is hosted in Australia.  

AI tools take the friction out of a lot of menial, time-consuming tasks – including data leakage, whether accidental or malicious. AI data leakage is a security risk you should be actively aiming to curb, even if you don’t yet have an official AI risk management policy.   

 Shadow AI risk 2: an incomplete risk register 

You wouldn’t put your name to an AI risk register that’s treated as complete when you know it isn’t. But if shadow AI tools exist in your organisation, that’s exactly what you’re doing – even if you can say you didn’t know.  

Every risk assessment, vendor review and policy decision rests on an inventory of approved tools. Most likely shadow AI isn’t on it because, officially, it doesn’t exist. At best, that means your risk register is unreliable and missing key risks. At worst, those risks materialise and you’re left explaining how they slipped past the keeper. 

Shadow AI risk 3: decisions being made on output nobody checked.

Imagine this: a contractor makes a critical mistake that has disastrous consequences. You interview the contractor to find out what went wrong, and you trace the mistake back to a subcontractor you didn’t know they had. 

Your third-party risk management policies hopefully wouldn’t let that happen. But it’s exactly what’s happening every day with shadow AI. An AI summary that leaves out a key contract clause. A forecast built on a figure the model made up. A script that deletes the wrong rows. The point here is not just to say “always review AI’s work” as AI can and will make mistakes. That’s one thing, but a mistake that originated from a shadow AI tool is another. When someone asks where it came from, there’s no record, no reviewer and no owner.  Of all the generative AI risks, this is the hardest one to explain afterwards, whether to a customer, a board or a regulator.

Which Australian obligations does shadow AI put at risk?

Shadow AI puts four Australian obligations at risk: the Privacy Act’s rules on sending personal information overseas, the Notifiable Data Breaches scheme, and for APRA-regulated entities, CPS 234 and CPS 230. If the Privacy Act covers your organisation, the first two apply. If you’re APRA-regulated, all four apply.  

For most organisations 

Start with the Privacy Act. Australian Privacy Principle 8 (APP 8) says that before an organisation discloses personal information to an overseas recipient, it must take reasonable steps to make sure the recipient handles the information the way the Act requires. The organisation stays accountable for what the recipient does with it.  

Paste a customer’s details into a consumer AI tool hosted overseas and you’ve just disclosed personal information to an overseas recipient. If it’s a shadow AI tool and therefore your organisation didn’t know it was happening, it means no one took reasonable steps to control it. Seeing “hosted in Australia” on the vendor’s website doesn’t settle it either. Many Australian-hosted products send the prompt to an overseas model for the answer.  

Then there’s the Notifiable Data Breaches scheme. If personal information in a shadow AI tool is retained, exposed or used in a way the organisation didn’t authorise, that can be an eligible data breach. In this case, the impacted organisation has 30 days to assess whether serious harm is likely. If it is, they must notify the Office of the Australian Information Commissioner (OAIC) and the people affected as soon as practicable. Additionally, an exposure draft released for consultation on 31 August 2026, not yet law, would replace “as soon as practicable” with a fixed 72 hours to notify the Commissioner, counted from the moment the organisation has reasonable grounds to believe an eligible breach has occurred. Not knowing the tool was in use isn’t an exception, or excuse, for not acting fast enough. 

 For APRA-regulated entities

APRA-regulated organisations such as banks, insurers and super funds carry two further obligations. 

CPS 234 expects information security controls to cover the information assets actually in use. This includes assets managed by third parties and doesn’t distinguish between approved and unapproved. A material information security incident must be reported to APRA as soon as possible and within 72 hours of the organisation becoming aware of it. Shadow AI makes both of these obligations harder to meet. An AI tool holding customer data that nobody assessed is a control gap hiding in plain sight. That means an incident inside it is less likely to be noticed in time, and more consequential as a result. 

CPS 230 goes a step further. A shadow AI service a team has built into a critical process can meet the definition of a material service provider. That is, one your organisation relies on for a critical operation, or that exposes it to material operational risk. Those providers must be identified, managed and listed in a register submitted to APRA every year. A provider the organisation doesn’t know it has can’t be on that register, which is the kind of gap a supervisor knows to look for.  

 For everyone, in theory

The government’s Guidance for AI Adoption, published on 21 October 2025 as the update to the 2024 Voluntary AI Safety Standard, carries no penalty. Its first three practices are: deciding who is accountable, understanding impacts and planning for them and measuring and managing risks. Shadow AI fails all three – and that’s before you go any further into the standard. While the standard is voluntary, it’s increasingly guiding the expected answers in procurement questionnaires and board papers. So, it’s worth understanding your obligations. Of course, the standard applies to any AI tool you’re using. But it should act as a prompt (pun intended) to rein in any shadow AI use. 

How do you run a shadow AI audit?

 A shadow AI audit is an exercise that helps you understand if (or more likely, what and how much) shadow AI is running in your organisation.  

Who should run a shadow AI audit? For most organisations, your IT team is best-placed. Who should own the results of the audit? When the results come out, your Risk team should own the outcome. That is, what was uncovered and what to do about it.  

 How long should a shadow AI audit take? For a mid-size organisation with one IT function, plan on two to four weeks, and plan on being surprised. A shadow AI audit involves six exercises, run in order of effort. The cheapest, most automated ones come first, then the ones that need people to run them follow.  

 1. Expense and subscription data  

Owner: Finance team. 

Time: 1-2 days  

Process: Search card statements and expense claims for AI vendors. This finds the paid tools, and while that’s usually only the smaller part of the problem, it’s a good place to start.   

2. DNS and proxy logs 

Owner: IT 

Time: About 1 week 

Process: Filter the last 90 days for AI domains. This shows which free web tools are in use and how often, but not what was pasted into them. It also assumes logging is already on. If it’s not, jump to steps 4 and 5 and come back. 

 3. Endpoint and browser extension inventory

Owner: IT

Time: Alongside the logs

Process: Pull installed extensions and desktop apps from device management. Of course, this applies to managed devices only – personal devices are invisible here. 

4. Admin consoles of licensed suites

Owner: IT

Time: 1 day

Process: Open Microsoft 365, Google Workspace, Salesforce and whatever tools your organisation uses, and check which AI features are switched on by default. Logs and expense data will never show these, because the licence was already approved years ago. 

 5. A no-blame staff survey 

Owner: HR/People and Culture

Time: 1-2 weeks

Process: Ask what people use, for what and why the approved option didn’t work. Say up front that nobody gets in trouble for answering honestly – and mean it. This is the only step that tells you why your teams are using shadow AI. You’ll need that insight for what comes next in the process. 

 6. Team lead conversations

Owner: IT/Risk

Time: Last

Process: Take the findings to each team lead to confirm them, fill the gaps, and find the tools that didn’t show up in any of the previous reviews because they existed on unmanaged personal devices. 

Note: The timeline assumes you’ve got an IT function and a managed fleet. Several IT functions, an outsourced helpdesk or a lot of unmanaged devices will stretch them. 

How do you assess which shadow AI use is actually risky? 

A mistake many organisations make after a shadow AI audit is to treat every finding the same and introduce a blanket ban. Most of what the audit finds will be low risk, and restricting use will only cause a dip in productivity from staff used to using those tools.  

To separate genuine AI risk reduction from unnecessary friction to your team’s established workflows, ask these two questions of each tool: 

• What class or type of data goes into it?  
• Does anyone hold an agreement with the vendor that says what happens to that data?

The agreement must be a document someone in your organisation signed (or agreed to) and holds. It should cover data use, training on inputs and where the data is hosted.  

Shadow AI use by data classification

Your organisation should have its own data classification policy, so treat the below as general guidance.  

Public information (published website content, job ads, annual reports): allow with or without an agreement. The information is available to anyone anyway, so if it helps your team get the job done faster, there’s no benefit in restricting its use.  

 Non-confidential internal information (meeting agendas, staff FAQs, training material): also allowed. However, if there’s no agreement in place, exercise caution: make sure no customer names or dollar figures go into it.  

 Confidential information (contracts, pricing, source code, strategy): Only allow if there’s an agreement and someone in your organisation who owns it internally. If there isn’t, replace the tool with a sanctioned one. 

 Personal or regulated information (customer records, employee data, health, financial): Same as above. It needs an agreement and at least one of two things to be true: 

– No personal information reaches an overseas recipient anywhere in the chain (storage, inference, sub-processors, the vendor’s support staff). Australian hosting satisfies the first condition only if the prompt stays here too, so make sure the vendor doesn’t send anything to an overseas model.   

– The agreement covers data use, training and cross-border transfer well enough to meet the APP 8 reasonable-steps test.  

 Checking a tool against APP 8

 Overseas data transfer isn’t automatically a problem. You just need to make sure it complies with APP 8. 

To confirm an AI tool meets APP 8, ask these four questions of the vendor. As above, this assumes there’s an agreement in place, or you’re going to get one. 

• Who is the overseas recipient? 
• What can they do with the data? 
• Does the agreement bind them to handle it the way the Privacy Act requires? 
• Where is the decision documented? 

 The case that catches most organisations out is an AI feature that switched itself on inside a non-AI tool you license. Only allow this with conditions. Check what it can read (email, files, chat) and whether the existing agreement’s AI terms cover it. Many don’t or do only after a setting is changed or you’ve specifically requested it from the vendor. 

 If a prompt mixes classes, even just a little, assess it by the highest class. For example, a meeting summary with one customer’s name in it is personal information, whatever the rest of it is. Every decision goes into the AI risk register (what the register holds is in the control section below). A blanket ban skips all of this and only punishes the harmless majority. Worse still, it moves a potentially dangerous minority onto personal devices, where the next audit won’t see what they’re doing.

What if data has already gone out via shadow AI?

 Sometimes the audit finds AI data leakage that has already happened. If personal or regulated data has gone into a tool with no agreement, treat it as a suspected data breach. Here’s what you need to do – in order.  

1. Stop the use. Not the tool for the whole organisation, just that tool for that class of data, today. 
2. Keep the evidence. Export the chat history, keep the account and keep the logs. Don’t delete or cancel anything until you know what went in and when. While it might be tempting, don’t try and make the data disappear. It doesn’t change what happened and will make your breach notification obligations harder.  
3. Tell the privacy officer the same day. Whoever owns privacy runs the next steps. 
4. Assess against the Notifiable Data Breaches (NDB) test within 30 days. An eligible data breach is unauthorised access to, disclosure of, or loss of personal information that a reasonable person would say is likely to cause someone serious harm. The Privacy Act gives you 30 days from suspecting a breach to finish that assessment. 
5. Notify if it’s eligible. The OAIC and the people affected, as soon as practicable. Under the draft 2026 reforms, not yet law, that becomes a fixed 72 hours to notify the Commissioner from the moment you have reasonable grounds to believe it’s an eligible breach. 
6. If APRA regulates you, notify APRA too. CPS 234 states that APRA needs to hear about a material information security incident within 72 hours of you becoming aware of it.

Then go back to the audit. Assume you’ll find more potential breaches. In our experience, finding multiple breaches in a shadow AI audit is more likely than finding one in isolation. 

How do you bring shadow AI under control? 

 Bringing shadow AI under control can be a straightforward process. Crucially though, it depends on you giving people a sanctioned tool, alongside an AI usage policy. From there, you can confidently block what’s still high risk and keep a live AI risk register.  

 Give people a sanctioned tool. Meet the demand that pushed people to shadow AI in the first place. The survey told you what staff are doing with AI: summarising, drafting, writing code, transcribing calls. Provide an approved tool for each of those jobs with an agreement behind it and make it the easiest tool to reach for. If the approved option adds friction, they’ll keep reaching for the unapproved one – policy or no policy. 

 Write an AI use policy. This is your team’s quick reference guide for acceptable AI use, so a one-page policy is ideal. The policy should make clear what kind of information can go where, including what information can only go in AI tools with a current business agreement. Anchor it to the first three practices in the government’s Guidance for AI Adoption: who is accountable, what the impacts are and how risk is measured and managed. That’s what gives your policy standards procurement and your board can align with. If you’d like an AI policy template guide, reach out to us and we’d be happy to help you put one together.  

 Block narrowly, and last. Once a sanctioned path exists and the policy is out, blocking the remaining consumer tools at the proxy is a small, justifiable step. Where a shadow tool is already wired into a live process, assess the business impact before anyone switches it off. Treat the tool as an unplanned vendor and give it the same due diligence you’d apply to any other supplier.  

 Keep the AI risk register live. Name an owner. Tools change monthly, so re-run the log check at least quarterly. Record every tool’s data class, agreement status, hosting, review date and who owns it in your organisation. Give staff a way to request a new tool and answer in days, so the sanctioned route stays faster than the shadow one. That owner, process and register are also the starting point for ISO 42001, which is the management standard for organisations that use AI. While it’s still emerging, as AI use matures more customers are going to expect ISO 42001 certification. 

You might be thinking: We’ve got an approved AI tool. Should I just block shadow AI use? While tempting, banning shadow AI, especially before you’ve completed the steps above, is the wrong move. Blocking first will disrupt the way your team is used to working, impacting productivity and staff morale. At best, it just teaches people to hide their shadow AI use better. At worst, it pushes shadow AI use even further underground – which increases the chance something will go wrong.  

 Ultimately, your goal shouldn’t be to stop all use of shadow AI among your employees. That’s about as realistic as expecting every employee to bank with your organisation’s preferred bank. 

 Instead, the goal should be to adopt an AI platform that does all the jobs your employees need done – faster, better and easier than the ones they’re using. The survey told you what those use cases are. And there are enough enterprise-grade options available now that “there’s no tool we can approve that does this well” isn’t an excuse – for procurement or shadow AI users.

This is exactly what we’ve done at Interactive. We deployed an approved tool, one that covers as many use cases as possible. To ensure adoption, we’ve made a company-wide effort to get the entire team up to speed with, and confident in, using the tool. This also includes aligning AI adoption and literacy with staff performance goals and running workshops where team members share real AI use cases that have helped them do their job better. All this was designed to make our approved tool the most attractive one.  

As for shadow AI, we’ve not banned any tools. However, we have restricted their usage. We track the data that goes into unsanctioned models, using data classification labels to flag, and then block if sensitive data is used. The best part is that this all happens automatically and in the background. Team members using unapproved AI tools (responsibly) at work can still do so without any added friction.  

Where does sovereign or private AI fit?

Some of the concerns around using AI tools centre on where the data goes, broadly: does it stay in Australia or does it go somewhere else? Sovereign AI reduces that risk. Sovereign AI keeps the data, AI processing and operational control within Australia, under Australian law. This includes where the model runs, who can access the system and whether any data is exposed to overseas jurisdictions. 

Importantly though, “Australian-hosted” doesn’t mean sovereign. As we’ve mentioned already in this article, some AI products marketed as Australian-hosted keep your data here and send the prompt overseas to get the answer – that’s the part APP 8 cares about.  

So, to distinguish “sovereign” from “locally hosted, globally enabled”, ask three questions of any potential AI vendor:  

• Where does the model run? 
• Who are the sub-processors, and where do they operate? 
• Where do the vendor’s support staff log in from? 

If all three answers are Australia, there’s no overseas recipient, so you won’t get on the wrong side of APP 8. Like anything though, the least risky AI solution is private AI that keeps you in complete operational control.  

However, neither sovereign nor private AI impacts the other two risks – unchecked output still needs a reviewer and you’ll still need an AI risk register. But it does take the largest single risk off the table for your most sensitive, regulated data.  

If you’re looking for a reliable sovereign AI partner to host your private AI, we can help. Our sovereign private cloud gives you performance alongside regulatory assurance and control, and we can host it in our data centres in Melbourne, Sydney and Brisbane. 

Where to start

So, you want to get shadow AI under control, where do you begin? If you do one thing this week, ask three team leads where AI is already showing up, then check browser extensions and admin settings for the tools you already license. That will quickly tell you whether shadow AI is a few obvious apps, or something already embedded in day-to-day work. Also look at your existing vendor agreements to find out which ones have AI features that could be classified as shadow AI. 

 If, in discovering shadow AI in your organisation, you also discover that today’s productivity has become dependent on it, you’re not alone. That’s where many organisations are right now. The challenge is that productivity doesn’t remove the risk. If a tool is handling business, customer or regulated data, you still need to understand how it’s being used, what data it can access and whether the right controls are in place. The goal isn’t to stop useful AI work. It’s to bring it into view, manage the risk and give people a safer way to keep doing their job.  

 Our Data and AI Discovery Workshop can help. Our AI experts will come in to understand your organisation and help identify the AI use cases you shouldn’t have to live without. Then, we’ll give you a roadmap to bring those capabilities into your organisation. We can also help you through the full shadow AI discovery and audit process outlined above.  

To find out more or get started, contact our team.