Wiki source code of 人与 AI 协作:ITIL 第5版谈人工智能,重点不在工具,而在治理与能力边界
Version 4.1 by superadmin on 2026/02/04, 17:17
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | 2026年1月29日,PeopleCert正式发布了ITIL 第5版。作为ITIL官方中国区产品大使,我将会推出系列文章帮大家解读ITIL 第5版到底有哪些重大的更新。 | ||
| 2 | |||
| 3 | |||
| 4 | |||
| 5 | (% style="text-align:center" %) | ||
| 6 | [[image:11.png]] | ||
| 7 | |||
| 8 | 对 IT 负责人和治理负责人来说,你现在面对的最大变化,不是系统更复杂了,而是“决策链条更长了”。生成式 AI 与自动化一旦进入日常运营,它们不只是在替你做事,更在参与判断、参与沟通、参与分派、参与编排,甚至影响你对事实的认知。 | ||
| 9 | |||
| 10 | 这意味着治理对象发生了变化:过去你主要治理“人怎么做”,现在你必须同时治理“系统怎么决定”。如果你依旧用旧思路,把 AI 当成一个管理工具、一个效率插件,你很快就会被三件事反噬: | ||
| 11 | |||
| 12 | • 风险边界变模糊:同样一句建议,人说出来和模型说出来,责任归属完全不同。 | ||
| 13 | |||
| 14 | • 证据链变脆弱:模型输出看似合理,但依据不透明,回溯困难,可审计性下降。 | ||
| 15 | |||
| 16 | • 组织行为变扭曲:一线开始把模型当盾牌,把“系统说的”当免责理由,责任被稀释。 | ||
| 17 | |||
| 18 | 所以本篇只解决一个核心问题:你到底该怎么定义人与 AI 的能力边界,以及如何用 ITIL 第5版的语言把它管起来。 | ||
| 19 | |||
| 20 | |||
| 21 | == 一、更新内容概述:为什么 ITIL 第5版会把 AI 推到方法论核心 == | ||
| 22 | |||
| 23 | 我们先看看ITIL 第5版到底有哪些核心更新,我会用“AI 为什么迫使六个要点一起升级”来解释。 | ||
| 24 | |||
| 25 | **1、定位升级:数字化产品和服务管理** | ||
| 26 | |||
| 27 | AI 的价值不只在支持环节,它会进入发现、设计、构建、转换、运营、交付、支持的每个活动。你要治理的是端到端价值创造里的 AI 参与方式。 | ||
| 28 | |||
| 29 | **2、生命周期模型升级:八个活动覆盖从发现到支持** | ||
| 30 | |||
| 31 | AI 会在不同活动承担不同角色:在发现阶段辅助洞察,在设计阶段生成方案,在构建阶段辅助开发,在支持阶段辅助分流与知识检索。不同活动的风险不同,能力边界必须差异化。 | ||
| 32 | |||
| 33 | **3、人工智能进入方法论核心:从应用走向治理与管理能力** | ||
| 34 | |||
| 35 | 这不是鼓励你“多上 AI”,而是要求你建立管理能力:明确授权与控制点,明确证据链,明确责任。 | ||
| 36 | |||
| 37 | **4、指导原则更强调取舍:尤其是优化和自动化** | ||
| 38 | |||
| 39 | AI 与自动化最容易造成“局部效率提高、系统风险上升”。指导原则提醒你:优化不是只看效率,自动化不是越多越好,必须在风险与价值之间做取舍。 | ||
| 40 | |||
| 41 | **5、实践从清单走向组件库:强调适用性与可裁剪** | ||
| 42 | |||
| 43 | AI 能力不可能一刀切。你必须按价值流裁剪:哪些实践适合引入 AI,哪些实践必须保留人工确认,哪些实践需要先补数据治理。 | ||
| 44 | |||
| 45 | **6、迁移与学习路径更强调能力栈与路线图** | ||
| 46 | |||
| 47 | AI 不是一次性项目,而是能力栈演进。组织需要路线图:先做可控试点,再扩展到更多价值流,把治理与度量固化下来。 | ||
| 48 | |||
| 49 | 你会发现,ITIL 第5版对 AI 的态度非常清晰:不是“推工具”,而是“推治理”。 | ||
| 50 | |||
| 51 | |||
| 52 | |||
| 53 | (% style="text-align:center" %) | ||
| 54 | [[image:12.jpg]] | ||
| 55 | |||
| 56 | == 二、先把分工说透:人擅长什么,AI 擅长什么 == | ||
| 57 | |||
| 58 | 治理的第一步,是把能力边界说清楚。你不需要写一篇哲学论文,你只需要把两类能力区分开:什么更适合人,什么更适合 AI。否则你会在上线后陷入无休止的争吵:到底是谁的错,到底该不该让模型做。 | ||
| 59 | |||
| 60 | **1、人更擅长的事情** | ||
| 61 | |||
| 62 | • 价值判断:在冲突目标之间取舍,例如效率与风险、成本与体验的平衡 | ||
| 63 | |||
| 64 | • 责任承担:对结果负责、对外部承诺负责、对重大风险负责 | ||
| 65 | |||
| 66 | • 情境理解:识别隐含假设、理解组织情境、理解客户组织的敏感点 | ||
| 67 | |||
| 68 | • 伦理与合规判断:当规则不清晰、边界模糊时,做保守选择 | ||
| 69 | |||
| 70 | • 异常处置:在事故、重大事件、混乱情境中做快速决策与协调 | ||
| 71 | |||
| 72 | **2、AI 更擅长的事情** | ||
| 73 | |||
| 74 | • 信息检索与聚合:在海量文档、日志、记录中快速找相关内容 | ||
| 75 | |||
| 76 | • 模式识别:从历史数据中发现相关性与异常信号,辅助预测与预警 | ||
| 77 | |||
| 78 | • 文本生成与改写:生成草稿、摘要、知识条目、沟通模板 | ||
| 79 | |||
| 80 | • 初步分类与分派:把简单问题快速分流,把重复工作自动化 | ||
| 81 | |||
| 82 | • 编排建议:在确定规则下给出候选步骤,减少人为遗漏 | ||
| 83 | |||
| 84 | 你会看到,AI 的优势主要在“规模与速度”,人的优势主要在“责任与取舍”。治理的关键,就是让 AI 不越界,让人不偷懒。 | ||
| 85 | |||
| 86 | |||
| 87 | == 三、能力边界怎么落到制度上:三条红线与三条绿线 == | ||
| 88 | |||
| 89 | 光说分工太虚。治理负责人需要的是可执行的边界。我通常会用“红线/绿线”的方式让组织快速达成共识:哪些决策必须人工确认,哪些可以让 AI 自动化,哪些属于灰区要试点。 | ||
| 90 | |||
| 91 | **1、三条红线:必须人工确认的决策** | ||
| 92 | |||
| 93 | • 涉及高风险变更与不可逆操作的:例如影响关键业务功能、影响生产环境的操作,必须人工批准 | ||
| 94 | |||
| 95 | • 涉及合规、隐私、财务、客户承诺的:任何对外承诺、对客户组织的关键沟通,必须人工审核 | ||
| 96 | |||
| 97 | • 涉及重大事件处置策略的:是否回滚、是否降级、是否停机、是否启动灾难恢复计划,必须由授权人决策 | ||
| 98 | |||
| 99 | **2、三条绿线:可以优先自动化或 AI 辅助的工作** | ||
| 100 | |||
| 101 | • 标准化、可回滚、影响范围有限的:例如标准请求的履行、常见问题的知识检索与建议 | ||
| 102 | |||
| 103 | • 信息整理与证据收集:例如把日志、告警、工单历史汇总成可读摘要 | ||
| 104 | |||
| 105 | • 初步分类、优先级排序与分派:尤其适用于服务台的高频重复工作 | ||
| 106 | |||
| 107 | **3、灰区:需要试点的能力** | ||
| 108 | |||
| 109 | • AI 触发自动补救:如果补救动作可能引发连锁反应,先从“建议”做起,再逐步走向“自动执行” | ||
| 110 | |||
| 111 | • AI 参与变更评审:先让 AI 提供风险提示与依赖关系分析,再决定是否让它参与推荐批准 | ||
| 112 | |||
| 113 | • AI 生成面向客户的回复:先做内部草稿与人工审核,再逐步扩大范围 | ||
| 114 | |||
| 115 | 你会发现,这套边界不是“反 AI”,而是“让 AI 走在可控轨道上”。真正危险的不是 AI 做得少,而是 AI 做得快但不可控。 | ||
| 116 | |||
| 117 | |||
| 118 | == 四、治理设计的核心:控制点、证据链与责任分配 == | ||
| 119 | |||
| 120 | 人与 AI 协作,最难的不是上线,而是“出了问题怎么追溯、怎么恢复、怎么改进”。这三件事离不开治理设计。 | ||
| 121 | |||
| 122 | **1、控制点怎么放** | ||
| 123 | |||
| 124 | 控制点不是审批越多越好,而是要放在高风险决策处: | ||
| 125 | |||
| 126 | • AI 给出建议时,哪些建议必须触发人工批准 | ||
| 127 | |||
| 128 | • AI 触发自动化动作时,哪些动作必须有安全阈值与回滚机制 | ||
| 129 | |||
| 130 | • AI 输出用于对外沟通时,必须设置人工审核门槛 | ||
| 131 | |||
| 132 | **2、证据链怎么留** | ||
| 133 | |||
| 134 | 可审计性不是附加项,而是 AI 时代的硬门槛。你至少要做到: | ||
| 135 | |||
| 136 | • 记录 AI 参考了哪些数据源或知识条目 | ||
| 137 | |||
| 138 | • 记录关键输入与关键输出 | ||
| 139 | |||
| 140 | • 记录是谁批准了哪些动作,批准依据是什么 | ||
| 141 | |||
| 142 | • 记录自动化执行了哪些步骤,失败时如何恢复 | ||
| 143 | |||
| 144 | **3、责任怎么分配** | ||
| 145 | |||
| 146 | accountability 即“责任”楚: | ||
| 147 | |||
| 148 | • 决策责任:谁批准 AI 建议被采纳,谁就承担决策责任 | ||
| 149 | |||
| 150 | • 执行责任:自动化执行由谁维护规则与脚本,谁承担执行责任 | ||
| 151 | |||
| 152 | • 恢复责任:出现事故时谁负责恢复与协调 | ||
| 153 | |||
| 154 | • 改进责任:复盘后谁负责把问题转化为改进举措并验证有效 | ||
| 155 | |||
| 156 | 当责任被说清楚,AI 才不会变成“甩锅工具”。否则你会听到一句非常危险的话:系统自动的,不是我。 | ||
| 157 | |||
| 158 | |||
| 159 | == 五、用三个典型场景讲透:服务台、变更实施、知识管理 == | ||
| 160 | |||
| 161 | 为了让治理落到实处,我用三个最常见场景,把“人机协作”怎么做讲得更具体。 | ||
| 162 | |||
| 163 | **场景一:服务台引入生成式 AI** | ||
| 164 | |||
| 165 | 你想要的结果通常是:减少人工处理、提升响应速度、提高用户满意度。但治理上你必须先回答: | ||
| 166 | |||
| 167 | • AI 用于“建议”还是用于“直接回复”? | ||
| 168 | |||
| 169 | • 对外回复是否必须人工审核?哪些类型的请求可以自动回复? | ||
| 170 | |||
| 171 | • 如果 AI 给出错误建议导致事故,升级路径是什么?谁有暂停权? | ||
| 172 | |||
| 173 | • 知识库与记录是否足够完整、准确、一致?数据治理是否到位? | ||
| 174 | |||
| 175 | • 可观测性如何做:错误率、升级率、回退率如何监控? | ||
| 176 | |||
| 177 | **场景二:变更实施与发布管理中的 AI 辅助** | ||
| 178 | |||
| 179 | 很多组织希望 AI 做风险评估、依赖关系识别、变更窗口建议。你可以让 AI 提升质量,但不能让它越界: | ||
| 180 | |||
| 181 | • 风险提示与依赖分析可以自动化 | ||
| 182 | |||
| 183 | • 批准与最终决策必须由授权人承担责任 | ||
| 184 | |||
| 185 | • 如果 AI 推荐了错误窗口导致中断,证据链必须能追溯:推荐依据是什么,谁批准了,谁执行了 | ||
| 186 | |||
| 187 | **场景三:知识管理与文档生成** | ||
| 188 | |||
| 189 | 这是 AI 最适合切入的地方之一,但也最容易埋雷: | ||
| 190 | |||
| 191 | • AI 可以生成草稿与摘要,但必须有人工审核机制 | ||
| 192 | |||
| 193 | • 知识条目必须具备来源与版本控制,否则错误会被规模化复制 | ||
| 194 | |||
| 195 | • 你要建立反馈回路:哪些条目被引用、哪些条目导致误导、如何持续改进 | ||
| 196 | |||
| 197 | 你会发现,AI 真正有价值的切入点,往往在“信息整理、建议生成、辅助决策”这些环节,而不是一上来就把它推到“替你拍板”的位置。 | ||
| 198 | |||
| 199 | |||
| 200 | ITIL 第5版谈人与 AI 协作,核心不是让你选更聪明的模型,而是让你建立更可靠的治理:把能力边界说清,把控制点放在高风险决策处,把证据链做成可审计,把责任分配落到人身上。你只要把这四件事做扎实,AI 才会成为组织能力的放大器,而不是风险的放大器。 | ||
| 201 | |||
| 202 | |||
| 203 | 我是AI+ITIL教练长河achotsao,欢迎添加长河老师微信 achotsao 深入交流,即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析,全网同名。 |