AI能自动处理工单后，企业为什么反而更需要ITSM？

当AI只能回答问题时，企业需要知识库来沉淀信息；当AI开始执行操作时，企业更需要流程、权限、审批和审计来约束行为。一个典型的场景是：员工对系统说"请帮我开通生产数据库的只读权限"，传统模式需要创建工单、分派任务、发起审批，再由运维人员执行。而AI Agent进入企业后，它可以识别员工身份、查询部门和项目、关联数据库配置项、匹配权限策略、发起审批，并在审批通过后直接调用账号系统执行开通。过去需要多个人、多个系统协作完成的流程，现在可能几分钟就能闭环。

概述

然而，当AI承担起执行角色时，一系列问题也随之浮现：如果AI申请错了权限怎么办？谁批准了这次操作？它依据什么信息作出判断？出现事故后，能不能还原完整过程？这些追问指向一个核心命题——AI越能执行任务，企业越需要一套约束执行的系统。

从辅助坐到端到端执行

传统ITSM默认真正执行任务的是人，系统负责建单、分派、通知和记录，工程师负责判断与操作。但当AI可以调用CMDB、监控平台、账号系统、云平台和企业内部接口时，它就不再只是一个功能模块，而是拥有身份、权限和执行能力的数字员工。企业必须认真回答七个关键问题：它是什么角色，可以查看哪些数据？它可以调用哪些工具，执行哪些动作？哪些操作可以自动完成，哪些必须审批？什么情况下转交人工？失败之后如何停止、补偿和回滚？如何记录每一次判断和工具调用？如何评价执行质量、业务结果与模型成本？因此，AI Native ITSM不能只是在工单页面增加一个聊天框。真正的AI Native，是把AI作为流程中的正式参与者：它可以提出建议，也可以在权限允许的范围内执行；风险超过阈值时，流程必须自动进入审批或人工接管。

AI Native ITSM需要回答的七个问题

首先，CMDB是AI理解企业的上下文底座。同一个"服务器异常"，可能发生在测试环境，也可能发生在核心生产系统。如果没有CMDB，AI看到的只是一条孤立告警；有了业务服务、应用、服务器、数据库、负责人和依赖关系，它才能判断影响范围与操作风险。其次，Agent必须在明确的权限边界中执行——可以查询服务器状态，不代表可以重启服务器；可以生成变更方案，不代表可以直接执行生产变更。Agent需要独立身份、角色权限、工具白名单和高风险审批策略。第三，每一次执行都必须能够还原。系统需要记录用户请求、上下文来源、模型与Agent判断结果、工具参数、审批过程、执行返回、人工接管以及最终业务影响。没有这些记录，企业就无法完成事故追踪、安全审计和责任认定。企业级AI的竞争重点，不只是模型回答得好不好，更重要的是它能不能在角色权限、企业上下文和完整审计的约束下安全完成工作。

三大治理要点

从更深层看，员工并不想要一张工单，而是希望电脑恢复正常、账号完成开通、订单成功处理。普通AI客服会回答"请联系管理员申请权限"；而AI Native ITSM应该能识别身份和需求，查询服务与权限策略，生成申请，找到审批人，审批通过后调用连接器执行，验证结果、写入审计，并在到期后自动回收权限。真正的闭环是：理解请求→聚合上下文→风险判断→流程审批→工具执行→结果验证→审计留痕→知识沉淀。企业真正需要的不是一个会聊天的机器人，而是一个能够在制度约束下完成工作的数字员工。对于国内企业而言，协作入口可能是飞书、企业微信或钉钉，身份来自统一认证平台，审批发生在办公协同系统，资产数据分散在云平台、监控系统、数据库和内部应用中。因此，面向国内企业的AI Native ITSM至少需要四层能力：流程引擎（配置事件、问题、变更、服务请求和审批，决定节点由人工还是AI处理）、CMDB与企业上下文（建立业务服务、应用、资源、人员和组织之间的关系）、连接器体系（连接协同工具、监控、云平台、账号系统和内部应用，让AI可以跨系统执行）、AI治理（管理Agent身份、权限、审批、审计、成本、质量和人工接管）。

如有侵权，请联系删除。