AI卓越中心怎么建：组织模式、岗位职责与章程模板

AI卓越中心的价值，在于帮助业务团队把 AI 用到实处，并明确谁来负责。对于 100 至 2,000 人的企业，先梳理哪些决策需要统筹；如果两位明确的负责人就能协调好这些工作，不妨先设一个 AI 工作小组，再考虑成立部门。

真正需要产出的是一份可执行的工作约定：优先解决哪些问题、遵循哪些标准、谁提供共用工具，以及上线后由谁持续负责。仅仅调整汇报关系，回答不了这些问题。

核验日期：2026 年 10 月 26 日。 下文有关组织建设的指导已对照 Microsoft、IBM 和 NIST 的现行资料核验。文中的章程、人员配置建议及 90 天推进安排，都是建议的运作方案，并非行业人员配置基准，也不承诺在相应期限内完成交付。

AI卓越中心到底负责什么？

AI卓越中心（AI Center of Excellence，简称 AI CoE）负责统筹专业能力与共享服务，帮助企业各团队使用 AI。它将业务优先事项与交付、评估、标准及培训衔接起来。它的权限来自高管批准的授权，而不是“卓越”二字。

可以把它想象成一座教学温室：温室提供共用设备、种植方法和专家指导，但每块苗床仍要由负责的园丁照料。CoE 可以为客服回复起草提供经过验证的方法，但客户回复是否准确、审核工作如何开展，仍由客服负责人承担责任。

Microsoft 的 CoE 指南涵盖需求受理、试点、标准、技能、可复用资产及成效报告。对于本文面向的企业，可以将这些工作归为四项职责。

与业务负责人一起筛选应用场景

维护一份按优先级排序的待办需求清单。一个应用场景，应当对应特定工作流程中的具体任务，例如根据已批准的帮助文档起草客服回复。“把 AI 用于客户服务”过于宽泛，既难以分工，也无法评估。

每项需求都应明确负责人、当前绩效基线，以及可观察的结果。优先选择数据可获取、产出可由人工核查的任务。一个经常发生、出错后可以补救的任务，比一场演示效果惊艳却无法融入日常工作的展示，更适合作为起点。

优先事项由企业的 AI 战略确定。CoE 的职责是将其转化为获得资源支持的工作，并把依赖关系说清楚，而不是在不知不觉中另起一套业务战略。

把标准写成人人能执行的规则

明确允许使用哪些数据、访问权限如何设置、需要哪些审核、如何记录变更，以及什么情况下必须停用系统。再把这些标准转化为可直接采用的默认设置和简短检查清单。

以客服回复起草为例，规则可以是：只使用批准的知识来源，向审核者展示出处，每条对外回复都必须经客服人员批准。笼统地要求“负责任地使用 AI”，并不能让客服人员知道具体该做什么。

将技术规则与企业的 AI 使用规范衔接起来，让员工清楚日常工作中哪些事可以做。

为共用工具和评估方法明确负责人

共用能力都要有人负责，包括获准使用的访问入口、可复用集成、系统清单、工作流程示例，以及开展评估的方法。评估是指用有代表性的案例，对完整工作流程的表现进行可重复的检验。

CoE 负责共用方法，业务负责人则定义自己的任务做到什么程度才算合格。即便客服问答与招聘流程使用同一个底层模型，客服问答测试集也不能证明招聘流程合格。

围绕真实工作培训团队

教会客服审核人员识别缺乏依据的表述，教会工程师测试权限边界，教会管理者区分“有人在用”和“确实有效”。让参与者实际演示如何完成任务，以及出错后如何应对。

提示词工作坊可以帮助大家认识一款工具，却无法证明某个人已经能够安全地操作会带来重大影响的工作流程。

三种组织模式，企业该怎么选？

选择模式，要看交付责任与日常运行责任放在哪里才靠得住。单凭人数判断并不可靠：大企业也可能缺少 AI 专业人才，小型软件公司却可能拥有能力成熟的产品团队。

这些模式的名称并没有完全统一的边界。Microsoft 的组织运作模式指南使用集中式、混合式和联邦式的划分，也将“中心提供平台、各团队分头交付”的安排称为轴辐式。IBM 对 CoE 的介绍则采用略有不同的划分。分配工作时，可以以下面的定义为准。

集中式的优势，在于有意识地集中稀缺专业能力。 产出是否有助于业务流程，仍由业务负责人判断。应让需求队列保持可见，避免一个小型技术团队变成外界看不见的候办室。

多个部门开始需要相同基础能力时，轴辐式通常是值得优先考虑的方案。 以一家假设有 700 人的企业为例，中心团队可以维护访问入口和评估工具，客服部门负责回复质量，财务部门负责自己的文档流程。集成出错由谁修复、每项服务由谁暂停，都应写清楚。

联邦式要求各团队具备实际运行能力，光有热情还不够。 对于一家假设有 1,800 人的企业，在下放日常发布决策权之前，应要求每个参与的业务单元说明负责人是谁，并展示测试记录、监控及事件响应能力。达不到这一要求的部门，应继续采用支持更充分的安排。

不同工作流程可以采用不同模式。敏感的共享服务可以保持集中管理，而能力足够的部门可以自行管理一个范围明确的内部助手。是否授权，应由团队和任务的实际证据决定，无须等全公司统一“毕业”。

AI CoE 与 AI 治理委员会如何分工？

AI CoE 提供交付能力；AI 治理委员会行使被授予的政策与风险管理权限。双方需要协作，也可以有人员重叠，但各自做哪些决策，必须分得清。

例如，委员会可以批准企业的风险容忍度、禁止用途及例外处理流程；CoE 则将这些决定落实为系统配置、评估要求、培训和运行支持。企业的 AI 治理框架应明确两者的关系。

可以参考以下权限划分：

委员会不必逐一审核所有已获批准的内部文稿起草流程。同样，CoE 也不能仅因为系统由自己搭建，就擅自接受重大风险。谁能批准例外、例外适用什么范围、何时失效，都要记录在案。

NIST 的 AI RMF 核心部分在 GOVERN 2.1 中要求记录职责，在 GOVERN 2.3 中要求高管对 AI 风险决策负责。落实这些要求，比是否新设委员会更重要。只要职责范围明确，现有的领导层议事机制或风险管理机制也可以承担相应权限。

先分清职责与决策权，再考虑招聘

先确保每项职责有人承担，再设岗位。有些工作需要专人投入，有些则需要在需要时能可靠地获得现有专家支持。列出职责，并不意味着组织架构图每一行都要新招一个人。

高管发起人： 为已商定的优先事项提供资源，协调部门冲突，并指定各项决策的授权主体。COO 可以牵头运营变革，CTO 可以牵头共用技术能力建设。即便两人都参与，也应指定一位承担最终责任的发起人。

CoE 负责人： 负责授权范围、需求受理流程、共用待办清单及汇报。在章程授予的权限内，此人必须有权暂缓没有负责人或尚未准备就绪的提案。

业务流程负责人： 提供基线，定义合格结果，安排审核人员，并对实际运行成效负责。以客服回复起草为例，这个角色应由对客服质量负责的管理者担任，而不是由最懂模型的人担任。

技术与评估负责人： 维护共用集成、访问控制、可重复测试及变更记录。当潜在影响需要独立审核时，应将修改系统的权限与批准其业务结果的权限分开。

数据与风险协作方： 数据负责人判断信息是否适合且获准用于相应用途。安全、隐私、法务及其他相关专家在各自职责范围内开展评估。CoE 负责协调他们的意见，并不会自动获得他们的权限。

培训推广负责人及部门骨干： 将批准的工作流程转化为培训内容，收集用户遇到的问题，更新操作指引。部门骨干需要有明确保障的工作时间和获取技术帮助的渠道，不能只有一个荣誉头衔。

每个投入正式运行的工作流程，还应指定由谁接收事件报告、谁有权停止服务，以及谁组织恢复。AWS 的 CoE 指南包含正式的事件处理职责和响应措施。在试点转为日常工作之前，就应将这些安排写入运作约定。

什么时候两个人的 AI 工作小组就够了？

如果两位明确的执行负责人，加上现有专家支持，就能承担协调工作，可以先采用 AI 工作小组的形式。这是一种起步建议，既不是通用的最低人员配置，也不意味着两个人可以运行所有 AI 系统。

指定一位运营或产品负责人，负责需求受理、流程设计、培训和成效衡量；再指定一位技术负责人，负责获准使用的访问入口、集成、评估和支持。为他们安排高管发起人，并确保他们能获得现有数据、安全和法务负责人的支持。起步时可以先划拨工作时间，不一定新增全职岗位，但直属管理者必须保障这部分时间不被挤占。

以一家假设有 150 人的服务企业为例，如果只是试行有人监督的文稿起草流程，这样的安排就可能足以建立共用实践，并判断是否有必要设立更大的职能团队。两位负责人协调工作，产出仍由相关业务部门审核。

符合以下条件时，可以继续采用工作小组形式：

• 在推进的工作量足够小，能够得到妥善支持和监控。
• 各部门能够使用共用工具，无须大量定制开发。
• 现有负责人能够及时解答数据与风险问题。
• 明确分配的工作容量足以覆盖日常支持和评估。

当反复出现的跨团队依赖、积压未解决的需求或运行支持需要超出这一容量时，再扩大团队。

对于潜在后果更严重的工作，应单独评估所需能力。小企业如果建设会影响人的权利或安全的系统，可能在开展大范围培训推广之前，就需要专业监督。

一页式 AI CoE 章程模板

可以从这份精简章程起步，将方括号内的字段替换为具体姓名和承诺。模板按一页篇幅设计，填入细节后仍需检查排版。只要范围控制得当，两个人的工作小组也能使用同一份章程。

AI卓越中心章程：[公司名称]

发起人与期限。 发起人：[姓名]。CoE 负责人：[姓名]。生效日期：[日期]。复审日期：[日期，首次设为第 90 天]。投入人员及工作时间：[具体承诺]。

职责授权。 帮助[业务职能部门]通过适当使用 AI 改善[具体目标]。确定应用场景优先级，维护共用标准与工具，协调评估，并培训团队运行获准使用的工作流程。

范围。 覆盖[工作流程、用户和环境]。从[范围明确的试点]开始。排除[禁止用途及本授权范围之外的工作]。业务负责人继续对各自流程和结果承担责任。

决策权。 发起人批准优先事项及资源投入。CoE 负责人管理需求受理，并在政策范围内批准受支持的技术方案。数据负责人批准每项拟议的数据用途。指定服务负责人在取得必要证据并完成专家审核后批准发布。[风险决策者]决定例外事项及其有效期。[运行人员]可以暂停不安全或发生故障的服务；经复核后，由[负责人]批准恢复。任何角色都无权免除另一负责人必须作出的审批。

需求受理。 通过[表单／位置]提交工作流程、业务负责人、基线、预期成效、用户、数据、拟执行的操作、可预见的危害、评估方法及支持负责人。每周审核。将决定记录为推进、准备、升级处理或终止，同时注明理由、负责人及下次处理日期。未解决的优先级冲突提交发起人，政策例外提交风险决策者。未回应不等于批准。

共享服务。 在[位置]维护获准使用的访问入口、AI 清单、可复用方案、评估方法、培训材料及事件联系人。每项资产均有负责人和复审日期。各工作流程的验收标准由相应业务负责人负责。

衡量指标。 跟踪通过验收的任务结果、质量问题、需求决策耗时、持续维护资产的复用情况，以及用户实际展示的操作能力。为每个试点记录基线、目标、证据来源、汇报负责人及终止条件。绩效衡量必须计入审核与返工。

工作节奏与移交。 每周开展需求审核，每月由发起人复审。转入日常使用之前，确认运行责任归属、监控、事件响应及回退方案。到复审日期时，根据证据决定扩大、修订或终止本项授权。

详细操作规程另行维护，并在章程中提供链接。章程应让人无须翻阅整本手册，就能解决责任归属争议。

需求受理，最后必须有明确决定

需求受理应让提案尽快进入有人负责的下一步。先收集足以决定后续行动的信息，再根据工作流程可能造成的后果，要求相应深度的证据。

借助 AI 就绪度评估，检查拟开展的任务、所需数据及相关人员。全公司的积极性评分，无法证明某个具体工作流程已经准备就绪。

假设客服经理提出，用已批准的帮助文档生成回复草稿。一份有用的需求记录，应明确这位经理、资料集合、审核者、当前处理流程，以及哪些错误会使结果不可接受。还应明确：草稿不能自动发送。

如果无人能对资料集合负责，就将提案转入准备；如果申请的数据用途超出政策允许范围，就升级处理。只有负责人、获准使用的数据、审核流程和评估安排都已就绪，才能进入试点。如果预期收益不足以支撑投入，或拟议用途本身被禁止，就应终止。

在生成看起来很出色的示例之前，先定义试点验收标准。以客服回复起草为例，要评估事实依据、来源相关性、不当承诺、信息披露，以及得到一条合格回复所需的审核工作量。也要加入棘手案例，例如文档相互矛盾，或知识库无法回答的问题。

CoE 应让这些检查可以重复执行，客服负责人则应依据实际服务要求判断结果。如果审核生成内容比原本直接完成任务更耗时，即便技术上生成成功，也可能无法通过业务检验。

AI卓越中心如何起步：前 90 天怎么安排？

用前 90 天建立运作约定，并通过一个范围明确的试点收集证据。把这些日期视为复审节点。一个未达到验收标准的工作流程，不会因为日历走到最后阶段，就自动获得正式发布资格。

1. 1

   第 1-30 天：明确工作与权限

   确定发起人和执行负责人。盘点现有 AI 使用情况，包括业务软件中已经内置的 AI 功能。找出重复工作、尚不明确的数据权限，以及缺少支持的服务。

   商定章程，为首个工作流程选择组织模式。建立该流程的基线，补全需求受理记录。公布获准用途的指引、需求提交入口及事件联系人。

   阶段完成所需证据： 已签署的授权文件、可用的清单、明确的流程负责人及商定的评估计划。如果数据访问问题仍未解决，下一阶段就应继续做准备工作。

2. 2

   第 31-60 天：测试范围明确的工作流程

   在已批准的范围内开展试点。记录相关系统配置、指令和来源材料，确保能解释某个结果是如何产生的。培训负责审核产出的人员。

   按照商定标准评估常规案例和失败案例。除产出质量外，同时记录审核时间与返工情况。演练如何暂停工作流程，并回到原有流程。

   阶段完成所需证据： 经审核的结果、问题记录、完成培训的运行人员，以及可执行的回退方案。参考 NIST AI RMF 指南中的证据实践，将风险、测试和决策衔接起来。

3. 3

   第 61-90 天：作出决定，明确持续运行责任

   由流程负责人和必要的审核者决定继续、调整还是终止，并记录理由。有清晰证据支持的试点终止，同样是有价值的决定。

   如果继续推进，就分配监控、支持、变更审核及退役职责。只发布其中可复用的部分，并指定维护者。判断下一项需求能否由现有 AI 工作小组承担，还是揭示了 CoE 需要补充的具体能力。

   阶段完成所需证据： 已记录的处置决定、所有继续运行事项均有人确认接手，以及排好优先级的后续待办清单。只有证据支持时，才扩大范围。

衡量的是审核通过后的成果

应在审核和修正之后衡量成效。只统计生成了多少份草稿，会掩盖把草稿变成可用内容所需的工作。

在客服试点中，应将得到一条合格回复的总耗时与原有流程基线比较，计入审核和返工。质量与速度必须同时检查，不能让更快的流程靠发送更差的答案来显得成功。小规模试点只能提供局部证据，不能据此估算全公司的生产力提升。

将 CoE 自身的指标与工作流程的指标分开：

• 决策耗时： 从完整需求提交到记录决策的耗时中位数。因信息缺失造成的延误应单独跟踪。
• 质量： 按试点前商定的标准，记录不可接受的结果和严重失败。记录严重程度，而不只是平均分。
• 复用： 哪些工作流程使用了持续维护的共用资产，并且能明确其版本与负责人。
• 能力： 用户是否能完成任务、识别失败，并按规定路径升级处理。

培训出席情况和活跃账号数，可以帮助判断推广使用中的问题，却不能证明工作已经改善。除非业务部门能说明节省出的工作容量具体如何使用，否则不要把估算的节省时间直接换算成财务收益。

哪些团队应该现在行动，哪些可以再等等？

当协调问题已经显现，就应行动。如果现有责任安排仍足以承接工作，可以暂缓成立新部门。

COO 与运营负责人： 当团队重复投入、提案缺少业务负责人，或没人说得清哪些试点应该继续时，就应牵头明确授权。首先要决定的是：哪个结果最重要，由谁负责。

CTO 与技术建设者： 当各自维护相同能力反复引发问题时，应集中管理共用访问入口、评估方法及运行支持。只向能够运行自建系统的团队下放交付责任。

采购方与采购负责人： 扩大投入承诺之前，借助 CoE 明确获准用途、技术要求及运行责任归属。除非正式重新分配，采购权限与合同审核仍由原有负责人掌握。

已经拥有有效且获准使用流程的团队： 继续使用。成立 CoE 的消息，并不意味着所有工具都要替换、所有决策都要重审，也不意味着已经符合商定标准的流程必须迁移。

关于 AI CoE，哪些期待被夸大了？

中心不会仅凭自身存在就创造价值。它的价值，在于促成了哪些工作，又帮助避免了哪些错误决策。

组织架构更大，不代表成熟度更高。 即便委员会规模庞大，也可能没有人负责恢复发生故障的工作流程。增设议事机制之前，先确定运行负责人。

工具获批，不代表所有用途都获批。 允许起草内部笔记，不等于允许同一系统向客户发送承诺。审批必须明确用途、数据范围及操作边界。

共用评估体系，不能为所有场景背书。 可以复用的是方法和基础设施。具体业务领域的案例、危害及验收标准，仍需要业务负责人判断。

CoE 不必永久包揽交付。 随着团队证明自身能力，可以逐步下放日常工作；适合统一负责的服务则保留在中心。复审 CoE 的授权范围，应与复审试点同样认真。

常见问题

什么是 AI卓越中心？

AI卓越中心是一项统筹职能，帮助企业确定 AI 应用场景的优先级、制定标准、提供共用工具和评估能力，并培训人员。它既可以集中交付系统，也可以支持业务团队自行建设和运行系统。

哪些内容不该交给 AI，哪些事不该让 AI 做？

不要提交企业数据规则禁止的信息，也不要要求系统执行超出其获准范围的操作。在工作场景中，CoE 或 AI 工作小组应公布允许的用途，并将不确定的情况转交相关数据或风险负责人处理。

AI 可能带来哪些风险？

风险因工作流程而异，可能包括输出错误、敏感信息泄露、不公平对待，以及未经授权的操作。应先识别具体任务可能造成的后果，再配置管控措施、审核者及恢复路径。一份通用风险清单不能替代这项评估。

下周一就可以做的事

请发起人、一位运营负责人和一位技术负责人围绕一个反复发生的工作流程坐下来。填好章程中的职责授权和决策权，明确谁对结果负责，并写下出现哪些证据时就应停止。如果这几个人足以管理商定的范围，就先以 AI 工作小组起步，让实际工作量决定何时扩充。

想获取更多将 AI 用于企业运营的实用指南，欢迎订阅邮件通讯。