The switch to review before August 17, Atlassian AI data contribution

AI 요약

• What happened: Atlassian completed the rollout of data contribution controls on May 19, with changed AI improvement data use scheduled for August 17.
  • Free and Standard plans have in-app data contribution on by default, while Premium and Enterprise start with it off.
• Boundary to inspect: Jira issues, Confluence pages, Rovo Chat, and Teamwork Graph connector data sit inside the policy surface.
• Builder impact: The question is no longer only "do not paste secrets into a model"; admins need to review organization defaults in admin.atlassian.com.
• Watch: Atlassian describes de-identification and aggregation, but metadata opt-out is available only to Enterprise customers.

Atlassian's AI data contribution controls are now available across the admin console. The controls matter because the underlying change is still ahead: on August 17, 2026, Atlassian says it will begin using customer metadata and in-app data to improve apps and AI experiences for all customers. That sounds like a routine policy update. For development teams, it is a prompt to inspect the default path from Jira tickets, Confluence design documents, Rovo Chat, and Teamwork Graph connectors into Atlassian's AI improvement loop.

The interesting part is not that Atlassian is adding AI features. Rovo, Rovo Dev, Teamwork Graph, and the Rovo MCP server already show where the company is taking its collaboration stack. Atlassian wants organizational knowledge to become searchable, explainable, and executable by AI agents. The deeper shift is that work data is no longer only context for the current tenant's search and answers. Under the new policy, some of it can also become product-improvement material across the platform, depending on plan, data type, and admin settings.

That makes this a governance story rather than a feature story. Enterprise AI competition is increasingly about who controls the richest work graph and under which defaults that graph can be used. Jira and Confluence are not neutral text buckets. They contain incident histories, product roadmaps, customer commitments, security discussions, planning tradeoffs, and the messy reasoning that sits between code and business decisions. When AI products become useful precisely because they see that context, the default data contract becomes part of the product.

The official Atlassian Trust page lays out the timeline in three steps. The company began rolling out data contribution settings on April 16, completed the rollout on May 19, and plans to apply the updated data use and customer terms on August 17. So this is not a retroactive surprise after data already moved under the changed rules. It is a review window. The practical question is whether organization admins, security teams, and development leaders use that window before the policy date arrives.

What is on by default

The core table in Atlassian's support material is about plan-based defaults. For Free and Standard organizations, metadata contribution is always on and in-app data contribution is on by default. Premium organizations also contribute metadata, but in-app data contribution starts off. Enterprise organizations start with metadata on and in-app data off, but Enterprise is the only tier that can disable metadata contribution. Atlassian notes that some organizations with compliance requirements may see different defaults, but this is the general baseline.

The detail teams can easily miss is "highest active plan." Atlassian says organization defaults are based on the highest active plan when multiple apps coexist in one organization. If Confluence is Free and Jira is Standard, the organization still has in-app data contribution on by default. If a Premium or Enterprise app is present, the default can change. This is not just a billing nuance. It means data policy is resolved at the organization layer, not by a single Jira project or Confluence space viewed in isolation.

That matters for mixed organizations. A development lead looking only at Jira may believe the team understands the relevant setting. A documentation owner looking only at Confluence may reach a different conclusion. But the actual contribution default may come from the organization plan mix, plus later project, space, app, and connector exclusions. AI data governance is becoming a cross-admin problem, not something any one product owner can infer from the tool they use every day.

The weight of in-app data

Atlassian's definition of in-app data is not just abstract usage telemetry. Its FAQ gives examples such as Confluence page titles and bodies, Jira work item titles, descriptions and comments, custom emoji names, custom Jira or Confluence status names, and custom workflow names. In a development organization, that data is rarely harmless filler. Ticket descriptions can include reproduction steps for customer incidents. Comments can carry product decisions. Confluence pages can hold architecture migration plans, security reviews, launch plans, and internal postmortems.

Atlassian does not say it will expose raw customer content or train a public model on original documents as-is. The company's explanation emphasizes de-identification and aggregation for contributed in-app data and metadata. It says directly identifying information such as names and email addresses is removed and that controls are applied to reduce re-identification risk. Those protections are important, but they do not fully settle the issue for enterprise work data.

The sensitivity of company data is not limited to personal identifiers. A project delay, a pattern of customer escalations, an internal service name, a recurring security weakness, or an unusually structured workflow can matter even without a person attached to it. Competitive and operational signals often live in the shape of the work itself. That is why "de-identified" is not the same thing as "not sensitive" when the source data is a company's operating memory.

Metadata is the other contested category. Atlassian describes metadata through content attributes and common patterns. Content attributes can include statistical or derived characteristics such as story point counts or Confluence page complexity. Common patterns can include search queries and results, Rovo Chat conversations, prompts and responses, and frequent phrases, keywords, or topics from custom configuration data. The documentation says low-frequency data that may be unique to an organization is excluded.

The dispute starts because this is wider than what many developers instinctively call metadata. It is not only file size, timestamp, author, and product usage counters. It can include derived patterns from content and interaction flows. One Hacker News commenter argued that Atlassian's "metadata" looks closer to a derived data product from customer content than to ordinary metadata. The wording was blunt, but the operational point is real. In AI systems, derived data can still encode useful and sensitive signals.

Rovo and Teamwork Graph widen the surface

This setting is not only about Jira and Confluence. Atlassian says the initial scope includes Jira, Confluence, and Jira Service Management, plus Atlassian Platform apps such as Rovo, Home, Teams, Projects, Assets, Goals, Analytics, and Administration. It also applies to some Teamwork Graph connectors configured by the organization. That extends the surface beyond the issue tracker developers already know.

Rovo's direction is to search organizational knowledge, summarize it, and let agents perform work across it. Teamwork Graph connects people, teams, projects, goals, content, and apps into an organizational knowledge graph. With the Rovo MCP server in the background, the connection surface between external AI clients and Atlassian work data also grows. In that architecture, a Jira ticket is not an isolated document. It is a node in a graph of people, projects, goals, conversations, and connected systems.

That is why the policy is important from an AI governance point of view. Older governance guidance often focused on writing discipline: do not put customer names into tickets, do not paste secrets into a document, do not expose sensitive spaces broadly. Those rules still matter, but they are no longer enough. Teams also need operational rules for organization-level defaults, product-level inclusion, space exclusions, connector exclusions, and the review period when a new app is added.

The question is not whether to ban AI tools or adopt them without friction. The real question is which data contract applies when the work graph becomes fuel for AI-powered search, recommendations, summaries, and agent actions. Useful enterprise AI needs context. Responsible enterprise AI needs a clear account of which context is used locally, which context contributes to product improvement, and who can change that boundary.

Why the community reacted sharply

The Hacker News thread about Atlassian enabling default data collection drew more than 600 points and over 100 comments. The strongest reaction was about defaults. Free and Standard customers have in-app data contribution on by default, and metadata cannot be disabled outside Enterprise. Atlassian says all customers can opt out of in-app data contribution, but the important part remains: an admin has to find the control and take action.

The second issue was visibility. The original HN post linked Atlassian's support page and said the setting was not visible in the author's instance. Other commenters shared email language saying Atlassian was rolling the opt-out control into the Admin portal through May. That lines up with the May 19 rollout-complete date. After that point, organization admins should be able to check the path through Atlassian Administration, Security, and Data contribution.

The third issue is the broad purpose phrase "AI improvement." Atlassian frames the change as a way to create better AI experiences, such as improving search relevance and understanding common tasks so products can provide better recommendations or next steps. That is plausible product work. But a development team sees Jira and Confluence as more than a UX signal source. They are ledgers of roadmap bets, outage response, security concerns, and customer-specific commitments. The community reaction comes from that gap.

AI tool cost is not only token price

When builders evaluate AI tools, the first questions often involve model price, latency, benchmark scores, context length, and coding performance. Enterprise AI has another cost center: data-boundary operations. Who owns the setting? Which defaults change by plan? What happens when a new app or connector is added? Do legal, security, and engineering teams interpret metadata and in-app data in the same way? The answers can matter as much as the model name.

Atlassian's documentation says a newly added app inherits the existing data contribution setting. Metadata and in-app data from that new app begin to be used after 30 days, giving admins a review window. New spaces are different: the documentation says metadata and in-app data from a new space are used from creation time. That small distinction is operationally large. AI data policy is not a one-time checkbox. It recurs whenever teams add products, spaces, and connectors.

Plan changes are another variable. Atlassian says it tries to preserve existing selections when a plan is upgraded or downgraded. But if an organization moves from Enterprise to Free, Standard, or Premium, it loses the metadata control that only Enterprise provides. If metadata was disabled at Enterprise and the organization moves down, metadata contribution can be turned on, with notification and a 30-day review period. Cost optimization, app consolidation, and procurement changes can therefore become AI data-control changes.

That is a practical risk for smaller teams too. Free and Standard defaults are easy to overlook because those organizations often lack a dedicated security operations function. They may also use Jira and Confluence precisely because the tools are convenient for early-stage roadmaps, customer feedback, and support triage. The data may be strategically dense even when the company is small. A plan label is not a sensitivity label.

What development teams should check now

This does not need to be exaggerated. The event is not a claim that Atlassian is publishing customer data, and the company documents de-identification, aggregation, access controls, and monitoring as safeguards. It also should not be minimized. "It is de-identified" is not enough to describe the business context embedded in Jira, Confluence, Rovo Chat, and connected work graphs.

The immediate checklist is concrete. First, identify the organization's highest active Atlassian plan and the actual data contribution defaults visible in the admin console. Free and Standard teams should assume in-app contribution may be on until verified. Premium teams should understand that metadata contribution remains on. Enterprise teams should decide whether metadata contribution should stay enabled rather than leaving the default untouched.

Second, decide which Jira projects, Confluence spaces, and Teamwork Graph connectors should be excluded from AI improvement data. Spaces containing product roadmaps, vulnerability analysis, customer incident records, unpublished contract details, acquisition planning, or compliance evidence may need separate handling. The right answer will vary by organization, but the decision should be explicit.

Third, update user guidance for Rovo Chat and search behavior. Atlassian's metadata definition can include common patterns from Rovo Chat conversations, prompts, responses, search queries, and results. That does not mean every prompt is treated as reusable text. It does mean the chat and search layer belongs in the policy conversation, not only the documents and tickets that users already recognize as content.

Fourth, attach the setting to an owner and a review rhythm. New apps, connectors, spaces, plan changes, and procurement renewals should trigger a data contribution review. Otherwise, a setting that looked acceptable in May can become wrong by August or after the next product expansion. AI governance fails quietly when nobody owns the boring defaults.

The default-setting era

This is not only an Atlassian issue. Microsoft 365 Copilot, Google Workspace Gemini, Notion AI, Slack AI, GitHub Copilot Enterprise, Linear, and other work tools are all moving toward the same center of gravity. The more useful an AI assistant becomes, the more it wants access to the work record. Vendors then try to turn patterns from that record into better search, recommendations, automation, and agent behavior. The differentiator is not simply which model they use. It is how they design defaults, controls, exclusions, auditability, and customer trust.

Developers used to ask AI vendors, "Which model powers this?" That question is still useful, but it is incomplete. The sharper questions are now about data flow. What is included by default? What can be turned off? What requires a higher plan to control? What happens when a new connector appears? Are prompts, search queries, derived patterns, and workflow metadata treated differently from page bodies and ticket comments?

Atlassian's May 19 rollout-complete notice makes those questions difficult to postpone. August 17 is not just a customer-terms date. It is a marker for Jira and Confluence being interpreted through the broader work-graph logic of the AI era. Better AI experiences need data. Better AI operations need defaults, exclusions, and review habits that match the sensitivity of that data. The switch lives in an admin screen, but the decision belongs in the development team's governance standard.