模型 API 接入评审常被简化成“有没有 HTTPS”和“密钥放在哪里”，但真正需要回答的是数据经历了什么：用户输入是否与内部文档拼接，代理或网关会不会记录正文，上游服务如何处理请求，错误追踪是否又复制一份敏感内容。只看应用到模型的一条箭头，容易遗漏日志、重试队列和人工调试这些旁路。本文给出一套上线前的数据流盘点方法，产出处理节点清单、字段分类、允许用途和阻断措施，供工程、安全与合规人员共同核对。

先画出真实请求链路

从一个具体功能开始，例如“根据内部文档回答员工问题”，把所有组件画出来：

用户界面
  → 应用后端
  → 身份与权限检查
  → 文档检索
  → 提示词组装
  → 代理或 API 客户端
  → 模型服务
  → 输出校验
  → 用户界面

再补上旁路：应用日志、错误追踪、请求重试、缓存、消息队列、人工排查导出和备份。每个旁路都可能形成新的数据副本。

为每个节点记录六类信息

使用一张处理清单：

字段 说明
component 实际处理数据的服务或进程
operator 负责该组件的团队或外部主体
data_fields 进入该节点的字段和内容类别
purpose 处理这些字段的明确用途
storage 是否落盘、缓存、记录日志及保存位置
controls 访问、脱敏、阻断、删除和审计措施

不要只写“用户数据”。应具体到账号标识、自由文本、检索片段、文件名、会话标识和工具结果。只有字段足够具体，才能判断它是否确实是功能所必需。

用业务影响进行数据分类

分类名称可以沿用组织现有标准，不必另造体系。评审时至少区分：

同一请求可能同时包含多类数据，以限制最严格的字段决定处理方式。模型生成的摘要仍可能保留敏感含义，不能因为文本经过改写就自动降级。

在组装请求前设置阻断点

最有效的控制发生在数据离开应用边界之前。请求构造器应只选择任务必需字段，并对禁止字段直接失败，而不是先发出请求再依靠日志发现问题。

一条阻断记录应包含：

请求标识
命中的数据类别或规则
被阻断的处理阶段
非敏感字段摘要
规则版本
人工例外审批标识（如适用）

不要把被阻断的完整敏感内容再次写入安全日志。

脱敏需要按业务语义验证

正则可以识别某些格式稳定的字段，但无法覆盖所有姓名、地址、合同条款或自由文本中的间接识别信息。脱敏方案应说明：

使用代表性样本测试，并由业务负责人判断信息是否仍可能识别主体。单个示例通过不能证明所有文本安全。

把日志当作独立数据产品审查

调用日志通常只需要时间、请求标识、服务、模型标识、状态、用量和错误类别。完整提示词、检索片段、文件正文、响应和密钥不应默认记录。

逐项检查：

应用日志是否打印请求对象？
错误追踪是否附加本地变量？
代理是否记录请求与响应正文？
调试模式是否会改变日志级别？
谁能查询日志，如何导出？
删除策略是否覆盖备份和派生索引？

日志保留时间不能使用通用数字代替组织政策和适用要求。

核对所有实际处理者

请求路径可能包括应用托管方、代理服务、模型提供方、监控平台和支持人员。对每一方确认其角色、处理位置、保存行为、访问权限、删除机制和下游依赖。

这些信息应来自当前合同、服务条款和技术文档。无法确认时，把它记录为发布阻断或待决事项，不能假设“请求不会存储”或“不会用于其他目的”。

设计泄露后的可执行动作

预案至少需要：

  1. 定位受影响的应用、凭据和时间范围；
  2. 撤销或轮换具体凭据，而不扩大业务中断；
  3. 保存调查需要且获准保留的日志证据；
  4. 识别可能涉及的数据类别和处理者；
  5. 停止相关数据流或降级为不发送敏感上下文的模式；
  6. 由负责团队判断通知、修复和恢复条件。

定期使用测试凭据演练定位和撤销。演练不能使用真实敏感数据，也不应默认触发外部通知。

上线评审的最小产物

发布前应具备：

数据流图与组件负责人
字段级数据分类清单
每个处理者及其依据
请求构造和阻断规则
日志字段与访问范围
保留和删除责任
例外审批路径
凭据撤销与事件响应步骤
尚未确认的限制

任何新增工具、知识库、代理或日志平台都会改变数据流，应触发清单更新，而不是沿用旧审批。

结论与限制

模型 API 安全评审的基础是完整数据流，而不是单个网络入口。沿采集、组装、传输、日志和销毁逐节点记录字段、处理者与控制措施，才能发现不必要的数据副本并设置可执行阻断点。

本文是工程盘点方法，不构成法律或合规结论。数据分类、保留、跨境、告知与授权要求取决于组织、行业、法域和具体处理活动，应由有权限的安全与合规人员结合当前事实判断。