3. 核心概念与术语

在第三方AI模型与供应商风险审计中，术语混淆往往比技术漏洞更危险。审计人员若把“微调”当成“再训练”，把“模型卡”当成“合规证明”，就会在供应商尽调中放过真实风险。本节围绕七个高频术语，建立一套可审计的概念坐标系。

一、核心原理：从能力供给到责任边界

这些术语并非孤立名词，而是描述AI能力从生产到交付的链条。理解它们的关键，是看清每个环节谁掌握控制权、谁承担披露义务。

• 模型即服务（MaaS）：供应商以API或托管端点形式提供模型能力，客户不接触权重，只按调用量或订阅付费。审计关注点在于：数据是否被用于训练、日志保留多久、SLA与退出机制。
• 基础模型（Foundation Model）：在大规模广谱数据上预训练、可适配多种下游任务的模型。它是供应商的核心资产，也是风险集中点——一旦基础模型存在偏见或后门，所有下游应用都会被波及。
• 微调（Fine-tuning）：在基础模型上使用特定领域数据继续训练，调整部分或全部参数。它改变的是模型行为，不改变基础架构。审计需区分全参数微调与参数高效微调（如LoRA），后者风险更低但效果边界不同。
• 推理端点（Inference Endpoint）：模型对外提供预测服务的网络入口，包含URL、认证方式、限流策略和版本号。端点是审计的“物理接触面”，其配置直接决定数据暴露面。
• 数据飞轮（Data Flywheel）：用户交互产生数据，数据反哺模型优化，优化后吸引更多用户，形成正反馈循环。它是供应商增长逻辑，也是客户数据被二次利用的隐蔽通道。
• 模型卡（Model Card）：描述单个模型用途、训练数据、评估指标和局限性的结构化文档。它是“模型身份证”，但不等于合规认证。
• 系统卡（System Card）：描述包含模型在内的完整AI系统，涵盖安全护栏、部署环境、人机交互和滥用应对。它比模型卡更接近真实风险场景。

二、方法流程：术语如何映射到审计动作

把术语转化为审计清单，才能避免概念空转。以下流程展示从供应商声明到证据核验的路径。

1. 识别服务模式：确认是MaaS、私有化部署还是混合模式，明确权重是否可控。
2. 定位基础模型：要求供应商披露基础模型名称、版本、训练数据截止日期和已知限制。
3. 审查微调边界：获取微调数据集来源、标注流程、是否包含客户数据，以及微调后模型的评估报告。
4. 核验推理端点：检查端点认证、加密、日志策略、版本回滚能力和限流配置。
5. 评估数据飞轮：确认客户输入是否默认进入训练管道，是否有退出开关和删除机制。
6. 比对模型卡与系统卡：检查两者是否一致，系统卡是否覆盖安全测试、红队结果和滥用场景。

在技术层面，推理端点的配置可直接反映供应商的安全成熟度。例如，一个典型的端点配置应包含版本锁定和超时控制：

POST /v1/chat/completions
Host: api.vendor.example
Authorization: Bearer <>
X-Model-Version: 2024-08-01
X-Data-Retention: none
{
  "model": "foundation-x",
  "temperature": 0.2,
  "max_tokens": 512
}

若响应头中缺少数据保留策略或版本标识，审计应标记为“端点透明度不足”。

三、案例/场景：一次供应商尽调中的术语陷阱

某金融企业在引入第三方客服模型时，供应商声称“已通过微调实现金融领域适配，并提供完整模型卡”。审计团队初看材料齐全，但深入后发现三个问题：

• 模型卡仅描述基础模型，未披露微调数据中混入了该企业此前的工单记录，数据飞轮条款默认允许供应商使用客户数据优化模型。
• 推理端点未锁定版本，供应商可随时切换底层模型，导致行为漂移无法追溯。
• 系统卡缺失，安全护栏和滥用应对策略仅以口头承诺形式存在。

最终审计结论为“高风险”，要求供应商提供微调数据血缘、端点版本锁定和系统卡后方可上线。这个案例说明：术语不是文档装饰，而是责任分配的锚点。

四、误区/复盘：常见概念混淆与纠正