Version 3.1 by superadmin on 2026/02/09, 17:04
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:1.png||height="346" width="571"]] | ||
| 7 | |||
| 8 | |||
| 9 | 很多组织在推动 AI 时,最常见的表达是“我们要上一个大模型”“我们要做智能服务台”“我们要让 AI 自动化运维”。这些话都不算错,但它们刻意忽略了一个更关键的问题: | ||
| 10 | |||
| 11 | • 谁来承担决策责任 | ||
| 12 | |||
| 13 | • 出错时怎么追溯 | ||
| 14 | |||
| 15 | • 风险边界在哪里 | ||
| 16 | |||
| 17 | • 数据如何被使用与保护 | ||
| 18 | |||
| 19 | |||
| 20 | 从治理角度看,你要治理的不是模型本身,而是 AI 进入管理体系后带来的新型风险结构。AI 让建议与动作可以规模化,也让错误、偏见与幻觉可以规模化;AI 让决策链条更长,也让责任更容易被稀释。正因为如此,ITIL 第5版才会把 AI 治理单独拎出来:它不是一个“选修话题”,而是一条必须补齐的主干能力。 | ||
| 21 | |||
| 22 | |||
| 23 | == 一、更新内容概述:六个核心要点为什么最终都指向“AI 治理必须前置” == | ||
| 24 | |||
| 25 | 按照惯例,本篇依然完整覆盖 ITIL 第5版更新内容要点概述。我会从合规与风险负责人的角度解释:这六个变化为什么让 AI 治理成为必修。 | ||
| 26 | |||
| 27 | **1、定位升级:数字产品和服务管理** | ||
| 28 | |||
| 29 | 当管理对象扩展到端到端数字产品与服务,AI 不再只影响后台效率,而会直接影响客户体验与业务结果。风险因此从“内部失误”升级为“外部影响”。 | ||
| 30 | |||
| 31 | **2、生命周期模型升级:八个活动覆盖从发现到支持** | ||
| 32 | |||
| 33 | AI 会出现在多个活动中:发现、设计、构建、转换、运营、交付、支持。治理不能只盯某个部门,而要覆盖全生命周期。 | ||
| 34 | |||
| 35 | **3、人工智能进入方法论核心** | ||
| 36 | |||
| 37 | 这意味着 AI 不是项目,而是管理体系的一部分。只要进入体系,就必须有治理结构、可审计性与持续改进机制。 | ||
| 38 | |||
| 39 | **4、指导原则强调取舍** | ||
| 40 | |||
| 41 | AI 治理的难点不在“禁止”,而在“取舍”:哪里可以自动化,哪里必须人工确认;哪里允许试点,哪里必须严格控制。 | ||
| 42 | |||
| 43 | **5、实践从清单走向组件库** | ||
| 44 | |||
| 45 | AI 能力会作为组件被组合到不同实践中。没有统一治理规则,组件组合会把风险扩散到全系统。 | ||
| 46 | |||
| 47 | **6、持续改进对象扩大** | ||
| 48 | |||
| 49 | AI 的表现会随数据、场景与环境变化。治理必须可更新,必须能通过持续改进不断修正边界与控制点。 | ||
| 50 | |||
| 51 | 因此,AI 治理不是附加条款,而是 ITIL 第5版“AI 原生管理体系”的底座。 | ||
| 52 | |||
| 53 | |||
| 54 | == 二、AI 治理到底治理什么:三条主线,比“伦理口号”更重要 == | ||
| 55 | |||
| 56 | 很多组织谈 AI 治理容易空泛。我建议你抓住三条主线,它们每一条都能落到制度与动作上。 | ||
| 57 | |||
| 58 | **1、风险边界:AI 可以做什么,不可以做什么** | ||
| 59 | |||
| 60 | • 哪些场景允许 AI 直接对外沟通 | ||
| 61 | |||
| 62 | • 哪些场景 AI 只能给建议,不能自动执行 | ||
| 63 | |||
| 64 | • 哪些场景必须人工批准,必须保留人工确认点 | ||
| 65 | |||
| 66 | 这条主线的本质是:把 AI 的作用域限定在可控范围内。 | ||
| 67 | |||
| 68 | **2、数据质量与数据治理:没有可靠数据,治理无从谈起** | ||
| 69 | |||
| 70 | • 数据是否完整、准确、一致 | ||
| 71 | |||
| 72 | • 记录是否可追溯、可审计 | ||
| 73 | |||
| 74 | • 训练与推理用到的数据是否合规 | ||
| 75 | |||
| 76 | 数据治理做不好,AI 治理就会退化成口号,因为你无法证明风险被控制。 | ||
| 77 | |||
| 78 | **3、决策责任:谁承担责任,谁被问责** | ||
| 79 | |||
| 80 | • 谁批准 AI 建议被采纳 | ||
| 81 | |||
| 82 | • 谁批准自动化动作被执行 | ||
| 83 | |||
| 84 | • 出错时责任如何追溯到人 | ||
| 85 | |||
| 86 | AI 治理的核心,是防止责任被“算法”稀释。 | ||
| 87 | |||
| 88 | 这三条主线加在一起,就是 AI 治理的骨架:边界、数据、责任。 | ||
| 89 | |||
| 90 | [[image:https://my.feishu.cn/space/api/box/stream/download/asynccode/?code=YjkzN2Q5YWM4ZGViZDNjY2YwZjQ3MmMwOGI3ZWIzNDlfWlNMVnR4SnBWWDJOZjRZcEIxenBEb25wWHhtaFZDbHdfVG9rZW46SE90NWJxbGZCbzdzd2R4UjBzTWNoSTNobjRlXzE3NzA2MjM1MjY6MTc3MDYyNzEyNl9WNA||height="294" width="514"]] | ||
| 91 | |||
| 92 | |||
| 93 | == **三、为什么 AI 治理必须单独拎出来:因为 AI 改变了风险传播方式** == | ||
| 94 | |||
| 95 | 传统管理体系里的错误传播通常是线性的:某个环节错了,影响逐步扩散。AI的风险传播更像指数级: | ||
| 96 | |||
| 97 | • 一条错误知识被生成并复用,影响成百上千次回复 | ||
| 98 | |||
| 99 | • 一个错误分类规则被自动执行,错误分派规模化 | ||
| 100 | |||
| 101 | • 一个错误补救动作被自动触发,事故被自动放大 | ||
| 102 | |||
| 103 | 因此,AI 治理必须回答一个新问题:如何在规模化之前截断风险传播。你需要的是“门禁与回滚”,而不是“事后追责”。 | ||
| 104 | |||
| 105 | |||
| 106 | == **四、AI 治理怎么做才可执行:四个机制,把治理落到系统里** == | ||
| 107 | |||
| 108 | 治理如果只停在政策与宣导,就一定失败。可执行的 AI 治理至少要有四个机制。 | ||
| 109 | |||
| 110 | **1、场景分级与风险分级** | ||
| 111 | |||
| 112 | • 对外沟通场景、关键业务功能场景、合规敏感场景,必须高等级控制 | ||
| 113 | |||
| 114 | • 内部辅助场景、低风险标准化场景,可以采用更轻量治理 | ||
| 115 | |||
| 116 | 分级的意义是:把治理强度放在该放的位置。 | ||
| 117 | |||
| 118 | **2、人工确认点与授权边界** | ||
| 119 | |||
| 120 | • 哪些 AI 建议必须人工批准 | ||
| 121 | |||
| 122 | • 哪些自动化动作必须由变更授权人批准 | ||
| 123 | |||
| 124 | • 谁拥有暂停权与回滚权 | ||
| 125 | |||
| 126 | 没有人工确认点,治理就没有落点;没有授权边界,责任就会漂移。 | ||
| 127 | |||
| 128 | **3、证据链与可审计性默认开启** | ||
| 129 | |||
| 130 | • AI 建议依据必须可追溯 | ||
| 131 | |||
| 132 | • 采纳与否必须留痕 | ||
| 133 | |||
| 134 | • 执行轨迹必须可回放 | ||
| 135 | |||
| 136 | 这不是为了形式,而是为了在事故发生时能快速定位与纠偏。 | ||
| 137 | |||
| 138 | **4、持续监督与持续改进闭环** | ||
| 139 | |||
| 140 | • 误导输出率、误分类率、自动化误触发率必须被度量 | ||
| 141 | |||
| 142 | • 超阈值必须触发暂停与复核 | ||
| 143 | |||
| 144 | • 有效修正必须固化为规则与门禁 | ||
| 145 | |||
| 146 | AI 会变,场景会变,治理也必须能跟着变。 | ||
| 147 | |||
| 148 | 这四个机制一旦落到系统里,AI 治理就不再是抽象概念。 | ||
| 149 | |||
| 150 | |||
| 151 | == 五、你真正需要治理的风险类型:把风险说清楚,治理才会具体 == | ||
| 152 | |||
| 153 | 为了避免泛泛而谈,我把 AI 相关风险按管理体系常见表现归成五类。你可以用来做治理清单,但更重要的是用来做“边界划分”。 | ||
| 154 | |||
| 155 | • **偏见**:某些类别用户被系统性误判或被忽视 | ||
| 156 | |||
| 157 | • **幻觉**:生成看似合理但实际错误的内容 | ||
| 158 | |||
| 159 | • **违规与泄露**:不当使用敏感数据,或对外泄露信息 | ||
| 160 | |||
| 161 | • **责任不清**:AI 建议被采纳后出错,却找不到责任人 | ||
| 162 | |||
| 163 | • **自动化误触发**:补救动作被错误触发,影响扩大 | ||
| 164 | |||
| 165 | 治理不是把这些风险写在文档里,而是要给每类风险配置控制点:门禁、阈值、回滚与审计。 | ||
| 166 | |||
| 167 | |||
| 168 | == 六、AI 治理与价值系统如何联动:治理不是孤岛 == | ||
| 169 | |||
| 170 | ITIL 第5版讲价值系统五件套联动,AI 治理必须放在系统里理解,否则只能变成“合规部门的独角戏”。 | ||
| 171 | |||
| 172 | • **指导原则**:提供取舍语言,决定哪里可以快、哪里必须稳 | ||
| 173 | |||
| 174 | • **治理**:提供结构与责任,决定谁批准、谁监督、谁承担责任 | ||
| 175 | |||
| 176 | • **价值链**:提供落点,决定 AI 嵌入哪些活动、影响哪些价值流 | ||
| 177 | |||
| 178 | • **实践**:提供能力组件,决定控制点落在哪些流程与工具里 | ||
| 179 | |||
| 180 | • **持续改进**:提供更新机制,保证治理规则能随风险变化不断迭代 | ||
| 181 | |||
| 182 | 当这五件套联动,AI 治理才会从“限制创新”变成“保障创新可持续”。 | ||
| 183 | |||
| 184 | |||
| 185 | ITIL 第5版把 AI 治理单独拎出来,是因为 AI 改变了风险传播方式,也改变了责任结构。你要治理的不是模型,而是风险边界、数据质量与决策责任。只要你建立场景分级、人工确认点、可审计性证据链与持续监督闭环,AI 才能成为放大组织能力的杠杆,而不是放大风险的放大器。 | ||
| 186 | |||
| 187 | |||
| 188 | 我是AI+ITIL教练长河achotsao,欢迎+V:achotsao交流,即可第一时间获得ITIL 第5版最新动态及官方特邀中国区大使的深度解析。 |