系统清单与角色责任

本节目标

建立一张真正能支持决策的 AI 系统清单，并把每项责任落实到有权行动的人。治理的第一个失败模式不是“缺少复杂政策”，而是组织不知道哪些 AI 正在被谁、为了什么、对谁使用。

什么算一个“系统”

不要只登记基础模型。一个可治理的 AI 系统是完成特定用途的整体：界面、Prompt、模型、RAG 数据、Embedding、工具、身份、人工步骤、供应商、日志和下游决策都在边界内。同一模型用于“营销文案草稿”和“招聘筛选”应是两个用例记录，因为受影响者和风险完全不同。

清单覆盖自研、采购 SaaS、开源模型、办公软件内置 AI、试点、影子使用和已经退役但仍保留数据的系统。实验不等于不登记；可以用较轻字段和 experiment 状态管理。

Agent 系统还要登记非人身份和运行时发现的组件：工作负载/服务身份、委托用户与租户、MCP/工具 server、其他 Agent、队列和自动触发器。它们不是“基础设施细节”，而是决定谁能代表谁做什么、错误能传播到哪里的系统边界。

最小清单字段

字段	要回答的问题
system_id、名称、状态	唯一指向哪个系统？是提议、试验、生产、暂停还是退役？
目的与禁止用途	为什么用 AI？明确不允许做什么？非 AI 替代是什么？
业务负责人、系统负责人	谁接受业务结果？谁能停用和修复？
用户与受影响者	谁操作？谁可能承受错误或被排除？
输出与自主程度	是草稿、建议、排序、决定还是自动执行？人能否改写/否决？
组件与版本	模型、数据源、Prompt、工具、供应商、部署和关键依赖是什么？
数据与地区	使用哪些数据类别？处理/部署/受影响者在哪些地区？
风险与证据	当前分级、影响评估、测试、审批和残余风险链接在哪里？
运行与生命周期	监控负责人、复查日期、事件入口、回滚和退役条件是什么？

清单不是一次性问卷。每次上线、材料变更和退役都更新状态；资产发现、采购、费用、身份、网络流量和模型调用日志可用于发现漏登系统，但不能自动替代人工确认用途。

角色与决策权

• 高层/治理机构：确定风险容忍度和不可接受用途，处理超出项目权限的风险接受。
• 业务负责人（Accountable）：对目的、收益、受影响者和最终使用负责；一个决策最好只有一个清晰的最终责任人。
• 系统/产品负责人：维护边界、版本、控制、监控、变更和停用能力。
• 数据与模型负责人：对来源、质量、适用性、版本和限制提供证据。
• 安全、隐私、法律/合规、领域专家：按各自职责审查，不互相替代。
• 独立评测或风险挑战者：质疑假设和证据；不能由开发者单独批准自己的高风险例外。
• 运维与事件负责人：监控、升级、限制影响、恢复和复盘。
• 采购/供应商负责人：管理合同、变更通知、退出与第三方证据。
• 用户与受影响群体：提供实际工作流、可用性、申诉和潜在影响反馈。

RACI（Responsible、Accountable、Consulted、Informed）可以澄清分工，但它不是免责表。必须额外写清谁能上线、暂停、接受残余风险、批准例外、响应申诉和宣布退役。

责任链示例

“客服回复草稿 Agent”由客服运营负责人对用途负责，平台负责人维护系统，安全团队复核工具权限，隐私负责人审查数据流，质量团队独立验证，值班经理可紧急停用。模型供应商对其服务负责，但不能替本组织决定是否适合向客户使用。

练习与自测

列出你日常接触的三个 AI 用例。为每个用例写系统边界、禁止用途、受影响者、最终责任人和紧急停用者；若两人都声称“只是提供建议”，说明责任仍未闭环。

• 能区分模型、组件和完整 AI 系统。
• 能发现试点、SaaS 内置 AI 和影子使用。
• 每项高影响决定都有具名且有权的责任人。
• 供应商责任不会取代部署者对实际使用情境的责任。

下一步与资料基线

下一步进入 风险分级与影响评估。资料获取日期：2026-07-21。NIST AI RMF Core 的 Govern 1.6 要求建立 AI 系统清单，Govern 2 讨论角色与高层责任；见 NIST AI RMF Core 与 Govern Playbook。这些是自愿框架建议，不是通用法律义务。