把制度文档、操作手册和业务数据交给 AI，并不等于 AI 已经理解企业怎样运转。
2026 年 10 月下旬，Oracle 发布 AI Data Platform 新能力，提出用企业本体、语义推理和治理机制，让智能体理解业务实体、关系、政策与工作流；ARIS 同期发布面向企业 AI 的 Process Context，强调流程、角色、系统、规则、风险、控制和例外共同构成智能体需要的业务上下文。
这些发布背后有一个很现实的企业问题：标准流程通常写在制度里，真正让业务顺利运行的例外处理，却往往藏在老员工的经验、临时群聊和一句“这次特殊处理”中。
AI 可以很快学会“正常订单怎么审批”。企业更难教给它的是：客户临时改期怎么办，系统数据相互矛盾怎么办，关键供应商缺货怎么办，以及什么情况下可以偏离标准流程、由谁批准、偏离多久。
企业 AI 从会回答走向会办事，最缺的不是更多文档，而是一套可验证的例外知识。
标准流程描述“应该怎样”，业务现场记录“实际上怎样”
很多企业的流程资产分成两套：
两者之间的差异不一定意味着管理混乱。有些例外是合理的：大客户需要紧急交付，设备故障需要切换备用线路，法规要求对特定地区追加审核。问题在于，这些做法如果没有被结构化记录，AI 只能看到标准规则，或者从零散历史行为中自行推断。
前者会让 AI 机械执行，遇到现实变化就卡住；后者更危险，因为历史上“曾经这样做过”不代表现在仍被允许，也不代表那次做法本身正确。
所以，流程上下文不能只是“把更多企业数据接给模型”。它至少要区分三种事实：
如果把三者混在一起，智能体可能把违规操作学习成最佳实践，也可能把一次应急措施固化为日常规则。
- 正式流程存在于制度、SOP、流程图和系统配置中；
- 实际流程存在于邮件、聊天、表格、口头交接和员工经验中。
- 规定流程：制度要求应当怎样做；
- 观察流程：系统日志显示实际怎样做；
- 批准例外：在什么条件下，经谁授权，可以暂时偏离规定。
一条例外规则，必须回答六个问题
企业经常把例外写成一句话：“特殊客户可以加急”“金额较大需要领导确认”“系统异常时走人工”。这些表述对熟悉业务的人尚可理解，对需要自动执行的智能体则远远不够。
一条可用的例外规则至少要包含：
例如，“重要客户可以先发货后补审批”不是完整规则。企业还需要说明重要客户由谁定义、最多允许多少金额、库存与信用条件是什么、谁批准、必须在多长时间内补齐手续，以及逾期后是否暂停后续订单。
只有写清这些内容，智能体才能判断它面对的是合法例外、需要升级的新情况，还是不应执行的绕流程请求。
- 要素：需要明确的内容
- 触发条件：什么事实出现时才进入例外，而不是凭感觉判断
- 适用对象：哪类客户、产品、地区、合同或业务阶段适用
- 允许偏离：可以跳过、替换或延后哪一个标准步骤
- 权限边界：谁能提出、谁能批准、金额或影响范围上限是多少
- 补偿控制：省略原步骤后，用什么复核、留痕或后续动作弥补风险
- 失效条件：例外何时自动结束，何种变化必须重新审批
不要让 AI 从历史日志里自动发明政策
过程挖掘和智能体可以从系统记录中发现大量真实路径：哪些订单被退回，哪些审批被跳过，哪些工单在部门之间反复转派。这些数据非常适合识别流程瓶颈，却不能直接作为授权依据。
原因很简单：日志记录的是发生过什么，不是应该发生什么。
一个高频绕行路径可能代表标准流程已经过时，也可能代表控制长期失效；一个表现良好的特殊处理可能值得推广，也可能只是因为风险尚未暴露。AI 可以发现模式、整理证据和提出候选规则，但把候选规则变成正式流程，仍应由业务、风险与系统负责人共同确认。
Oracle 此次提出由 AI 分析数据库模式、语义模型、接口文档和非结构化知识，生成企业本体建议，再由领域专家审查和批准。这一“AI 发现、人类治理”的思路是合理方向，但相关公告也明确属于产品规划，能力、时间与价格可能变化。企业在采购时仍需通过自己的数据验证：系统能否区分政策与历史行为，能否展示规则来源，能否阻止未经批准的建议直接进入执行。
例外不应直接变成永久流程
企业的很多流程债务，来自临时措施没有退出机制。
疫情期间的远程签批、系统切换期间的人工表格、供应紧张时的替代采购，本应随条件消失而终止；但如果员工和系统已经习惯了新路径，它们可能在多年后仍然存在。
因此，每条例外都应带有生命周期：
这个分类能避免智能体犯两种相反的错误：每次遇到相同情况都重新请示，或者因为过去批准过一次就永久放行。
- 一次性例外：只对某个具体对象和任务有效；
- 限期例外：在明确时间窗口内有效，到期自动停止；
- 条件例外：只要外部条件持续存在就有效，并定期重新确认；
- 候选变更：多次发生且效果稳定，进入正式流程改造评审；
- 永久规则：完成风险、系统与岗位调整后，纳入标准流程。
从“例外台账”开始，比先建宏大知识图谱更实际
企业不必一开始就试图建成覆盖全公司的业务本体。更稳妥的起点，是选择一个高频、跨部门、例外较多的流程，建立最小例外台账。
可以按以下顺序推进：
这张台账的价值不只服务 AI。它还能帮助企业发现制度是否过时、系统是否迫使员工绕行、哪些审批没有降低风险，以及哪些“特殊情况”已经多到应当改造正式流程。
- 从系统退回、人工改派、审批撤回、超时和投诉中提取最近三个月的异常路径；
- 访谈真正处理这些情况的一线人员，补充日志看不到的判断依据；
- 将异常分为合规例外、流程缺陷、数据问题、系统限制和违规绕行；
- 为合规例外补齐触发条件、批准人、补偿控制与失效条件；
- 让 AI 只负责识别相似情形和准备证据，初期不自动批准例外；
- 统计人工升级率、误升级率、处理时长和例外复发率，再决定扩大自动化范围。
评估流程上下文平台，要看它如何处理冲突
演示环境通常只有一套清晰规则，真实企业却会出现多源冲突：制度文件说一套，ERP 配置是另一套，地区规定还有附加要求，最新会议纪要又批准了临时措施。
因此，平台选型不应只问“能接多少数据源”“能否自动生成知识图谱”，还应验证：
ARIS 与 The Hackett Group 联合发布的 2026 年调研称，86% 的受访大型企业管理者认为可靠部署智能体需要流程上下文，但只有 22% 表示拥有全面、实时的端到端流程可见性。该研究由解决方案厂商参与，应被视为市场调研而非独立因果证明；不过，这个差距与很多企业的实际感受一致：大家拥有大量数据，却未必清楚业务为什么这样流转。
- 同一概念存在多个定义时，是否能标明适用范围和权威来源；
- 规则冲突时，是否会停下来升级，而不是自行选择一个答案；
- 能否区分当前生效、未来生效、已废止和临时例外；
- 每个规则能否追溯到责任部门、批准记录和原始证据；
- 规则变更后，能否识别受影响的智能体、流程和历史任务；
- 一线人员能否报告新例外，而不是只能由技术团队维护；
- 是否记录人工覆盖以及覆盖后的业务结果，用于后续改进。
智能体成熟度，取决于它是否知道“该停下来”
企业往往用自动完成率衡量智能体，认为需要人工介入越少越好。但在例外密集的业务中，一个成熟系统的标志不是永不求助，而是能准确识别标准规则已经不足以支持安全行动。
NIST AI 风险管理框架建议记录人工监督、覆盖、投诉、政策例外与升级，并追踪责任方作出的继续或停止决定。这说明例外不是自动化失败的噪声，而是评估系统边界和改进流程的重要数据。
真正可靠的企业智能体，应当知道三件事：标准情况下怎么做，已批准的例外怎样做，以及遇到未定义情况时必须停止并找谁。
流程文档教 AI 怎样走直线；例外治理决定它遇到弯路时，是安全转向，还是自作主张。
