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