Consus瞄准敏感数据的LLM网关：企业接入大模型，缺的不是又一个模型

YC F24 创业公司 Consus 近日在 Launch HN 发布面向企业的 LLM 网关，主要服务处理敏感数据的公司。它试图解决的问题很明确：企业已经需要使用大模型，但不愿意把源代码、客户信息、合同、财务数据和内部知识库直接交给一个无法完全控制的外部调用链路。

LLM 网关是位于企业应用与多个大模型之间的统一控制层，负责请求转发、模型路由、权限管理、数据保护、成本统计和调用审计。它和普通的模型聚合平台不同，重点不只是让开发者用一个接口接入更多模型，而是让企业能够决定什么数据可以发送、发送给谁、以什么方式发送，以及调用结果能否被追溯。

这也是 Consus 的切入点：在企业真正把 AI 接入生产系统之后，模型选择只是问题的一部分，数据治理和责任边界才是更难绕开的部分。

企业使用大模型，最难处理的是数据边界

企业在内部部署 AI 助手时，通常会遇到一个看似简单但实际复杂的问题：用户输入中到底包含什么信息？

一条“帮我修复这段代码”的请求，可能携带完整的商业逻辑；一份“总结这份客户反馈”的文档，可能包含姓名、电话、订单记录和投诉细节；一次“分析这份财务表格”的任务，则可能涉及尚未公开的经营数据。如果应用直接把这些内容发送到外部模型，企业需要回答的不只是模型好不好用，还包括数据去了哪里、保存多久、谁能查看，以及供应商是否会将其用于训练。

敏感数据场景是指处理个人信息、源代码、商业机密、金融记录、医疗资料或其他受访问权限约束的数据场景。对于这类场景，单靠开发者在业务代码里写几条判断逻辑，往往不够可靠。

原因在于，企业的大模型调用通常分散在多个产品和团队中：客服助手可能使用一家供应商，代码工具使用另一家供应商，内部搜索又可能接入自建模型。如果每个应用各自处理脱敏、权限和日志，策略很容易不一致，后续也难以审计。

Consus 这类网关的价值，在于把这些规则从单个应用中抽出来，放到一个统一的基础设施层中。应用团队仍然可以快速接入模型，但安全团队可以在更靠近出口的位置设置统一边界。

Consus 的产品逻辑：把模型调用变成可治理的网络流量

从公开发布信息来看，Consus 的核心定位不是训练新模型，而是为企业提供一层面向敏感数据的 LLM 访问控制和治理能力。它更像传统企业网络中的安全代理、服务网格或数据出口控制系统，只不过被管理的对象从普通 HTTP 请求变成了自然语言、代码、文件和模型响应。

这类网关通常需要覆盖以下几类能力：

• 统一接入：让不同内部应用通过一致的接口访问不同模型，减少业务代码与单一供应商的绑定。
• 数据识别与过滤：识别个人信息、密钥、源代码片段或企业内部标记，并根据策略进行阻断、遮蔽或替换。
• 模型路由：根据任务类型、数据敏感等级、成本和可用性，把请求分配给不同模型。
• 权限控制：按照团队、用户、应用、项目或数据等级决定哪些模型可以被调用。
• 审计追踪：记录调用时间、请求来源、所用模型、策略命中情况、消耗量和结果状态。
• 成本治理：统计不同部门和应用的 token 消耗，设置预算、速率限制和异常告警。

其中，数据识别和模型路由是敏感数据场景最关键的两环。企业不一定要求所有数据都留在本地，但通常希望把“哪些数据可以出网”变成可配置、可审计的明确规则。

例如，普通公开资料可以发送给成本较低的通用模型；包含源代码但不含用户数据的请求，可以交给企业批准的代码模型；包含身份证号、银行卡号或客户合同的请求，则需要先脱敏，或者只能发送给企业自托管的模型。这样的决策如果写在每个应用里，维护成本会随着接入模型数量线性上升；集中到网关后，规则更容易统一更新。

它和普通模型聚合层，不是一回事

模型聚合层主要解决“一个入口接入多个模型”的问题，企业级 LLM 网关还需要解决“哪些请求允许通过这个入口”的问题。两者在产品形态上可能相似，但优先级完全不同。

| 对比维度 | 直接接入模型供应商 | 普通模型聚合层 | 企业级 LLM 网关 | |---|---|---|---| | 主要目标 | 快速调用单个模型 | 统一接入多个模型 | 在统一接入的同时控制风险 | | 模型切换 | 通常需要改业务代码 | 通常支持基础路由 | 可按数据、权限、预算和任务路由 | | 数据治理 | 由各应用自行实现 | 能力通常有限 | 强调脱敏、阻断、策略和审计 | | 权限管理 | 依赖供应商或应用自身 | 可能提供团队级权限 | 面向企业组织、应用和数据等级 | | 成本统计 | 分散在不同供应商账单中 | 可做基础汇总 | 支持部门、项目、模型和预算维度 | | 适用场景 | 原型和低风险应用 | 多模型实验和统一接入 | 生产系统、合规场景和敏感数据业务 |

这意味着，Consus 的竞争对手未必只是其他网关产品，也包括企业自己维护的一套中间件、云厂商的模型治理服务，以及在应用层零散拼接出来的安全规则。

Consus 如果能够把数据策略、模型路由和审计能力做得足够简单，它的价值会体现在减少企业自建基础设施的成本；如果只能提供一个统一转发入口，而没有足够细的策略控制，它就很容易退化成另一个模型聚合服务。

企业为什么在现在需要这类产品

大模型应用正在从演示阶段进入长期运行阶段，企业的关注重点也从“能不能调用”转向“能不能持续管理”。

在早期，开发者接入模型往往只需要完成三件事：选择供应商、配置访问凭证、把返回结果接入产品。但当一个应用每天处理数万甚至数百万次请求后，新的问题会迅速出现：某个模型临时不可用怎么办？某个团队的调用量突然失控怎么办？员工把内部文档粘贴到不允许使用的模型中怎么办？一次提示词注入攻击导致检索内容被带出系统怎么办？

这些问题的共同点是，它们都不属于单个模型的能力范围，而属于调用基础设施的治理范围。

此外，企业往往不会长期只使用一家模型供应商。不同模型在代码、长文本、结构化输出、视觉理解和推理任务上的表现不同，价格和延迟也会变化。统一网关可以帮助企业保留模型选择空间，避免业务系统在早期就被某个供应商的请求格式、响应格式和计费体系锁定。

但这里也需要保持克制：统一网关并不能自动消除供应商锁定。不同模型的上下文长度、工具调用格式、结构化输出能力和安全策略仍然存在差异。网关最多可以统一接入和路由，不能保证不同模型之间完全等价替换。企业仍然需要对关键任务做回归测试，验证模型切换后准确率、延迟和输出格式是否达标。

“敏感数据安全”不能只靠一句不训练承诺

模型供应商通常会强调不使用企业数据训练模型，但企业安全评估不能停留在这一点。

数据风险至少包括四个层面：请求在传输过程中是否加密，供应商是否保存请求和响应，内部哪些人员能够查看日志，模型响应是否可能重新暴露敏感信息。即使供应商不把数据用于训练，如果日志系统长期保存完整提示词，或者内部权限过宽，仍然可能产生泄露风险。

因此，一个真正面向敏感数据的网关，需要回答一些具体问题：

1. 脱敏是在数据发往外部模型之前完成，还是请求到达供应商后才处理？
2. 网关日志默认保存哪些字段，是否会保存完整请求和响应？
3. 企业能否按应用或数据类型设置不同的保留周期？
4. 被策略阻断的请求是否会留下审计记录？
5. 网关自身部署在哪里，是否支持企业现有的身份系统和网络隔离方案？
6. 当模型返回敏感内容时，系统是否能再次检测并阻断？
7. 网关是否支持人工复核、策略版本管理和误报处理？

这些问题比“支持多少模型”更能说明产品是否适合生产环境。尤其是脱敏系统，不能只靠正则表达式处理手机号和邮箱。源代码、内部项目名称、客户合同条款和未公开财务指标，往往没有稳定的格式，需要结合企业自定义词典、分类器或上下文规则识别。

Consus 目前最值得观察的三件事

第一是策略粒度。如果企业只能配置“允许”或“禁止”，产品很难覆盖复杂组织。更实用的方式是支持按用户、部门、应用、模型、数据类型和时间段组合策略，并能解释一次请求为什么被放行或阻断。

第二是对开发者的侵入程度。网关如果要求每个团队大规模改造现有应用，落地速度会明显变慢。企业更倾向于使用兼容现有模型调用方式的接入层，同时保留对模型特有能力的支持。对于开发者而言，最理想的网关不是增加一套复杂平台，而是把安全策略变成基础设施默认能力。

第三是可验证的安全结果。Consus 需要进一步披露部署方式、数据是否持久化、支持哪些身份认证机制、是否有合规认证、如何处理日志，以及在脱敏准确率、策略延迟和故障切换方面的实际数据。当前公开信息尚不足以判断它在这些指标上的成熟度，因此不宜直接把它等同于已经完成全面合规验证的企业安全产品。

对开发者和企业采购者的实际意义

对开发者来说，LLM 网关可以减少重复实现模型适配、重试、限流、日志和成本统计的工作，但也会引入新的依赖。团队需要确认网关是否支持流式输出、工具调用、结构化响应、多模态请求和长上下文，否则一些高级模型能力可能在中间层被削弱。

对安全团队来说，网关提供了一个统一观察点，可以把过去分散在各个应用里的模型调用集中起来。但集中也意味着网关本身会成为高价值组件，必须采用高可用部署、严格权限控制和清晰的故障处理机制。如果网关不可用，所有依赖它的 AI 应用可能同时受影响。

对采购者来说，不能只看模型数量和界面功能，应该重点核查以下指标：

• 是否支持自托管或企业私有网络部署；
• 是否能配置请求和响应的不同数据保留策略；
• 是否提供完整的审计日志和导出能力；
• 是否支持企业身份认证、单点登录和细粒度权限；
• 是否具备故障切换、限流、重试和预算控制；
• 是否公开延迟、吞吐量和策略处理开销；
• 是否明确说明自身是否保存企业请求数据。

判断：这是企业 AI 的基础设施机会，但安全承诺必须落到细节

Consus 发布的意义，不在于它又增加了一个模型入口，而在于它抓住了企业 AI 落地中越来越现实的矛盾：企业希望使用最先进的模型，却不能接受数据治理完全交给业务开发者和外部供应商自行处理。

LLM 网关是企业连接外部模型与内部数据之间的控制层。它不能替代权限系统、数据分类、模型评测和安全运营，但可以把这些要求集中到模型调用链路上，降低治理分散带来的风险。

Consus 的产品方向是对的，尤其适合软件公司、金融科技、医疗服务、法律服务和拥有大量内部代码与文档的企业。不过，方向正确不等于产品已经成熟。它接下来需要证明的不是“能不能把请求转发给多个模型”，而是能否在不显著增加延迟和开发成本的前提下，稳定执行企业策略，并且让审计人员看得懂、让开发者愿意用。

截至 2026 年 10 月 13 日，公开资料尚未披露 Consus 的完整价格、性能基准、支持模型清单和安全认证信息。对企业而言，现阶段更合理的判断方式是把它视为值得评估的新型基础设施方向，而不是仅凭发布信息直接投入生产。真正的竞争，将发生在数据策略准确性、部署灵活性、可观测性和故障恢复能力这些不那么容易展示、却决定长期使用体验的地方。

参考来源

• Consus 相关安全网关行业实践讨论：用于补充企业 AI 行为审计、研发数据防护和网关治理的行业背景。
• Consus 在 Launch HN 发布的公开产品介绍：用于整理其 YC F24 背景及企业级 LLM 网关定位。受本文来源域名白名单限制，原始讨论链接未在文末列出。