Effective August 17, 2026, Atlassian's updated terms allow customer metadata and in-app data — including Jira ticket text and Confluence content — to improve its apps and AI, on an opt-out basis. Here's exactly what's in scope, how to opt out, and the questions the toggle doesn't answer.

If you administer Jira, Confluence, or Jira Service Management in the cloud, this is a decision your organization is making in the next month whether anyone actively makes it or not. This post walks through what is actually in scope, what the safeguards cover, how to opt out, and the questions an opt-out toggle doesn't answer.

What's changing on August 17

According to Atlassian's notification email and supporting documentation, the change currently affects customers with an active plan or trial of Jira, Confluence, or Jira Service Management. Two categories of data are involved, and they are broader than the word "metadata" suggests.

What counts as "metadata"

Atlassian's metadata definition has two halves.

Content attributes are statistical characteristics and numeric fields derived from your data — things like the readability or complexity score of a Confluence page, task classifications assigned to content, semantic-similarity scores between pages, story points on a Jira work item, sprint end dates, and the SLA on a Jira Service Management request. Atlassian states these are de-identified and aggregated before use and don't contain health, location, workforce, or financial information.

Common patterns are derived from three kinds of in-app activity: search queries and results, prompts and responses in Rovo Chat, and configuration items you define, such as custom Jira fields and work item types. Atlassian extracts what is common across customers and omits low-frequency data that may be unique to your organization.

What counts as "in-app data"

This is the category that deserves your attention, because it is actual user content: the titles and content of Confluence pages, and the titles, descriptions, and comments of Jira work items — plus custom emoji names, custom status names, and custom workflow names.

In a service desk context, that means the free-text body of tickets. Password reset requests. HR cases. Security incident write-ups. Vendor disputes. The parts of your Atlassian footprint that were never written with a training pipeline in mind.

The safeguards — and their limits

Atlassian describes real safeguards: in-app data is de-identified and aggregated before use, with directly identifying information like names and email addresses removed. If you opt out, Atlassian commits to removing in-app data from its improvement datasets within 30 days and content attributes within 90 days, retraining any models previously trained on that data, and stopping new collection.

Two details are worth reading closely.

First, de-identified is not the same as non-sensitive. De-identification removes who said something. It doesn't change what was said — and a ticket describing an unreleased product, an ongoing security incident, or a personnel matter is sensitive because of its content, not its author line.

Second, retention: data that has been de-identified and aggregated at a customer level — including common patterns — may be retained for up to seven years.

How to opt out

Organization admins control this under Atlassian Administration → Security → Data contribution settings, with separate controls for metadata and in-app data. Two practical notes:

1. Availability of the settings varies by plan — verify what your plan actually exposes rather than assuming the toggle exists.
2. Document the decision. Whoever owns your next audit or DPA review will ask when the setting was checked, by whom, and what the organization decided about each data category.

What opting out doesn't solve

Opting out is the right immediate move for most organizations with sensitive ticket or page content. It is also worth being clear-eyed about what it is: a setting, not an architecture.

• It's a standing governance task. The setting exists per organization and needs re-verification whenever terms update, plans change, or new Atlassian apps are adopted.
• The default direction matters. Opt-out regimes mean the burden of protection sits with every customer, forever, rather than with the vendor once.
• Terms can change again. A toggle you control today is a paragraph in someone else's legal update tomorrow.

For some teams, the conclusion is that the setting is enough. For teams whose service desk holds genuinely sensitive content, the deeper question is whether data protection should depend on a checkbox at all.

The alternative posture: AI that never trains on your data

We'll be direct about where we stand, because this is the reason we wrote this post. Rezolve.ai does not use customer data to train its AI models. Not opt-out. Not de-identified-then-used. Not used.

Sidekick, our employee-facing AI, answers and acts by grounding in your knowledge sources — with citations — and every action runs through governed, approval-gated tools with a full audit trail. Your tickets, chats, and knowledge improve your service desk, and no one else's. That posture is backed by SOC 2 Type II, ISO 27001, GDPR compliance, and HIPAA-readiness — and it's how customers like MyEyeDr resolve issues in about ten minutes, with roughly 30% of issues never becoming tickets at all.

If your organization is reassessing where its service desk data should live ahead of August 17, we're happy to walk through what that looks like on your own tickets.

Before August 17: a five-minute checklist

• Locate Data contribution settings in Atlassian Administration and confirm what your plan exposes.
• Decide metadata and in-app data separately — they carry different risk.
• Document the decision, the date, and the decision-maker for your auditors.
• Put a recurring review on the calendar for every future terms update.
• If your tickets contain regulated or sensitive data, involve privacy and legal before the effective date — not after.