The AI Opt-Out That Doesn’t Exist: What We Found Checking 17 SaaS Platforms

Every SaaS platform you've connected your business to is quietly deciding, right now, whether your content trains someone else's AI model. We checked all 17 platforms in 8200.dev's connector library to see how each one actually handles it — expecting to find admin toggles. We mostly didn't.

Here's what we found. Slack includes every workspace in non-generative model training by default — there's no toggle anywhere in the admin console; opting out means a workspace owner emailing [email protected] with a specific subject line, tracked nowhere you can verify later. Salesforce has a real setting, but it's an Einstein GPT toggle buried in Setup, not something most admins know to look for — and reaching it can require a support case depending on your edition. Zendesk's version is a support ticket, full stop. Intercom's Fin AI has a workspace-level opt-out, but it lives in the UI, not the API — nobody outside your admin console can verify it's actually set.

Dropbox is the most interesting case: US accounts are opted in to third-party AI features by default; EU, UK, and Canadian accounts are opted OUT by default. Same product, same company, opposite defaults, depending on where your account is registered — and most teams have never checked which one applies to them. WhatsApp Business is regional too: an objection form exists for the EU, UK, and Brazil; everywhere else, there's simply no lever to pull.

On the other side, some platforms genuinely don't use your content for training at all — it's a contractual commitment, not a setting: Google Workspace, Microsoft 365, Box, Notion, and GCP all fall here. That's reassuring, but it's also not something you can verify by clicking around your own admin console — you're taking the vendor's word for a commitment buried in a data processing agreement most people never read past page one.

The pattern across all of it: outside of Jira and a couple of adjacent AI-feature toggles (GitHub Copilot's public-code-matching, GCP Vertex org policies), there is almost nowhere to point an API and get a straight answer. Which is exactly why this has to be checked platform by platform, by hand, once — and then flagged automatically every time you connect a new one, instead of trusting that someone on your team already read the fine print.

Why "someone should check this" quietly fails

The reason this problem festers is not negligence. It is that the usual control — assign it to a person, tell them to check — has nowhere to point.

Look again at the list above and notice what every entry has in common: the posture lives somewhere a dashboard can't see it. In a contract clause. In a regional default set at signup. In a plan tier that changed the last time procurement renewed. In an email address you have to write to. There is no single screen, on any of these platforms, that answers the one question a security team actually needs answered — *is my organization contributing training data right now, and did we decide that on purpose?*

So the check gets deferred, then forgotten, then inherited. The default wins by attrition. And the default was written by the vendor, optimizing for the vendor's AI roadmap, not for your data-processing obligations. This is the same shape we walked through for one platform in what changes for Atlassian Jira on August 17 — except it isn't one platform. It's every connected tool making its own version of the decision, on its own timeline, in its own hiding place.

This is a compliance question, not a curiosity

If your organization holds a SOC 2 report, is working toward ISO 27001, or processes personal data under GDPR, data contribution lands directly inside obligations you already carry.

A data processing agreement describes the purposes for which your data may be used. Training a third-party AI model is a purpose. If a customer's DPA says their data is used to deliver 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 permit upstream is yours to close — not the vendor's. Auditors have started asking about it directly, usually as some form of "do any of your subprocessors train AI on your data, and how do you know?" A defensible answer has two halves: 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 answer that fails outright. We covered what reviewers now expect in what auditors actually require for AI governance in 2026; data contribution is becoming a standard line item in exactly that review.

The one-time audit worth running now

The good news is that this is one of the rare governance 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. Concretely:

1. Inventory the surface. List every SaaS platform where your organization's content or metadata actually lives. If it holds customer data, regulated data, or anything under NDA, it's in scope — not just the tool that emailed you this week.
2. Find each platform's posture. Sometimes it's a settings page, sometimes a support ticket, sometimes an email opt-out, sometimes a contractual clause with no control at all. Record where it lives.
3. Confirm the tier. On several platforms the posture is tier-dependent — GitHub excludes Business and Enterprise data from training while lower tiers fall under broader terms, and a migration can silently flip your posture.
4. Decide deliberately. Opting in can be a legitimate choice; better AI features are a real benefit. The failure mode isn't contribution — it's contribution nobody decided. Exclude what's sensitive, then let the rest ride if that's your call.
5. Write it down, and re-check on a schedule. A dated note turns a silent default into governance evidence, and vendors change defaults often enough that a posture reviewed once is not a posture managed.

The honest description of that list is *recurring, cross-platform, and boring* — precisely the kind of control that rots when it depends on a human remembering.

What it looked like when we ran this check on ourselves

On July 31, 2026 we opened our own Atlassian organization's admin console and walked the five steps above. Reporting the result precisely matters, because it cuts both ways.

The organization-level control was already off. Atlassian Administration → Security → Data contribution offers a single organization-wide On/Off choice — not one per product — and ours was set to Off, with an empty include-list, so nothing had been selectively opted back in. Nothing to fix. That is what a good default, or a good earlier decision, looks like.

Then there is the sentence printed directly beneath that control: *"Metadata is always contributed."* The switch we had set governs in-app content — the things people write in tickets and pages. Metadata sits outside it, and on our plan the page offers no control for it at all. Our Jira subscription is Premium; full metadata opt-out is a Cloud Enterprise capability. A banner across every admin screen carries the date the change takes effect: August 17, 2026.

So an organization that had already made the deliberate choice, on a paid tier, still could not opt out completely — and the only way to learn that was to read one line of body copy on a settings page it had no particular reason to revisit. Bitbucket and Trello, meanwhile, are billed separately and sit outside that page entirely; whatever their posture is, it is a different check on a different screen.

None of this is a knock on Atlassian, which at least surfaces the control, states the limit plainly, and publishes the date. It is the argument of this article, demonstrated on ourselves: the decision and its limits live where no dashboard shows them, and "we turned it off" is not the same as "we are not contributing."

How 8200.dev surfaces this automatically

8200.dev now raises an AI-training posture finding for every platform you connect. Connect Slack, Dropbox, Salesforce, GitHub, or any of the other supported platforms, and the scan tells you — right 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 hand an auditor.

Where a platform does expose an API-readable policy on a neighboring axis, we check it live: the GitHub connector reads your organization's Copilot public-code-matching setting, and the GCP connector flags when 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 isn't that AI features are dangerous — many are worth turning on. The point is that data contribution should be a decision, not a default, on every platform your organization already runs. If you'd rather have that surfaced automatically than remembered manually, see plans and pricing and connect your first platform in minutes.