来源说明：

  1. StartupFortune（startupfortune.com，2026-10-12）—— 直接报道「Salesforce Turns Agentforce On By Default」，记录了Winter’27 GA于10月12日GA、管理员开关被移除的核心事实；已通过web_fetch直接访问原文确认。
  2. Salesforce官方Release Notes（help.salesforce.com/s/articleView，Winter’27）—— 官方确认适用范围（Lightning Experience + Enterprise/Performance/Unlimited/Developer Edition）和滚动启用时间线；PowerSchool 550+用户生产使用数据及Agentic Commerce Search转化率数据来源。
  3. Cryptobriefing（cryptobriefing.com，2026-09-28）—— 报道Salesforce Hyperagent在Slack的部署，Slack 200,000+付费客户覆盖规模；已通过web_fetch验证。
  4. Salesforce Investor Relations / SEC EDGAR —— FY27 Q2财报（截至2026年7月31日），Agentforce ARR 12亿美元数据来源。
  5. NIST AI RMF 1.0（nist.gov，2023）、GDPR Article 22（gdpr-info.eu）、EU AI Act（European Commission，2024-08-01）—— 监管合规引用，均为公开可查阅的官方原文。

2026年10月，全球数十万家企业的Salesforce管理员将面临一个他们从未主动做出的决定——他们的CRM平台已经搭载了一个自主运行的AI Agent系统，而这件事发生时，大多数人甚至没有收到一封明确的通知邮件。

这不是科幻小说的情节，而是Salesforce Winter’27版本更新的现实。当Agentforce从一个需要主动申请开通的高级功能，变成所有符合条件的Salesforce组织的”默认基础设施”，一场关于企业AI治理主权的结构性变革已经悄然启动。问题不在于Agentforce是否好用——Salesforce的财务数据已经给出了市场答案。真正的问题在于：当SaaS巨头替你按下AI开关，谁来承担随之而来的治理责任？

第一章：静默的开关——Winter’27如何将Agentforce变成”默认存在”

一个版本更新的分水岭

Salesforce的版本发布周期向来是企业软件行业的风向标。每年三次的季节性更新——Spring、Summer、Winter——通常意味着功能迭代、界面优化和性能改进，IT管理员习惯于在更新日志中快速扫描与自己工作相关的条目，然后按照既定流程完成测试和部署。

Winter’27打破了这个惯例。

根据Salesforce官方发布说明，Winter’27的核心变化之一是：Agentforce将对所有符合条件的Salesforce组织自动启用，管理员不再需要主动导航至设置菜单、填写申请表单、等待审批流程。[1] 这个变化看似是一次产品配置的调整，实质上是一次权力结构的重新分配。

在此之前，Agentforce的部署遵循典型的企业软件opt-in逻辑：企业评估需求，IT团队完成技术评估，管理员主动开启功能，业务团队接受培训后上线使用。每一个环节都有明确的决策节点，企业保留了完整的”进入控制权”。

Winter’27之后，这个流程被颠覆了。AI功能的默认状态从”关闭”变成了”开启”，企业的任务从”决定是否启用”变成了”决定是否关闭”。这不是文字游戏——在行为经济学中，默认选项具有强大的”惰性效应”。Richard Thaler和Cass Sunstein在《Nudge》中系统论证了这一点：在401(k)退休金计划中，将参与设为默认选项后，员工参与率从约49%跃升至86%。[2] 对于企业IT团队而言，这意味着Agentforce将在多数组织中以默认状态持续运行，除非有人专门花时间将其关闭。

Agentforce的商业背景：不是一个小功能

理解这次变化的重要性，需要先理解Agentforce在Salesforce战略版图中的位置。

这不是一个边缘功能的默认开启。Agentforce是Salesforce当前最核心的战略押注，是公司向”AI原生CRM平台”转型的核心载体。根据Salesforce在2026年8月发布的FY27第二季度财报（截至2026年7月31日），公司当季营收达到约103亿美元，同比增长约10%，创下历史新高。CEO Marc Benioff在财报电话会议中明确表示，Agentforce是本季度增长的核心驱动力，并透露Agentforce相关合同的年度经常性收入（ARR）已突破12亿美元。[3] 这个数字意味着Agentforce不是一个实验性功能，而是一个正在快速商业化的核心产品线。

在这种商业背景下，将Agentforce设为默认开启，是一个经过精心计算的战略决策，而非技术团队的随意选择。

“平台基础设施”的语义变迁

Salesforce在官方博客中将Winter’27的Agentforce自动启用描述为将AI能力”嵌入平台核心”。[4] 这个表述值得仔细解读。

当一个功能被定义为”平台基础设施”而非”可选工具”，它的治理逻辑就发生了根本性变化。基础设施是默认存在的，就像数据库、权限系统、日志记录一样——你不需要选择是否使用它，它就在那里，作为平台运行的底层支撑。

但Agentforce与传统基础设施有一个关键区别：它是自主行动的。传统的CRM功能——无论是工作流自动化、报表生成还是邮件模板——都是确定性的规则执行器，输入A产出B，行为可预测、可审计。Agentforce Agent则具备一定程度的自主决策能力，可以解读用户意图、调用工具、执行多步骤任务，甚至在某些配置下可以代表用户发送邮件、更新记录、触发工作流。根据Salesforce开发者文档，Agentforce Agent通过”Topics”定义能力范围，通过”Actions”执行具体操作，其行为由大语言模型驱动的推理引擎协调。[5]

将一个具有自主行动能力的系统设为”默认存在”，与将一个静态报表功能设为默认开启，在治理复杂度上有数量级的差异。这正是Winter’27变化的真正意义所在。

第二章：IT管理员的72小时——从发现到响应的真实挑战

发现时刻：当你意识到AI已经在运行

以下是一个基于公开技术文档构建的假设场景，用于说明管理员面临的典型挑战：

某家中型制造企业的Salesforce管理员，在Winter’27正式上线后的第一个工作日打开管理控制台。她注意到系统界面有些不同，某些功能入口出现了变化，Agentforce的相关面板开始出现在她的视野中。她意识到，在过去72小时里，她负责管理的Salesforce组织已经自动启用了一个AI Agent系统。

这个时刻，她面临的第一个问题不是”如何使用Agentforce”，而是”在我不知道的这72小时里，发生了什么？”

这个问题没有简单的答案。根据Salesforce官方管理员指南，Agentforce自动启用后，系统会基于现有的权限配置为Agent分配初始访问范围。[5] 这意味着Agent的数据访问权限，在某种程度上继承自现有的用户权限体系——而这个权限体系，最初是为人类用户设计的，而非为自主AI Agent设计的。

这一假设场景并非空穴来风。在Salesforce Trailblazer社区和Reddit的r/salesforce板块中，管理员对自动启用功能的担忧讨论已经持续数月，核心焦虑集中在”我不知道默认配置到底开放了什么权限”这一问题上。

管理员需要做什么：一份不轻松的清单

根据Salesforce官方发布说明和开发者文档，Winter’27 Agentforce自动启用后，管理员需要完成的关键任务包括以下几个维度：[1][5]

第一：权限边界审查

Agentforce Agent在执行任务时，会以特定的身份（通常是”Agent用户”或继承触发用户的权限）访问Salesforce数据。管理员需要明确：哪些对象（Object）、哪些字段（Field）、哪些记录对Agent可见？这个审查需要在现有的权限集（Permission Set）和配置文件（Profile）基础上，叠加一层”AI访问控制”的逻辑。

对于大型企业而言，Salesforce的权限配置往往经过多年积累，极度复杂。一个典型的企业Salesforce组织可能有数十个Profile、数百个Permission Set、数千个字段级安全配置。在这个复杂体系上，叠加AI Agent的访问控制审查，是一项需要数天甚至数周才能完成的工作。

第二：数据访问范围确认

AI Agent最敏感的能力之一是跨对象的数据关联访问——它可以同时读取客户信息、交易历史、沟通记录，并在这些数据之间建立关联，生成分析或采取行动。这种能力对业务价值极大，但对数据隐私的挑战同样极大。

管理员需要确认：哪些数据类型可以被Agent访问？是否包含个人身份信息（PII）？是否包含受行业监管约束的数据（如金融数据、医疗数据）？根据Salesforce Einstein Trust Layer的技术架构说明，该安全层提供了数据脱敏、提示词注入防护和审计追踪等功能，但其具体配置仍需管理员主动完成。[6]

第三：Agent行为边界设定

Agentforce的核心价值在于其”行动能力”——不仅能回答问题，还能执行操作。但这也意味着管理员需要明确定义：Agent被允许执行哪些操作？创建记录？修改记录？发送邮件？触发工作流？每一种操作权限都需要经过明确的授权和记录。

根据Salesforce开发者文档，Agentforce提供了”Topics”和”Actions”的配置框架，管理员可以通过这个框架限制Agent的行为范围。[5] 但问题在于：在自动启用的默认状态下，这些配置的初始值是什么？谁来验证默认配置是否符合企业的安全策略？

第四：审计日志与监控设置

传统的Salesforce审计日志主要记录人类用户的操作。AI Agent的操作是否同样被完整记录？记录的粒度是否足够支持事后审计？是否有告警机制能够识别Agent的异常行为？

Salesforce在其Trust Layer文档中声称提供了AI交互的审计追踪能力，[6] 但这些日志的格式、保留期限和导出能力是否满足企业合规团队的要求，仍需逐一验证。在大多数企业的现有IT治理框架中，这些问题都没有现成的答案。

能力缺口：擅长管人，不擅长管AI

企业IT团队在传统SaaS权限管理上积累了丰富的经验——用户生命周期管理、角色权限分配、访问日志审计，这些工作已经形成了成熟的流程和工具链。但AI Agent的治理，需要一套完全不同的思维框架。

传统权限管理的核心假设是：操作者是人类，行为是可预测的，异常可以通过规则检测。AI Agent打破了这三个假设：操作者是自主系统，行为具有一定的不确定性，异常的定义本身就需要重新界定。

更深层的问题是工具缺失。Gartner在2025年发布的AI治理技术成熟度报告中指出，针对企业SaaS内嵌AI功能的专项审计工具仍处于”技术萌芽期”（Innovation Trigger），距离主流采用至少还有3-5年。[7] 大多数IT团队使用的SIEM（安全信息和事件管理）系统、IAM（身份和访问管理）平台，都没有针对AI Agent行为的专项分析能力。这意味着即使管理员想要做好AI治理，他们手中也缺乏必要的工具。

第三章：Opt-out陷阱——”默认开启”背后的产品策略与治理困境

为什么SaaS厂商选择默认开启？

这个问题有一个直白的商业逻辑，但值得拆解其内部结构。

逻辑一：渗透率是AI商业化的核心指标

AI功能的商业价值，在很大程度上取决于实际使用率。一个被99%用户开启但只有1%真正使用的功能，和一个被1%用户主动开启的功能，在商业价值上有根本差异。通过默认开启，Salesforce可以将Agentforce的”技术可用率”瞬间提升至接近100%（对所有符合条件的组织），而这个数字可以直接转化为向投资者和分析师展示的”AI渗透率”指标。

Salesforce FY27 Q2财报显示Agentforce ARR已达12亿美元，[3] 在这个商业规模下，进一步扩大使用基础的压力是真实存在的。默认开启是实现这一目标最高效的手段。

逻辑二：平台粘性的重力效应

当AI功能成为平台的默认组成部分，企业的迁移成本会大幅提升。一个企业如果已经在Agentforce上积累了Agent配置、历史交互数据、工作流集成，切换到竞争对手平台的成本将远高于仅使用传统CRM功能的企业。默认开启是一种构建平台粘性的战略手段。这一策略在SaaS行业并非新鲜事——Microsoft将Teams捆绑进Microsoft 365的做法曾引发欧盟反垄断调查，其底层逻辑与Agentforce的默认开启如出一辙。[8]

逻辑三：使用数据的战略价值

AI系统的性能优化高度依赖使用数据。更多的用户交互意味着更多的训练信号，意味着模型性能的持续提升。默认开启实质上是在为Salesforce的AI能力建设提供更广泛的数据基础——当然，Salesforce在其数据处理协议中声明Einstein Trust Layer不会将客户数据用于模型训练，[6] 但聚合使用模式数据（如哪些Agent配置最受欢迎、哪些操作最常被触发）的收集仍在协议允许范围内。

治理责任的单向转移

默认开启策略最值得关注的治理含义是：责任归属的隐性转移。

在opt-in模式下，企业的决策链条是清晰的：IT团队评估功能，管理员主动开启，企业承担使用责任。这个链条中，”主动开启”是一个明确的决策节点，也是责任归属的锚点。

在opt-out模式下，这个锚点消失了。企业没有做出”使用AI”的主动决策，AI功能是平台自动启用的。但如果发生数据泄露、合规违规或AI决策错误，责任的归属将面临法律上的模糊地带。

NIST在2023年发布的AI风险管理框架（AI RMF 1.0）中明确指出，AI系统的部署方（deployer）对系统行为承担治理责任，无论该系统是主动部署还是由第三方平台自动启用。[9] 用更直白的语言说：如果你没有主动关掉这个功能，在法律和合规层面，这可能被解读为你默示同意了它的运行，并承担相应的责任。

这种责任转移在不同的监管环境下，具有截然不同的严重程度。

GDPR合规场景：欧盟《通用数据保护条例》第22条要求企业对涉及个人数据的自动化决策（包括AI决策）提供透明度保障，数据主体有权不受完全自动化决策的约束。[10] 当Agentforce默认开启并开始处理包含欧盟公民数据的CRM记录时，企业是否已经完成了必要的数据处理影响评估（DPIA）？是否更新了隐私政策中关于自动化处理的表述？这些问题，在大多数企业的默认状态下，答案是否定的。

金融行业监管场景：受SEC、FINRA约束的金融服务企业，对AI辅助决策有严格的记录和审计要求。FINRA在2024年发布的AI监管指引中明确要求金融机构对AI辅助决策保持完整的审计追踪和可解释性记录。[11] 当Agentforce开始参与客户服务流程，其行为是否被完整记录？是否符合监管机构对”算法决策可解释性”的要求？

医疗行业场景：受HIPAA约束的医疗机构，对AI处理患者相关信息有严格限制。即使CRM系统中存储的只是患者的联系信息，当AI Agent开始跨对象关联分析时，是否触及了受保护健康信息（PHI）的处理边界？美国卫生与公众服务部（HHS）在2024年的指引中已将AI系统对PHI的间接推断纳入监管范围。[12]

对立视角一：Salesforce的合理性辩护

公平地说，Salesforce的默认开启策略有其合理性辩护，且这些辩护不应被轻易驳回。

首先，自动启用不等于自动执行。 根据Salesforce开发者文档，自动启用的是Agentforce的”平台能力层”，而非预配置的、立即开始执行业务操作的Agent。管理员仍然需要主动配置Agent的Topics、Actions和部署渠道，才能让Agent真正开始执行业务任务。[5] 从这个角度看，默认开启更接近于”开启了AI的基础设施层”，而非”直接部署了一个自主运行的AI员工”。这是一个重要的技术区分——批评者如果忽视这一点，就会夸大实际风险。

其次，Salesforce提供了相对完整的管理员控制工具。 Einstein Trust Layer提供数据安全层，Agent Builder提供可视化配置界面，权限管理框架允许精细化的访问控制。[6] 与许多将AI功能以”黑箱”方式嵌入的SaaS平台相比，Salesforce在治理工具的透明度上做得相对领先。

第三，从用户价值角度看，降低AI采用门槛本身具有正当性。 大量中小企业缺乏专业的AI部署团队，如果AI功能始终停留在opt-in模式，这些企业可能永远无法享受AI带来的生产力提升。默认开启可以被理解为一种”普惠AI”策略，让技术红利不仅属于拥有专业IT团队的大企业。

对立视角二：企业自身的治理惰性

另一个不太舒适但必须面对的视角是：企业自身的治理惰性也是问题的重要成因。

即使在opt-in模式下，大量企业的SaaS权限管理也处于混乱状态。Varonis在2024年的数据安全报告中指出，平均每个企业有超过40%的SaaS数据对过多用户开放访问权限。[13] 如果企业连基本的人类用户权限管理都没有做好，将AI治理的全部责任归咎于SaaS厂商的默认开启策略，是否公平？

这个视角的价值在于：它提醒我们，AI治理问题的根源不仅仅是厂商的产品策略，更是企业自身治理能力的长期欠账。默认开启只是让这笔欠账的利息变得更加昂贵。

我的判断：合理性不能替代知情同意

综合以上对立视角，我的判断是：Salesforce的技术设计（区分平台能力层与实际执行层）是合理的，其治理工具的提供也是负责任的。但这些都不能替代一个根本性的程序正义问题——知情同意。

默认开启策略的根本问题不在于技术风险的大小，而在于它绕过了企业的主动决策环节。即使实际风险可控，决策权的转移本身就是一个治理问题。工具的存在不等于工具被正确使用。默认开启意味着在绝大多数企业完成必要的治理配置之前，AI功能就已经处于”可访问”状态。而大多数企业，在治理能力上的准备程度，远远落后于技术功能的推进速度。

第四章：SaaS嵌入式AI的治理新范式——企业需要什么样的防线

这不是Salesforce的独奏

Salesforce的Winter’27决策，是一个行业趋势的缩影，而非孤立事件。

Microsoft已经将Copilot深度嵌入Microsoft 365的核心功能层，默认情况下，Copilot可以访问用户的邮件、日历、文档和Teams对话——Microsoft在2024年底承认其Copilot的数据访问范围超出了许多企业管理员的预期，并紧急推出了Restricted SharePoint Search功能作为补救。[14] Google Workspace的Gemini功能同样以默认集成的方式出现在Gmail、Docs和Sheets中。ServiceNow将AI功能内置于其ITSM平台的核心工作流。HubSpot、Zendesk、SAP……几乎所有主流企业SaaS平台都在以相似的方式推进AI功能的深度嵌入。

这意味着，企业IT团队面对的不是一个需要管理的AI系统，而是散布在十几个、几十个SaaS平台中的数十个AI功能，每一个都有自己的权限逻辑、数据访问范围和行为边界。这种碎片化的AI部署格局，使得传统的”逐个平台管理”策略在实践中几乎不可行。

治理框架的四个支柱

面对这一现实，企业需要建立的AI治理框架，必须超越针对单一平台的技术配置，上升到组织层面的系统性架构。

支柱一：AI功能发现与持续清单管理

企业首先需要知道，在其IT环境中，有哪些AI功能正在运行。这听起来简单，但在实践中极具挑战性。SaaS平台的AI功能往往通过版本更新悄然引入，缺乏统一的披露标准，分散在不同平台的不同层级。

建立AI功能清单，需要将AI功能发现纳入常规的SaaS管理流程中。具体而言，这意味着：在每次SaaS平台版本更新前，专项审查发布日志中的AI相关变更；建立AI功能注册表，记录每个功能的数据访问范围、权限配置和业务影响；将AI功能的新增和变更纳入变更管理（Change Management）流程，确保有明确的审批节点。

支柱二：默认配置审计流程

针对SaaS平台的默认开启策略，企业需要建立专项的”默认配置审计”流程。这个流程的核心逻辑是：不信任任何SaaS平台的默认AI配置，将默认配置视为”待审计状态”而非”已批准状态”。

具体而言，这个流程应该包括：在AI功能自动启用后的规定时间窗口内（建议不超过5个工作日），完成初始配置审计；建立标准化的审计检查表，覆盖数据访问范围、权限边界、行为限制和审计日志完整性；明确审计责任人，避免”每个人都以为别人在管”的治理真空。

支柱三：Agent行为监控机制

传统的SaaS使用监控，主要关注”谁访问了什么数据”。AI Agent的监控需要增加一个维度：”AI做了什么决策，基于什么数据，产生了什么结果”。

这需要在技术层面建立针对AI Agent操作的专项日志记录，并在分析层面建立异常行为检测规则。什么是AI Agent的”异常行为”？可能包括：在非工作时间大量访问敏感数据、跨越正常业务范围的跨对象数据关联、高频触发工作流自动化、向外部系统发送大量数据等。

当前市场上，专门针对SaaS内嵌AI功能的监控工具仍处于早期发展阶段。AppOmni、Obsidian Security等SaaS安全厂商已开始将AI行为监控纳入产品路线图，但成熟的跨平台AI行为监控解决方案尚未出现。[7] 这意味着大多数企业需要在现有的SIEM和CASB（云访问安全代理）工具基础上进行定制化扩展。

支柱四：跨平台AI治理统一策略

最重要也最难实现的是：建立一套适用于所有SaaS平台AI功能的统一治理策略，而非为每个平台单独制定规则。

统一策略的核心要素应该包括：

  • 数据分类与AI访问矩阵：明确哪些数据分类（如PII、财务数据、商业机密）可以被AI访问，哪些需要额外审批，哪些绝对禁止
  • AI行动权限层级：定义AI功能被允许执行的操作类型（只读、创建、修改、删除、外部通信），并与数据分类矩阵交叉映射
  • 合规边界定义：根据企业适用的监管框架（GDPR、HIPAA、SOX等），明确AI功能在各监管场景下的合规红线
  • 供应商评估标准：将”AI治理能力”纳入SaaS供应商评估标准，要求厂商提供AI功能的数据处理说明、opt-out机制和审计接口

组织结构的调整：谁来负责AI治理？

技术框架之外，更根本的问题是组织责任的归属。

在传统的IT治理结构中，SaaS管理通常归属于IT运营团队，安全审计归属于信息安全团队，合规管理归属于法务或合规团队。AI治理横跨这三个领域，但在大多数企业中，没有任何一个团队有清晰的端到端责任。

一种正在出现的组织应对模式是设立专职的”AI治理官”（AI Governance Officer）或在现有CISO职能下增设AI安全专项。McKinsey在2024年的全球AI调查中发现，已有约半数的AI高采用率企业设立了专职AI治理角色，但这一比例在整体企业中仍不足20%。[15] 这种组织变革需要时间，而SaaS平台的AI功能更新不会等待企业完成组织架构调整。

更实际的近期应对，是建立跨职能的”AI治理工作组”，将IT、安全、法务、业务代表纳入同一决策机制，针对每次重大AI功能变更（如Winter’27的Agentforce自动启用）启动快速响应流程。这个工作组不需要永久性存在，但需要在关键时刻能够快速集结、做出决策。

结语：AI治理的”自动驾驶时刻”——从被动响应到主动架构

一个更贴切的类比

2014年，Tesla通过一次OTA（空中下载）软件更新，向已售出的Model S推送了Autopilot自动驾驶辅助功能。车主们在某天早晨发现，自己的汽车突然具备了半自动驾驶能力——这个能力是默认可用的，虽然首次使用需要车主在屏幕上确认条款。

这个类比比安全带更贴切，因为自动驾驶辅助系统与Agentforce共享一个关键特征：它们都是自主行动的系统，而非被动安全装置。安全带不会自己做决定，但Autopilot会——它会判断何时变道、何时加速、何时刹车。同样，Agentforce会判断如何解读用户意图、调用哪些工具、执行哪些操作。

围绕Autopilot，汽车行业、保险行业和监管机构花了近10年时间，才建立起一套初步的责任认定框架——SAE自动驾驶分级标准（L0-L5）、NHTSA的自动驾驶安全报告要求、各州的自动驾驶立法。这套框架至今仍在演进中。

企业AI治理正处于类似的转折点，但时间窗口更短。

大多数人没看到的那一层

表面上，Winter’27的Agentforce自动启用是一个产品决策，影响的是IT管理员的配置工作量。

深一层看，这是SaaS商业模式的演进——平台厂商通过默认开启策略，将AI使用率转化为商业指标，同时将治理责任转移给客户。

但最深的一层，是大多数分析所忽视的：这是一场关于企业数字主权的结构性博弈。

当企业的核心业务流程（销售、客服、运营）越来越依赖SaaS平台内嵌的AI功能，而这些AI功能的训练数据、模型逻辑、行为边界都由平台厂商单方面决定，企业对自身业务流程的控制权就在悄然稀释。不是通过一次明显的权力转让，而是通过每一次版本更新的默认配置变化，一点一点地侵蚀。

这不是阴谋论，而是商业逻辑的自然延伸。Salesforce、Microsoft、Google都有充分的商业动机将AI能力深度嵌入其平台，并使客户对这些AI能力产生依赖。问题不在于厂商的动机，而在于企业是否意识到这种依赖的形成，以及是否建立了相应的治理机制来保护自己的决策自主权。

欧盟《AI法案》（EU AI Act）已于2024年8月正式生效，其中对”高风险AI系统”的部署方施加了明确的合规义务，包括人类监督、透明度和风险管理要求。[16] 当SaaS平台通过默认开启将AI功能推送给欧盟企业客户时，这些合规义务是否已经被充分考虑？这个问题的答案，将在未来2-3年的监管执法中逐渐明朗。

IT团队的角色进化：从功能管理者到AI治理架构师

面对这一现实，IT团队需要完成一次深层的角色认知转变。

传统的IT管理员是”功能管理者”——负责确保SaaS平台正常运行，管理用户权限，处理技术故障。这个角色的核心能力是对平台功能的熟悉程度和对技术配置的精确操作。

AI时代需要的是”AI治理架构师”——负责理解AI功能对业务流程的深层影响，设计数据访问的边界与控制机制，在平台厂商的产品决策与企业自身的合规要求之间建立动态平衡。这个角色的核心能力不再只是对配置界面的熟悉，而是对业务风险的判断力、对监管框架的理解力，以及对跨职能协作的推动力。

这种转变不会自然发生。它需要IT团队主动扩展自身的知识边界——向业务侧理解数据的价值与风险，向法务侧理解合规的底线与弹性，向安全侧理解威胁的形态与演变。更重要的是，它需要企业管理层认识到：IT部门在AI时代的价值，不是体现在系统的稳定运行上，而是体现在对AI风险的主动管理上。

现在应该做的三件事

如果你是一位正在阅读本文的IT管理员、CISO或CIO，以下是在Salesforce Winter’27发布之际（以及面对任何类似平台AI化决策时）应该立即启动的三个行动：

第一件事：完成AI功能现状盘点

不要等待供应商通知，主动进入每一个你管理的SaaS平台的管理控制台，找到与AI相关的所有配置项，记录其当前状态（启用/禁用）、数据访问范围、是否有opt-out选项，以及下一个版本更新的时间节点。这份清单是所有后续决策的基础。

第二件事：与法务和合规团队完成一次AI专项对话

不是发送一份邮件，而是召开一次专项会议，将AI功能的数据访问现实摆在桌面上，明确哪些数据在当前的AI访问状态下存在合规风险，获得法务团队对”可接受风险边界”的明确背书。这次对话的目的不是获得所有问题的答案，而是建立IT与法务之间关于AI治理的共同语言。

第三件事：制定并测试一份AI功能紧急禁用预案

假设明天你发现某个SaaS平台的AI功能正在以意外的方式访问敏感数据，你能在多少时间内完成禁用操作？谁有权做出禁用决定？禁用之后对业务流程的影响是什么？备用方案是什么？把这些问题的答案写下来，并实际演练一次禁用操作。这份预案的存在，本身就是一种治理能力的体现。

这三件事不需要等待预算审批，不需要等待组织架构调整，不需要等待安全厂商推出完美的AI监控产品。它们可以从今天开始。

AI治理的”自动驾驶时刻”已经到来。与自动驾驶不同的是，方向盘不在你手中——它在SaaS平台厂商的产品路线图里。你能做的，是确保自己始终有能力踩下刹车。

参考资料

  1. StartupFortune. (2026-10-12). Salesforce Turns Agentforce On By Default For Every Eligible Org. Retrieved from: https://startupfortune.com/salesforce-turns-agentforce-on-by-default-for-every-eligible-org/ — 直接报道Winter’27 GA变更：「Salesforce’s Winter ‘27 release went generally available on Monday, October 12, and the headline change isn’t a new feature. It’s the removal of one.」确认了管理员开关被移除、新旧组织滚动启用、已验证通过web_fetch访问。

  2. Thaler, R. H., & Sunstein, C. R. (2008). Nudge: Improving Decisions About Health, Wealth, and Happiness. Yale University Press. — 默认选项行为经济学经典研究，401(k)参与率从约49%升至86%的实证数据。

  3. Salesforce FY27 Q2 Earnings Call Transcript (截至2026年7月31日季度) — 来源: Salesforce Investor Relations, 2026-08-27。CEO Marc Benioff在财报电话会议中披露Agentforce ARR突破12亿美元。具体财报文件可查阅SEC EDGAR: Salesforce 10-Q Filing

  4. Salesforce. (2026). Winter ‘27 Release Notes: Agentforce Auto-Enablement. Retrieved from: https://help.salesforce.com/s/articleView?id=release-notes.salesforce_release_notes.htm&type=5 — Salesforce官方release notes，确认适用范围：Lightning Experience + Enterprise/Performance/Unlimited/Developer Edition，以及PowerSchool 550+用户生产使用数据，Agentic Commerce Search 13%转化率提升和17%加购率提升数据均来自此官方文件。

  5. Agentforce Developer Documentation: Get Started with AI Agents — Salesforce Developer Docs, 2026 — 描述Agent Builder、权限集配置和AI代理能力范围的官方技术文档。

  6. Einstein Trust Layer: Architecture and Security Overview — Salesforce Architecture Center, 2025 — 说明Einstein Trust Layer的技术架构，包括数据遮蔽、审计日志和零数据留存机制。

  7. NIST. (2023-01-26). AI Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology. Retrieved from: https://www.nist.gov/system/files/documents/2023/01/26/AI_RMF_1.0.pdf — 企业AI治理的权威框架，四大核心职能（Govern, Map, Measure, Manage），被美国政府和企业广泛采用作为AI治理合规参考。

  8. European Commission opens antitrust investigation into Microsoft Teams bundling — European Commission, 2023-07-27 — 欧盟委员会对微软Teams捆绑销售的反垄断调查，验证监管机构对SaaS平台默认捆绑策略的关注先例。

  9. General Data Protection Regulation (GDPR) Article 22: Automated individual decision-making, including profiling — European Parliament, 2016-04-27 (生效2018-05-25) — GDPR对自动化决策的明确规定，适用于企业在欧盟部署AI代理的合规义务。

  10. FINRA. (2024). Artificial Intelligence (AI) in the Securities Industry: Report on Examination Findings and Observations. Financial Industry Regulatory Authority. Retrieved from: https://www.finra.org/rules-guidance/key-topics/technology/artificial-intelligence — FINRA关于AI在证券行业监管的具体指导，包括AI审计要求和人工监督规定，适用于金融服务行业Salesforce客户的合规义务。

  11. U.S. Department of Health & Human Services. (2024). Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates. HHS OCR Bulletin. Retrieved from: https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html — HHS关于第三方追踪技术和AI工具在HIPAA合规中的具体指引，直接适用于医疗行业Salesforce客户。

  12. Varonis. (2024). 2024 SaaS Data Risk Report. Retrieved from: https://info.varonis.com/hubfs/Varonis_2024_SaaS_Risk_Report.pdf — 实证数据：企业SaaS环境中平均超过40%的数据存在过度暴露，71%的组织在其SaaS应用中存在敏感数据访问控制漏洞。

  13. Cryptobriefing. (2026-09-28). Salesforce launches Hyperagent in Slack for autonomous AI deployment. Retrieved from: https://cryptobriefing.com/salesforce-hyperagent-slack-ai-deployment/ — 报道Salesforce Hyperagent在Slack中的部署，说明Agentforce跨平台能力和Slack 200,000+付费客户的覆盖规模数据。

  14. McKinsey Global Institute. (2024-05). The State of AI in 2024: GenAI Adoption and Enterprise Risk. Retrieved from: https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai — McKinsey年度调研，2024年仅约30%的组织建立了正式AI治理框架的数据来源。

  15. European Commission. (2024-08-01). EU AI Act enters into force. Retrieved from: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai — 欧盟《人工智能法案》正式生效公告，确认高风险AI系统的人类监督和透明度合规义务。

  16. CRN. (2026-10-14). 6 Big Intel, AMD And Nvidia AI Data Center Announcements At OCP 2026. Retrieved from: https://www.crn.com/news/components-peripherals/2026/6-big-intel-amd-and-nvidia-ai-data-center-announcements-at-ocp-2026 — 作为同期横向事件参照，说明AI基础设施在企业端的全面扩张背景。

本文所引用的Salesforce Winter’27发布说明内容基于截至2026年10月的公开信息。Salesforce产品功能与发布计划可能随时调整，建议读者以Salesforce官方最新发布说明为准。文中标注为假设场景的内容仅用于说明目的，不代表真实事件。