数据敏感级别模型路由：管控哪个模型能看到哪些数据

你的 AI 系统在上午 9 点将一条患者查询路由到了自托管模型。上午 11 点，该模型的 Pod 在部署时重启。请求队列积压，路由器检测到超时，随即回退到你用于通用查询的云端 LLM。请求成功完成，没有告警触发，监控面板一片绿色。而就在这次交互中，受保护的健康信息悄然流向了一个你根本没有签署《业务伙伴协议》的供应商。

这不是假设，而是几乎所有未经专门设计来防范此类问题的 AI 路由栈的默认行为。

当前大多数 AI 路由是一个成本与延迟优化问题：将简单查询路由到廉价快速的模型，将复杂查询路由到昂贵但强大的模型，主链路不可用时切换到备用。这套逻辑对于通用内容场景完全正确，而对于处理受监管数据的企业系统则完全错误。

缺失的维度是数据敏感性。哪个模型被允许看到这条请求，比哪个模型最便宜或最快更重要。大多数团队在原则上明白这一点，却在实践中置之不理，直到合规审查把这个问题摆上桌面。

每个团队都在做的路由决策——只是没有明确说出来

每个 AI 产品都在做路由决策，哪怕那个决策是"始终用 GPT-4o"或"始终用我们托管的 Llama 实例"。区别在于敏感性是否纳入了这个决策。

当前路由优化的是三个变量：每 token 成本、延迟百分位数，以及与查询复杂度匹配的能力等级。OpenRouter、AI 网关及各种自定义路由器都把这些旋钮暴露得很好。通过智能的供应商选择，你能降低 20-40% 的推理成本。这些都是值得追求的实实在在的收益。

但有第四个变量，大多数路由器将其视为范围之外的事：请求中数据的隐私分类。这是一条公开的帮助中心查询？是包含 HR 语境的内部员工问题？是暴露了账户详情的客户查询？是带有 PHI 的临床记录？

对于每一种情况，路由决策都是不同的——不是因为它们需要不同的能力等级，而是因为它们对于哪些模型可以合法地、符合合同地看到它们有着不同的许可集合。

数据敏感级别的实际样貌

企业数据分类框架通常收敛于三到四个级别：

• 公开：无敏感性约束。通用帮助中心内容、产品文档、匿名化的 FAQ 数据。任何有能力的模型均可。
• 内部：非受监管但不应流出组织的业务上下文。组织架构查询中的员工姓名、内部工具文档、非受监管的财务摘要。优先使用私有端点；在大多数数据协议下可接受云端回退。
• 保密：PII、财务记录、商业敏感通信。欧盟用户的 GDPR 范围数据。需要私有或合同覆盖的端点，不允许不受控的云端回退。
• 受限：HIPAA 下的 PHI、凭证、生物特征，以及受行业特定法规约束的数据（PCI、FedRAMP、ITAR）。必须运行在私有或本地基础设施上。需要明确的供应商合同。向未覆盖端点的故障转移是合规违规，而不是性能降级。

特定数据的分类并不总是显而易见的，上下文会将级别向上合并。单独的姓名是内部级别。姓名加诊断结果是 PHI 级别。姓名加金融账户是保密级别。你的分类层必须对组合进行推断，而不仅仅是单个字段的存在。

关键一点：分类必须在数据管道中向前传播。当一个源列被标记为 PII，该标签需要到达 LLM 路由器——而不是停留在最初应用它的数据目录里。

分类与路由之间的鸿沟

大多数在 AI 治理上有所投入的组织都有两个互不相通的系统：数据分类系统和 AI 路由系统。

数据目录知道哪些数据集包含敏感信息。Databricks Unity Catalog、Atlan、Alation 等工具在静态数据上进行分类，通过数据血缘传播标签，并为分析工作负载执行访问策略。这是针对数据仓库的成熟的、被充分理解的基础设施。

AI 路由器知道哪些模型可用、它们的成本和延迟概况。它对自己正在路由的请求内容一无所知。

两者之间的鸿沟，就是合规风险静默积累的地方。一条携带 PHI 的请求到达路由层，路由器评估成本和延迟，将其发送给最便宜的可用供应商。分类系统从未见过这条请求；路由系统从未见过分类。

弥合这一鸿沟，需要一个对在途请求而非静态数据集进行操作的分类层。这意味着 PII 检测需要运行在请求路径中——命名实体识别模型、针对已知标识符格式的正则模式，以及考虑字段组合的规则。检测到的敏感级别随后与成本和能力信号一起，作为第一类输入传递给路由决策。

执行实际上是什么样子的

一旦你有了敏感性感知路由，就必须决定当合适的模型不可用时该怎么办。大多数实现在这里犯了错误。

建议模式：路由器倾向于选择合适级别，但如果不可用则回退到限制较宽松的级别，也许记录一条警告。对于公开数据以上的任何数据，这都是错误的默认值。当私有端点在凌晨两点繁忙的夜晚宕机时，建议性执行等同于没有执行。

强制执行模式：对于保密或受限敏感性的请求，如果合适的模型级别不可用，则显式失败。请求返回 503。没有任何内容被记录为"成功"。告警触发。你的值班团队介入调查。

从可用性的角度思考，这感觉是错的。从合规角度思考，这感觉是正确的。一个保持静默的 HIPAA 违规，并不因为你的系统显示绿色而变得不那么违规。对合规审计员来说，可观察的事件不是"你的 AI 产品是否保持可用"，而是"PHI 是否流向了未覆盖的供应商"。显式失败才是正确的响应。

硬性执行要求将敏感性约束编码为阻断条件，而非偏好。在实践中，这看起来像是：

• 在成本/延迟优化之前，将敏感性级别作为硬性约束评估的路由规则
• 只列举同级别或更高隐私选项的回退链——受限级别的请求可以回退到不同的受限级别端点（例如，第二个本地集群），但绝不能回退到保密级别或公开端点
• 捕获每个路由决策及其敏感级别和所选模型的审计日志——不仅是错误，而是所有决策，这样你就可以向审计员证明哪些请求去了哪里
• 明确区分"该模型因成本原因是首选"与"该模型是该级别唯一允许的选项"的配置

分类分类体系在哪里失效

即使是设计良好的系统，在边缘情况下也会遇到摩擦。

动态内容组合很难处理。一条请求可能开始时无害，而在智能体工作流的中途变得敏感。一个以公开级别用户意图开始的智能体，可能通过工具调用拉入客户账户数据，突然使整个上下文变成受限级别。如果分类只在请求入口运行，这将被遗漏。分类需要在工具调用响应上运行，当任何组件受限时，整体上下文的敏感级别需要向上棘进。

跨系统边界的元数据传播比听起来更难。如果你的分类系统在数据仓库中，而你的 AI 网关在应用层，让标签清晰传播需要刻意的集成工作，而这往往因多团队所有权边界而落入裂缝。数据团队拥有目录；平台团队拥有网关；没有人拥有交接处。

分类模型本身可能失效。基于 ML 的 PII 检测会遗漏混淆的标识符，并捕获使成本膨胀的误报。基于规则的模式随着标识符格式的演变需要维护。两者都不足以作为唯一的执行机制，这就是为什么大多数成熟实现使用纵深防御：作为信号的请求级分类、供应商层的合同级控制（BAA、DPA、ZDR 协议），以及上游的数据最小化，以减少进入 AI 层的数据量。

审计发现问题

大多数团队被动地构建敏感级别路由，原因在于失败模式是不可见的，直到它不再不可见。

将 PHI 路由到未覆盖的供应商不会产生错误。它会产生一个成功的响应。失败是一种合规状态，而不是系统状态——合规状态只在审计、违规调查或监管询问期间变得可见。到那时，你正在解释你的系统根本没有记录的历史决策。

审计后评估中反复出现的模式：一个组织发现他们一直在将敏感数据路由到错误级别，只是在外部审计发现差距之后，因为他们的监控在衡量系统健康（延迟、错误率、模型可用性），而不是合规健康（哪个敏感级别去了哪个端点，是否有任何路由决策违反了策略）。

与修复成本相比，检测投资很小。捕获请求时间戳、检测到的敏感级别、所选模型以及是否评估了任何硬性约束的路由决策日志，每条请求只需几百字节。当审计员询问 PHI 是否曾经流向未覆盖的供应商时，这份日志也是你的合规证据。

构建执行栈

敏感级别路由实现有三个组件，需要在路由逻辑能够工作之前就位：

请求层的分类。 请求路径中产生敏感级别的 PII 检测步骤。这与你的数据目录分类不同，但理想情况下与之同步。请求层分类器需要处理非结构化文本，而不仅仅是结构化字段名称。

将敏感性视为硬性约束的路由策略。 这是配置，不是代码。它看起来像这样：级别=受限 → 必须使用端点集合 {私有 LLM 集群 A，私有 LLM 集群 B}；如果没有可用的 → 显式错误失败。级别=保密 → 优先使用私有端点；仅当该供应商确认 BAA 时允许云端回退。级别=公开 → 优化成本和延迟。

捕获路由决策的审计日志。 每条请求，包含其检测到的级别和所选端点。与你的操作延迟/错误日志分开，因为它服务于不同的消费者：合规职能，而不是值班工程师。

第三个环节始终是实现中被草草了事的地方。审计日志存储是无聊的基础设施，在你需要它之前没有可见的投资回报。无论如何都要构建它。

市场现状

主要云 AI 平台正在添加敏感性感知路由功能，这是一个有用的信号，表明该实践正在成为预期。Azure AI Foundry 的模型路由器支持带有区域和敏感性约束的策略驱动选择。AWS SageMaker Catalog 添加了受限分类术语，触发路由到合规批准的项目边界。OpenRouter 的主权路由将推理限制在特定地理区域以满足数据驻留合规。Vercel 的 AI 网关添加了零数据保留路由，将请求固定到具有 ZDR 策略的供应商。

这些都不能消除自己设计执行逻辑的需要。它们提供了执行原语；你仍然需要决定哪些敏感级别映射到哪些模型池，故障转移行为是什么样子，以及如何将现有的数据分类基础设施与请求路径集成。

在拥有正式 AI 治理计划的企业中，大约 40% 有某种形式的路由策略。不到 15% 将敏感级别分类集成到该路由中。差距主要是集成和所有权问题，而非技术能力问题——工具存在，但没有任何单一团队同时拥有管道的两端。

一旦第一波审计后修复故事公开，这个数字将迅速压缩。问题是你的组织是在合规审查强制要求之前，还是之后构建这一切。

现在该怎么做

如果你从零开始：先构建审计日志。在你有分类和执行之前，至少记录哪些模型端点正在处理哪些用户角色和数据上下文的请求。这给了你追溯性的可辩护性，并在你投入自动化分类之前揭示哪些流实际上是敏感的。

如果你有分类但没有路由集成：在自动化之前，将级别到端点的映射定义为明确的策略文档。跳过这一步的团队最终会得到分类数据，但无论如何都会路由到最便宜的模型，因为网关从未被告知这些级别意味着什么。

如果你有路由但没有执行：先将你的最高级别从建议切换到硬性失败。受限数据显式失败的操作中断是一个特性，而不是错误——它浮现了私有基础设施不够可靠、无法成为唯一选项的案例，在审计迫使你进行这场对话之前，推动了关于备用容量的讨论。

静默的合规失败并不是一个难以预防的问题。它是一个在发生之前难以优先考虑的问题。