不存在的AI退出选项：我们核查了17个SaaS平台后的发现

你的企业所连接的每一个SaaS平台，此刻都在悄悄决定：你的内容是否正在训练别人的AI模型。我们核查了8200.dev连接器库中的全部17个平台，看它们实际是如何处理这个问题的——本以为会找到管理员开关。结果大多没有。

以下是我们的发现。Slack默认将每个工作空间纳入非生成式模型训练——管理控制台里任何地方都没有开关；要退出，需要工作空间所有者向[email protected]发送一封主题特定的邮件，且此操作无任何可日后核实的记录。Salesforce确实有一个设置，但它是埋在Setup深处的Einstein GPT开关，大多数管理员根本不知道要去哪里找——而且根据版本不同，要访问它可能还需要提交支持工单。Zendesk的做法则就是一张支持工单，仅此而已。Intercom的Fin AI在工作空间层面有退出选项，但它存在于界面中，而非API中——你控制台之外的任何人都无法验证它是否真的被设置了。

Dropbox是最有意思的案例：美国账户默认选择加入第三方AI功能；欧盟、英国和加拿大账户默认选择退出。同一产品，同一家公司，默认设置却截然相反，取决于账户注册地——而大多数团队从未核实过自己适用哪一种。WhatsApp Business同样分地区处理：欧盟、英国和巴西存在异议表单；其他所有地区，根本没有任何可操作的开关。

另一方面，有些平台确实完全不用你的内容进行训练——这是合同承诺，而非某个设置项：Google Workspace、Microsoft 365、Box、Notion和GCP都属于这一类。这令人安心，但这也不是你能在自己的管理控制台里点几下就能核实的东西——你只能相信供应商的承诺，而这个承诺埋在一份多数人从未读过第一页之后的数据处理协议里。

贯穿所有情况的模式是：除了Jira和少数几个相邻的AI功能开关（GitHub Copilot的公开代码匹配、GCP Vertex的组织策略）之外，几乎没有任何地方可以直接调用API获得一个明确的答案。这正是为什么这件事必须逐个平台、人工核查一遍——然后每次连接新平台时自动标记出来，而不是指望团队里有人已经读过了细则。

为什么"应该有人核查这个"这种想法悄然失效

这个问题持续溃烂，原因不是疏忽。而是通常的管控方式——指派给某个人，让他去检查——根本找不到该指向哪里。

再看一眼上面的清单，注意每一项的共同点：这种状态设置存在于仪表盘看不到的地方。存在于合同条款中。存在于注册时设定的地区默认值中。存在于采购上次续约时悄然改变的套餐层级中。存在于你必须写信申诉的邮箱地址里。在这些平台上，没有任何一个单一屏幕能回答安全团队真正需要知道的那个问题——*我的组织此刻是否正在贡献训练数据，而我们是否是有意做出这个决定的？*

于是核查被推迟，然后被遗忘，然后被继承下来。默认设置靠着这种消耗战获胜。而这个默认设置是供应商写的，服务于供应商自己的AI路线图，而非你的数据处理义务。这与我们此前针对单一平台探讨的情况如出一辙——参见Atlassian Jira在8月17日将发生的变化——只不过这次不止一个平台。而是每一个已连接的工具都在按自己的时间表、在自己隐蔽的角落做出类似的决定。

这是合规问题，不是猎奇话题

如果你的组织持有SOC 2报告、正朝ISO 27001迈进，或在GDPR下处理个人数据，那么数据贡献问题会直接落入你本已承担的义务之中。

数据处理协议描述了你的数据可被使用的目的。用来训练第三方AI模型是一种目的。如果客户的DPA声明其数据仅用于提供服务，而你所连接的某个平台正悄悄将同一份数据输入模型训练，那么你对下游的承诺与你对上游的许可之间存在的差距，需要由你来弥合——而不是供应商。审计员已经开始直接询问这个问题，通常以某种形式提出："你的任何分包处理方是否用你的数据训练AI，你如何知道？"一个能立得住的答案有两部分：状态（哪些平台参与贡献，哪些受合同排除）和决策记录（谁审查过，何时审查，做出了什么选择）。"我们从没查过"是唯一一个彻底不及格的答案。我们在2026年审计员对AI治理的实际要求一文中介绍了审阅方现在的期望；数据贡献正在成为这类审查中的一项标准条目。

现在就该跑一次的一次性审查

好消息是，这是治理事项中少数真正修复成本低廉的一项。无需重新架构任何东西。你需要找到设置项，做出有意的决定，并把决定记录下来。具体而言：

1. 盘点覆盖范围。列出你组织的内容或元数据实际存在的每一个SaaS平台。只要它承载客户数据、受监管数据，或任何受NDA约束的内容，就属于范围之内——不只是本周给你发邮件的那个工具。
2. 找出每个平台的态度。有时是一个设置页面，有时是一张支持工单，有时是邮件退出方式，有时是一条根本没有任何控制手段的合同条款。把它们所在的位置记录下来。
3. 确认所在层级。在若干平台上，这种态度取决于套餐层级——GitHub将Business和Enterprise数据排除在训练之外，而较低层级则受更宽泛的条款约束，一次迁移就可能悄然翻转你的状态。
4. 审慎决定。选择加入可以是一个合理的选择；更好的AI功能是实实在在的好处。真正的失败模式不是"贡献数据"本身——而是"没人决定的贡献"。把敏感内容排除在外，其余的如果这是你的选择，就随它去。
5. 记录下来，并按计划定期复查。一份带日期的记录，能把一个悄无声息的默认设置变成治理证据；而且供应商更改默认设置的频率之高，意味着审查过一次的状态并不等于被持续管理的状态。

对这份清单的真实描述是*循环反复、跨平台、枯燥无味*——恰恰正是那种一旦依赖人来记忆就会腐烂的管控措施。

我们对自己进行这项检查时是什么样的

2026年7月31日，我们打开了自己Atlassian组织的管理控制台，按照上述五个步骤逐一核查。精确地报告结果很重要，因为它是双向的。

组织层面的控制早已关闭。Atlassian Administration → Security → Data contribution提供了一个单一的组织级开/关选项——不是按产品分别设置——而我们的设置已是关闭状态，包含列表为空，所以没有任何内容被有选择地重新选择加入。无需修复。这正是良好默认设置，或早先良好决策，应有的样子。

但紧接着，那条控制项下方直接印着一句话：*"元数据始终被贡献。"*我们设置的那个开关管的是应用内内容——人们在工单和页面中写下的内容。元数据在其管辖范围之外，而在我们的套餐里，这个页面对元数据根本没有提供任何控制选项。我们的Jira订阅是Premium版；完整的元数据退出是Cloud Enterprise才有的功能。每个管理屏幕顶部都有一条横幅，标注了变更生效的日期：2026年8月17日。

所以，一个已经在付费层级上做出了审慎选择的组织，仍然无法完全退出——而唯一能了解到这一点的方式，是去阅读一个设置页面上它本没有特别理由去重新查看的一行正文。而Bitbucket和Trello则是单独计费的，完全不在那个页面范围之内；它们各自的状态如何，需要在另一个屏幕上另做核查。

这些都不是在指责Atlassian，它至少呈现了这个控制项、清楚说明了限制、并公布了日期。这正是本文的论点，在我们自己身上得到了证实：决定和它的局限存在于任何仪表盘都无法显示的地方，"我们把它关了"和"我们没有在贡献数据"并不是同一件事。

8200.dev如何自动发现这一切

8200.dev现在会为你连接的每一个平台生成一条AI训练状态发现项。连接Slack、Dropbox、Salesforce、GitHub，或其他任何受支持的平台，扫描结果就会紧挨着你的共享和权限发现项，告诉你：该供应商是否默认用你的数据训练AI、退出选项或合同保证存在于何处，以及这一状态上次得到核实的时间。默认选择加入的平台会作为需要决策的发现项呈现；合同保障安全的平台则会作为可以出示给审计员的证明呈现。

在平台确实在相邻维度上公开了可通过API读取的策略时，我们会实时核查：GitHub连接器读取你组织的Copilot公开代码匹配设置，GCP连接器会在Vertex AI在没有任何组织策略约束的情况下运行时发出标记。每一条发现项都附带一份分步整改手册，完整的核查项目清单在功能页面上可查看。

重点不在于AI功能本身是危险的——很多功能值得启用。重点在于，在你组织已经运行的每一个平台上，数据贡献应该是一个决定，而不是一个默认设置。如果你希望这一切被自动发现，而不是靠人工记住，请查看方案与定价，几分钟内即可连接你的第一个平台。