智谱MaaS将上线“数据不留存”机制,调用内容用完即焚

0 阅读

智谱MaaS推“数据不留存”:调用内容用完就删

9月21日,智谱MaaS平台宣布即将上线一项新功能——“数据内容不留存”。简单来说,用户通过该平台调用大模型时,输入的提示词(prompt)和模型返回的结果(output),平台不会再存下来。这些数据只在调用过程中临时存在,任务一结束,立刻清除。

这项功能主要面向对数据敏感的企业和开发者。比如一家金融公司想用大模型分析客户投诉文本,又担心原始内容被平台留存,现在就可以申请开启这个“不留存”模式,相当于给数据加了一道保险。

不过,这并不是绝对的“零留存”。智谱明确表示,像Batch API(批量处理接口)和File API(文件上传接口)这类需要平台长期保存任务状态或文件的功能,不在此机制覆盖范围内。因为技术上,批量任务可能要跑几小时甚至几天,中间必须有状态记录;上传的文件也得暂存才能处理。强行“不留存”反而会导致功能无法使用。

此外,即便用户开启了该选项,平台在特定情况下仍会保留数据。比如监管部门要求依法留存,或者系统检测到异常行为(如大量生成违法内容、高频攻击性调用等),平台可能会把相关记录保存30天以上,用于配合调查或内部风控复盘。

为什么企业越来越在意“数据留不留”?

过去几年,大模型服务商普遍默认留存用户调用数据。理由很实际:这些数据能用来优化模型、分析使用行为、排查故障。但对企业客户来说,这带来了实实在在的合规风险。

比如医疗、金融、政务等行业,客户数据往往属于敏感个人信息或商业秘密。根据《个人信息保护法》《数据安全法》等法规,未经同意将这类数据传给第三方平台,本身就可能违规。即使平台承诺“仅用于服务”,企业法务部门也很难放心。

更麻烦的是,一旦平台发生数据泄露,哪怕只是日志里的prompt片段,也可能暴露业务逻辑、客户信息甚至内部策略。这种风险不是理论上的——2023年就有海外AI公司因日志泄露导致客户数据外流的案例。

QQ20260921-085641.jpg

所以,越来越多企业开始在采购AI服务时明确提出“数据不留存”要求。有些甚至要求签署专门的数据处理协议(DPA),明确约定数据生命周期。智谱这次的功能更新,本质上是对这类市场需求的直接回应。

“不留存”怎么实现?技术上可行吗?

从技术角度看,“不留存”并不等于“完全不留痕迹”。关键在于区分“处理中数据”和“持久化存储”。

在标准架构中,用户请求到达后,会经过网关、调度器、推理引擎等多个组件。每个环节都可能产生日志或缓存。所谓“不留存”,是指这些中间数据不会写入数据库、对象存储等长期存储系统,也不会进入用于模型训练或分析的数据管道。

具体到智谱的做法,大概率是在请求链路中标记“不留存”标签。所有带此标签的请求,其输入输出内容会被排除在常规日志采集和数据归档流程之外。内存中的临时缓存也会在任务完成后立即释放,而不是等待统一清理周期。

但要注意,基础运维日志(比如请求时间、IP地址、API密钥ID、响应状态码)通常还是会保留。这些元数据不包含业务内容,主要用于计费、限流和安全审计,一般不在“不留存”范畴内。

另外,性能上也会有轻微影响。因为跳过了部分日志写入和缓存落盘操作,单次调用的延迟可能略低;但平台整体监控和排障能力会受限,尤其在处理复杂问题时,工程师能拿到的信息变少了。

哪些场景适合开启?哪些要谨慎?

如果你是企业用户,以下情况可以优先考虑启用该功能:

  • 处理敏感文本:如客户身份证号、病历摘要、合同条款、内部会议纪要等。
  • 涉及商业机密:比如用模型分析竞品策略、生成未公开的产品方案。
  • 合规强要求行业:金融、医疗、政府、教育等领域,已有明确数据出境或第三方处理限制。

但也有几类场景要三思:

  • 依赖历史记录的功能:比如需要回溯某次生成结果做对比,或基于历史对话上下文续聊。一旦不留存,这些功能就失效了。
  • 调试和问题排查:如果模型返回了错误结果,你无法通过平台日志查看当时的输入内容,只能靠自己本地记录。
  • 使用高级API:如前所述,Batch和File类接口本身就需要持久化,强行开启可能报错或被忽略。

目前,该功能需要用户主动在MaaS控制台提交申请,经平台审核后开通。这意味着它还不是默认选项,而是作为高阶隐私保护能力提供给有明确需求的客户。

隐私与效率的平衡点在哪?

智谱这次的方案,其实反映了一个行业趋势:大模型平台正在从“默认收集”转向“按需留存”。

早期为了快速迭代,厂商倾向于尽可能多地收集使用数据。但现在,随着企业客户成熟度提高、监管趋严,平台必须提供更多数据控制权。除了“不留存”,未来可能还会出现“数据隔离区”“客户自管密钥”“本地化推理网关”等更细粒度的选项。

值得注意的是,智谱并没有走极端。它保留了法律和风控场景下的留存权限,说明平台清楚:完全的“不留痕”既不现实,也不负责任。毕竟,如果有人用API大规模生成诈骗话术,平台总得有能力追溯源头。

这种“原则+例外”的设计,或许才是可持续的路径——在尊重用户数据主权的同时,守住安全底线。

对普通开发者来说,这项更新可能影响不大。但对企业技术决策者而言,它多了一个谈判筹码:下次和AI供应商谈合同时,可以直接问:“你们支持调用数据不留存吗?”