Atlassian Starts Training Rovo on Your Jira and Confluence Data Today

Sophie Laurent Legal & Compliance Lead, YuSMP Group · EU regulatory frameworks, GDPR, DORA, NIS2 and AI Act compliance for software teams

The short answer

What data Atlassian is collecting

Atlassian separates the collection into two categories with different opt-out rights.

Metadata covers derived signals: readability scores, task type classifications, story points, sprint end dates, SLA values, and semantic similarity scores produced by the Teamwork Graph. Atlassian states this data is de-identified before use and safeguards are in place to prevent re-identification. The company argues metadata is already aggregated and anonymized, which is why it treats opt-out as a Premium/Enterprise feature rather than a baseline right.

In-app data is more sensitive: Confluence page titles and body text, Jira work item titles, descriptions and comments, custom status names, and workflow names. This category includes content that may contain client names, product roadmaps, security findings, and other confidential project information depending on how your teams use Jira and Confluence.

Data is retained for a maximum of seven years. After an opt-out, in-app data is deleted within 30 days and metadata within 90 days.

Opt-out rights by plan tier

The tiered structure means the organizations most likely to hold regulated data — those on Free or Standard plans, often smaller companies, startups, or cost-conscious FinTech and HealthTech teams — have the least control. Enterprise-tier customers, who typically have dedicated compliance teams and legal review, are given full control by default. The asymmetry is worth flagging to your vendor management process: a tool used for roadmap planning or security backlog tracking may be on a plan that does not align with the sensitivity of its content.

What it means for US & EU software teams

Why the GDPR question is not trivial

GDPR Article 6(4) sets out a compatibility test: when a controller wants to process data for a new purpose not covered by the original consent or lawful basis, it must assess whether that re-use is compatible. Training a commercial AI assistant on project management data is a materially different purpose from the operational use for which the data was created. EU software teams — and their customers whose data flows into Jira tickets — may need to revisit whether their current lawful basis extends to this re-use or whether a Data Protection Impact Assessment update is required.

Teams seeking structured guidance on this analysis should consider a formal EU AI Act and GDPR compliance review, particularly if Jira or Confluence handles personal data belonging to EU data subjects.

DORA and NIS2 implications

Under DORA Article 28, financial entities in the EU must maintain a register of all ICT third-party service arrangements. Atlassian's policy change constitutes a material update to the nature of data processing under that arrangement. The register entry for Atlassian should now record the current AI training contribution status, the date the setting was reviewed, and who approved the decision. An exit-strategy clause addressing data used for model training — not only data extraction at contract termination — is now a best-practice addition to any Atlassian vendor agreement.

For teams subject to NIS2 security obligations, the change extends the supply-chain risk dimension: your operational incident data, SLA breach records, and workflow definitions now feed a vendor AI model. Documenting this in your supplier mapping is the minimum required step; teams operating critical infrastructure may need to escalate to their CISO before today's default takes effect.

US teams: IP and confidentiality considerations

US software teams operating under SOC 2 or contractual confidentiality obligations should audit whether their Jira and Confluence instances contain data covered by client NDAs, security audit findings, or unreleased product specifications. Atlassian states data is de-identified, but the definition of de-identification does not eliminate IP-exposure risk for highly specific technical content. Teams building software for regulated industries — FinTech, HealthTech, Defense — should review their client contracts for provisions restricting third-party AI training on project data before the opt-out window closes.

What to do now

• Log into Atlassian Administration today. Navigate to Security → Data contribution and record your current settings. This is the fastest check, takes under two minutes, and is the baseline for any subsequent compliance action.
• Identify your plan tier and the gap. If your organization is on Free or Standard and holds regulated, confidential, or client-owned data in Jira or Confluence, the metadata collection is non-negotiable without a plan upgrade. Decide whether that trade-off is acceptable or whether a tier upgrade is warranted.
• Classify content sensitivity. Jira projects and Confluence spaces vary enormously in sensitivity. A public-facing product backlog is different from a security vulnerability tracker. Classify which spaces and projects contain regulated data and factor that into your opt-out decision.
• Run the GDPR Article 6(4) compatibility check. Document whether your current lawful basis extends to AI model training. If you have a DPIA that predates 2024, it almost certainly does not cover AI re-use. Update it or commission an addendum.
• Update DORA and NIS2 supplier registers. Record the change in your ICT third-party register. Note the date, the setting chosen, the plan tier, and the responsible admin. This record protects you in a supervisory review.
• Review client contracts. If you build software for clients and use Jira to manage that work, check whether any contract restricts feeding project data to third-party AI systems. Take corrective action — opt-out or renegotiate — before the contract obligation and the vendor default diverge.

Frequently asked questions