数据、模型与供应商治理
本节目标
把 AI 系统拆成可追溯的组件与责任边界，管理数据、模型、工具和供应商从引入到退出的风险。治理对象不是一个 API 名称，而是一条可能随时变化的价值链。
数据治理证据
每个数据源记录：来源与负责人、收集/使用目的、字段与数据主体、许可或其他授权依据、代表性与已知缺口、标注过程、质量检查、敏感类别、访问、保留/删除、跨境/共享、版本与血缘。训练、RAG、评测、人工反馈、日志和缓存都要分别登记，不能用一句“公开数据”概括。
数据质量必须与任务相连：客服历史工单很多，不代表适合医疗建议；标签一致性高，不代表历史流程公平。若无法证明来源或许可，不应通过“模型不会原样输出”来消除问题。
模型与系统组件治理
模型记录至少包含提供者、模型/权重标识、版本或快照日期、许可、预期用途、禁止用途、上下文限制、训练/微调概况（若可得）、评测、已知限制、安全配置、数据处理路径、更新策略和回退版本。
Prompt、检索索引、Embedding、阈值、工具 schema、Guardrail 和人工流程同样会改变行为，应进入组件清单与版本链。托管模型没有固定权重版本时，记录供应商暴露的版本、调用日期、区域和回归结果，并把不可控变化视为风险。
组件清单可以扩展传统 SBOM，但不能只罗列包名。每项还应关联来源/许可、完整性或固定证据、运行身份、可访问数据、网络目的地、变更通知和回滚；动态发现的 MCP server、工具与其他 Agent 必须先形成版本化快照和差异，再经允许列表与授权门进入运行时。
供应商尽调
采购前用可验证问题取代营销词：
- 服务会接收、保留、训练或人工查看哪些输入、输出、日志和反馈？默认与可配置行为分别是什么？
- 数据存放、子处理者和支持人员在哪里？组织需要哪些通知与批准？
- 如何发布模型、政策、过滤器和 API 变更？是否提供固定版本、过渡期、回滚或导出？
- 提供哪些评测、安全、隐私、可用性和事件证据？证据覆盖你的具体配置吗？
- 谁在多长时间内通知严重事件、数据问题和服务变化？如何配合调查、删除、申诉和监管询问？
- 退出时怎样导出必要记录、删除数据、撤销身份并切换到人工或替代服务？
合同可以约定数据用途、保留、子处理、变更通知、服务级别、事件协作、审计证据、知识产权、责任分配和终止协助；具体条款由采购与法律团队确定。认证或报告是输入证据，不证明你的用途、配置和集成安全。
共享责任与集中失败
供应商负责其组件，本组织仍负责选择、配置、下游动作和对受影响者的实际用途。建立“控制→责任方→证据→失效时动作”矩阵，尤其标出双方都以为对方负责的空白。
避免单点依赖：准备限流、断网、模型降级、人工处理、数据导出和退出方案。供应商不能提供必要透明度时，应降低系统权限、缩小用途或不采用，而不是用合同措辞填补不可验证的技术事实。
练习与自测
为一个外部 LLM + 内部 RAG + 发工单工具的 Agent 建组件表。逐项写数据去向、版本、责任方、变更通知、验证证据和退出动作；找出至少两个供应商故障会传导到业务的路径。
- 数据、模型、Prompt、索引、工具和人工流程都有版本与负责人。
- 能区分供应商声明、独立证据和本组织配置测试。
- 合同、技术控制和运行监控彼此补充但不互相替代。
- 退出和人工降级在采用前就已设计。
下一步与资料基线
下一步进入 文档、透明与可追溯证据。资料获取日期：2026-07-21。参考 NIST AI RMF Core 的 Govern 6/Map 4、NIST AI 600-1 的价值链与组件集成建议，以及 NIST Govern Playbook。这些资料提供风险管理建议，不构成供应商合规背书。