Atlassian 是否正在用你的 Jira 数据训练 AI？8 月 17 日将发生这些变化

如果你是 Jira、Confluence 或 Jira Service Management 站点的管理员，Atlassian 很可能已经就新的“数据贡献”设置给你发过邮件。以下是它究竟意味着什么，以及在 2026 年 8 月 17 日之前你应该采取的行动。

将发生的变化： Atlassian 正在 Atlassian Administration（安全 → 数据贡献）中推出组织级别的控制项，用于决定你的元数据和应用内内容是否被用于训练 Atlassian 的 AI 模型、以及改进其在 Jira、Confluence、JSM 及关联 Platform 应用中的 AI 驱动功能。从 2026 年 8 月 17 日起，Atlassian 将根据这些设置——无论是你自行配置的，还是保留默认值——开始使用你的数据。

多数管理员容易忽略的一点： 你对此的控制权完全取决于你的套餐等级。只有 Cloud Enterprise 客户才能完全选择退出元数据贡献。其他所有等级——Free、Standard、Premium——都会自动贡献元数据，没有关闭的方式。无论你处于哪个等级，通常可以控制的是应用内内容：即便你无法彻底关闭该设置，也可以将特定的 Confluence 空间、Jira 项目或 Teamwork Graph 连接器排除在贡献范围之外。

实际应该怎么做： 前往 Atlassian Administration → Security → Data contribution，查看目前已配置的内容。确认你所在组织当前生效的最高套餐等级（它决定了你的默认设置——即使组织内任意一处存在一个 Enterprise 许可证，也会改变整个组织内的计算方式）。如果你的组织处理客户数据、受监管信息，或任何受数据处理协议约束的内容，请审慎地决定是否应将特定项目或空间排除在外，而不是被动接受默认设置。

这只是一个平台上的一项设置。如果你的组织还在使用 Slack、Notion、GitHub、Salesforce 或其他数十种连接的 SaaS 工具，每一个工具都在悄悄地替你做出同样的决定——有些提供可见的开关，有些（比如 Slack 的非生成式机器学习训练）根本没有开关，只能通过邮件申请退出。这种模式——真实的设置、真实的截止日期、真实的后果，却被埋在没人负责检查的管理面板里——正是 8200.dev 的连接器所要自动揭示的内容，覆盖你所连接的每一个平台，而不仅仅是这周恰好给你发邮件的那一个。

一个没人被指派去做的决定

先从 Atlassian 这个具体案例中抽身出来，看看这个问题的整体形态，因为它在各处不断重演。

每个构建 AI 功能的 SaaS 供应商都面临同样的问题：模型可以从哪些客户数据中学习？每个供应商的回答都不同，公布答案的位置不同，给予客户的控制程度也不同：

• Slack 默认使用客户消息和内容来训练平台级别的非生成式机器学习模型（搜索排序、推荐）。工作区设置中没有任何管理员开关——要退出，需要工作区所有者发邮件到 Slack 的反馈邮箱提出请求。
• Dropbox 提供一个“第三方 AI”设置，其默认值取决于你的账户所在地区：美国账户默认开启，欧盟、英国和加拿大账户默认关闭。两家拥有相同 Dropbox 套餐的组织，可能处于完全相反的状态却毫不知情。
• GitHub 按套餐划定界限：Business 和 Enterprise 客户的数据在合同上被排除在模型训练之外，而较低等级则受更宽泛的产品条款约束。同一个组织在迁移套餐等级时，其状态可能会悄然改变。
• Salesforce、Zendesk 和 Intercom 各自有不同的默认设置和退出路径——一个 Setup 页面、一张工单、一个工作区设置。
• Google Workspace、Microsoft 365、Notion 和 Box 则处于另一端：它们的条款以合同形式承诺客户内容不会被用于训练模型，因此没有开关，因为根本不需要。这是一种真正不同的立场——但你仍然需要了解它，并能够在审计时向审计员出示证据。

请注意这些案例的共同点：没有一个供应商提供可供查询“我的组织当前是否正在贡献训练数据？”的 API。 这种状态存在于合同中、邮件中、区域默认设置中、套餐等级中。它是真实存在的，有真实的后果，却对你的安全团队查看的每一个仪表盘都不可见。

这正是为什么“应该有人去检查一下”作为一项控制措施是失效的。根本没有地方可以去检查。这个决定默认由供应商的选择决定，而供应商的选择基于自身的利益考量。

这对合规意味着什么

如果你的组织持有 SOC 2 报告、正在推进 ISO 27001 认证，或依据 GDPR 处理个人数据，那么数据贡献问题绝不是可有可无的细枝末节——它直接落在你现有的义务范围之内。

数据处理协议描述了处理方可以将你的数据用于哪些用途。供应商用你的内容训练 AI 模型就是一种*用途*。如果你与客户签订的数据处理协议规定其数据仅用于提供服务，而你所连接的某个平台正悄悄将这些数据输入模型训练，那么你对下游做出的承诺与你在上游允许的做法之间的差距，需要由你来弥合——而不是供应商。

审计员已经开始就此直接提问。这个问题会以“你的任何分包处理方是否使用你的数据训练 AI 模型，你如何得知”之类的形式出现在供应商风险问卷中。一个站得住脚的答案包含两部分：*现状*（哪些平台会贡献数据，哪些在合同上被排除）和*决策记录*（谁审查过、何时审查、做出了什么选择）。“我们从来没查过”是唯一错误的答案。我们在 2026 年审计员对 AI 治理的实际要求 中更全面地讨论了审计员目前对 AI 治理的期望——数据贡献正在成为这项审查中的标准条目。

好消息是：这是少数几个真正修复成本很低的合规事项之一。无需重新架构任何东西。你需要做的只是*找到*这些设置、*刻意做出*决定，并*把决定记录下来*。

8 月 17 日之前的管理员检查清单

以下是在 Atlassian 截止日期之前需要执行的具体步骤，并做了通用化处理，以便你可以将其应用到你运营的每一个平台上：

1. 梳理覆盖范围。 列出你组织的内容或元数据实际存放的所有 SaaS 平台——不仅仅是 Atlassian。只要其中存有客户数据、受监管数据，或任何受保密协议约束的内容，就都在此范围之内。
2. 找到每个平台的数据贡献状态。 对于 Atlassian：Administration → Security → Data contribution。对于其他平台，控制项可能是一个设置页面、一张工单、一封退出邮件，或者是一条完全没有控制选项的合同条款。
3. 确认每个平台上你的套餐等级，尤其是在状态取决于等级的平台上。在 Atlassian 上，组织当前生效的最高套餐决定了组织内一切内容的默认设置。在 GitHub 上，等级决定了合同排除条款是否覆盖你。
4. 审慎地做出决定。 选择加入是一种合理的选择——更好的 AI 功能是真实的好处。真正的失败模式不是贡献数据本身，而是*没有人做出决定*的情况下发生了数据贡献。将存有敏感材料的项目和空间排除在外，其余部分如果这是你的选择，可以顺其自然。
5. 记录决定。 一条带日期的记录——谁审查过、配置了什么、原因是什么——能把一个默默无闻的默认设置变成可以交给审计员的治理证据。
6. 按计划定期复查。 供应商会更改默认设置、增加 AI 功能、移动设置位置。2026 年审查过一次的状态，并不等于 2027 年仍处于受管理状态。

如果这份清单看起来像是需要有人专门负责的工作——确实如此。这个问题的真实情况是，它*反复出现、跨平台、而且枯燥乏味*，而这恰恰是那种一旦依赖人类去记住就会悄悄失效的控制措施。

8200.dev 如何自动揭示这一切

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

在某些平台*确实*在相邻维度上暴露了可通过 API 读取的 AI 政策时，我们会实时进行检查：GitHub 连接器会读取你组织的 Copilot 公开代码匹配政策，GCP 连接器会检查 Vertex AI 是否在没有任何组织策略约束的情况下运行。每一项发现都附带循序渐进的修复指南，完整的检查项目录请见功能页面。

重点不在于 AI 功能本身是危险的。重点在于*数据贡献应该是一个决定，而不是一个默认设置*——无论是在 8 月 17 日之前的 Atlassian 上，还是在你组织已经在使用的其他任何平台上。如果你希望这个决定被自动揭示，而不是靠人工记忆，欢迎查看方案与定价，几分钟内即可连接你的第一个平台。