AI治理与组织制度：角色、流程、评审、审计、采购和成本控制
写作日期：2026-05-22
摘要
AI 治理不是限制创新的审批墙，而是让组织在模型、数据、工具、供应商和业务责任不断变化时仍能做出可复盘判断的管理系统。生成式 AI 与传统软件不同，它会根据上下文生成结果、调用工具、受模型版本和资料质量影响，并可能把错误输出包装成流畅语言。本文把 AI 治理拆成角色、用例台账、风险分级、上线评审、审计证据、采购管理、成本控制和智能体治理八个部分，强调制度必须落到工具和流程里。生产级治理的目标，是让低风险探索有快车道，让高风险用例有足够证据、人工监督和暂停能力，让成本和供应商可退出，让事故可以追踪到数据、模型、提示词、知识库、工具和责任人。
关键词
AI 治理；用例台账；风险分级；AI 管理体系；审计；供应商采购；FinOps for AI；智能体治理；人工复核；成本归因
研究问题与方法
本文讨论三个问题：组织如何在不扼杀探索的前提下控制 AI 风险；AI 用例从需求到退役应保留哪些证据；成本、采购和智能体权限如何进入同一套治理体系。方法上，本文采用生命周期治理框架：先以用例台账建立可见性，再用影响对象、数据敏感度和自动化程度分级，随后把分级结果映射到评审、评测、供应商条款、运行监控和审计抽样。重点不是写一份完整手册，而是形成可以运行的决策链。
| 风险层级 | 典型用例 | 必要控制 | 主要证据 |
|---|---|---|---|
| 低风险 | 公开资料摘要、非敏感草稿 | 备案、标准工具、基础日志 | 负责人、工具、成本 |
| 中风险 | 内部知识问答、客服建议、合同初筛 | 数据评审、评测集、人工复核、监控 | 权限、引用、版本、样本结果 |
| 高风险 | 权益决策、资金动作、招聘筛选、自动写入 | 影响评估、联合评审、红队、审批、暂停机制 | 评审记录、审计 trace、申诉和回滚 |
| 禁止或暂缓 | 无授权敏感数据训练、绕过验证、不可解释自动决策 | 拒绝上线或重设范围 | 禁止原因和替代方案 |
这个分级表的价值，是让治理强度与风险相称。所有用例都走最重流程会导致绕行，所有用例都自由试验会导致失控；分级治理让组织既能探索，也能承担责任。
AI 治理不是给创新加一道审批墙，也不是把所有风险都推给法务、安全或技术团队。真正有用的 AI 治理，是让组织能持续判断：哪些 AI 用法值得做，哪些数据可以用，哪些模型或供应商适合当前风险等级，哪些输出必须有人复核，哪些调用和成本需要被记录，出现问题后由谁负责修正。没有这套制度，AI 项目会在早期演示里显得很快，进入真实业务后却变成责任不清、费用失控、质量难复盘和采购难退出的复杂系统。
生成式 AI 与传统软件最大的差异，是它的行为不完全由代码显式写死。模型会根据上下文生成结果，会调用工具，会受数据质量、提示词版本、供应商策略、模型升级和用户输入影响。一个内部知识助手可能因为检索到过期资料而误导员工；一个客服机器人可能因为缺少交接规则而给出不当承诺；一个代码智能体可能在权限过大时改错文件；一个采购来的 AI SaaS 可能把企业输入保留在供应商日志里。组织如果只用传统 IT 审批看 AI，很容易漏掉模型质量、数据权利、输出责任和持续评估这些关键问题。
生产级 AI 治理要把制度落到日常动作里：建用例台账，分风险等级，定义角色责任，设置上线前评审，保留审计证据，管理供应商和模型版本，记录 Token 与成本，定期抽检真实输出，形成事故复盘和退出机制。治理的目标不是让所有 AI 项目变慢，而是让高风险项目有足够控制，让低风险项目有清晰快车道，让业务团队知道如何合规使用，让技术团队知道如何交付可运营系统。
引言：AI 治理先回答六个问题
AI 治理的起点不是写一份很长的政策，而是把六个问题变成组织共识。第一，这个 AI 用例服务谁，影响什么决策，失败后会造成什么后果。第二，它需要哪些数据，数据是否包含个人信息、商业秘密、客户资料、学生记录、医疗或金融信息。第三，它使用什么模型、供应商、插件和工具，模型输出会不会触发外部动作。第四，谁负责评估质量，谁负责审核上线，谁负责日常监控。第五，发生错误、投诉、泄露、越权或成本异常时，谁能暂停系统并完成复盘。第六，这个系统长期运行的成本和退出成本由谁承担。
这六个问题覆盖了治理的主体、对象、边界、证据和责任。很多组织失败在第一步：业务部门认为 AI 是技术工具，技术部门认为场景责任在业务，安全部门只看网络和账号，法务部门只在合同签署时介入，财务部门只到月末看到供应商账单。结果是每个人都参与了一点，但没有人真正拥有端到端风险。
AI 治理要避免两种极端。一种极端是所有用例都走同样重的审批，导致员工绕开正式流程，私下使用公开工具。另一种极端是鼓励所有团队先试再说，直到数据泄露、虚假输出或成本爆炸才补规则。合理做法是按风险分层：低风险的个人效率和公开资料生成可以走轻流程；涉及内部数据、客户交互、自动化操作和业务决策的用例要走标准流程；影响权益、安全、财务、招聘、教育评价、医疗建议、法律判断等场景要走增强评审和人工复核。
治理的成果也不只是文档。它应表现为可执行的机制：员工知道哪些工具能用，系统能自动阻止高敏数据进入外部模型，模型网关能记录调用和成本，项目上线前有评测结果，供应商合同包含数据和退出条款，审计人员能看到用例台账、版本记录、访问日志和事故处理过程。制度如果不能进入工具和流程，就会停留在口号。
组织角色：不要让 AI 责任悬空
AI 治理需要明确角色，但不一定需要每个公司都成立庞大的专门委员会。小团队可以一人兼多职，大组织可以设立 AI 能力中心或 AI 治理委员会。关键是每个职责必须有人承担，并且在项目流程中有实际权限。
最高管理层负责定义 AI 使用原则、风险偏好和资源边界。AI 会改变业务流程、数据流和组织责任，不能只由技术团队自发推进。管理层要决定哪些领域优先投入，哪些领域禁止或暂缓，哪些高风险用例必须保留人工决策，哪些成本上限不可突破。没有管理层背书，治理要求很容易在业务压力下被绕过。
AI 负责人或首席 AI 角色负责把原则变成制度。这个角色不一定只看算法，而要连接业务、数据、安全、法务、采购、财务和技术平台。其职责包括维护 AI 用例台账，组织评审，推动模型和供应商标准化，制定评测和监控要求，协调事故处理，向管理层报告风险和价值。美国 OMB 的联邦机构 AI 备忘录要求机构设置首席 AI 官，背后的逻辑就是 AI 风险跨越多个职能，必须有清晰统筹角色。
业务负责人是具体用例的第一责任人。AI 系统最终服务业务目标，输出是否可用、错误影响多大、用户如何补救，都不能只靠技术团队判断。业务负责人要定义任务目标、成功指标、人工复核规则和异常处理流程，并对上线后的实际使用负责。若一个客服 AI 误导客户，不能只问模型供应商，也要问业务规则和知识库是否被正确维护。
产品和技术团队负责把治理要求落到系统设计。它们要实现权限、日志、模型路由、提示词版本、评测集、人工确认、回滚、监控和成本归因。AI 治理如果没有产品化，员工只能填表，管理者只能开会，真正风险仍留在运行链路里。技术团队不是治理的唯一主人，但它决定制度能否自动执行。
数据、隐私、安全和法务角色负责边界控制。数据团队判断数据来源、质量、血缘、分类和保留期限；隐私角色判断个人信息处理目的、最小化和授权；安全角色检查账号、工具权限、提示注入、供应链、日志保护和高风险操作；法务角色处理合同条款、知识产权、行业监管、跨境传输和责任分配。这些角色应在设计早期介入，而不是上线前最后一周才审。
采购和财务角色经常被低估。AI 项目可能从一个 API Key 开始，几个月后变成多模型、多供应商、多部门账单。采购要管理供应商准入、合同条款、服务等级、价格模型、数据处理和退出计划；财务要管理预算、分摊、单位成本和异常使用。没有采购和财务参与，组织很容易被单一供应商锁定，或在业务尚未证明价值前承担持续费用。
内部审计或合规角色负责独立复核。审计不是每天指挥项目怎么做，而是在合适周期检查制度是否被执行：用例台账是否完整，风险等级是否合理，评审证据是否存在，高风险输出是否有人复核，日志是否可追踪，供应商条款是否符合要求，成本是否按规则归因，事故是否复盘。审计要看证据，不只看承诺。
用例台账和风险分级
AI 治理的第一张表应是用例台账。台账记录组织正在使用、试点、采购、停用和计划建设的 AI 用例。没有台账，管理层不知道组织里到底有哪些 AI 系统；安全团队不知道哪些系统接触敏感数据；财务团队不知道成本来自哪里；审计团队不知道该抽查什么。台账不是为了形式，而是 AI 资产管理的入口。
一个实用台账至少包含：用例名称、业务负责人、技术负责人、使用人群、业务目标、当前状态、模型或供应商、是否使用外部服务、数据类型、是否包含个人或敏感信息、是否面向客户、是否影响重要决策、是否调用工具、是否有自动写入动作、风险等级、上线日期、评审记录、监控入口、成本归属、退出方案。字段不必一开始完美，但要能支撑分级管理。
风险分级可以从影响对象和系统能力两条线判断。影响对象包括员工、客户、学生、患者、求职者、合作伙伴和公众；影响越接近权益、安全、财务、就业、教育、医疗、法律和公共服务，风险越高。系统能力包括是否只是生成草稿，是否读取敏感资料，是否对外回复，是否自动调用工具，是否能写入业务系统，是否影响最终决策。能力越强，风险越高。
低风险用例可以包括公开资料摘要、内部会议纪要初稿、非敏感文案改写、开发者个人辅助阅读。中风险用例可能包括内部知识库问答、客服建议、合同初筛、代码生成、销售邮件草稿、采购比价分析。高风险用例包括自动审批贷款、招聘筛选、学生评价、医疗建议、法律结论、关键基础设施运维、自动下单或付款、对外承诺和权限变更。风险等级不是永恒标签，同一个技术能力放在不同场景里风险完全不同。
风险分级要绑定流程，而不是只做颜色标记。低风险用例可以快速备案、使用标准工具和默认日志；中风险用例需要数据评审、模型评测、人工复核策略和上线监控；高风险用例需要影响评估、法务和安全联合评审、明确人类监督、压力测试、红队测试、供应商尽调、发布审批、定期审计和暂停机制。分级的价值在于让控制强度匹配实际影响。
从需求到上线的流程
AI 项目的流程应覆盖需求、设计、数据、模型、评测、上线、监控和退役。很多团队只管理开发阶段，忽略模型升级、知识库变化、供应商策略变化和真实用户反馈。AI 系统一旦上线，它仍在变化的环境里运行，所以生命周期管理比一次性项目管理更重要。
需求阶段要写清楚业务目标和禁止目标。比如“降低客服人工查资料时间”比“建设智能客服”更具体；“生成客服建议，由人工确认后发送”比“自动回复所有客户”风险更低。需求文档应说明目标用户、任务边界、成功指标、失败后果、人工参与方式和数据来源。若业务目标无法衡量，后续评审就会变成主观争论。
设计阶段要确定系统边界。系统是只读还是可写，是辅助人还是自动执行，是否面向外部用户，是否需要引用来源，是否要保留会话记录，是否需要权限隔离，是否允许模型调用工具。对智能体系统，还要画出工具清单、权限范围、人工确认点和最大步骤数。设计评审不是审界面是否好看，而是审系统如何控制风险。
数据阶段要确认数据权利和质量。AI 系统可能使用训练数据、检索数据、用户输入、业务数据库、日志和反馈样本。每类数据都要问：来源是否合法，是否有授权，是否需要脱敏，是否允许进入外部模型，是否可用于评测或训练，是否有保留期限，是否可删除，是否存在过期或错误内容。RAG 系统尤其要关注资料版本和权限同步，不能让模型检索到用户无权访问的文档。
模型和供应商阶段要做适配评估。不要只看榜单分数或销售演示。要用真实样本比较准确性、中文能力、长上下文、工具调用、结构化输出、拒答、延迟、成本、稳定性、数据条款和可替换性。强模型不一定适合所有任务，便宜模型也不一定省钱。模型选择应与任务风险、输出要求和成本目标绑定。
评测阶段要同时看质量、安全和业务结果。质量评测包括准确性、引用支持、格式遵循、推理步骤、错答类型和人工采纳率；安全评测包括提示注入、敏感信息泄露、越权工具调用、不当内容、拒答边界和供应链风险；业务评测包括任务完成率、节省时间、用户满意度、人工复核负担和单位成本。只让模型自评不够，必须有人工样本和真实业务样本。
上线阶段应采用灰度和回滚。AI 系统的输出分布可能在真实用户中暴露新问题，直接全量上线风险很高。可以先给内部用户、单一部门、低风险客户或小比例流量使用，观察错误、投诉、成本和人工修改。若模型、提示词、知识库或工具策略出现异常，要能快速回滚到上一版本。上线审批应检查证据是否齐全，而不是重新讨论所有细节。
运行阶段要持续监控。AI 监控不仅看服务器是否正常，还要看 Token、延迟、成本、错误、检索质量、工具调用、用户反馈、人工采纳和安全事件。知识库更新、模型升级、供应商降级、提示词改动和业务规则变化，都应进入变更记录。退役阶段也要有流程：关闭接口，撤销权限，归档证据，处理日志和数据，通知用户，保留必要审计资料，清理供应商访问。
评审机制：审什么，谁来审
AI 评审要避免开成泛泛而谈的会议。评审应围绕证据、风险和决策展开。每次评审都要明确：这是需求评审、数据评审、安全评审、模型评审、上线评审、采购评审还是事故复盘。不同评审有不同材料和结论，不应把所有问题堆到一次会议里。
需求评审看业务目标是否清晰，是否存在更简单的非 AI 方案，是否定义了不可做的范围。不是所有问题都需要大模型。有些需求用搜索、表单、规则、自动化脚本或流程优化更可靠。AI 治理不是排斥 AI，而是防止团队为了展示“智能”而把不稳定生成放进本来确定性很强的流程。
数据评审看数据是否能用、该不该用、如何用。评审材料应包含数据清单、分类分级、来源、授权、脱敏方式、权限边界、保留期限、是否进入外部供应商、是否用于训练或评测。若数据包含客户合同、学生记录、员工绩效、健康信息或商业秘密，就不能只写“内部数据”四个字。分类越粗，后续越难控制。
模型评审看模型是否适合任务。材料应包含候选模型、测试样本、指标、失败案例、成本估算、延迟、上下文限制、工具调用表现、输出稳定性和供应商条款。模型评审不应被单个 benchmark 支配。一个模型在数学榜单上强，不代表它适合客服；一个模型中文写作流畅，不代表它会严格引用资料；一个模型便宜，不代表多轮失败后总成本低。
安全评审看系统如何防止越权、泄露和误操作。重点包括身份认证、数据隔离、最小权限、工具确认、提示注入防护、日志脱敏、密钥管理、插件供应链、代码执行沙箱、文件访问范围和异常暂停。智能体系统尤其要看“能做什么”和“不能做什么”。如果模型可以通过工具写数据库、发邮件、下单或改权限，人工确认和审计记录就不是可选项。
上线评审看证据是否达到风险等级要求。低风险用例可以看备案、标准工具、基础测试和责任人；中风险用例要看评测、数据审核、人工复核策略、监控和回滚；高风险用例还要看影响评估、红队结果、法务意见、供应商尽调、用户告知、人工监督和定期审计计划。评审结论应是通过、条件通过、限范围试点或不通过，并写明原因和责任人。
评审人不必追求越多越好。参与者太多会降低效率，参与者不对又会漏风险。实用做法是按风险分级设置固定角色：低风险由业务负责人和技术负责人确认；中风险加入数据、安全或隐私角色；高风险加入法务、采购、财务、审计和管理层代表。评审制度要让合适的人在合适阶段出现。
审计证据：能复盘才算可治理
AI 审计不是把每次模型输出都打印成文档，而是保留足以解释系统行为和组织决策的证据。审计要能回答：这个用例为什么被批准，使用了什么数据和模型，谁评估过风险，谁改过提示词，某次输出基于哪些资料，用户是否有权限，供应商是否处理了数据，成本为何上涨，事故发生后采取了什么措施。
用例层证据包括台账、风险分级、业务目标、责任人、上线时间、评审结论、影响评估、人工复核规则和退役状态。系统层证据包括架构图、数据流、权限模型、工具清单、模型版本、提示词版本、知识库版本、评测集版本、发布记录和回滚记录。运行层证据包括请求日志、Token、延迟、模型调用、检索结果 ID、工具调用、错误类型、用户反馈、人工修改和成本归因。
审计日志要注意隐私。完整保存用户输入和模型输出虽然方便排查，但可能形成新的敏感数据库。更稳妥的方式是分层保存：默认保存元数据、摘要、哈希、文档 ID、版本、指标和错误类型；对需要质量复盘的样本进入受控审计池，设置访问审批、脱敏、保留期限和查看日志。能追踪不等于能任意查看，审计系统本身也要被审计。
版本记录非常重要。AI 系统的行为会因模型、提示词、知识库、检索策略、工具 schema 和安全策略变化而变化。一次投诉发生后，如果团队只能看到当前配置，却看不到当时配置，就很难判断责任。每次变更都应记录版本、变更原因、影响范围、评测结果、发布人、发布时间和回滚方案。对高风险系统，模型供应商自动升级也应纳入变更管理。
抽样审计比事后追责更有价值。每月抽查一批高风险输出、低满意会话、高成本任务、被人工大幅修改的结果、工具调用失败样本和异常拒答样本，可以提前发现趋势。审计结论应进入改进流程：更新知识库、调整提示词、收紧权限、补充评测集、修改供应商条款或暂停某类用例。审计若只出报告，不推动改进，治理价值会下降。
事故复盘也属于审计证据。AI 事故不一定是系统宕机，可能是错误建议、越权访问、敏感信息外泄、虚假引用、错误自动操作、成本异常、供应商不可用或用户误信输出。复盘要记录触发条件、影响范围、发现方式、为什么监控没有提前发现、如何修复、如何补偿、哪些控制要加强。组织要允许报告问题，否则员工会把 AI 风险藏到小范围里。
采购：买 AI 不只是买软件
AI 采购比普通 SaaS 采购更复杂，因为供应商可能处理输入数据、保存日志、使用客户数据改进模型、调用第三方模型、持续调整模型版本、按 Token 计费，并在输出质量上存在不确定性。采购不能只比较功能列表和报价，要把数据、模型、合规、成本和退出都写进评估。
采购前先判断买什么。组织可能购买基础模型 API、模型网关、知识库平台、客服机器人、代码助手、办公插件、标注工具、评测平台、向量数据库、Agent 平台或行业解决方案。不同产品的风险不同。一个只处理公开文案的写作工具，与一个能读取企业网盘并自动回复客户的 Agent，不能走同一采购问卷。
供应商尽调要覆盖数据处理。要问清楚：客户输入和输出是否被保存，保存多久，是否用于训练或产品改进，是否可关闭，是否会传给分包商或第三方模型，数据存储地区在哪里，是否支持删除和导出，日志是否脱敏，谁能访问原始内容，安全事件如何通知。若供应商回答模糊，说明后续风险会落到采购方身上。
模型和服务条款也要细看。供应商是否会无通知更换模型版本，是否保证接口兼容，是否提供模型版本标识，是否支持私有部署或专属实例，是否有速率限制和配额，是否提供审计日志，是否支持企业密钥管理，是否有服务等级承诺，是否明确输出责任边界。AI SaaS 的销售演示往往展示最好样本，合同要覆盖最坏情况。
采购评测不能只做一次演示。应准备真实样本集，覆盖常见任务、边界任务、敏感数据、长文本、中文表达、格式要求、工具调用和失败场景。评测要记录准确性、引用、稳定性、人工修改比例、延迟、Token、价格、管理员控制、权限隔离和导出能力。供应商若不能配合真实评测，只能说明它还不适合关键业务。
退出计划必须在签约前谈清楚。AI 产品一旦接入知识库、流程、提示词和用户习惯，退出成本会迅速升高。合同应包含数据导出、日志导出、知识库迁移、向量索引重建、提示词和配置归属、接口替换、账号关闭、数据删除证明和费用结算。没有退出计划，采购就会变成长期锁定。
采购还要避免“部门各买各的”。多个部门分别购买不同 AI 工具，会造成数据条款不一致、账号管理分散、成本不可见、员工体验混乱和安全难审。更稳妥的方式是建立供应商白名单、模型网关、统一账号和统一成本看板。业务部门仍可选择合适工具，但底层治理和采购标准应统一。
成本控制：从账单管理到单位经济
AI 成本控制不能等到账单来了再做。模型调用按 Token、图片、音频、向量、重排、存储、并发或席位计费，成本会随着使用习惯快速变化。一个看似便宜的内部助手，如果每次都把长历史、整份文档和大段工具返回塞给强模型，成本会在几周内失控。治理要把成本当作设计指标，而不是财务尾项。
成本至少分为六类。第一是模型推理成本，包括输入 Token、输出 Token、缓存 Token、推理 Token 和多次重试。第二是数据处理成本，包括文档解析、OCR、Embedding、重排、向量库、对象存储和同步。第三是基础设施成本，包括 GPU、CPU、内存、网络、日志和备份。第四是人工成本，包括标注、审核、客服接管、内容修正和评测维护。第五是治理成本，包括采购、审计、合规、培训和事故处理。第六是退出成本，包括迁移、重建、替换和历史数据处理。
成本归因要细到功能、租户、团队和任务。总账单只能告诉组织花了多少钱，不能告诉钱花得值不值。一个合同审阅任务单次成本高但节省律师时间，可能合理；一个闲聊助手单次成本低但大量无效调用，可能不合理。成本看板应显示每个功能的请求量、Token、模型占比、单位任务成本、失败重试成本、人工接管成本和预算使用率。
预算控制要配合产品策略。免费用户、试点团队、付费客户、高价值内部流程和后台批处理不应共用同一预算池。可以设置软额度和硬额度：软额度触发提醒和成本分析，硬额度限制低价值调用或要求审批。对实时客户流程，不能简单因为预算到顶就中断服务，而应有降级模型、队列、缓存或人工接管。
模型路由是成本控制核心。简单分类、摘要、格式化、意图识别可以用小模型或本地模型；复杂推理、高风险输出、长文综合和关键客户任务可以用强模型；失败重试不应盲目换更贵模型，而要先判断失败原因是检索、提示词、工具还是模型能力。路由策略要有评测和监控支撑，否则会变成凭感觉省钱。
上下文治理比模型单价更重要。很多成本失控来自上下文膨胀：把完整对话历史无限追加，把工具返回的大 JSON 原样塞入 prompt，把无关文档片段全部注入，把系统提示词越写越长，把调试信息放进生产上下文。治理应要求上下文预算、检索片段上限、历史压缩、工具结果摘要、缓存和截断告警。控制 Token，不只是省钱，也能提升质量和延迟。
成本控制不能牺牲可追溯性和质量。为了省钱关闭日志，后续事故会更贵；为了省 Token 去掉引用，用户信任会下降；为了用便宜模型处理高风险任务，人工补救成本可能更高。成熟的成本治理看单位价值：每完成一个可靠任务花多少钱，而不是每次调用最低多少钱。
制度文件应分层，不要写成一本厚手册
AI 制度最好分层管理。第一层是组织原则，说明 AI 使用的基本价值：合法、透明、可控、最小数据、人工负责、可审计、成本可归因。原则面向所有员工，语言要清楚，不要充满模型术语。第二层是政策，规定允许和禁止的用法、风险分级、角色职责、采购要求、数据要求和事故报告。第三层是流程，指导项目如何备案、评审、上线、监控和退役。第四层是操作模板，包括用例登记表、风险评估表、供应商问卷、评测报告、上线清单和事故复盘模板。
员工使用规范要短而明确。比如不得把客户敏感信息、未公开财务、密钥、个人隐私、源代码秘密或受合同限制资料输入未批准工具；不得把 AI 输出直接作为高风险决策依据；对外发布内容必须经过责任人确认；使用 AI 生成材料时应核查事实和来源；发现错误、泄露或异常成本要报告。员工最需要的是可执行边界，而不是长篇伦理说明。
项目团队需要更细的工程规范。包括提示词版本管理、评测集维护、日志字段、模型网关接入、工具权限、人工确认、灰度发布、回滚、知识库更新、数据脱敏和安全测试。工程规范要能嵌入开发流程，例如 pull request 模板、发布检查、监控指标和自动化测试，而不是单独存在于文档库。
供应商管理需要单独规范。不同供应商的合同、数据处理、日志、模型版本、服务等级和退出能力差异很大。组织应建立供应商等级：允许处理公开数据、允许处理内部低敏数据、允许处理敏感数据、允许进入关键流程。供应商等级要与合同和技术控制绑定，不能只靠采购备注。
制度还要定期更新。AI 模型、法规、供应商和攻击方式变化很快。制度不应每天变，但应至少按季度复盘高风险清单、供应商状态、事故情况、成本结构和员工反馈。更新制度时要说明变化点和生效时间，让员工知道新边界，而不是悄悄替换文档。
真正的智能体更需要治理
组织建设 AI 智能体时，治理要求会明显提高。普通聊天助手主要生成文本，智能体会计划步骤、调用工具、读写文件、访问网页、查询数据库、提交表单、修改代码、发送邮件或触发业务流程。能力越接近行动，越需要清晰的权限、确认和审计。
智能体治理的第一条原则是最小工具集。不要把浏览器、文件系统、数据库、邮件、支付、代码仓库和生产运维权限一次性给模型。每个工具都要有用途、输入 schema、权限范围、错误处理、速率限制和审计字段。模型不能因为“可能有用”就拥有所有工具。工具越多，攻击面越大，复盘越困难。
第二条原则是把读和写分开。读取资料、搜索文档、生成建议和创建草稿的风险，低于直接写入业务系统、发送外部消息、删除文件、提交代码和改权限。读操作可以自动完成，写操作应按风险等级设置人工确认。高风险写操作不仅要确认“是否执行”，还要展示将执行的对象、内容、影响范围和回滚方式。
第三条原则是限制循环。智能体很容易因为目标不清、工具失败或模型误判进入重复尝试。系统应设置最大步骤数、最大耗时、最大成本、重复工具调用检测和阶段性检查点。到达限制时，智能体应说明已完成什么、卡在哪里、需要人提供什么，而不是继续消耗 Token。
第四条原则是验证产物。智能体最终输出“已完成”不够，系统要验证文件是否存在、测试是否通过、数据是否写入正确位置、邮件是否进入草稿而非直接发送、工单是否附带证据。对代码、数据和文档类任务，应尽量通过测试、校验、差异预览和人工审阅确认。智能体治理不是让模型更谨慎地说话，而是让行动可控。
第五条原则是记录决策链路。智能体每一步调用了什么工具、传了什么关键参数、得到了什么结果、为什么进入下一步，都应有 trace。不是为了向最终用户展示所有细节，而是为了事故复盘和质量改进。没有步骤记录，智能体就像一个会操作系统的黑箱，风险远高于普通问答。
典型场景的治理做法
内部知识助手通常属于中风险起步。治理重点是资料权限、引用、过期内容、检索质量和反馈闭环。系统应按用户权限检索资料，回答时引用来源，遇到资料不足时明确说明，不应凭模型常识编造公司政策。知识库更新要有版本和责任人，员工点踩或质疑答案后应进入资料修正流程。审计时重点看越权引用、过期资料命中和低满意样本。
AI 客服系统风险更高，因为它面对客户并可能影响承诺。治理重点是业务边界、人工交接、话术审核、质检和投诉处理。低风险问题可以自动回复，高风险问题如退款、赔偿、法律条款、账户安全和投诉升级应转人工。客服 AI 给出的答案应来自已批准知识库，不能自由承诺价格、政策或服务结果。上线前要用真实工单评测，运行后要看转人工率、首次解决率、投诉和人工修改比例。
代码智能体治理重点是仓库权限、测试、代码审查和回滚。智能体可以读代码、提出修改、运行测试和生成补丁，但不能在没有审查的情况下直接合并到主分支或改生产配置。对有写权限的智能体，应限制仓库范围、分支范围、文件范围和命令权限。审计要保留任务描述、差异、测试结果、审查记录和部署记录。
招聘和绩效类 AI 应高度谨慎。涉及人的机会、评价和权益，模型输出容易带来偏见和解释责任。即便系统只做简历摘要或面试记录整理，也要明确它不是最终决策者。若用于筛选、打分或排序，应进行偏见评估、数据合法性审查、人工复核和申诉机制。很多组织应先从行政辅助开始，而不是直接进入自动决策。
营销内容生成相对低风险，但仍有版权、事实和品牌风险。治理重点是素材来源、引用、商标、肖像、敏感表达和发布审核。AI 可以生成草稿、标题、海报文案和变体，但对外发布前应由品牌或内容负责人确认。若使用图像、视频或音乐生成工具，还要检查许可和相似性风险。
财务、采购和合同分析类 AI 要关注事实准确、来源证据和权限。系统可以帮助抽取条款、比较报价、识别异常和生成初稿，但不能替代最终审批。合同和报价往往包含商业秘密，外部模型调用要有供应商条款和日志控制。所有建议应保留来源段落，便于人工核查。
常见误区
误区一，把 AI 治理等同于禁止员工使用公开工具。禁止可以降低一部分风险，但不能创造组织能力。员工如果没有合规可用的替代工具，通常会绕开规则。治理应提供白名单工具、数据边界、培训和快速申请流程，让安全路径比灰色路径更方便。
误区二，只审供应商，不审用例。同一个供应商在不同场景里风险完全不同。一个模型 API 用来改公开文案风险较低，用来分析客户合同就需要数据和合同控制，用来自动给客户承诺就要业务和法务评审。供应商合格不代表所有用例都合格。
误区三，只看模型准确率。AI 系统的可靠性还取决于数据、检索、权限、提示词、工具、人工复核、用户界面和监控。模型在测试集上表现好，不代表上线后不会因资料过期、上下文截断或工具失败出错。
误区四，把人类复核写成万能兜底。人工复核要有时间、界面、证据和责任。如果审核人只能看到模型结论，看不到来源和变更影响，就很难真正复核。高风险流程要设计让人能有效介入，而不是在制度上写“由人工确认”。
误区五，不记录成本归因。AI 成本往往不是一次性采购费，而是持续使用费。没有按功能和团队归因，成本异常时无法治理，也无法判断哪些用例值得继续投入。
误区六，采购时忽视模型版本变化。供应商升级模型可能改善能力，也可能改变输出风格、拒答边界和格式稳定性。关键业务应要求版本标识、变更通知、回归测试和回滚选择。
误区七，审计只看文档。AI 风险经常藏在真实调用里：用户输入了什么，模型引用了什么，工具执行了什么，成本为何升高。审计要看运行证据和样本，而不是只看流程是否存在。
误区八，治理团队远离产品体验。过重的流程、难懂的警告、重复的表单和技术化文案，会让员工不愿走正式路径。好的治理应该让合规动作嵌入产品，不把内部字段和实现细节暴露给最终用户。
九十天落地路线
第一个三十天，先建立底线和可见性。组织应发布简短 AI 使用原则，明确禁止把高敏数据输入未批准工具；建立 AI 用例台账；列出已采购和正在试用的 AI 工具；确定 AI 负责人和跨职能联络人；选择统一模型调用或网关入口；为员工提供可用的合规工具。这个阶段不要追求制度完美，先避免盲区。
第二个三十天，建立分级流程。定义低、中、高风险用例，设计对应评审材料和审批路径；制定数据分类和供应商问卷；为中高风险用例建立评测模板；在模型网关或应用层记录 Token、模型、成本、错误和反馈；选择一两个真实项目做试点。这个阶段要让流程跑起来，发现哪些字段太繁琐，哪些证据缺失。
第三个三十天，进入运营闭环。对试点项目做上线后抽检，查看质量、成本、安全和用户反馈；建立月度 AI 风险和价值报告；把低满意样本、事故样本和高成本样本加入评测集；完善采购白名单和退出条款；对员工做针对场景的培训；开始定期审计高风险用例。这个阶段要把治理从审批转成持续运营。
九十天内不必解决所有问题，但必须形成四个资产：用例台账、风险分级、评审证据和运行指标。有了这四个资产，组织就能知道 AI 正在哪里发生，风险集中在哪里，成本花在哪里，哪些项目值得扩展。没有这四个资产，再多原则也难以落地。
检查清单
- 是否建立了覆盖试点、上线、采购和停用状态的 AI 用例台账。
- 是否为每个用例指定业务负责人、技术负责人和成本归属。
- 是否按数据敏感度、用户影响、自动化程度和工具权限划分风险等级。
- 是否明确低、中、高风险用例对应的评审材料和审批路径。
- 是否在需求阶段写清业务目标、禁止范围、人工参与和失败后果。
- 是否评审数据来源、授权、脱敏、权限、保留期限和外部传输。
- 是否用真实业务样本评估模型、供应商、提示词和检索策略。
- 是否为高风险输出设置有效人工复核、证据展示和申诉路径。
- 是否记录模型版本、提示词版本、知识库版本、工具版本和发布记录。
- 是否通过模型网关或应用日志记录 Token、延迟、错误、反馈和成本。
- 是否对智能体工具设置最小权限、写操作确认、步骤限制和行动审计。
- 是否把采购条款覆盖数据使用、日志保留、模型变更、服务等级和退出计划。
- 是否按功能、团队、租户或任务归因成本，并设置预算和异常告警。
- 是否定期抽查低满意、高风险、高成本、工具失败和投诉样本。
- 是否有 AI 事故报告、暂停、修复、复盘和制度更新流程。
参考资料
- NIST, Artificial Intelligence Risk Management Framework 1.0: https://www.nist.gov/itl/ai-risk-management-framework
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
- NIST AI 600-1 PDF, Generative AI Profile: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- ISO/IEC 42001:2023, Artificial intelligence management systems: https://www.iso.org/standard/81230.html
- ISO, AI management systems: What businesses need to know: https://www.iso.org/artificial-intelligence/ai-management-systems
- Regulation (EU) 2024/1689, Artificial Intelligence Act: https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
- OMB M-24-10, Advancing Governance, Innovation, and Risk Management for Agency Use of Artificial Intelligence: https://www.whitehouse.gov/wp-content/uploads/2024/03/M-24-10-Advancing-Governance-Innovation-and-Risk-Management-for-Agency-Use-of-Artificial-Intelligence.pdf
- OECD AI Principles: https://oecd.ai/en/ai-principles
- World Economic Forum, AI Procurement in a Box: https://www.weforum.org/publications/ai-procurement-in-a-box/project-overview/
- GOV.UK, Generative AI Framework for HMG: https://www.gov.uk/government/publications/generative-ai-framework-for-hmg/
- OWASP Top 10 for Large Language Model Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/
- OWASP GenAI Security Project, 2025 Top 10 Risk and Mitigations for LLMs and GenAI Apps: https://genai.owasp.org/llm-top-10/
- FinOps Foundation, FinOps for AI: https://www.finops.org/framework/scope/finops-for-ai/
- NIST SP 800-53 Rev. 5, Security and Privacy Controls: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final