On August 17, Atlassian begins using content from Jira and Confluence to train its AI systems — by default, across all pricing tiers. The change affects roughly 300,000 businesses worldwide. For most teams, it means the work product stored in those tools becomes training data unless someone actively opts out before the deadline.
This is not a minor policy clarification. It’s a material change to how one of the world’s most widely deployed project management platforms uses the data it holds.
What Atlassian Is Collecting
Atlassian distinguishes between two categories of data for this policy change, and the distinction matters.
In-app content is the first category. This includes Jira issue titles, descriptions, and comments — the actual text of work items, bug reports, feature requests, and tickets. It also includes the body of Confluence pages: documentation, decision records, meeting notes, architecture diagrams described in text, and anything else written into the product.
This is the category that’s arguably the most sensitive, and it’s the one all customers can opt out of before August 17.
Metadata is the second category. This includes aggregated, de-identified signals about how the products are used: readability scores, story point distributions, task classification patterns, SLA performance metrics, and common search query structures. It does not contain the content of tickets or pages — just signals about how they were used.
For metadata, opt-out is only available to Enterprise-tier customers. Free, Standard, and Premium plans cannot turn off metadata collection.
Why Work Data Is More Sensitive Than It Looks
The scope of what lives in a typical Jira or Confluence deployment is easy to underestimate.
Jira tickets routinely contain client names, internal project codenames, budget constraints, security vulnerabilities, competitive intelligence, and staff performance details. A bug ticket might describe a security flaw in an unreleased product. A backlog item might name a customer whose data was affected by an error. Sprint notes might include discussion of an acquisition that hasn’t been announced.
Confluence often holds more. Architecture decision records explain exactly how a system is built. Post-incident reports document the root cause of outages. Hiring decision documents capture reasoning about specific candidates. Onboarding guides detail the internal systems of organizations.
None of this content was created with the expectation that it would be processed as training material for an external AI system. But that’s the expected destination after August 17 unless you change the setting.
The OpenAI Connection
Atlassian’s sub-processor list confirms that some AI processing routes through third parties, including OpenAI. The exact scope of what data flows to which sub-processor depends on which Atlassian AI features are active, but the AI training pipeline is documented as flowing data to the United States.
This has specific implications for Atlassian’s data residency customers. Atlassian offers data residency options that keep certain data at rest in the EU, Australia, or other regions. The data residency commitment applies to stored data — not to the AI training pipeline. In other words, you can have your Jira data hosted in Frankfurt and still have it processed in the United States for AI training purposes.
For organizations whose data residency choices were driven by compliance requirements rather than preference, this is a meaningful gap to understand.
What Actually Gets Trained On What
Atlassian is building two primary AI products that use this training data: Rovo and Rovo Dev.
Rovo is a knowledge assistant designed to surface answers from across the Atlassian product suite. It uses content from Confluence pages and Jira history to respond to questions about projects, past decisions, and institutional knowledge. The better the training data, the more accurate the answers — and content from real customer deployments is what makes training effective.
Rovo Dev extends these capabilities specifically to software development workflows, helping with code review, PR descriptions, and development planning. Its training benefits from real Jira tickets, sprint data, and technical discussion found in Confluence engineering documentation.
The relationship is direct: what’s in your Jira and Confluence feeds into the accuracy of these AI features, including when those features are deployed for other customers.
How to Opt Out Before August 17
The opt-out process is available to all pricing tiers for the in-app content category. An organization admin needs to:
- Go to admin.atlassian.com
- Navigate to Security → Data contribution
- Turn off in-app data collection
This must be done before August 17. Data already collected before that date is not automatically deleted when you opt out.
One important point: the opt-out applies at the organization level, not the user level. Individual contributors cannot opt out of their own content being used — that decision belongs to whoever administers the Atlassian instance. If you’re an individual contributor and want to know whether your organization has opted out, you’ll need to ask your admin.
What Metadata Collection Means for Non-Enterprise Plans
For customers on Free, Standard, or Premium plans, there is no opt-out for the metadata category. Atlassian collects aggregated signals about how the tools are used — patterns that improve AI feature quality without using the literal content of your tickets.
In isolation, de-identified aggregated metadata carries lower privacy risk than the content of your Jira tickets. But “lower risk” is not “no risk.” Aggregated behavioral data across millions of teams can reveal competitive patterns, productivity benchmarks, and organizational signals that were not intended to be shared.
This version of the policy change is also ongoing. Opt-out of in-app content is a meaningful and actionable step available to all tiers; ongoing metadata collection becomes the baseline for non-Enterprise plans going forward, unless Atlassian changes course.
The Broader Pattern
Atlassian is not unique. A growing number of software platforms have changed their defaults to enable AI training on user content, often with minimal friction at the time of the policy change. The pattern is consistent: the capability launches, the policy update appears in a changelog or settings page, and customers who want to stay out have a window to act.
What varies is the opt-out window, the granularity of control, and what happens to data already collected when someone opts out.
Atlassian’s handling is more transparent than some: it has documented what it collects, distinguished between content and metadata, and provided an opt-out path for in-app content across all tiers. But the default — training on unless opted out — places the burden on administrators to take action, and most won’t.
What This Means for Personal Data in Business Tools
The Atlassian change is primarily about business data, but a significant amount of personal information lives in business tools.
Bug reports mention customers by name. Ticket discussions reference specific employees. Meeting notes capture what specific people said. Onboarding documentation describes individuals and their access levels. Under GDPR, this constitutes personal data, and its processing for AI training requires a lawful basis. Atlassian’s position is that AI training falls within its legitimate interests under GDPR — a legal basis assessment that will be tested as EU regulators work through AI Act compliance alongside existing GDPR obligations.
For anyone who stores sensitive personal files — not just work data but personal documents, private notes, or individual records — the Atlassian situation is a useful reminder that the terms under which data is stored can change, and the default setting on those changes often favors the provider.
If you keep personal documents or sensitive files in tools built for collaboration, those files inherit the privacy posture of that platform. The safer approach is to separate what’s personal from what’s organizational, and keep the former somewhere designed for privacy rather than somewhere designed for team collaboration.