最近，我在LinkedIn上看到一篇来自营销技术领域的文章，其中提出了一个简单却十分重要的问题：企业在增加下一个工具之前，是否真正理解现有系统、数据和工作流是如何协同运作的？
这个问题早已不只属于营销部门，而是直指AI转型的核心。许多企业已经拥有CRM、ERP、数据分析、自动化平台、云服务以及初步的AI应用。它们缺少的，通常不是另一个技术入口，而是一个可靠的企业情境，使AI能够做出有意义的判断、执行行动，并在受控条件下持续学习。
我在效果营销、CRM、数字化转型、自动化以及AI领域工作超过20年，反复看到同一种现象：企业购买新能力的速度，往往快于其设计责任、数据流和决策逻辑的速度。 这会产生大量AI活动，却不会自然形成可规模化的运营系统。
因此，我的结论是：情境不仅是数据问题，更是一种管理架构。
治理优先的AI转型，是指在允许AI跨企业执行任务之前，系统性地设计数据访问、决策情境、工作流、责任机制和控制规则。其目的不是减缓创新，而是让AI在正确情境、明确权限和可衡量责任之下实现规模化。
这一定义进一步扩展了“AI不是一个工具，AI是一个操作系统”的观点。AI操作系统把战略、流程、数据、技术、治理和人员连接成一种可管理的运营模式。治理优先明确了正确顺序：先设计情境、权限、责任和证据，再扩大自动化。
成熟的国际框架也指向同一方向。NIST AI风险管理框架把治理视为贯穿AI设计、开发、部署和评估的横向职能。1 ISO/IEC 42001则把AI治理定义为需要建立、运行、审核和持续改进的组织级管理体系，而不是发布一次便束之高阁的政策文件。2
增加工具无法弥补企业理解的缺失
许多AI路线图依然从产品清单开始：选择哪一种Copilot授权？使用哪一个模型？采用哪一个智能体平台？配置哪一套营销自动化？这些问题并非不重要，只是被问得太早。
如果CRM、电商和客服系统保存着不同版本的客户信息，AI就无法合理地确定客户优先级。如果绩效指标总是延迟，或者业务定义彼此冲突，AI就无法给出可靠行动建议。如果访问权限、审批节点和升级路径尚未明确，AI就不应该自主执行工作流。如果企业没有记录正确结果应该是什么，AI也无法真正从错误中学习。
问题不是“AI太少”，而是共享企业情境太少。
McKinsey 2026全球AI调查清楚揭示了这条分界线。AI高绩效企业并非简单地把AI插入现有流程。接近四分之三的高绩效企业表示，它们因AI而对工作流进行了根本性重构；其他企业的这一比例仅约为四分之一。高绩效企业也更常表现出明确的高层承诺，并建立正式的AI价值衡量流程。3
这一区别具有重要战略意义。单点工具优化的是一个任务；AI操作系统设计的是端到端价值流，其中包括数据、决策、例外和责任。
Fassbender“情境到控制堆栈”让企业情境变得可管理
为了把复杂问题转化为管理层可以讨论和决策的结构，我采用 Fassbender情境到控制堆栈（Context-to-Control Stack）。它由五个相互连接的层级组成，AI工作流只有在这些层级具备基本一致性后，才适合规模化。这里的“控制”并不意味着微观管理，而是企业能够主动管理价值、权限、质量和风险。
| 层级 | 核心管理问题 | 典型断点 | 可供决策的输出 |
|---|---|---|---|
| 1. 业务与数据情境 | 流程需要哪些数据和知识，才能稳定产生正确结果？ | 数据孤岛、定义冲突、来源不明 | 数据源地图、数据责任、质量与时效规则 |
| 2. 身份与权限情境 | 谁或什么系统可以查看、修改和使用哪些情境？ | 共享账号、权限过宽、智能体身份不清 | 角色模型、访问规则、委托权限与撤销机制 |
| 3. 洞察与决策情境 | 哪种洞察应在什么条件下触发何种决策？ | 只有仪表盘没有决策、阈值模糊、理由缺失 | 决策逻辑、证据要求、基线与KPI |
| 4. 工作流与执行情境 | 一项决策如何转化为受控行动？ | 系统断点、人工交接、局部优化 | 目标流程、集成节点、审批与例外机制 |
| 5. 治理与学习情境 | 谁对结果负责，系统如何持续改进？ | 政策无法落地、缺少事件机制、没有反馈 | 责任人、测试、审计轨迹、监控与学习闭环 |
这五个层级并不是一种新的软件类别，而是一套诊断和设计逻辑。企业即使拥有现代化技术栈，也可能在每个层级存在严重缺口。
数据只有具备含义、来源和时效，才会成为情境
“我们有足够的数据”是AI项目启动时最常听到的说法之一。从数据量来看，这通常没错。但AI需要的并不是更多记录，而是能够理解记录的含义、来源、质量、时效和允许用途。
同一个“收入”指标，可能指已预订、已开票或已支付收入。“活跃客户”可能依据登录、购买、合同或服务互动定义。一份文件可能是有效版本、过期版本，也可能只允许在某个地区使用。如果这些语义和运营信息缺失，AI很容易给出看似合理、实则不符合业务事实的答案。
因此，NIST生成式AI配置文件建议企业建立包含数据来源信息的AI清单，明确周期性审核责任，并持续监控AI事件。4 新加坡生成式AI治理模型框架同样把数据质量、数据完整性和内容来源视为可信AI生态的重要组成部分。6
管理层由此需要面对一个不太舒服却十分有效的问题：我们的企业能否解释某项AI辅助决策建立在哪些情境之上，还是只能看到最终输出？
身份决定情境是有用还是危险
AI系统掌握的情境越多，其潜在价值越大，同时身份与授权也越重要。销售助手和人力资源系统需要的信息及权限显然不同。外部合作伙伴不应获得与内部流程负责人相同的企业情境。只读取数据的AI智能体，与能够调整价格、发起付款或联系客户的AI智能体，也具有完全不同的风险等级。
因此，生产级AI架构不仅要管理人的身份，还要管理系统身份和被委托的行动权限。任何权限都应具有明确目的、范围、有效期、操作记录和撤销机制。
NIST零信任架构不因网络位置或资产归属而给予默认信任。在访问企业资源之前，主体和设备都必须分别完成认证与授权。5 将这一原则应用于AI，结论十分清楚：企业情境不能被普遍开放，而应针对具体角色、流程和行动进行有意识的授权。
这不只是网络安全决定，更是企业对“AI可以代表我们做什么”的设计决定。
洞察只有转化为决策，才会创造价值
许多企业并不缺少洞察，而是缺少执行。仪表盘显示异常，分析报告识别机会，AI生成建议，但企业没有定义在什么阈值下采取行动、由谁做出决定，以及之后需要更新哪个系统。
没有决策权的洞察仍然只是信息。没有工作流的决策仍然只是意图。没有反馈的工作流仍然是盲目的。
因此，情境到控制堆栈的第三层不只记录KPI，还要记录完整的决策逻辑：需要哪些证据？可以接受多大不确定性？何时AI建议已经足够？何时必须由人批准？哪些决策必须说明理由，并在之后接受复核？
这种纪律能够防止企业把速度误认为进步。一个系统如果在几秒钟内生成模糊决策，并没有完成转型，它只是加速了模糊性。
治理是瓶颈，但不应该成为刹车
很多企业只有在法务、合规或数据保护团队审核AI项目时，才开始讨论治理。此时，治理几乎必然被视为项目后期的障碍。治理优先则完全改变了这个顺序。
良好的治理会及早定义哪些数据可以使用、什么质量标准必须达到、谁来处理例外、哪些行动必须可逆，以及何时需要停止系统。这不仅降低风险，也能提升速度，因为团队不必为每一个个案重新谈判规则。
NIST AI风险管理框架把治理明确设为横向职能。1 ISO/IEC 42001要求企业建立持续改进的AI管理体系。2 NIST生成式AI配置文件进一步提出角色、清单、人工监督、测试、事件流程以及第三方责任等运营措施。4
对于欧洲企业，《欧盟人工智能法案》构成重要的监管基线。针对高风险系统，其要求包括风险管理、数据质量、日志、文件记录、人工监督、稳健性和准确性。8 但AI操作系统不能止步于合规，还必须设计优先级、价值、系统交接和学习闭环。
合规关注一个系统是否可以使用；治理优先的转型还要回答，它在什么条件下能够持续创造价值。