# Atlassian Is Changing Data Use for AI as of August 17, 2026: Your Checklist

> Everything about Atlassian

Source: https://www.xalt.de/en/blog/atlassian-changes-ai-data-use-checklist/

Everything about Atlassian's data contribution changes from August 17, 2026: timeline, plan defaults, governance, and a 6-step checklist.

Marcel Wänke Senior Atlassian AI Consultant at XALT · 28 April 2026 · 9 min

Atlassian is consistently expanding AI experiences such as Rovo. For AI to truly help in everyday life, it needs context – and context arises from patterns in usage. That is exactly why Atlassian is updating its data usage policies and introducing new, central settings for **Data Contribution**.

Important for you as an Atlassian Admin: This is not a "sudden siphoning off" of data, but a clearly announced step with lead time, protection mechanisms, and – depending on the plan – configuration options up to **Opt-out**. Your task now is to steer the topic towards compliance early on, understand the defaults, and prepare your organisation cleanly for the deadline of **17 August 2026**.

In this article, you will get the context plus a concrete checklist of what you should complete by autumn 2026.

## The Atlassian timeline for adjusting your settings

![Timeline of Atlassian’s changes to data use for AI](https://cdn.sanity.io/images/c475o02b/production/9f0c013edb929dd9e09e55dcd9ed4f73a50ca742-2560x697.png?w=1504&q=75&fit=max&auto=format)

## What you should avoid

In practice, the topic rarely fails due to technology – but rather due to governance and timing:

- **"We'll look at it later"**: The changes take effect from **17.08.2026**. Those who only check shortly before often no longer manage to achieve clean stakeholder alignment (compliance/data protection/security).
- **Misunderstanding of responsibility**: According to Atlassian's DPA, your **product settings** are legally binding, "documented instructions" to Atlassian. This means: Atlassian does not decide for you – but you must actively decide what should be allowed in your setup.
- **Unclear data terms**: Metadata, in-app data, de-identified, aggregated – many discussions go in circles because terms are not clearly separated.
- **Plan/trial pitfalls**: Defaults depend on the **Highest Active Plan** – including trial versions. A trial can therefore shift defaults without everyone being aware of it.

## The right approach: A two-track procedure

1. **Governance first** (clarify internally what is allowed): Which data may (de-identified and aggregated) contribute to product improvement – and which may not?
2. **Technology afterwards** (implement settings exactly): Check, document, and only apply your configuration finally after approval in **Atlassian Administration \> Security \> Data contribution**.

This keeps you action-oriented: You support AI innovations where they make sense and are compliant for you – and switch off where your guidelines require it.

## Your checklist: 6 concrete steps

### Step 1: Use the timeline and time windows correctly

[Atlassian communicates the transition with a clear roadmap](https://www.atlassian.com/trust/ai/data-contribution?utm_source=sfmc&utm_medium=email&utm_campaign=ACM-11618&jobid=107996203&subid=157395364):

- **16 April 2026**: Rollout of Data Contribution settings begins (phased).
- **19 May 2026**: Rollout completed, settings fully available.
- **17 August 2026**: Changes take effect (according to your selection).

Equally important in parallel: The framework (DPA) has been in effect since **October 2024** and describes the framework in which Atlassian acts as a Processor and you decide as the Controller.

**Governance note:** The DPA also enshrines a **72-hour standard** for “Security Incidents”: Atlassian informs the customer without undue delay and – where possible – at the latest **within 72 hours** of Atlassian becoming aware of an incident. This is a good trigger to review your internal incident response processes (Security/DPO/Legal) once: who receives the notification, who assesses, who escalates – and what evidence do you need for the audit?

**Practical tip:**Equally important in parallel: The framework (DPA) has been in effect since **October 2024** and describes the framework in which Atlassian acts as a Processor and you decide as the Controller. Plan for **at least 4–6 weeks** internally to reach a final agreement with Compliance/Data Protection – especially if multiple products/organisations/connectors are affected.

### Step 2: Separate metadata vs. in-app data for risk assessment

For a robust risk assessment, you must separate:

- **Metadata**: Content Attributes (e.g., readability scores, story points, due dates) + “Common Patterns”. Atlassian focuses on high-frequency patterns and omits unique/rare information.
- **In-app data**: Actual content such as page titles, Jira descriptions, comments.

Important in this regard: Before use, data is **de-identified** and **aggregated at the customer level**, so that it can no longer be attributed to individual users. In addition, Atlassian may retain this de-identified, aggregated data for up to **seven years** to observe trends and improve models.

**Important governance argument from the statement:** Atlassian commits technically and politically to **“Un-learn”**:

- If you opt out or delete an app, Atlassian commits to **retraining** models that were trained on this data.
- Removal from training sets: **In-app data within 30 days**, Content Attributes within **90 days**.

This is a key point in many compliance discussions, as it goes beyond "no more from now on" and also addresses "training data already used".

**Practical tip:**For security/compliance, it makes sense not to make a blanket assessment ("AI = no"), but rather **data-type-based**: metadata and content are often of different criticality in many companies.

### Step 3: Check your defaults – they depend on your plan (including trials)

A common aha moment: privacy defaults are coupled to the subscription model. Atlassian handles it as follows:

| Plan | Metadaten | In-App-Daten | Steuerungs-möglichkeiten |
| --- | --- | --- | --- |
| Free/Standard | Always shared | On (default) | In-app data can be disabled. Metadata cannot be changed. |
| Premium | Always shared | Off (default) | In-app data can be enabled. Metadata cannot be changed. |
| Enterprise | On (default) | Off (default) | Both settings can be enabled and disabled. |

Nuances that hurt in everyday life:

- **Trials count**: A premium trial can change defaults.
- **Downgrade from Enterprise**: You lose metadata control; Atlassian provides a **30-day review phase** before metadata is automatically enabled.

**Practical tip:**Record plan/trial events in your admin change log, as they indirectly influence "privacy defaults".

### Step 4: Use the 30-day "grace period" for new apps

When a **new app** is added to the organisation, Atlassian provides a **30-day grace period** before metadata or in-app data from that app is used. This is your window for a mini-PIA (Privacy Impact Assessment) and settings adjustments.

**Space exception:** This grace period does **not** apply to new spaces/projects within an app that is already contributing. Example: If Confluence is already set to contribute, a newly created space contributes immediately.

**Practical tip:**If you frequently create new spaces/projects (e.g., per team/programme), you need clear guardrails (naming, space templates, classification, possibly exclusions), not just a one-off settings decision.

### Step 5: Inform your compliance officer before you click

From an admin perspective, this is the "compliance-safe move":

- You inform the data protection officer (compliance/DPO) **proactively** about the planned data usage and the available settings.
- You finalise opt-in/opt-out only after **explicit instruction/approval**.
- Additionally important (and often forgotten): If you have “Authorized Affiliates” (subsidiaries/partners operating under your organisation), you, as the primary contracting party, are the **central coordination point**. Your organisation's settings therefore also bind their data.

**Practical tip:**Build a communication matrix: *Who needs to be informed (Compliance, Legal, Security, Data Owners, Affiliates)?* and *who gives final approval?*

### Step 6: Implement Data Contribution technically (and consider scope exceptions)

Depending on your plan, you can disable metadata and/or in-app data or exclude specific apps/spaces/teamwork graph connectors.

Practical example:

- Confluence contains much sensitive content → you define stricter rules for in-app data.
- Jira projects contain more structured tickets → you allow metadata contribution (or vice versa, depending on policy).

**Practical tip:** Treat this configuration as a security-relevant change:

- Change ticket
- Four-eyes principle (Admin + Compliance)
- Documentation in the admin manual
- Review date (e.g. annually or upon plan change)

https://youtu.be/-EJF6iQe4Dw

## Summary

- **Note the deadline:** On **17.08.2026**, Atlassian's data practices for AI/apps will change – with a prior rollout of settings from April/May 2026.
- **Your settings are legally relevant:** Your product configuration is (in the sense of DPA logic) your “documented instruction” – you must actively manage it.
- **Metadata ≠ In-App Data:** Only those who distinguish between data types can make a robust risk assessment.
- **Defaults are tied to the plan (including trials):** The highest active plan determines what is enabled by default and what you can change.
- **Best practice:** First align with stakeholders (compliance), then proceed with technical implementation, including documentation and review.

If you need support to set up your data contribution decision properly (stakeholder alignment, documentation, technical implementation, connector/scope design): **XALT** supports you pragmatically and compliantly from assessment to implementation.

[Your contact at XALT](https://www.xalt.de/en/contact/)

**In addition, Atlassian is offering a live webinar on April 28 and 29**. It covers, among other things, the scope of changes, protection mechanisms (e.g., de-identification & aggregation), and the practical configuration of data contribution settings in Atlassian Administration – including a Q&A with Atlassian experts.

[Register for the webinar now](https://www.atlassian.com/webinars/enterprise-cloud/data-contribution)

## Set up data contribution cleanly and compliantly

If you need help setting up your data contribution decision properly – stakeholder alignment, documentation, technical implementation, connector and scope design – XALT supports you from assessment through implementation, pragmatically and compliantly.

[Talk to us](https://www.xalt.de/en/contact/)

## More articles

### [Personal AI Agents Compared: Rovo, OpenClaw, and Agent SDKs Like Claude or OpenAI](https://www.xalt.de/en/blog/personal-ai-agents-compared-rovo-openclaw-and-agent-sdks/)

Rovo, OpenClaw, or Claude/OpenAI: how personal AI agents differ in 2026 and which approach fits your team.

*Atlassian*

### [BaFin Compliance for Atlassian Cloud – What Financial Institutions Need to Know Now](https://www.xalt.de/en/blog/bafin-compliance-atlassian-cloud-migration/)

New EU FSA rules have been in effect for Atlassian Cloud in financial services since December 2024. We show what has changed and how you can migrate to the cloud in a BaFin-compliant way.

*Atlassian*

### [Atlassian Team '26 Recap: The Shift to the AI-Native Organization and the Role of the Teamwork Graph](https://www.xalt.de/en/blog/atlassian-team-26-recap-teamwork-graph/)

XALT was on the ground at Atlassian Team '26 in Anaheim. Our recap covers the Teamwork Graph, Rovo, and the new Teamwork, Service, Product, Software, and Strategy Collections – and what it means for enterprises in Germany.

*Atlassian*

---

*This version is for AI agents. Every page of this site is available as Markdown: append `index.md` to its path. Index of all pages: [llms.txt](https://www.xalt.de/llms.txt)*