合作的具体形态
10 月 28 日，ServiceNow 与 OpenAI 宣布在 1 月合作基础上扩大范围，核心是一个双向通道。正向：新的 ServiceNow 插件把企业工作流搬进 ChatGPT，由 ServiceNow Action Fabric 提供企业上下文、业务规则与权限，用户在同一个会话里从「提问」走到「受治理的执行」。官方给出的场景是运维智能体在对话中检索相似工单、评估变更风险、更新相应记录，而记录的实际写入与治理仍发生在 ServiceNow 平台内。
反向：ServiceNow 的工作流与平台能力将进入 OpenAI 一侧。Codex 计划接入 ServiceNow 的 AI Workflow Factory，OpenAI 模型同时驱动其中的 Build Agent 与 Autonomous Engineer，目标是让开发者带着 ServiceNow 的业务上下文与治理规则构建应用。组织层面，OpenAI 计划在自身运营中使用 ServiceNow，ServiceNow 计划向全体员工提供 ChatGPT Work 与 Codex。
安全与治理两条线
- 联合安全方案：把 OpenAI 的网络安全能力与 ServiceNow 的资产、访问与企业上下文结合，做识别、分级、验证、缓解的闭环。官方提到代码库扫描可能一次暴露 1 万到 10 万条以上漏洞，真正的难点是判断哪些是迫在眉睫的风险。
- 信任关系：ServiceNow 已加入 OpenAI 的 Trusted Access for Cyber 计划；OpenAI 则作为创始成员加入 ServiceNow 新成立的 Control Tower Alliance。
- 风险评估：ServiceNow 计划预览语音版 Super Intelligence Control Tower——风险人员口述用例，智能体填写评估字段、追问细节，并按所述用途给出风险评级。
落地前要看的三件事
公告里大量使用「计划」「预览」，没有 GA 日期，也没有定价与计费口径，短期内难以据此做预算与排期。第二，跨系统权限边界需要逐条确认：插件让智能体读到了工单、变更与服务关系数据，企业要能回答「哪个智能体在什么条件下可以写哪张表」，以及审批链是否被绕过。第三，审计留痕与回滚路径。ServiceNow 称平台每年承载超过 1000 亿次工作流，这个体量下，一次错误写入的影响面会被放大；OpenAI 官方口径强调执行与治理留在 ServiceNow，但企业仍需在自身环境里验证日志是否完整、能否按会话还原决策链。对于正在做 IT 运维智能体的团队，这份公告的价值不在功能清单，而在于它明确了分工：模型负责推理，平台负责权限与执行。这条边界也决定了事故责任如何划分，采购合同里应当写明双方在误操作、越权访问与数据留存上的义务。