AI治理怎么落地：中小企业的一页框架

AI治理可以从5项管控措施入手：AI使用清单、数据规则、人工审核、供应商审查和事件处置流程。没有专职合规团队的企业，至少要为每项措施明确负责人，并留下实际执行的证据。这样，回答客户问卷时，才能说清楚自己做到了什么，而不是承诺一些无法证明的措施。

可以用美国国家标准与技术研究院的AI风险管理框架，即 NIST AI RMF，来组织这项工作。如果外部认证有明确的商业价值，再考虑国际AI管理体系标准 ISO/IEC 42001。至于自身角色和使用场景涉及哪些法律义务，则需要单独核查欧盟《AI法案》。三者解决的问题各不相同。

下文对框架的说明及欧盟相关日期，已于2026年10月20日依据NIST、ISO和欧盟委员会的官方页面核实。本文提供的是运营层面的指导，不构成法律意见；具体法律义务应咨询具备相应资质的专业人士。

什么是AI治理？

AI治理要回答的是：谁可以使用AI，用来做什么工作，可以接触哪些数据，以及当AI给出答案或采取行动时，由谁承担责任。政策负责定规则，审批、技术限制和记录则让规则真正执行起来。

不妨把它想成一座共用花园。有一张允许种植的植物清单，并不等于已经明确谁能开门、谁能调整灌溉设施、花坛损坏后又由谁处理。还需要划清边界、指定负责人，并建立发现和修复问题的办法。买来更好的园艺设备，解决不了这些问题。

放到企业里，客服助手从“起草回复”变成“直接退款”，就是一个具体例子。模型可能没变，权限却变了。治理机制应当在新权限影响客户之前，发现并审查这一变化。

数据治理管的是信息本身：访问权限、质量、允许的用途和保留期限。AI治理还要管系统的行为：它可以推断什么、建议什么、执行什么，如何检查这些行为，以及后果由谁负责。

一页AI治理框架：把责任、规则和证据写清楚

对于20至500人的企业，流程应当与每种用途可能造成的后果相匹配。每项管控措施都要有负责人、有规则、有记录。下面是面向中小企业的原创运营模板，不是认证检查清单，也不能替代针对具体系统的评估。

适用范围： 员工使用AI，以及销售、客服和工程工作中的AI功能，包括现有软件内置的AI功能。
最终负责的高管： COO或创始人。各职能负责人负责本部门的工作流程，IT或安全负责人负责访问权限和技术管控。
触发审批的情形： 新增用途、敏感数据来源、对外受众或操作权限，都必须先审查，再使用。

复查频率： 每季度复查台账；用途、权限、供应商行为或数据发生变化时，也要复查。这只是建议的起始频率，潜在后果越严重，复查就应越频繁。
例外管理： 写明批准人、理由、限制条件和到期时间。没有记录的例外，就是尚未看清的风险。
向董事会或客户汇报： 说明覆盖哪些范围、已落实哪些管控、还有哪些问题未解决，以及下一项决策由谁负责。

这一页要保持简短。详细清单和证据放在后面；记录涉及客户或员工信息时，应限制访问。这一页的作用，是让人能据此找到一套实际运行的流程。

销售、客服与代码开发中的AI治理实践

先处理最可能泄露数据或影响客户的工作流程。只统计订阅了多少工具，会漏掉真正关键的权限。

清单要记录用途，不能只列工具名称

同一款产品只要用途不同或权限不同，就应分别建档。即使来自同一家供应商，销售文案助手和客户资料补全流程也应各有一条记录。

每条记录应包括：业务目的、责任人、服务和账户、数据类别、连接的系统、读写权限、受影响的人群、审核方法、审批状态，以及上次复查日期。如果是自行构建的系统，还要补充已部署的模型或服务配置，并附上变更记录链接。

请各职能负责人把浏览器扩展、会议助手、编程助手、自动化流程，以及现有软件中已开启的AI功能都纳入清单，再与可获取的账单和访问记录核对。覆盖范围要如实说明：员工调查加账户审查，只是一种排查方法，不能证明所有未经批准的使用都已被发现。

以一家假设的30人公司为例，可以由创始人维护台账，销售、客服和工程负责人分别确认本部门的记录。这样既能明确问题上报路径，也不必专门设立常设委员会。

AI治理政策要明确哪些数据可以用

规则要具体到员工能照着做：哪个账户、哪些数据、什么任务。“负责任地使用AI”并不能告诉销售人员，客户合同能不能上传到聊天窗口。

默认规则应当谨慎：公开资料可以放入获批工具；客户记录、保密代码和内部商业信息，则必须有针对服务和使用场景的明确批准。凭据和密钥不要写进提示词。敏感个人信息应经过明确评估，不能靠口头同意当作例外处理。

把批准所依据的条件记录下来，包括保留设置、访问权限、合同约定的数据用途，以及相关集成。供应商关于模型训练的声明，本身并不能回答提示词存在哪里、谁能访问。这些需要分别核查。

面向员工的规则，可以使用本站已发布的AI可接受使用政策模板。将它与这套治理流程衔接起来，让每项例外都有负责人和复查日期。

在后果发生前完成人工审核

审核人需要拿到源信息、有明确标准、有足够时间，也有权拒绝输出。缺少这些条件，只是有人点一下批准按钮，并不能提供多少保护。

销售场景中，涉及价格、安全和合同条款的承诺，应先由人工核查，再发给潜在客户。客服场景中，可以让助手依据获批材料起草回复，但退款、账户变更和敏感信息披露要由指定员工检查。工程场景中，AI生成的改动也要经过与其他代码贡献相同的代码审查、测试和发布管控。

为每条工作流程写清楚哪些问题会阻止发布。客服回复即使再流畅，只要暴露了其他客户的信息，就不能通过。代码改动即使通过了单元测试，只要绕过了授权检查，也仍然不可接受。

AI智能体是能够调用工具并执行操作的软件。除了审核输出，还必须划清它的权限边界，限制它能访问的账户、记录和操作。授予写入权限前，要先测试这道边界，并保留随时撤销权限的办法。

审查实际使用的供应商服务与配置

评估的对象应当是实际采购的服务，包括套餐、账户类型和集成方式。通用安全介绍页面只能作为参考，不能代表你的具体配置。

为以下核查事项留下简明记录：

• 数据处理： 保留哪些输入、输出和元数据？是否用于训练？有哪些删除控制措施？
• 合同与处理安排： 协议允许哪些用途？还有哪些服务商会处理数据？发生事件时适用哪些承诺？
• 身份与权限： 能否控制访问、移除离职员工的权限，以及限制连接的系统？
• 运行证据： 针对这条工作流程，能获取哪些日志、变更通知和支持渠道？
• 退出与故障应对： 能否关闭功能、撤销凭据，并在不依赖它的情况下继续完成关键任务？

没有得到回答的问题，应标为“待解决”。如果缺失的信息涉及客户数据或不可逆操作，就应缩小使用范围，或继续暂停该用途，直到有人明确接受一项具体且有记录的风险。

接入现有的事件处置流程

给员工一个清楚易用的渠道，用来报告不安全的回答、数据泄露、未经授权的操作或疑似滥用。第一响应人应当知道谁能关闭集成，以及由谁决定是否恢复。

记录受影响的工作流程、时间、涉及的数据、相关输出或操作、权限和可获取的日志，并限制证据的访问范围。控制事态、评估受影响的人群，再根据合同和适用规则，明确相关通知义务由谁落实。

接下来要修复失效的管控措施。如果客服助手泄露了一份受限文档，删除回答并不能修复它的文档访问权限。应检查权限变更，重新测试出错场景，并记录恢复运行的决定。

以一家假设的150人企业为例，可以由现有的安全事件负责人和客服负责人协同处理。如果没有专职安全岗位，就要明确谁能撤销访问权限，以及由哪位高管决定是否升级处理。

AI治理标准怎么用：NIST、ISO与欧盟《AI法案》

用NIST组织风险决策，用ISO建立管理体系，再用欧盟《AI法案》判断适用的法律义务。把三者混为一谈，很容易在客户问卷中给出误导性的回答。

把NIST用在一条能够实际检查的工作流程上

NIST的各项职能需要持续开展，并非四个勾选完就能结束的步骤。官方的AI RMF核心说明明确允许按需调整，并指出治理应贯穿其他职能。

以客服助手为例，可以这样对应：

• 治理（Govern）： 客服负责人负责这项用途，COO批准风险边界，IT控制访问权限。
• 映射（Map）： 记录助手读取哪些客户信息、谁会收到回答，以及错误回答可能造成什么损害。
• 度量（Measure）： 检查有代表性的场景和难处理的场景，包括尝试获取受限信息的情况。记录结果和仍未解决的局限。
• 管理（Manage）： 限制访问，在必要环节要求审核，监测问题；一旦突破边界，就停用这条工作流程。

这只是一个示例。如果实际做的是这些，就可以表述为“使用NIST AI RMF组织风险管理工作”。相关证据也要留存，支撑这句话。

AI治理认证：先明确商业目的和认证范围

ISO/IEC 42001关注的是组织的AI管理体系。其公开说明采用“策划—实施—检查—改进”的方法：建立流程、运行流程、评估流程，再持续改进。一页政策只是其中很小的一部分。参见ISO标准概览。

认证是单独进行的外部评估。ISO制定标准，但不直接为组织颁发认证，相关工作由外部认证机构承担。参见ISO认证说明。

当客户提出要求、所处采购市场认可这类认证，或AI业务本身需要正式管理体系时，可以考虑认证。要确认认证证书覆盖哪些实体、地点和活动。某位员工的课程证书，不能证明公司的工作流程运行在经过评估的管理体系之下。

欧盟《AI法案》时间线：区分已生效义务与后续期限

高风险规则的时间表已经调整，但这并不意味着整部法案都被推迟。欧盟委员会表示，AI Omnibus已于2026年7月27日生效，延后了主要高风险规则的适用日期，并简化了此前对企业的AI素养要求。参见欧盟委员会公告。

官方实施时间线列出了以下节点：

• 2025年2月2日： 原有禁止事项和AI素养条款开始适用。
• 2025年8月2日： 通用AI模型义务及治理条款开始适用。
• 2026年8月2日： 法案开始普遍适用，包括第50条的透明度规则。
• 2026年12月2日： 第50条第(2)款针对部分在2026年8月2日之前已上市的合成内容系统提供者设有特定过渡安排；这不是对所有透明度义务的统一延期。
• 2027年12月2日： 附件III所列高风险系统。
• 2028年8月2日： 附件I涵盖的受监管产品中嵌入的高风险AI。

这里只列出了部分节点；相关条款和过渡安排详见欧盟委员会实施时间线。

对创始人来说，首先要判断自身角色和预期用途。欧盟委员会说明，适用范围涉及欧盟内外的公共及私营主体：只要其将AI投放欧盟市场，或在欧盟投入使用、使用AI，就可能落入该范围。委员会也将某些就业和信用评估用途列为高风险示例。企业人数本身无法回答角色和用途这两个问题。参见欧盟委员会关于适用范围与分类的常见问题。

运营面向客户的聊天机器人，应当现在就审查适用的披露要求。开发者如果考虑把AI用于招聘自动化，应先评估预期用途，不能直接当作普通的文案起草助手处理。把评估日期和依据来源记入清单。

本站的欧盟《AI法案》工具指南可作为相关采购参考。本文概述的日期和要求，应以上述官方来源为依据。

客户安全问卷应该附哪些材料？

提交的证据应与客户的问题及你提供的服务相匹配。不存在一套适用于所有情况、保证过审的最小材料包：评估内部文案起草的客户，与采购可访问生产数据的自主系统的客户，关注点并不相同。

对于一般企业AI使用的首次审查，可以准备以下六项证据：

1. 已批准的政策及责任人： 当前有效的政策、批准日期、适用范围，以及承担最终责任的高管。
2. 相关清单摘录： 客户所用服务涉及的AI用途，包括供应商、数据类别、权限和负责人。
3. 供应商证据： 针对这些用途的评估，以及作为依据的条款或设置。仅分享协议允许披露的材料。
4. 审核与测试样本： 经脱敏的记录，展示某个实际输出或改动如何按既定标准接受检查，以及未通过时如何处理。
5. 员工宣导记录： 哪些员工已收到适用规则，以及他们如何了解报告和审批渠道。
6. 事件处置渠道与演练： 联系人、叫停权限，以及一份已完成的事件记录，或明确标注为演练的记录。

不要为了让材料包显得完整，就发送敏感提示词或客户数据。先提供范围明确的摘要，再为合适的支撑记录提供受限访问。

有用的问卷回答会把边界讲清楚。只有在这些措施已经落实时，才有依据使用下面这样的表述：

AI辅助客服起草已纳入我们的AI使用台账，由客服负责人负责。获授权的员工会在发送前审核回复，该集成没有退款权限，相关事件纳入现有安全处置流程。我们可以提供相应政策、供应商评估和经脱敏的审核记录。

如果某项措施尚在计划中，就如实说明，并注明责任人和目标日期。如果只评估了客服，就不要让人误以为这段声明也覆盖销售和工程。不要笼统地说“所有AI都合规”，而应明确可用证据支持的范围和措施。

向董事会汇报时，重点是需要决策的事项，而不是文档数量：哪些用途已获批、哪些能操作外部系统、发生了哪些重大问题、哪些例外仍未关闭，以及哪些事项需要高管批准。数量应来自自己的台账；清单不完整，就应明确标注。

哪些事现在就要做，哪些可以缓一缓？

只要AI会处理客户信息、作出承诺，或能够修改线上运行的系统，就应立即行动。在扩大权限之前，先把权限边界和责任人理清楚。

创始人： 明确承担最终责任的高管，不要再仅凭聊天中的口头同意批准AI用途。小公司可以一人兼任多个角色，但每次决策仍要留下记录。

业务运营负责人： 在销售和客服流程中，把起草与会产生实质影响的操作分开。以一家假设的400人公司为例，高级运营负责人应当能直接查到每条工作流程由谁负责，而不必沿着一串转发消息追问。

开发者： 新增工具连接、改变数据访问范围，或部署有实质差异的配置时，都要重新评估。已有的文本生成批准，不等于已经获准写入生产系统。

采购方： 开放敏感访问权限之前，先索取供应商证据。当实际使用的各项AI应用已让人工记录和审批变得不可靠时，再考虑治理软件。AI智能体治理平台对比讨论了这类采购决策。

如果没有硬性要求，现有管控也仍然可管理，正式认证和专门的治理平台可以暂缓。无害的内部草稿，无需套用与能够修改账户的智能体相同的审批流程。如果用途、数据、权限和风险都没有变化，可以继续沿用现有管控，并按计划复查。

AI治理培训要围绕岗位中的实际决策

培训应针对员工必须作出的判断。泛泛的意识宣讲，无法教会客服人员如何停用不安全的集成。

给销售人员一份含有无依据产品承诺的草稿，给客服人员一段混入不同客户信息的回答，给开发者一项看似合理、却削弱了访问检查的改动。请他们找出问题、拒绝输出，并通过正确渠道报告。

记录培训内容、出席情况和后续跟进。工作流程变更或事件暴露出缺口后，再补训相关部分。这是运营建议，不意味着所有公司都必须购买某门课程，或完成固定时数的培训。

AI治理中，哪些做法被过度寄望？

最昂贵的误区，是把治理文件或工具当成已经有效运行的管控措施。

政策无法限制凭据权限。 如果助手拥有广泛的写入权限，写一句“需先申请批准”并不会收回这些权限。规则必须与技术权限一致。

有人工审核，不等于自动获得保障。 审核需要标准、源材料、决策权限，以及发现问题后的处理办法。要追踪漏检的问题，并修复流程。

供应商的保证无法说明你的工作流程是否妥当。 先核查其保证覆盖的服务和范围，再评估自己的数据访问、集成方式和运营决策。

获得认证，不代表每次输出都正确。 认证可以作为被评估管理体系的证据，但对可能影响客户的系统行为，仍要持续检查。

仪表盘不能承担决策责任。 接受风险、收窄用途或叫停使用，最终仍然需要有人拍板。如果这个人是谁都不清楚，多买一层报表工具也填不上缺口。

常见问题

AI会取代数据治理吗？

AI可以协助完成治理任务，但数据质量、访问权限、允许的用途和保留期限，仍然需要有人负责。保留这些管控，再补充AI如何使用数据、如何依据输出采取行动的规则。

GovAI是做什么的？

GovAI是一家智库，通过前沿AI研究和治理人才培养项目，为政府及业界决策者提供支持。它是一个独立组织，不是企业合规标准的名称。参见GovAI的使命。

AI治理的一大难点是什么？

让获批用途与实际用途始终保持一致。系统可能已经接入新的数据源，或获得新的操作权限，旧评估却仍把它描述成起草助手。这类变化应当触发复查。

什么是AI安全治理？

它是对AI安全决策明确责任并实施监督，涵盖信息处理、访问权限、测试、部署和事件响应。应将其接入现有安全流程，并明确谁有权停用每条AI工作流程。

AI治理在实际工作中是什么样的？

客服助手依据获批文档起草回复，由指定员工在发送前检查，且助手没有退款权限。企业记录供应商审查情况，检查是否存在不当数据访问，并为员工提供问题报告渠道。

AI治理值得作为职业方向吗？

如果你喜欢把技术行为与政策、风险决策和证据联系起来，这个方向值得了解。判断具体岗位时，要看职责和所需技能；仅凭职位名称，很难知道实际工作内容。

AI治理岗位的薪资是多少？

这个宽泛名称没有一个有参考价值的统一薪资。应比较同一地区、相近资历和职责范围的在招岗位薪资区间，并区分运营风险、技术保障和政策研究等岗位。把它们混在一起算一个数字，会掩盖这些差异。

哪5种工作不会被AI取代？

没有任何固定的五种工作，能够保证不受AI影响而保持原样。若想从事治理工作，应着重培养跨岗位通用的能力：调查故障、核查证据、理解权限，以及向承担后果的人解释决策。

如何进入AI治理领域？

从一条已获授权、边界明确的工作流程入手：建立清单记录，找出可能的故障，提出管控措施，再通过审查或明确标注的演练形成证据。这样能展示你如何把政策要求落实到实际运行中。

下周一就能开始做的事

请销售、客服和工程团队带上目前在用的AI用途，开一次简短的工作会。明确负责高管、填好台账，再选出对客户或数据影响最大的一条工作流程。

沿着这条流程，从获批数据一路检查到输出、审核和可能执行的操作。确认谁能叫停它，演练一次故障，记录缺口，并将每项整改落实到具体人员。下一次回复客户或向董事会汇报时，就用这些实际发现作为依据。

想了解企业内部使用AI的实操方法，欢迎订阅邮件通讯。