AI API 脱敏策略是一本规则手册，规定你的团队可以向模型发送什么、模型响应后可以存储什么、请求日志中会显示什么，以及当客户提交工单时支持团队能看到什么。它之所以重要，是因为提示词和输出不再只是转瞬即逝的开发者输入。它们会变成调试记录、审计证据、截图、导出文件、支持附件以及采购审查材料。
这个策略的薄弱版本只会说“不要记录敏感数据”。这还不够。在生产流量接入模型网关之前，团队需要做出字段级决策、明确责任人、设定保留期限并制定例外处理流程。一个好的 AI API 脱敏策略会告诉工程团队何时拦截请求、告诉安全团队何时掩码数据、告诉支持团队何时对工单进行脱敏，以及告诉采购团队哪些证据可以证明工作流受到控制。
Flatkey 在这个讨论中很有用，因为目前公开网站将 flatkey.ai 定位为一个 API key，可用于官方 GPT、Claude、Gemini 以及其他模型流量，并提供使用分析、成本控制以及跨供应商的一张账单。把它视为统一的访问和审查入口。不要把它当作你自己的数据分类、法律审查、保留策略或支持脱敏流程的替代品。在上线前，请在你自己的买家账户中核实准确的账户设置、日志、导出、保留行为以及 DPA 范围。
AI API 脱敏策略：简版
在提示词到达生产环境之前，AI API 脱敏策略应回答五个运营问题：
| 问题 | 策略决策 | 责任人 |
|---|---|---|
| 提示词中禁止包含哪些数据？ | 在 API 调用前拦截机密、支付数据、原始凭证、私钥以及不受支持的受监管数据 | 安全负责人 |
| 哪些数据可以掩码后发送？ | 当任务质量仍可接受时，用令牌、哈希、标签或合成占位符替换直接标识符 | 应用负责人 |
| 哪些内容会被存入日志？ | 默认优先仅记录元数据；仅在获批的调试场景中存储载荷摘录 | 平台负责人 |
| 支持团队能看到什么？ | 在共享工单前，对客户提示词、输出、附件、截图和追踪记录进行脱敏 | 支持负责人 |
| 何时可以绕过脱敏？ | 需要明确的例外、事件目的、访问限制、保留日期以及法律/安全批准 | 治理负责人 |
实际目标不是移除每一个有用细节。目标是在不把提示词、输出、日志或工单变成失控敏感记录的前提下，保留足够的证据来排查问题、核对用量并支持客户。
先从数据地图开始，而不是正则列表
当团队从狭窄的正则表达式列表开始时，LLM 提示词脱敏通常会失败。正则有助于发现明显模式，但它们并不能定义策略。应先梳理 AI 流量出现在哪些位置：
| 记录表面 | 典型字段 | 默认处理方式 |
|---|---|---|
| 提示词正文 | 用户文本、工具参数、上传的上下文、检索到的文档、系统指令 | 发送前分类；拦截或令牌化敏感值 |
| 模型输出 | 生成的答案、引用、工具调用、代码、结构化 JSON | 在显示、存储、导出或复制到工单前扫描 |
| 网关元数据 | 供应商、模型、状态、延迟、令牌数、请求 ID、工作区、环境 | 保留用于运维和计费，除非它暴露敏感内容 |
| 网关载荷日志 | 提示词、响应、工具输入/输出、附件、嵌入输入 | 默认关闭，或放入短期保留的调试保险库 |
| 支持工单 | 客户报告、复制的提示词、输出、截图、HAR 文件、堆栈跟踪 | 在广泛共享前进行脱敏；将事件证据与常规支持分开 |
| 分析导出 | 成本行、用量行、客户/团队标签、错误类别 | 当导出离开运营团队时，对标签去标识化 |
这张地图应成为你的 AI API 脱敏策略的附录。它为审阅者提供了一个提出具体问题的位置：哪些字段被分类、哪些被掩码、哪些被保留，以及哪些角色可以批准例外。
在模型调用前对提示词进行分类
供应商的保留控制很重要，但它们不能替代提示词卫生。OpenAI 当前的 API 数据控制 说明，除非客户明确选择加入，否则 API 数据不会用于训练 OpenAI 模型，但它们也描述了可能包含提示词、响应和派生元数据的滥用监测日志，这些日志默认最多保留 30 天。Anthropic 的 API 和数据保留文档 也类似地区分了数据处理安排、零数据保留，以及安全标记的输入和输出可能被保留的情况。
这意味着你的策略不应把“供应商不会用它训练模型”作为唯一控制措施。生产环境中的 AI API 脱敏策略应定义哪些内容绝不能越过边界：
| 数据类型 | 建议操作 | 示例替换 |
|---|---|---|
| API 密钥、会话令牌、OAuth 刷新令牌、私钥 | 阻止请求并提醒所有者 | SECRET_BLOCKED |
| 支付卡号和银行详细信息 | 除非存在合规、已批准的支付流程，否则阻止 | PAYMENT_FIELD_REMOVED |
| 密码或恢复答案 | 阻止并创建安全工单 | CREDENTIAL_REMOVED |
| 任务质量不需要的直接个人标识符 | 令牌化或泛化 | CUSTOMER_4821，city_region |
| 调试所需的账户 ID | 哈希化或使用内部替代 ID | acct_hash_... |
| 内部系统提示词和隐藏的策略文本 | 不要向用户输入或支持工单暴露 | SYSTEM_CONTEXT_REDACTED |
提示词分类器不必完美也能发挥作用。它需要升级路径。如果请求包含凭据，就阻止。如果包含模型不需要的个人数据，就进行掩码处理。如果产品确实需要某个敏感值，则要求有记录在案的目的、受限的模型路径、保留责任人和审查者。
对于构建自有分类器的团队，Google Sensitive Data Protection 是关于去标识化和脱敏转换概念的有用官方参考资料。将其作为设计模式来源，而不是某个网关已启用这些控制的证明。
在输出成为记录之前进行扫描
提示词输出隐私常常被忽视，因为团队会把模型答案当作展示产物来看待。实际上，输出会被复制到工单中，存储在聊天记录里，嵌入到分析系统中，附加到缺陷报告里，并粘贴到客户邮件中。你的输出策略至少应覆盖四类风险：
| 输出风险 | 控制措施 |
|---|---|
| 模型重复了敏感提示词内容 | 在持久化和支持共享之前扫描生成文本 |
| 模型泄露了系统指令或隐藏上下文 | 检测并阻止策略/前置文本泄露模式 |
| 模型编造个人或财务事实 | 在受监管或会影响客户的使用前要求进行来源感知审查 |
| 模型包含不安全代码、秘密或凭据 | 隔离并转交安全审查 |
OWASP 的 LLM02 敏感信息泄露风险类别将泄露界定为一种模型和应用风险，可能包括个人数据、财务细节、健康记录、机密商业数据、凭据和法律文件。这是一个有用的提醒：AI API 脱敏策略不仅仅是输入过滤。它还包括输出检查、存储控制和支持流程控制。
对于高风险工作流，将生成的答案与原始提示词分开存储。在常规操作中保存经过脱敏的转录记录；只有在存在经批准的目的时，才将原始证据保留在受限的事件保险库中。
让 AI API 日志脱敏以元数据优先
AI API 日志脱敏应从“元数据优先”的默认策略开始。大多数平台团队需要请求 ID、模型名称、状态码、延迟、令牌数、路由尝试、环境、负责人和成本字段。他们并不总是需要原始提示词和原始响应。
Cloudflare 的 AI Gateway 日志文档很好地说明了这种区别为什么重要：它分别记录了收集日志和收集日志负载的控制，以及策略触发时的 DLP 字段。Vercel 的 AI Gateway 可观测性文档描述了用于监控和调试的支出、模型使用情况和可观测性指标。这些示例不是 Flatkey 的功能声明。它们展示了每个网关采购方都应评估的运行模式：元数据、负载、DLP 信号、保留和删除是彼此独立的决策。
将此日志策略作为基线：
| 日志字段 | 默认值 | 例外情况 |
|---|---|---|
| 请求 ID、工作区、环境、路由、模型、提供商 | 保留 | 无；支持和审计需要 |
| 状态、错误代码、延迟、重试/回退事件 | 保留 | 无；可靠性审查需要 |
| 令牌使用量和成本估算 | 保留 | 在需要时，在财务导出中对客户/团队标签去标识化 |
| 提示词和响应正文 | 默认不存储 | 带有已命名事件的短保留期调试保险库 |
| 工具参数和工具输出 | 按字段脱敏；仅存储已批准片段 | 安全事件或可复现的缺陷案例 |
| DLP 命中类别 | 保留策略 ID 和类别 | 避免存储被匹配到的秘密本身 |
AI API 脱敏策略还应定义删除机制。谁可以删除日志？谁可以施加法律保全？一旦原始负载被清除，派生分析会怎样处理？如果团队无法回答这些问题，那么负载日志就还不适合大规模生产使用。
在支持工单传播前先进行脱敏
支持工单往往是严谨工程控制最容易泄露的地方。客户会在工单中粘贴完整提示词。工程师会附上包含请求体的跟踪记录。截图里可能包含密钥。支持宏会把线程转发给另一家供应商。突然之间，敏感记录不再只存在于模型路径中；它还出现在帮助台、邮件通知、数仓导出以及事故复盘里。
你的 AI API 脱敏策略应把支持环节视为一个单独的表面：
| 支持工件 | 所需审核 |
|---|---|
| 复制的提示词或模型输出 | 在广泛可见之前，先脱敏标识符、密钥和受监管数据 |
| 截图 | 裁剪或模糊密钥、邮箱、客户 ID、请求体和隐藏提示词 |
| HAR 文件或跟踪记录 | 移除授权头、Cookie、载荷和签名 URL |
| 工单附件 | 在升级前先脱敏或移除敏感文件 |
| 供应商升级处理 | 共享最小复现数据，而不是原始客户内容 |
Zendesk 的官方 API 文档通过记录工单评论中字符串的脱敏，以及单独的评论附件脱敏端点，支持这种运作模式。即使你的团队使用的是不同的帮助台，策略要点也是一样：支持脱敏应当是一个明确命名的工作流，而不是在有人发现泄露值后才进行的一次性清理。
在事故发生前定义例外
每一项严格策略都需要一个受控的例外路径。如果没有，团队要么会非正式地绕过策略，要么会保留太少证据，无法解决生产问题。
使用这个例外记录：
| 字段 | 必需值 |
|---|---|
exception_id |
与事故或调查关联的唯一 ID |
business_purpose |
调试、欺诈审查、安全审查、法律保全或客户批准的支持 |
data_scope |
允许的确切字段，默认不是“完整载荷” |
access_group |
具名人员或具有限时访问权限的角色 |
retention_until |
结束该例外的日期或事件 |
reviewer |
安全、法务、隐私或产品负责人 |
customer_notice_required |
是/否，并附理由 |
deletion_or_redaction_task |
用于闭环的后续工单 |
例外路径应该足够严格，以防止随意访问原始载荷，同时又足够快速，以支持事故响应。对于常规调试，优先使用合成复现或已脱敏的样本。对于法律保全，仅保留法律顾问要求的范围。对于客户支持，在原始支持上下文之外使用客户提供的原始内容前，先征得同意。
在策略中明确责任归属
没有责任人的策略会变成束之高阁的文件。按表面划分决策归属：
| 表面 | 主要负责人 | 备份负责人 | 审查频率 |
|---|---|---|---|
| 提示词分类器和阻止规则 | 安全工程 | 应用平台 | 每月及事故后 |
| 输出扫描器 | 产品工程 | 信任与安全 | 每月 |
| 网关日志字段 | 平台工程 | 安全工程 | 每季度 |
| 保留计划 | 隐私/法务 | 安全工程 | 每季度 |
| 支持脱敏工作流 | 支持运营 | 安全运营 | 每月 |
| 导出和分析去标识化 | 数据/财务运营 | 隐私/法务 | 每季度 |
| 例外审批 | 安全/隐私委员会 | 事故指挥官 | 每次例外 |
在重大模型变更、新模态、新支持工具、新数据处理方，以及任何涉及提示词或输出暴露的事故之后，都要审查 AI API 脱敏策略。脱敏不是一次性的正则项目。它是一项随 AI 流量生命周期持续变化的活控措施。
Flatkey 买家应如何使用此策略
如果你的团队正在评估统一的 AI API 访问，请把这项策略当作采购检查清单。无论流量经过直接供应商账户、内部代理还是托管网关，都要问同样的问题：
- 哪些请求字段会出现在日志、导出、账单、仪表盘和支持工作流中？
- 载荷日志能否被禁用、限定范围或设置时限？
- 谁可以查看原始提示词和输出？
- 支持工单和附件如何脱敏？
- 哪些保留设置是合同约定、可配置的，或仅仅是运营实践？
- 供应商如何处理次级处理方、DPA 范围、法律保全和删除请求？
- 买家可以导出哪些审计证据，而不会导出原始客户内容？
Flatkey 当前的公开页面围绕一个核心：模型访问、使用分析、成本控制、预付余额，以及跨提供商的一张发票。这使它成为集中进行 AI API 运营审查的相关位置。买方仍需要先验证账户级控制，再将任何网关视为隐私、保留或支持证据的系统记录。有关当前套餐、模型和充值上下文，请在批准前查看 Flatkey pricing。
实施清单
在首次生产上线前使用此清单：
- 对提示词、输出、元数据、日志、工单、截图和导出字段进行分类。
- 在发起 AI API 请求之前阻止密钥和凭据。
- 对任务质量不需要的个人标识符进行令牌化或泛化处理。
- 默认存储元数据日志，并要求批准后才能捕获原始载荷。
- 为已批准的调试载荷设置较短的保留窗口。
- 在持久化、分析导出或支持共享之前扫描输出。
- 在升级处理前，对支持工单、附件、截图和跟踪信息进行脱敏。
- 记录例外责任人、保留日期和删除任务。
- 验证提供方的数据控制、DPA 条款、子处理方范围和账户设置。
- 在发生事故、新模型和新的支持工具之后，重新审查 AI API 脱敏策略。
常见问题
什么是 AI API 脱敏策略？
AI API 脱敏策略定义了在提示词、模型输出、网关日志、导出和支持工单中，哪些敏感字段必须被阻止、遮盖、令牌化、保留、删除或批准。它比隐私声明更具体，因为它会分配字段级处理方式和责任人。
提供方零数据保留是否足够？
不够。零数据保留或修改后的保留可以减少提供方侧存储，但它无法对你自己的提示词进行分类、清理日志、对支持工单进行脱敏，也不能管理导出。应将提供方保留策略视为更广泛的 AI API 脱敏策略中的一项控制。
AI API 日志是否应包含提示词和输出？
对于大多数生产流量，应默认仅记录元数据日志。只有在调试或合规目的已获批准、访问受限、保留期较短且清理任务已被跟踪时，才存储原始提示词和输出。
支持团队应如何处理客户提示词？
支持团队应请求所需的最小复现信息，在广泛共享前对复制的提示词和输出进行脱敏，从跟踪信息和截图中去除密钥，并且仅在受限的事故或支持工作流中保留原始证据，同时指定一个保留责任人。
Flatkey 团队应从哪里开始？
从载荷日志、数据保留和网关治理之间的内部链接开始：查看 AI API payload logging，结合 AI API data retention checklist，将其映射到你的 GDPR AI API gateway checklist，然后 get a key，并在生产前验证账户特定设置。
最终要点
持久有效的 AI API 脱敏策略，应当是开发人员、支持团队、隐私审查员和财务负责人都能实际执行的策略。保留有用的元数据。在敏感值扩散之前将其遮盖或阻止。仅为已命名的例外存储原始载荷。在升级处理前对支持工单进行脱敏。然后利用网关审查界面、最新的提供方文档以及你自己的 DPA 证据，证明这项策略不仅是写出来了，而且真正有效。
