← 返回列表

企业引入大模型 API,数据真的安全吗

这个问题被讨论得很多,但被理解得很少。同样的顾虑,在不同行业性质和解法完全不同;而企业讨论最多的厂商侧风险,在实践中往往和员工行为侧的风险同等重要,两者需要截然不同的应对。


前段时间和一位在某大型互联网公司做开发的朋友聊天,他提到公司内部给员工提供了非常充裕的大模型 API 额度,Claude、GPT 都可以用。我当时顺口问了一句:用国外厂商的 API,不担心公司内部数据泄露吗?

他想了想,说不太清楚,他的关注点是怎么用 AI 提升效率,内部怎么考虑安全这块他没参与过。

这个回答让我觉得有点意思。不是因为他不关心安全,而是因为这个状态本身就说明了一些事情:风险是真实存在的,但大多数人并没有在认真面对它,或者说,面对它的人和使用它的人根本不是同一批人。

我在某金融科技公司做过 RAG 系统,也在不同场合和不同行业的人聊过这个话题。我的判断是,"企业用大模型 API 安不安全"这个问题,被讨论得很多,但经常被当成一个统一的技术问题在处理,而实际上它在不同行业、不同场景下性质完全不同,解法也完全不同。

两个核心顾虑,一个共同困境

企业对大模型 API 的数据安全担忧,通常集中在两点:第一,数据会不会被厂商拿去训练模型;第二,厂商内部员工能不能看到请求内容。

这两个顾虑都可以通过合同约束来管理——数据不用于训练、访问控制要求、违规追责条款都可以写进协议。但合同约束的是行为规范,不是可验证性本身。你可以要求厂商承诺"员工不得访问客户数据",却无法实时验证这个承诺是否被执行。

这才是这两个顾虑共同指向的底层困境:企业真正需要的是事前可验证,而市场上提供的几乎全是事后追责机制。SOC 2 认证、数据保密协议、访问日志审计,解决的是"出了事谁负责",而不是"怎么证明没出事"。对于一家把商业机密或客户数据发给外部 API 的企业来说,协议再完善,数据一旦泄露,损失是即时且可能不可逆的;事后打官司滞后,时间战线很长,结果也不确定。这是一个风险不对称的问题。

目前 Anthropic 和 OpenAI 的企业版协议都承诺 API 数据默认不用于训练,也有基于角色的访问控制和多因素认证。但这些保证来自厂商自述,企业客户无法独立验证,这才是这个顾虑真正难以消解的地方。

强监管行业:不是信任问题,是合规硬约束

如果把"企业用 AI API 的数据安全顾虑"当成一个统一问题来讨论,第一个需要打破的认知是:对于金融、医疗、政务这类强监管行业,这根本不是信任问题。

我在某金融科技公司参与 RAG 系统建设时,感受最深的一点是:数据在哪里处理,不是产品决策,是合规前提。核心业务系统封闭部署,外部 API 的接入有严格的审批流程,涉及客户数据的场景根本不会走外部网络。这不是因为大家不信任某个厂商,而是监管本身就不允许核心数据出企业边界。

银保监会 2016 年发布的云计算监管指导意见明确要求金融机构对敏感数据采用私有云部署,这套逻辑直接延伸到了 AI 场景。这类机构对外部大模型 API 的态度大致是:非核心、非敏感的场景可以用,核心业务数据不会出去。

海外顶级基模厂商(OpenAI、Anthropic)目前也基本不提供真正意义上的私有化部署,他们的策略是通过 AWS Bedrock、Google Vertex 这类云合作伙伴做隔离托管,数据承诺不用于训练、有访问控制,但物理上还是跑在对方的基础设施上。对强监管行业来说,这条路从合规层面就走不通。

其他行业:灰色地带里的博弈

强监管行业之外,情况完全不同。

2023 年 3 月,三星在内部引入 ChatGPT 后,短短数周内发生了三起机密数据泄露事件。涉事员工把芯片测量数据、内部会议记录、专有程序源代码直接输入 ChatGPT 获取帮助,这些内容随即上传到了 OpenAI 的服务器。三件事的共同点是:员工不是在刻意泄密,只是在用顺手的工具解决眼前的问题。事件曝光后三星随即发布内部禁令,但数据已经无法收回。

这个案例说明了灰色地带里的核心矛盾:员工的生产力诉求是真实的,风险也是真实的,但两者之间没有一个清晰的管控边界。据 Cyberhaven 的报告,2024 年企业员工上传到生成式 AI 工具的敏感数据较上年增长了 485%,其中包括客户支持信息、源代码和研发数据。这个数字来自安全厂商,有一定选择性偏差,但趋势方向大概率是真实的。

对大多数互联网公司、咨询公司、科技公司来说,引入大模型 API 并没有明确的监管红线,更多是在观望——用着,但没人愿意正式拍板说"可以用"。这就形成了一种典型的组织内部博弈:合规部门没有明确说不行,业务部门默认可以用;出了事是业务部门的问题,合规部门可以说我没批准过。风险被稀释在组织结构里,没有人真正承担。

目前实际在跑的解法

技术层面,TEE(可信执行环境)和同态加密都被讨论过,但各有局限:TEE 的性能开销在大模型推理场景下还没有大规模验证;同态加密的计算成本目前不现实。短期内没有哪个技术路径能一劳永逸地解决可验证性问题。

目前跑得通的务实路径是数据分层处理:敏感数据走本地部署的小模型,非敏感数据走公有云大模型 API。这个方案在工程上可行,在合规上说得通,代价是能力上限受本地小模型约束,而且"哪些数据算敏感"这个判断本身也需要额外的分类机制来支撑。

市场上也出现了一类专门坐在用户和大模型之间的安全网关产品,比如 Harmonic Security、Lakera 等。它们在员工发给大模型的内容里做实时检测,发现敏感信息后进行脱敏替换或直接拦截。脱敏替换的做法是把"张三的账户余额 128 万"替换成"[客户姓名]的账户余额[金额]"发出去,返回结果后再还原。这对逻辑类任务影响不大,但对需要对敏感数据本身做分析的场景会失真,延迟增加在大多数对话场景下可接受。这类产品的真实目标客户不是大型金融机构——后者直接从网络层封锁,根本不需要这层——而是管控没那么严、员工已经在自发使用 AI 的中型企业。

员工行为侧的风险同样值得重视

三星的案例也提醒了另一个容易被忽视的维度:和厂商侧风险并列,员工主动把不该发的内容发出去,同样是真实的风险来源,而且往往更难防范。

Harmonic Security 分析了 2025 年全年超过 2200 万条企业员工发给 AI 工具的真实 prompt,发现超过 90% 的企业员工在使用 AI 工具,但只有约 40% 的公司购买了官方企业版订阅(官方声称,未经独立验证)。这意味着大量员工在用个人账号访问 AI,完全在企业 IT 管控之外。这个数据来自一家卖安全产品的公司,存在选择性偏差,结论需要打折理解,但员工通过个人账号使用 AI 这个现象本身,从常识角度也说得通。

这个风险在不同行业分布很不均匀。大型金融机构通常直接在网络层封锁 ChatGPT、Claude 等域名,员工在公司网络里根本访问不了,这条路从源头切断。但在管控相对宽松的行业,这类行为既难以全面监控,责任边界也很模糊。

厂商侧风险和员工行为侧风险,是两个需要分开应对的问题,前者靠合同、合规框架和产品选型,后者靠内部管控、员工培训和使用规范。把两者混为一谈,往往导致在技术方案上过度投入,在员工行为管理上反而疏忽。

这个顾虑最终会怎么被解决

强监管行业的路径反而更清晰,因为合规边界早就划定了,现在等的是国内模型能力和私有化部署成本跟上来。海外顶级模型在这个市场里没有太多空间,这一点大概不会变。

其他行业卡在另一个地方。员工层面已经在自发使用了,但企业层面的正式决策还在观望——不是技术不够,而是"合规的 AI 使用姿势"还没有人定义清楚。

监管侧其实已经在动。2025 年 1 月《网络数据安全管理条例》正式施行,要求重要数据处理者在委托处理、共同处理重要数据前进行风险评估,并每年度更新。《个人信息保护法》也已明确,企业把含有个人信息的数据交给第三方处理,需要满足告知同意等合规要求。网络安全等级保护制度(等保 2.0)则从系统安全防护层面提出了分级要求。但这些法规针对的是数据处理的通用场景,还没有细化到"企业通过 API 调用外部大模型处理业务数据"这个具体场景的合规指引。

这个缺口迟早会被填上。历史上云计算在金融行业的普及,是监管明确给出"合规上云姿势"之后才真正加速的。AI 数据安全的合规细则一旦落地,企业就有了正式采购决策的依据,灰色地带才会开始收窄。

在这个细则出来之前,大多数企业的真实状态大概还是:知道有风险,但竞争压力摆在那里,睁一只眼闭一只眼。

从业者视角:厂商侧风险和员工行为侧风险是两条完全不同的治理链路,需要分开建账。把精力都砸在技术方案上、忽略员工使用规范,是当前企业在这个问题上最常见的失衡。在合规细则到来之前,先把"哪些数据不该出企业边界"这条红线内部说清楚,比等一个完美方案更实际。