2. AI供应链基础
在开展第三方AI模型与供应商风险审计之前,必须先建立一张清晰的“AI供应链地图”。与传统软件采购不同,AI模型的引入不是一次性交付,而是一条从数据、训练、托管到推理输出的持续链条。审计对象也不仅是合同上的供应商名称,而是模型生命周期中每一个可能引入风险的环节。
一、AI模型生命周期:风险沿链条传递
一个可审计的AI模型生命周期通常包含六个阶段:数据采集与标注、模型训练与微调、模型评估与对齐、模型部署与托管、推理服务与集成、监控与退役。每个阶段都可能由不同主体完成,风险也随之在链条中传递。
- 数据阶段:训练数据来源不明、版权瑕疵、隐私数据未脱敏,可能导致合规与偏见风险。
- 训练阶段:第三方使用未公开的微调方法或外部权重,可能引入后门或投毒。
- 评估阶段:供应商自评报告缺乏可复现证据,安全对齐结论难以验证。
- 部署阶段:模型托管在境外或共享推理集群,带来数据跨境与隔离风险。
- 集成阶段:API调用中传输敏感提示词,可能被供应商留存或用于再训练。
- 退役阶段:模型下线后权重、缓存与日志未清理,形成残留数据暴露。
二、第三方供应商类型:责任边界决定审计重点
AI供应链中的第三方并非同质。按责任边界,可划分为基础模型供应商、云托管与推理平台、微调与集成服务商、数据与标注供应商、插件与工具供应商五类。它们的审计重点差异明显。
| 供应商类型 | 典型交付物 | 核心风险 | 审计重点 |
|---|---|---|---|
| 基础模型供应商 | 预训练权重、API | 后门、偏见、许可限制 | 模型卡、评测报告、许可条款 |
| 云托管与推理平台 | 推理端点、GPU资源 | 数据跨境、多租户隔离 | 区域配置、日志策略、加密 |
| 微调与集成服务商 | 定制模型、RAG管道 | 数据泄露、权重外流 | 数据留存、权限、版本管理 |
| 数据与标注供应商 | 数据集、标注结果 | 版权、隐私、标注质量 | 来源证明、脱敏流程、抽检 |
| 插件与工具供应商 | Agent工具、连接器 | 越权调用、供应链投毒 | 权限最小化、签名校验 |
三、API与开源模型的引入方式及风险场景
企业引入AI模型主要有两种路径:调用第三方API,或下载开源模型自行部署。两者风险画像截然不同。
API引入方式的优点是快速、免运维,但数据必须离开企业边界。典型风险包括:提示词与输出被供应商留存、模型版本静默更新导致行为漂移、泄露、以及供应商单点故障。审计时应重点检查数据处理协议、日志保留周期、版本变更通知机制和密钥轮换策略。
开源模型引入方式看似可控,实则风险内移。企业需要自行承担权重来源验证、依赖组件漏洞、推理环境加固和许可证合规。常见误区是“开源等于安全”,忽略了模型权重可能被篡改、依赖库存在已知CVE、以及商用许可限制。
# 开源模型引入时的最小审计检查示例
model_source: huggingface.co/org/model-name
revision: a1b2c3d4 # 固定commit,避免静默更新
license: apache-2.0 # 确认商用允许
weights_sha256: 9f2c... # 校验权重完整性
dependencies:
- transformers==4.40.0
- torch==2.2.1 # 检查已知漏洞
deployment:
network: internal-only # 禁止公网直接暴露
logging: prompt_masked # 日志脱敏
四、典型风险场景与复盘
场景一:某企业通过第三方API处理客户合同,供应商在条款中保留“改进服务”的权利,导致合同文本被用于再训练。复盘结论是:数据处理条款必须明确禁止训练用途,并约定删除周期。
场景二:团队从公开仓库下载开源模型,未固定版本,某次自动拉取更新后模型输出风格突变,触发合规告警。复盘结论是:必须锁定commit与权重哈希,变更需走审批。
场景三:微调服务商将企业数据与自有数据混合训练,导致模型在其他客户场景中泄露敏感信息。复盘结论是:微调合同需约定数据隔离、权重归属和删除验证。
综合来看,AI供应链审计的起点是看清生命周期、分清供应商类型、识别引入方式。只有把这三层结构映射到具体合同、配置和日志中,后续的审计清单与测试方法才有落点。