SaaS 治理的性质已经改变。问题不再只是了解有多少许可证，而是理解数据在哪里流转、哪些应用是在目录之外被采用、AI 如何在官方工具内外被使用，以及当某些事项偏离标准时由谁负责。2026 年 6 月和 7 月，Gartner 再次强调，overspend、可见性不足和 contract sprawl 是 SaaS 与生成式 AI 使用叠加产生的结果；与此同时，Microsoft 扩展了对在 SaaS、AI 应用和非托管存储库之间流动数据的控制。(gartner.com)
生成式 AI 如何改变了 SaaS 治理？
简短的回答是：控制面变得动态化。过去，治理 SaaS 意味着梳理应用、审批采购、审查权限和跟踪续约。现在，这些工作仍然必要，但已不足够。AI 增加了三层复杂性：工具的不可见使用、敏感数据在 prompts 和文件中的流动，以及无需持续人工监督即可执行操作的智能体扩张。Gartner 在 2026 年 4 月指出，到 2028 年，Fortune 500 企业中的智能体数量可能超过 15 万，而仅有 13% 的组织认为自己具备应对这一场景的正确治理。(gartner.com)
实际影响容易描述，却很难纠正。企业失去了身份、数据、合同和运营之间的一致性。一个团队绕过 procurement 采用工具；另一个团队在官方流程之外创建 AI 自动化；第三个团队在外部应用中共享数据。单独看，这些都似乎是小事；合在一起，就会演变为 compliance 风险、隐性成本和可追溯性缺失。
内联术语表
SaaS sprawl：缺乏标准化或集中可见性的应用泛滥。
Contract sprawl：合同、续约和条款分散在多个团队中。
Shadow AI：未经批准、监控或正式政策约束的 AI 工具使用。
可执行治理：不只依赖文档的控制；它在实际使用流程中得到执行。
为什么应用清单已不再足够？
因为清单是照片，治理需要是影片。SaaS 目录可以展示已购买或获批的内容，但它本身无法显示谁在使用平行应用、哪些数据被发送到外部服务，也无法显示新集成是否改变了应用风险。Microsoft 在 2026 年 7 月报告称，数据如今持续在 endpoints、SaaS、AI 应用和个人存储库之间流动，因此需要实时保护，而不只是事后审查。(techcommunity.microsoft.com)
这改变了 IT、安全和运营工作的逻辑。团队需要同时交叉分析四张地图：身份、使用、数据和成本。任何一张过时，决策都会变得薄弱。例如，一个应用在清单中看似合规，却可能拥有过度权限、向未批准域名传输流量，并在没有实际使用的情况下自动续约。在这种情况下，问题不在于缺少工具，而在于各控制层之间缺少关联。
其后果也体现在财务上。Gartner 在 2026 年 6 月强调，SaaS 管理平台有助于应对 overspend、高风险、可见性不足和 contract sprawl。换言之，浪费已不只是财务问题，而成为治理薄弱的症状。(gartner.com)
如何设计能够日常运作的治理体系？
具体做法是按层构建治理，而不是建立抽象委员会。最有效的结构结合了发现、分类、政策、enforcement 和审计。每一层都回答一个明确的问题。
第一：存在哪些对象？这包括应用、集成、账户和数据流的发现。第二：哪些内容敏感？按数据类型、关键性和使用场景进行分类。第三：哪些行为可以发生？制定访问、共享、保留和 AI 使用政策。第四：哪些行为会被阻断或修复？通过身份、设备、网络或应用实施自动 enforcement。第五：哪些内容被记录？建立用于举证和调查的审计轨迹。
这种逻辑比依赖人工审批更具韧性。Gartner 在 2026 年 6 月也强调，AI 治理必须从通用政策转向持续、技术化且嵌入工作流程的控制。(gartner.com)
在实践中，这意味着要将治理视为内部产品。它有 backlog，有规则，有例外，有效性评审，也有明确的 owners。没有这些，治理就会沦为失效文档。
IT、安全、procurement 和业务分别扮演什么角色？
简短的回答是：没有人能够独自治理 SaaS。IT 了解架构和集成；安全团队了解风险、身份和数据；procurement 了解合同、价格和续约；业务团队了解生产力和采用情况。常见错误是将全部责任放在单一团队身上，结果就是延迟、摩擦和 bypass。
正确的模式是在不分散决策的前提下分配职责。IT 定义技术标准；安全团队定义最低控制要求；procurement 控制采购和续约；业务负责人验证需求和关键性。如果 SaaS 内嵌 AI，还应评估数据使用、保留和自动化行为。
在更成熟的环境中，这可以通过治理中心或共享政策网络来运营。关键在于，最终决策不应依赖电子邮件、电子表格或组织记忆。
哪些指标能够体现治理是否成熟？
直接的回答是衡量覆盖度、风险和效率。没有这些，治理在第一次事故发生前看起来总是良好的。最有用的指标并不多，但都很直接。
发现覆盖度：已识别的应用、集成和账户占实际使用情况的比例。
政策覆盖度：处于访问、共享和保留有效规则之下的关键应用比例。
修复时间：纠正过度权限、未批准应用或高风险合同所需的时间。
检测到的 shadow AI 比率：按部门或用户类型统计的未授权工具使用量。
避免的支出：因低使用率而取消的许可证、重新谈判的合同和被阻止续约所节省的成本。
SaaS 数据事件：数据暴露、不当共享或发送至外部应用的事件。
这些指标应结合跟踪。如果团队降低了成本却增加了事故，治理就是失败的；如果降低了风险却造成过度摩擦，同样是失败。目标是在真实控制下实现运营平衡。
Microsoft 也在 2026 年 7 月 1 日强调，需要借助实时可见性和 enforcement，检测敏感数据如何与 shadow AI tools 及非托管 SaaS 共享。这表明，风险指标必须跟踪流动，而不能只关注静态配置。(techcommunity.microsoft.com)
如何在不失去控制的情况下管理智能体和自动化？
最重要的回答是：智能体不能像普通用户一样运行。它需要独立身份、有限范围和授权轨迹。Gartner 在 2026 年 4 月警示了 agent sprawl 的加速增长，以及 oversharing、数据丢失和管理复杂性的风险。(gartner.com)
这要求专门的治理模式。第一，每个智能体必须有声明的用途。第二，权限应遵循最小化原则，并设置时效。第三，关键操作需要审批或双重验证。第四，日志必须记录谁进行了授权、执行了什么操作，以及使用了哪个数据基础。第五，审查必须定期进行，因为智能体变化很快。
这里有一个有用的区分。自动化执行可预测的任务。智能体能力则在限定范围内做出决策。当企业不加规则地混用两者时，就会失去审计能力。成熟的路径是在低风险场景允许自主性，在具有监管、财务或声誉影响的场景要求控制。
在实践中，这减少了“不可见自动化”的空间，尤其是在已内嵌 AI 功能的 SaaS 中。问题不在于技术本身，而在于缺乏运营边界。
SaaS 治理如何与战略相连？
具体的答案是：成本、速度和信任。治理薄弱的企业购买的多于实际使用的，集成的多于能够控制的，做出的反应多于主动规划。治理成熟的企业能够以更低风险和更高可预测性采用新工具。
这对处于增长阶段、拥有众多业务单元、分布式团队且面临生产力压力的组织尤其重要。在这种情况下，治理不是刹车，而是规模化机制。它避免每个部门都建立自己的工具栈、自己的合同和自己的例外。
这正是像 Centriu 这样的平台可以作为编排层发挥作用的地方，但核心仍然不变：治理必须可运营、可衡量且持续进行。否则，企业积累的只是工具，而不是能力。
未来 90 天应该做什么？
最有用的答案是从小范围、高影响的事项开始。以下三项工作足以让企业从诊断进入控制。
- 统一发现：梳理目录之外的应用、账户、集成和 AI 使用。
- 风险分类：区分关键、敏感、受监管和可有可无的对象。
- 具备 enforcement 的政策：对访问、共享和续约应用自动规则。
之后，与 procurement、安全和业务团队建立月度评审机制。目标不是审批一切，而是减少意外。当企业减少意外，就能降低成本、加快决策，并改善风险态势。
2026 年的 SaaS 治理已不再是一项行政职能，而是一门生态系统控制学科。继续将这一议题视为清单和许可证的企业，将在结构上滞后；将其视为动态决策层的企业，则会获得更高可见性、更少浪费，并为 AI、智能体和新的软件采购做好更充分准备。
Quer o passo a passo aplicado ao seu cenário?
Comece pelo e-mail — sem cadastro longo.
