Is Atlassian Training AI on Your Jira Data? Here’s What Changes on August 17

If you admin a Jira, Confluence, or Jira Service Management site, Atlassian has probably already emailed you about new "data contribution" settings. Here's what it actually means, and what to do about it before August 17, 2026.

What's changing: Atlassian is rolling out organization-level controls in Atlassian Administration (Security → Data contribution) governing whether your metadata and in-app content are used to train Atlassian's AI models and improve its AI-powered features across Jira, Confluence, JSM, and connected Platform apps. Starting August 17, 2026, Atlassian begins using your data according to whatever these settings are — configured by you, or left on the default.

The part most admins miss: your control over this depends entirely on your plan tier. Only Cloud Enterprise customers can fully opt out of metadata contribution. Every other tier — Free, Standard, Premium — contributes metadata automatically, with no way to switch it off. What you can usually control, regardless of tier, is in-app content: you can exclude specific Confluence spaces, Jira projects, or Teamwork Graph connectors from contribution, even if you can't turn the setting off entirely.

What to actually do: go to Atlassian Administration → Security → Data contribution and see what's already configured. Confirm your organization's highest active plan (it determines your defaults — even a single Enterprise license anywhere in your org changes the calculation for everything in it). If your organization handles client data, regulated information, or anything covered by a data processing agreement, decide deliberately whether specific projects or spaces should be excluded, rather than inheriting whatever the default happens to be.

This is one setting, on one platform. If your organization also runs Slack, Notion, GitHub, Salesforce, or half a dozen other connected SaaS tools, each one is quietly making its own version of this same decision on your behalf — some with a visible toggle, some (like Slack's non-generative ML training) with no toggle at all, opt-out only by email. That pattern — real settings, real deadlines, real consequences, buried in an admin panel nobody's assigned to check — is exactly what 8200.dev's connectors are built to surface automatically, across every platform you've connected, not just the one that happened to send you an email this week.

The decision nobody was assigned

Step back from Atlassian for a moment and look at the shape of the problem, because it repeats everywhere.

Every SaaS vendor building AI features faces the same question: what customer data may the models learn from? Each vendor answers it differently, publishes the answer in a different place, and gives customers a different degree of control:

• Slack uses customer messages and content to train platform-level, non-generative machine-learning models (search ranking, recommendations) by default. There is no admin toggle anywhere in the workspace settings — opting out means the workspace owner emails Slack's feedback address and asks.
• Dropbox exposes a "third-party AI" setting whose default depends on where your account lives: on by default for US accounts, off by default in the EU, UK, and Canada. Two organizations with identical Dropbox plans can have opposite postures and never know it.
• GitHub draws the line by plan: Business and Enterprise customer data is contractually excluded from model training, while lower tiers are covered by broader product terms. The same organization can migrate tiers and silently change its posture.
• Salesforce, Zendesk, and Intercom each have their own defaults and their own opt-out paths — a Setup page, a support ticket, a workspace setting.
• Google Workspace, Microsoft 365, Notion, and Box sit on the other side: their terms commit contractually that customer content is not used to train models, so there is no toggle because none is needed. That is a genuinely different posture — but you still need to know it, and be able to point an auditor at it.

Notice what is common to all of these: not one of them exposes an API you can query to ask "is my organization contributing training data right now?" The posture lives in contracts, in emails, in regional defaults, in plan tiers. It is real, it has consequences, and it is invisible to every dashboard your security team looks at.

That is why "somebody should check this" fails as a control. There is no place to check. The decision defaults to whatever the vendor chose, and the vendor chose with its own incentives.

What this means for compliance

If your organization holds a SOC 2 report, is working toward ISO 27001, or processes personal data under GDPR, the data-contribution question is not optional trivia — it lands directly inside your existing obligations.

Data-processing agreements describe the purposes for which a processor may use your data. A vendor training AI models on your content is a *purpose*. If your DPA with a customer says their data is used to provide the service, and one of your connected platforms is quietly feeding that same data into model training, the gap between what you promised downstream and what you allow upstream is yours to close — not the vendor's.

Auditors have started asking about this directly. The question shows up in vendor-risk questionnaires as some variant of "do any of your subprocessors use your data to train AI models, and how do you know?" A defensible answer has two parts: the *posture* (which platforms contribute, which are contractually excluded) and the *decision record* (who reviewed it, when, and what they chose). "We never looked" is the only wrong answer. We covered what auditors now expect from AI governance more broadly in what auditors actually require for AI governance in 2026 — data contribution is becoming a standard line item in exactly that review.

The good news: this is one of the rare compliance items where the fix is genuinely cheap. Nothing needs re-architecting. You need to *find* the settings, *decide* on purpose, and *write the decision down*.

An admin checklist for August 17

Here is the concrete pass to make before Atlassian's deadline, generalized so you can run it against every platform you operate:

1. Inventory the surface. List the SaaS platforms where your organization's content or metadata actually lives — not just Atlassian. If it holds customer data, regulated data, or anything under NDA, it is in scope.
2. Find each platform's data-contribution posture. For Atlassian: Administration → Security → Data contribution. For others, the control may be a settings page, a support ticket, an email opt-out, or a contractual clause with no control at all.
3. Confirm your plan tier on each platform where the posture is tier-dependent. On Atlassian, your organization's highest active plan sets your defaults for everything inside it. On GitHub, the tier decides whether the contractual exclusion covers you.
4. Decide deliberately. Opting in is a legitimate choice — better AI features are a real benefit. The failure mode is not contribution; it is contribution *nobody decided*. Exclude the projects and spaces that hold sensitive material, then let the rest ride if that is your call.
5. Record the decision. A dated note — who reviewed, what was configured, why — turns a silent default into governance evidence you can hand an auditor.
6. Re-check on a schedule. Vendors change defaults, add AI features, and move settings. A posture reviewed once in 2026 is not a posture managed in 2027.

If that list looks like work someone has to own — it is. The honest version of this problem is that it is *recurring, cross-platform, and boring*, which is exactly the kind of control that silently rots when it depends on a human remembering.

How 8200.dev surfaces this automatically

8200.dev now raises an AI-training posture finding for every platform you connect. Connect Jira, Slack, Dropbox, GitHub, Salesforce, or any of the other supported platforms, and the scan tells you — next to your sharing and permission findings — whether that vendor uses your data for AI training by default, where the opt-out or contractual guarantee lives, and when that posture was last verified. Default-opt-in platforms surface as findings that demand a decision; contractually-safe platforms surface as attestations you can point auditors to.

Where a platform *does* expose an API-readable AI policy on a neighboring axis, we check it live: the GitHub connector reads your organization's Copilot public-code-matching policy, and the GCP connector checks whether Vertex AI is running with no organization policy constraining it. Every finding ships with a step-by-step remediation playbook, and the full check catalog is on the features page.

The point is not that AI features are dangerous. The point is that *data contribution should be a decision, not a default* — on Atlassian before August 17, and on every other platform your organization already runs. If you want that decision surfaced automatically instead of remembered manually, see plans and pricing and connect your first platform in minutes.