On August 17 2026, Atlassian’s updated cross-product terms take effect. Under the new clause, customer content created in Jira, Confluence, and other Atlassian products becomes eligible to be used for AI model training and improvement, unless an admin opts out.
If you’ve seen the headlines and want a clear summary of what’s actually changing and what your options are, this post is the practical guide. We have an obvious interest here — we make a Jira alternative — but the goal isn’t to push a migration. The goal is to lay out the facts so you can decide whether to opt out, negotiate, switch, or do nothing.
We’ll keep the source links inline so you can verify everything against Atlassian’s own documentation.
What’s actually changing
The change is in Atlassian’s cross-product terms, which apply across the Atlassian Cloud platform. The relevant clause grants Atlassian the right to use customer content — meaning what your team creates inside the products — to train and improve their AI models. Before August 17, this use was either narrower or required explicit opt-in (depending on the product); after August 17, it becomes opt-out by default.
Per Atlassian’s published guidance, this includes:
- Jira issue titles, descriptions, comments, and attachments
- Confluence pages and attachments
- Other product content (Loom recordings, Bitbucket pull request descriptions in some configurations)
- Associated metadata
It excludes:
- Data that’s already public
- Customers covered by separate enterprise data-protection terms (typically negotiated Enterprise contracts)
The full language is in Atlassian’s cross-product terms and the trust privacy hub. Read the source before making any decisions based on this post — terms change, and the version you read on the day you decide is the one that governs.
What’s actually at risk
The risk depends entirely on what’s in your Jira. For most product teams, it’s not nothing.
A typical Jira instance contains:
- Customer requirements and feedback summaries, sometimes verbatim from sales calls
- Internal discussions about prioritization, including who said what
- Security incident retrospectives and the details that led to them
- Vendor and integration choices, including the reasons you rejected alternatives
- Roadmap thinking — what you’re planning to build and why
None of this is uniquely sensitive in the way that, say, healthcare PHI is. But it is exactly the kind of context that would meaningfully improve a model’s ability to answer questions about how your company operates and what it’s planning to ship. That’s the point of training data, and that’s what’s being granted.
Whether that matters to you is a judgment call that depends on your industry, your competitive sensitivity, and your trust in Atlassian’s technical safeguards against training-data leakage.
Your four options
There are four real options. None of them is obviously correct for every team.
Option 1 — Opt out
The cheapest move. Per Atlassian’s published process, the opt-out is at the admin level: in your Atlassian admin console, go to Settings → AI features → Data usage, and toggle off the model-improvement option. The opt-out applies per product, so if you use Jira AND Confluence AND Bitbucket, you’ll need to repeat it in each. The UI may change — check Atlassian’s docs directly for the current path on the day you do it.
Trade-off: opt-outs depend on the vendor honoring them and on the user remembering to set them. If a new product launches inside Atlassian’s suite, the default will likely be opt-in. You’re permanently on watch.
Option 2 — Negotiate an enterprise contract
If you’re large enough to have an Atlassian Enterprise contract, the cross-product terms can be replaced by a negotiated agreement that excludes training. This is the cleanest legal position, but it requires real Enterprise spend and a procurement process most small product teams don’t want to take on.
Trade-off: cost. Enterprise pricing is several multiples of standard per-seat pricing, and the legal review burden lands on you.
Option 3 — Migrate
Move your backlog and active work to a system that doesn’t train on customer data, period. For some teams this is overkill; for others — particularly those in competitive markets or regulated industries — it’s the only acceptable answer.
Trade-off: switching cost. Migrating a working Jira instance with years of history is real work. Coexistence (running both for a few weeks) takes the edge off, but it’s not zero effort.
Option 4 — Do nothing
This is a legitimate choice if your Jira doesn’t contain anything you’d care about a model being trained on. Marketing teams, side projects, internal task tracking that doesn’t touch customer or competitive context — for these, the change may not be load-bearing.
Trade-off: precedent. The policy can be expanded in future updates, and you’ve established that you’re a team that doesn’t object.
How to export Jira data cleanly (48 hours)
If you decide to migrate, here’s the vendor-neutral path:
- Export issues. Atlassian provides a CSV export from the issue navigator (filter to “all issues,” then Export → CSV). For larger instances, the Jira REST API is the more reliable path — fewer truncation issues, full custom-field coverage.
- Export Confluence pages. Confluence Cloud has a space export that produces HTML or XML. For full fidelity, the XML export preserves attachments and inter-page links.
- Export attachments separately. CSV exports don’t include attachments by default. The REST API does, but you’ll need to script it. Budget half a day for an instance with substantial attachment volume.
- Capture the workflow context. Workflow schemes, custom field configurations, permission schemes — these don’t export cleanly anywhere. Document the ones that matter in a doc somewhere; rebuild only what your new system actually needs.
Most teams don’t actually need to migrate everything. The 80/20 is: active projects + the last 12 months of issues + a frozen archive of everything else.
What to look for in an alternative
If you’re evaluating where your data should live next, three questions matter more than feature parity:
1. The AI training policy, stated plainly. Look for explicit language: “we do not train on customer data, ever, on any tier.” If the policy is hedged, qualified, or buried in a sub-clause of the privacy notice, treat that as a signal. The clearest policies are short.
2. Data ownership and export. Can you export your data in a standard format on every plan, including the lowest tier? Vendors that gate export to Enterprise are betting you won’t leave; vendors that include it everywhere are betting on their product.
3. AI architecture. How does the AI feature work? Vendors that route your content through opaque credit meters and proprietary fine-tuning are a different category from vendors that call a third-party model via API where your content is used only for the immediate response. Both can be reasonable; you should know which one you’re choosing.
Bonus criterion if you use AI assistants like Claude, Cursor, or ChatGPT: does the vendor expose its data over MCP, so you can actually use those assistants against your product data? We’ve written about the difference between tool-MCPs and spine-MCPs — worth understanding the distinction before committing.
Where we stand
AIOProductOS doesn’t train on customer data, on any tier. All AI features use third-party foundation models (Anthropic Claude, Deepgram for transcription) via API — your content is used only to produce the immediate response, never for model improvement. The policy is at /ai-transparency; the full data protection posture is at /trust.
If migration is on the table, we have an honest /vs/atlassian-ai-training comparison with a calculator that shows the license-cost math both ways (Jira is cheaper on licenses alone at most team sizes — but the bundled stack changes the picture), and a Jira import flow that brings your issues onto the spine with the customer context attached.
If you’re staying on Jira and just want to opt out, the action is the admin toggle. Do it before August 17 if you’ve decided that’s the right call. The link from this post to Atlassian’s own guidance is the source of truth; we’re not it.
— Last updated June 28 2026. Atlassian’s policy may change; verify the current terms at atlassian.com/trust/privacy before making decisions.