Executive Briefing by Exposure Security
Atlassian announced it will begin using customer metadata and in-app data from Jira, Confluence, and Jira Service Management (JSM) to improve its applications and AI experiences for all customers, effective August 17, 2026. This reverses Atlassian’s previous public position, which explicitly stated that customer data wasn’t used for AI model training. The announcement was made on April 16, 2026.
Atlassian is rolling out new organization-level settings in Atlassian Administration that let customers control their in-app data contribution. These settings are available gradually between now and May 19, 2026. However, the degree of control depends on your subscription tier, and certain data categories (metadata) can’t be opted out of on most plans.
To check your current plan tier, go to Atlassian Administration → Billing. Your plan tier determines your default data contribution settings and the level of control you have over them (see Default Settings by Plan Tier in the Full Analysis).
This change affects all Atlassian Cloud customers on any active plan, including trials. It initially covers data in Jira, Confluence, JSM, and their associated Platform apps (Rovo, Home, Teams, Projects, Assets, Goals, Analytics, and Administration). Atlassian said it will notify customers when settings become available for additional apps.
If you manage multiple Atlassian cloud organizations, each one must be configured separately. Each organization has its own data contribution settings, determined by its own highest active plan tier.
Free and Standard plans: default opt-in. Organizations on Free or Standard plans will have in-app data contribution turned on by default. Atlassian will begin using the content of your Jira issues, Confluence pages, and JSM tickets to improve its products unless you actively disable this setting before August 17.
Premium and Enterprise plans default to off for in-app data. Organizations on Premium or Enterprise plans will have in-app data contribution turned off by default. However, Premium customers can’t opt out of metadata contribution. Only Enterprise customers can disable metadata contribution entirely.
Metadata is always contributed on Free, Standard, and Premium plans. Regardless of your in-app data settings, metadata is always contributed on these plans. This setting can’t be changed. Organizations for which metadata contribution is a concern have one option: upgrade to Enterprise, which carries significant cost implications that should be weighed against the risk.
Trial plans count toward your defaults. Your defaults are set by the highest active plan in your organization, including active trials. If a Premium or Enterprise trial expires, your organization may revert to Free/Standard defaults, which would silently re-enable in-app data contribution. Monitor plan expirations accordingly.
Vendor risk assessment. Reversing a stated policy position is itself a risk signal. Organizations maintaining vendor risk registers should update Atlassian’s entry to reflect this change, particularly if data handling commitments were documented as part of the initial vendor assessment.
Until this announcement, Atlassian maintained a clear public position: customer data wasn’t used to train, fine-tune, or improve AI models. Their AI Trust page and support documentation explicitly stated this for both Atlassian’s own models and third-party providers (such as OpenAI) used by features like Rovo and Atlassian Intelligence. Their CTO reiterated this position publicly as recently as late 2025. The new data contribution model reverses that stance.
This change is separate from Atlassian Intelligence itself. Atlassian Intelligence (Rovo, AI-powered search, etc.) processes data on a per-request basis and, according to Atlassian, still doesn’t retain or train on those inputs/outputs. The new data contribution model instead covers a broader, ongoing use of your metadata and in-app content to improve Atlassian’s applications and AI experiences across all customers.
The practical question organizations should be asking: could Atlassian’s use of contributed data result in patterns, structures, or insights from one customer’s data surfacing in features or suggestions visible to other customers? Atlassian says it applies aggregation and de-identification, but hasn’t published the specific techniques used, and these safeguards haven’t been independently audited.
Your default data contribution settings are determined by the highest active plan in your Atlassian organization, including trials:
Metadata is described by Atlassian as usage telemetry and structural information about how your organization uses Atlassian products. Atlassian hasn’t published a precise list of what this includes. It likely covers project names, workflow configurations, issue type distributions, user counts, feature usage patterns, and similar structural data. On Free, Standard, and Premium plans, this category can’t be opted out of.
In-app data includes the actual content of your Jira issues, Confluence pages, JSM tickets, and connected data from Teamwork Graph connectors. This is the category you can control via the new settings.
Important: If your organization has connected third-party data sources via Teamwork Graph (Google Drive, Slack, SharePoint, etc.), the in-app data contribution setting may extend to content pulled from those external systems. This significantly expands the scope beyond Jira and Confluence content alone. Review and exclude individual Teamwork Graph connectors as needed.
Your defaults are set by the highest active plan in your organization, including trials. If your organization is on a Standard plan and activates a Premium trial, in-app data contribution defaults to Off for the trial’s duration. When that trial expires, the organization reverts to Standard-tier defaults, and in-app data contribution silently re-enables to On. Atlassian says it will notify you and give you 30 days to review settings after a downgrade, but this requires active monitoring.
Organizations that configured data residency in Atlassian (restricting data to specific geographic regions) should determine whether contributed data stays subject to those residency constraints or gets processed elsewhere for AI improvement. This is particularly relevant for GDPR compliance and cross-border data transfer obligations. Atlassian’s documentation doesn’t currently address this interaction.
Organizations using Atlassian Guard data security policies (to restrict exports, block Marketplace app access, prevent public links, etc.) should determine whether those controls affect data contribution. Based on current documentation, data contribution settings appear to operate independently of Guard policies.
If your Atlassian instance contains data from clients, partners, or other third parties, contributing that data to Atlassian’s improvement pipeline may conflict with your contractual obligations or data processing agreements. This applies to both in-app data and metadata: even structural information like project names or workflow configurations could reveal client-specific details.
Atlassian hasn’t published clear guidance on how to verify that the opt-out took effect beyond checking the toggle in Atlassian Administration. Organizations should:
When you add a new app to your organization, Atlassian applies a 30-day delay before data from that app is contributed. This gives you time to review and adjust settings. However, when you add a new Confluence space to an existing app, data contribution begins immediately according to your current settings. IT Admins should communicate this distinction to teams creating new spaces and confirm that organization-level defaults reflect the desired posture.
This briefing is part of Exposure Security's ongoing executive intelligence series. For questions about how this applies to your organization specifically, contact us.