接入外部大模型前，先查清个人数据流向

接入外部 LLM API，数据离开自己控制范围的时间点，是第一次请求发出时。作者担心的是：团队在原型阶段默认放行，等到准备上线，才发现姓名、邮箱和账号早已随输入一起发送给第三方。

这份清单给出的顺序很明确：先查看真实输入，再减少发送内容，核对供应商条款，最后把日志、密钥和事故处理纳入检查。它没有提供实验对照，但很适合用来补齐 AI 功能从演示走向上线时容易遗漏的问题。

模型需要回答问题，未必需要知道用户是谁

作者建议先抽取 50 条真实输入逐条查看。检查对象不能只有表单字段，还包括签名里的姓名、自由文本里的电话、能够关联个人的订单号，以及附件中的证件扫描件。

这里最容易低估的是间接识别信息。订单号看起来不像个人信息，却可能通过业务系统找到对应用户。只搜索邮箱和手机号，无法弄清实际发送了什么。

接着判断每类信息是否影响任务。模型可能只需要用户的问题，并不需要用户身份。没有用处的内容，可以删除或替换。

下面这段代码解决最基础的邮箱、电话替换问题：

import re
EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+")
PHONE = re.compile(r"\+?\d[\d\s().-]{7,}\d")
def scrub(text: str) -> str:
    return PHONE.sub("[PHONE]", EMAIL.sub("[EMAIL]", text))

要关注的是最后一行：它只执行两种正则替换，没有处理姓名、地址和附件。作者也明确承认，正则只能覆盖容易识别的情况，其他信息需要更合适的检测器，并用自己的数据检查遗漏。

脱敏函数存在，不代表发送内容已经安全。

供应商怎么处理数据，要在接入前写清楚

作者把供应商条款拆成四组问题：

• 输入是否被保存，保存多久，能否关闭留存。
• 数据是否默认用于训练，Business、API 档位与消费级产品是否不同。
• 数据在哪里处理，涉及哪些分包处理方。
• 能否申请删除，是否提供数据处理协议，以及有哪些审计安排。

这些问题需要和负责合规的人一起核对，并记录答案及日期。产品名称相同，也不能直接拿消费级产品的说明推断 API 条款；条款还可能变化。

另一项独立工作是确认处理个人信息的合法依据，以及现有隐私告知是否覆盖这项用途。作者认为，这个决定应由数据负责人作出，开发者需要在上线前推动确认。原文没有指定司法辖区，也没有给出某种场景必然合规的结论。

技术路线同样有选择：在自己的服务器上运行较小模型或传统机器学习方案，选择区域和留存设置合适的供应商，或者脱敏后再调用外部模型。

作者倾向于让敏感部分留在内部。但原文没有成本、效果或维护投入的对照，不能据此认定自部署一定更便宜。

API 之外，日志和缓存也在接收同一份数据

即便供应商不留存输入，原文仍可能长期保存在应用日志、错误追踪平台、分析系统、提示词缓存，或被分享到聊天中的评估集里。

因此，检查范围应该沿着文本流转路径展开。只检查请求目标地址，很容易漏掉内部复制出来的几份数据。

密钥和访问权限也是这条链路的一部分。作者要求 API keys 放在环境变量中，不进仓库或聊天；不同环境使用独立密钥，设置花费上限，保留轮换方式，并限制能够读取原始日志的人。

事故预案则要提前回答：通知谁、多久通知、如何查出哪些请求涉及哪些内容。作者建议记录请求元数据，而非原始敏感内容。不过，具体保留哪些字段、怎样关联业务记录，原文没有展开，需要团队自行设计。

我的判断

这份清单最有用的地方，是把讨论从「选哪个模型」拉回「到底发送什么」。对接收自由文本和附件的 AI 功能，这个顺序很合理。

它也有明确边界：没有报告抽查 50 条能覆盖多少问题，没有脱敏准确率，也没有比较三种部署路线。50 条适合作为起步检查，不能当成覆盖所有输入类型的保证。

正则替换门槛低，适合先处理明显格式；专门的检测器仍需要验证漏检。自部署能减少外部传输，却会增加运行和维护工作。如何取舍，要结合任务效果、数据类型和团队能力评估。

这是一份接入前的工程检查清单，还不足以单独证明系统已经满足全部要求。

能拿来做什么

• 给现有 AI 功能抽查 50 条真实输入，按正文、签名、业务编号和附件分类，记录每类信息是否确实影响任务。
• 在 Node 服务发起外部请求的位置统一处理删减和替换，并用实际输入检查漏检、误删及回答质量变化。
• 排查应用日志、错误追踪、缓存和评估集，确认输入文本被复制到了哪些地方，再分别确定访问权限和保留方式。
• 上线前整理一份带日期的接入记录，写清供应商留存、训练、处理位置和删除条款，并明确数据负责人、密钥轮换方式及事故通知安排。