Prompt-Eligibility：数据分类中缺失的那一列

调出你公司的数据分类政策。公开、内部、机密、受限——四个整齐的层级，每一个都映射到一组访问控制和一份批准的存储位置清单。现在问一个该政策从未准备回答的问题：这些层级中，哪些允许以发送给第三方模型 API 的 Token 序列的形式离开公司边界？

答案几乎总是沉默。这并非因为政策本身有误，而是因为它是不完整的。当今使用的每种分类方案都是为一种访问向量设计的，即询问“该员工是否被允许读取这一行？”Prompt 层引入了一个完全不同的向量：一个获得授权的服务读取了该行，将其转换为 Prompt，并将其跨网络传输给一个供应商，而该供应商可能会记录它、在其上进行训练，或将其以明文形式保存三十天。这些都不属于读取权限范畴。这些都不在覆盖范围内。

这就是缺失的一列。在你添加这一列之前，你的数据分类文档只是在自信地宣称一种你实际上并不具备的控制态势。

读取权限不等于外发资格

核心概念错误在于将“调用服务有权获取此字段”视为唯一需要关注的检查。当目的地是数据库连接（Join）、内部微服务或你自己基础设施中的日志行时，这是唯一重要的检查。一旦目的地变成 api.openai.com 或 api.anthropic.com，就会出现四个新问题，而读取权限无法回答其中任何一个。

第一：供应商是否保留 Prompt？大多数供应商默认的消费者条款允许出于滥用审查的目的将日志保留三十天或更长时间，有些甚至为了改进服务而永久保留。企业级层级可以协商缩短至七天或零天，但前提是你签署了协议，且仅适用于该协议涵盖的产品。例如，Anthropic 最近将默认的 API 日志保留期从三十天降至七天，并仅向符合条件的企业客户且仅针对特定的 API 产品（而非所有与 Claude 端点通信的产品）提供真正的零数据保留。

第二：Prompt 是否会进入训练集？即使“不对客户数据进行训练”是付费 API 层级的默认设置，这种承诺也是合同层面的，而非架构层面的。它仅适用于数据处理协议（DPA）中指名的产品和账户。使用个人 API Key 开发的侧边项目不在覆盖范围内。在采购部门完成审查之前，团队注册的新产品线也不在覆盖范围内。

第三：Prompt 在物理上降落在哪里？一名美国居民客户的数据通过欧盟托管的网关路由到美国托管的模型，这跨越了两个司法管辖区。这种跨越是否合法取决于传输机制（如标准合同条款 SCCs、充分性认定、后隐私盾框架），而你的读取权限 ACL 对此一无所知。

第四：还有谁在传输过程中看到了字节流？内联 DLP 网关、可观测性供应商、Prompt 注入扫描器和分析工具都可能在 Prompt 到达模型之前对其进行处理。每一个都是独立的子处理器，每一个都需要自己的 DPA，而且每一个对于构建 Prompt 的应用程序代码来说都是不可见的。

读取权限无法回答这些问题。Prompt 资格（Prompt-eligibility）是数据敏感性以及目标合同的函数——而目标合同是一个随供应商 SKU 变化的动态目标。

Prompt 资格层级长什么样

解决方案不是在现有的分类方案上贴上警告标签。解决方案是增加一个平行的分类——称之为 Prompt 资格（Prompt-eligibility）——它是计算出来的，而不是声明出来的，它最终解析为一份允许的模型端点列表，而不是一份允许的用户列表。

一个可行的方案包含三个或四个层级，每个层级都附带合同要求：

• Open (公开)：对任何模型都具备 Prompt 资格，包括消费者级 API 和未经验证的供应商。公开的营销文案、文档、开源代码。
• Bounded (受限范围)：仅对签署了 DPA 的供应商具备 Prompt 资格，该协议需禁止对输入进行训练，并将保留期限制在记录的时间窗口内。大多数内部业务数据、非公开路线图、去除了标识符的客户沟通内容。
• Restricted (限制性)：仅对拥有涵盖所使用的特定 API 产品的有效零数据保留协议的供应商具备 Prompt 资格。PII、财务记录、员工数据、包含机密处理逻辑的源代码。
• Prohibited (禁止)：无论合同如何，对任何外部供应商都不具备 Prompt 资格。身份验证密钥、原始持卡人数据、供应商无法证明合规的司法管辖区内的受监管医疗数据、任何受出口管制覆盖的内容。

关键在于，“限制性”不仅仅是数据本身的属性。它是一个以数据层级和模型端点为参数并返回允许/拒绝的函数。同一个字段——例如员工的家庭住址——对于自托管的 Llama 实例是具备 Prompt 资格的，对于启用了 ZDR（零数据保留）的 Azure OpenAI 部署也是具备 Prompt 资格的，但对于公开的 OpenAI API 则不具备 Prompt 资格，即使该公司已经为另一种产品签署了企业合同。

这让人感到不安，因为这意味着分类决策不能仅在数据层进行一次性决策后就被遗忘。它必须在构建 Prompt 的时刻，针对 Prompt 即将发往的特定端点进行评估。这听起来成本很高。但这正是问题的本质所在。

像审计数据库查询一样审计每一个提示词模板

大多数团队将提示词模板视为应用程序代码。它们存在于代码库中，通过 PR 进行审查，并在 CI 通过后发布。从隐私的角度来看，这种做法是错误的：提示词模板更像是一个将数据外泄给外部方的 SQL 查询。它理应受到与针对受监管表格运行的 SELECT 语句同等严苛的审查。

必须落地的审计流程——而且目前几乎没人执行——如下所示：对于代码库中的每一个模板，提取出所有插入的字段。对于每个字段，记录其来源表或服务、当前的数据分类以及提示词准入层级（prompt-eligibility tier）。将准入层级与该模板指向的模型端点进行交叉比对。如果任何字段的准入层级禁止使用该端点，则拦截该变更。如果任何字段的准入层级比模板作者意识到的更为宽松，则要求签核（sign-off）。

这是一项枯燥的工作。但这也是唯一能捕获到那些让所有受害者都倍感头疼的失败模式的审计方法。2023 年的三星事件——三名工程师在内部禁令解除后的几周内，分别将源代码、会议纪要和良率测试序列粘贴到 ChatGPT 中——这并非数据分类政策的失败。该政策可能已经正确地将这些源代码标记为机密。失败的原因在于没有人划定“允许工程师阅读此代码”与“允许工程师将此代码发送给我们没有合同关系的供应商”之间的界限。模板级审计虽然无法阻止手动复制粘贴，但它可以阻止同类错误的制度化版本：内部工具悄无声息地将这些源代码插入提示词，并发送给了一个没人标记过的模型。

2025 年 Microsoft 365 Copilot 中的 EchoLeak 漏洞则展示了相反的情况。在那里，分类是正确的，合同也是正确的，但提示词注入链导致 Copilot 将敏感上下文嵌入到指向外部的链接中，从而绕过了脱敏层。这并不是说审计在面对攻击者时毫无意义；它的意义在于，无论你是否映射了出口通道，它都客观存在，而攻击者会先于你对其进行映射。

在构建时脱敏，而非在 API 边界脱敏

一个常见的架构错误是将脱敏工作推给 AI 网关——一个位于应用程序代码和模型 API 之间、对出站流量强制执行策略的中心化代理。作为深度防御层，这是正确的。但作为主要控制手段，这是错误的。

当提示词到达网关时，应用程序已经组装好了字节流。关于插入哪些字段的决策已经做出。如果应用程序选择在系统提示词中嵌入员工的 SSN（社会安全号码），网关可以进行模式匹配并脱敏，但网关现在是在低上下文环境下运行：它看到 123-45-6789，必须猜测这是一个 SSN、一个零件编号还是一个序列化的时间戳。误报会破坏合法的提示词；漏报则会泄露 SSN。

正确的首要控制措施是在提示词构建时，此时应用程序代码确切知道每个字段的含义，并可以做出类型化的决策：“这是 EmployeePII.SSN，当前激活的模型端点是 Bounded（受限端点），准入映射表显示 Restricted（受限）数据不能发送到 Bounded 端点，拒绝执行。”网关随后作为一个兜底方案，拦截构建层的 Bug、插入了未经授权字段的第三方库，以及将受限数据夹带进输出的提示词注入链。

这反转了时下流行的“AI 网关救世主”架构。网关是必要的，但它不是边界。边界存在于任何将类型化值拼接到将成为提示词的字符串中的地方——这通常发生在功能团队的代码内部，并且通常在安全团队的威胁模型中是不可见的。

将你的供应商技术栈映射到准入层级

最后一步是运营层面的。你的技术栈可以触达的每一个模型端点——包括功能团队上个月添加的、你购买的 SaaS 工具中嵌入的、以及外包人员接入内部 Demo 的——都需要标记其当前的合同状态。默认 API 层级（30 天数据保留）。企业级 API（7 天数据保留且默认不进行训练）。企业级 API（协商后的零数据保留）。自托管且无外部出口。每个标签决定了哪些提示词准入层级的数据可以发送给它。

这份清单很快就会过时。供应商会更改默认值。产品会在不同的 SKU 之间移动并继承不同的条款。一个团队升级到了新的 API 版本，可能就悄无声息地脱离了涵盖旧版本的合同。审计不能是一次性的练习；它必须是每个功能团队每季度都要提供证据的定期核查。一些较好的 AI 网关实现（如 Cloudflare、Vercel、Kong 等）现在可以自动执行这种约束——它们提供策略标记路由的变体，拒绝将 Restricted 载荷转发到非 ZDR（零数据保留）端点——但网关只知道应用程序告诉它的信息。输入垃圾标签，输出的就是虚假的合规假象。

没人点破的成本真相是：这是平台化工作。它不会体现在功能开发速度上，不会影响产品指标，而且会与那些能产生这些效果的事情争夺工程时长。做这项工作的团队可能一个季度都发布不了什么新东西。而没做这项工作的团队看起来一切都好，直到监管机构问起：“在 2026 年，有哪些数据作为模型输入离开了你的边界？”而得到的回答只有耸肩。欧盟 AI 法案对通用模型的执行期限已于 2026 年 8 月通过，最高罚款可达全球收入的 7%。这才是财务部门能听懂的语境。

架构实现

Prompt 层是一个你的现有 DLP（数据泄露防护）方案未能建模的数据出口通道。电子邮件、文件存储和出站网络流量都有相应的控制措施。Prompt 层之所以能绕过这些控制，是因为它看起来像是来自应用程序内部的 API 调用，而且流出的数据看起来不像文件或电子邮件 —— 它看起来就像普通的字符串插值，这种每个开发者每天都会写上百次的代码，根本不会被视为数据外泄。

命名这个通道是第一步。在数据分类文档中增加一列“Prompt 合规层级”，并建立相应的“按层级划分的已批准模型端点”清单，这将迫使团队进行原本只会在事故回顾中才有的对话。一旦这一列存在，填充它的审计工作就会迫使每个 Prompt 模板进入与其他处理敏感数据的代码相同的审查流程 —— 这正是它从一开始就该待的地方。

尚未开展这项工作的组织并不一定已经犯错。他们只是还未接受评分。当监管机构、客户安全审查或集体诉讼取证过程提出这个问题时，给不出答案本身就是一种答案。构建这个答案的工作并不光鲜，也不利于市场营销。然而，这恰恰是那种事后看来显而易见的平台投资 —— 就像在发生数据泄露后，回过头看第一批 DLP 的部署是多么理所当然一样。现在就为这一列命名的团队，未来就不必再临时拼凑审计追踪记录。