There is a specific kind of corporate announcement that buries the most consequential sentence three paragraphs in, after the part about how committed the company is to customer trust. Atlassian’s change enabling default data collection to train AI models follows that template closely enough to be a case study. The Hacker News thread hit 451 points, which tells you something about how the people who actually run these instances received the news.
The substance of the change is this: Atlassian turned on data collection for AI training by default across its product suite, meaning customer content in Jira, Confluence, Bitbucket, and related tools can be used to train Atlassian Intelligence models unless an administrator actively locates and toggles the relevant setting. The data includes the kind of content that lives in Jira and Confluence in the real world: internal engineering roadmaps, post-mortems, HR project tracking, customer-facing bug queues, and financial planning docs. This is not the kind of information companies consider generic.
Why This Is Different From the Consumer Case
The recurring criticism whenever a SaaS vendor does this is that opt-out consent is insufficient. The stronger version of that argument applies specifically to enterprise software, and Atlassian sits squarely in that category.
When a consumer product like a social network changes its defaults to allow AI training, the affected data is primarily personal posts, profile information, and engagement signals. Users agreed to terms of service individually and have at least nominal awareness that the platform monetizes their data. The relationship is direct.
Enterprise software operates differently. The data in Confluence was created by employees who have no direct relationship with Atlassian’s terms of service. A developer writing a post-mortem about a production incident is not thinking about whether that document will become training data for a vendor’s AI product. Their employer signed the enterprise agreement; they just used the tool. When Atlassian changes the default, the organization bears the obligation to understand what changed and act on it, while the employees who created the data remain unaware.
This is the same structural problem that made LinkedIn’s AI training opt-out controversy in 2024 genuinely serious rather than reflexive tech skepticism, and it is the same reason Slack’s announcement about training machine learning models on customer messages generated immediate legal scrutiny. In each case, the vendor shifted the burden of maintaining the prior state, which was the reasonable expectation of most customers, onto enterprise administrators who may not read product changelogs.
What Atlassian Intelligence Is Actually Building Toward
To be fair to Atlassian, the business logic here is not obscure. Atlassian Intelligence is a significant strategic bet. The product promises things like auto-summarizing Confluence pages, generating Jira issue descriptions, answering questions about project state, and providing inline writing assistance. These features, when they work well, genuinely reduce friction for teams drowning in ticket management and documentation upkeep.
Building those features well requires training data that reflects how people actually use these tools. Generic web-scraped text does not capture the idioms of Jira ticket writing, the structure of Confluence architecture decision records, or the patterns in how engineering teams track and resolve issues. Atlassian needs customer data to build a customer-data-aware product, and that is not an unreasonable product goal.
The problem is the mechanism. Opting in customers by default when training on their data is a shortcut that shifts real costs onto customers while capturing the benefit centrally. An opt-in model requires convincing customers that the benefit of contributing their data is worth it, which is harder. An opt-out model converts that hard problem into a settings page that most administrators will never find.
The Actual Risk Surface for Enterprise Teams
The practical concern for organizations with significant data in Atlassian products is not that Atlassian is malicious. It is that the training pipeline introduces data flows that the organization never audited, does not control, and may not be able to fully account for in compliance posture.
Consider a regulated industry like financial services or healthcare. The contents of a Confluence space often include information that is subject to data residency requirements, internal classification schemes, or regulatory obligations around third-party data processing. Enabling AI training changes what Atlassian does with that data, and that change may not have been cleared through your data processing agreements, your DPA addendum, or your GDPR Article 28 controller-processor analysis.
For teams in the EU, this is not a hypothetical risk. Transferring personal data, including the names and comments of employees visible in Jira tickets and Confluence pages, to a training pipeline that may involve infrastructure or subprocessors outside the approved transfer mechanisms is a compliance event. It requires documented assessment, and the fact that Atlassian changed the default means that organizations previously in compliance may no longer be unless they act.
What To Do Right Now
If your organization uses Atlassian Cloud products and you have not explicitly reviewed this setting, the first step is locating it. In Atlassian’s admin panel, this is typically under the organization-level settings related to Atlassian Intelligence and data sharing. The exact path depends on which tier you are on; enterprise plans with Atlassian Access tend to have more granular controls.
The second step is treating this like any other third-party data processing change: review what was enabled, assess whether it conflicts with your data classification policies or existing DPA terms, and document the decision either to opt out or to accept the new terms knowingly.
The third step, which most organizations skip, is establishing a process to catch these changes before they become incidents. Atlassian is not the last vendor that will do this. The pattern, which has now repeated with LinkedIn, Slack, GitHub Copilot’s training discussions, and Atlassian, is that AI training capability becomes a default feature rather than a deliberate choice. Vendors have strong incentives to do this and weak incentives to make it prominent. The organizational countermeasure is periodic review of product changelogs and terms, specifically watching for language around AI, training, and data sharing.
The Defaults Problem Is the Product
There is a version of this story where the headline is “Atlassian builds AI using customer data, provides opt-out.” That headline is accurate and boring. The reason the Hacker News thread generated friction is that the interesting version of the story is about defaults and what they signal.
Defaults encode assumptions about what is acceptable. When a vendor defaults to off for AI training, they are signaling that this is an active choice customers should make knowingly. When they default to on, they are signaling that participation is the expected state and non-participation is the exception. That framing, more than the data collection itself, is what enterprises should push back on.
The leverage point for enterprise customers is the contract, specifically the DPA and the renewal conversation. If enough large customers make this a condition of renewal, vendors adapt their defaults. This has happened before with data residency requirements, with SOC 2 audit access, and with encryption standards. The vendors who defaulted to the wrong side of those debates eventually moved, not because they changed their minds about what was acceptable, but because the commercial pressure made the right default easier than the wrong one.
Until then, admins: check your settings.