Shadow AI in approved software: what Atlassian Rovo shows

Shadow AI used to have a clear shape: employees paste confidential data into ChatGPT because the approved tools are too slow, and IT never hears about it. Gartner predicts that by 2030, more than 40% of organizations worldwide will suffer security or compliance incidents caused by unauthorized AI tools. Most organizations have a playbook for that by now: a policy, some training, an approved alternative.

That playbook assumes shadow AI comes in through a tool someone picked themselves, and more and more often it doesn't. The AI arrives by update, inside software IT signed off on years ago, and switches on in the collaboration tools, service desks and wikis your teams already use every day. Nobody broke a policy, so no policy flags it.

This second form of shadow AI is harder to spot and harder to govern, because the approval it runs under was given for something else. Atlassian Rovo, now running inside Jira and Confluence, is one of the clearest examples, and a good test for any AI governance policy: can you actually switch it off, and what applies as long as nobody touches the defaults? Below, we look first at what makes this kind of shadow AI different, then use Rovo as a practical example to show which features you can disable and which you can't, where your data goes, and which controls you have to set yourself.

Key takeaways

1. Shadow AI now has a second, quieter form

   The classic definition (unapproved tools, personal accounts) misses the case where software you approved long ago gains a new AI feature or new data access after approval, and nobody signs off on it again.

2. Rovo can be blocked per app, not per feature

   Admins can block whole apps, but Atlassian's own documentation offers no way to switch off a single AI feature inside one. Search, Chat and Create with Rovo stay available as long as any Jira app on the same site still uses Rovo.

3. Since August 17, 2026, Atlassian uses your data for its AI by default

   Only Enterprise customers can fully exclude both content and metadata. Among the subprocessors Atlassian lists for Rovo are Databricks and OpenAI, both located in the US.

4. Defaults widen what the AI can see, without anyone opting in

   Teamwork Graph's Microsoft Teams connector indexes every message by default, private direct messages included, unless someone narrows the scope during setup.

5. Enterprise controls exist, but the starting point stays the same

   App blocklists, IP restrictions, customer-managed keys and data residency all work. Someone has to configure them, and until then Atlassian's defaults apply.

6. AI sovereignty is decided at runtime, whatever the contract says

   A platform that makes AI switchable from the ground up, and controllable per model, answers the governance question differently from one that adds controls afterwards.

What is shadow AI? The second form most policies miss

What is shadow AI in the classic sense? Employees using AI tools that IT never approved, usually through personal accounts. How widespread that is shows up in the AI Governance Benchmark 2026, a June 2026 survey of 300 decision-makers at companies in Germany with 500 or more employees. Unapproved AI tools are used occasionally in 42% of those companies and frequently in another 34%. Only 9% ban external AI tools outright. For this kind of shadow AI, policies, training and approved alternatives do work, because the problem has a clear entry point: a tool someone outside IT picked.

An analysis published in August 2026, describes a second, quieter form. Approved software turns into shadow AI when its features, integrations or data access change after approval and nobody reviews the change. The approval becomes a snapshot, and it goes stale the moment the vendor switches on something new.

Rovo is a textbook case.

Many organizations approved Jira and Confluence years ago, and what they reviewed back then was ticketing and a wiki. Rovo came later, by update, and has been running under that old approval ever since. Obsidian Security counts this among the underrated risks. Across customer environments, it recorded almost 70,000 interactions between users and company data in just 30 days, all through AI features built into SaaS apps that had already been approved. Rovo is named as an example, alongside AI features in Slack and Zendesk.

What Atlassian Rovo does in Jira and Confluence

Rovo is Atlassian's AI layer across Jira, Confluence, Bitbucket and the rest of its cloud products. Jira Rovo and Confluence Rovo are the same layer, showing up in different places. Three parts of it matter for governance. Rovo Search looks across every connected system and answers questions directly instead of returning a list of hits. Rovo Chat and Rovo Studio let teams build their own AI agents that create tickets, summarize Confluence pages or trigger workflows. Teamwork Graph sits underneath: it links content from every connected source, so the agents have something to answer from.

That last part is what makes Rovo more than a search feature.

Through connectors, Teamwork Graph also pulls in outside sources such as Microsoft Teams. So the scope of what the AI sees wasn't settled when you bought Jira and Confluence. It grows with every connector someone switches on later.

What you can switch off, and what you can't

So can you switch off the AI in Jira and Confluence? Partly. According to Atlassian's admin guide, Rovo can only be blocked for whole apps: "Blocking an app will disable all current and upcoming AI features for that app." The guide has no option for turning off a single AI feature inside an app you keep using.

Even the block has gaps. Block Rovo for one of several Jira apps, and AI-powered Search, Chat and Create with Rovo stay available as long as another Jira app on the same site still has Rovo enabled.

Atlassian does offer controls, most of them on the Enterprise plan only:

• App blocklists and allowlists: you decide which apps Rovo may run in at all.

• IP restrictions: Rovo is only reachable from networks you approve. This also covers external tools that connect to Rovo through the Model Context Protocol (MCP), the open standard that lets outside tools plug into an AI system.

• Customer-managed keys: you hold the keys your data is encrypted with.

• Data residency: you choose the region your data is stored in.

• Atlassian-hosted models only: Rovo then uses only models Atlassian runs itself, instead of those from outside providers.

• Rovo agent controls: you decide what individual agents can access.

With these, Rovo can be fenced in properly. None of them is on from day one, though. Until someone sets them up, Rovo runs in the default state Atlassian chose.

Teamwork Graph's Microsoft Teams connector shows how far from safe that default can be. According to Atlassian's own documentation, it indexes every Teams message by default, private direct messages and private channels included, unless someone narrows the scope during setup. You can change which teams and channels get indexed later. How far back it reads messages can only be set at setup.

Where your Jira and Confluence data is processed

Since August 17, 2026, the stakes are higher. Atlassian now uses metadata and content from Jira and Confluence to improve its apps and AI features such as Rovo. On the Free and Standard plans, this is on by default for both kinds of data. On Premium and Enterprise, only metadata is on by default. Customers on Free, Standard and Premium can't opt out of metadata use. Only Enterprise customers can exclude both metadata and content entirely.

Who handles your data along the way is set out in Atlassian's list of subprocessors. For Rovo, it names Databricks as infrastructure for developing and training machine learning models, and OpenAI and Google Vertex AI as generative AI providers, among others. Databricks and OpenAI are listed with a US location, Google Vertex AI with locations in the US, the EEA and Asia. According to Atlassian, the outside model providers may not use your data to train their own models, and they work under zero data retention agreements, meaning they don't keep it.

Whether this data use is compatible with the GDPR is still legally unresolved, in the view of several advisors, partly because Atlassian may shift from processor to controller here: from handling data on your behalf to deciding for itself how it gets used. As of October 2026, we found no statement on Rovo specifically from any European data protection authority, the UK's ICO included. For now, your legal team has to assess the question itself, starting with your data processing agreement with Atlassian and your organization's data contribution settings.

For organizations operating in the EU, the AI Act adds another layer. Since August 2, 2026, the transparency obligations in Article 50 apply. Put simply, people must be able to tell they're dealing with an AI, and AI-generated text, images or video must be labeled as such in a machine-readable way. The obligation falls mainly on the providers of these systems, Atlassian in this case, and could apply to Rovo Chat and Rovo Agents. No regulator has yet spelled out how it applies to Rovo.

What this means for your AI governance

Every Rovo risk in this article comes with a switch, and none of them is flipped for you. Atlassian's defaults apply until someone in your organization changes them. In most organizations nobody has, because the last time anyone reviewed Jira and Confluence, Rovo didn't exist yet. That is the shadow AI pattern from the start of this article: the approval is a snapshot, and Rovo arrived after it was taken.

So review Rovo the way you would review any new AI tool someone wants to bring in:

1. Where does it run? List the apps Rovo is active in and decide which ones it should run in.

2. What can it see? Check every Teamwork Graph connector that's switched on, and its scope, starting with Microsoft Teams.

3. What happens to your data? Check your data contribution settings and the subprocessor list, and have legal compare both against your data processing agreement.

4. Who owns the answer? Ask Atlassian how Rovo meets its Article 50 obligations, and write the answer and a named owner into your AI policy.

The list also shows why a contract alone doesn't settle the question. Your data processing agreement covers what Atlassian promises to do with your data. It can't tell you whether someone connected Microsoft Teams last spring and kept the default scope. That gets decided in the admin console, by whoever did the setup. Control over AI is something you verify in the running system, one setting at a time.

We hear the same thing from organizations that have already worked through this. Over the past two months, we talked with three large organizations, and their requirements were almost identical. AI processing runs on their own infrastructure, data leaves only in periodic exports that someone reviews first, and sensitive data stays in their own systems. In all three cases, this was a fixed rule of their IT governance.

There are two ways to get there. One option is sovara, the European alternative to Jira and Confluence that we build at rready. Moving costs a one-off migration effort, set against a license model up to 30% cheaper than comparable Atlassian setups. Which path costs less depends on your current plan and user count.

In sovara, no AI connection is active until you set one up, so there are no defaults to go back and fix. You decide where AI requests go: a secure cloud, a model you host yourself, or European providers such as Aleph Alpha and Mistral AI. Or you leave AI off entirely. AI tools reach sovara's data through the Model Context Protocol, the same open standard mentioned above. That gives you one defined connection to control, instead of AI features spread across every app. If you pick a model from a US provider, that provider's jurisdiction still applies. What changes is that you made the choice, and you can see that you made it.

sovara deserves the same scrutiny this article applied to Atlassian. The platform as a whole is certified to ISO/IEC 27001:2022 and externally audited. That certificate covers rready's information security management system and makes no separate statement about the AI layer. Whether that's enough for your use case belongs in the security review you'd run on any vendor before signing. The details are in rready's Digital Sovereignty Trust Center.

Whichever platform you choose, the test from the start of this article still applies: what happens when nobody touches the defaults? Ask it of every vendor, us included.

FAQ

What is shadow AI?

Shadow AI is AI used at work without IT's approval. In its classic form, employees use tools like ChatGPT through personal accounts. In its second form, software that is already approved gains AI features or new data access after approval and nobody reviews the change, which is what happened with Atlassian Rovo in Jira and Confluence.

Can you disable Rovo in Jira and Confluence completely?

Per app, not per feature. Admins can block whole apps, but Atlassian's documentation offers no way to switch off a single AI feature inside one. AI-powered Search, Chat and Create with Rovo stay available as long as any Jira app on the same site still uses Rovo.

Does Atlassian use our Jira and Confluence data to train AI?

By default, yes, since August 17, 2026: metadata on every plan, content on Free and Standard. Only Enterprise customers can exclude both. According to Atlassian, outside model providers such as OpenAI and Google don't receive the data to train their own models.

Does the EU AI Act apply to Atlassian Rovo?

Possibly, for Rovo Chat and Rovo Agents, through the Article 50 transparency obligations in force since August 2026. No regulator has yet applied that obligation to Atlassian specifically.