用户一份请求发出去之后，数据在哪些地方停留过、被谁看过、留了多久。"安全不安全"是个笼统的判断，沿着数据走一遍，能得到具体得多的答案。

　　先看经手方。业务服务器把请求发给中转层，中转层再转发给上游模型厂商，两段都是跨网络的。TLS 加密保护的是链路，别人在半路截不到明文；但它不保护端点，中转层和上游各自都能看到完整内容。这一点常被混淆：链路加密不等于只有自己人看得到。所以真正要问的是这两方各自怎么处理数据。

　　入站这一段，先确认加密是不是强制。有的入口同时开着 HTTP 和 HTTPS，老代码没改就一直在走明文。再确认证书是不是自有域名签发，共用证书的入口，出问题时连责任主体都难定位。

　　转发环节看有没有落盘。正常实现是收到请求、转发、拿到结果、释放内存，中间不落地。但为了做相似度缓存，部分平台会把请求体和结果存下来，命中后直接返回。这个机制省钱，代价是业务数据在磁盘上多了一份副本。对内容敏感的团队，这一项要单独确认是否开启、能不能关。

　　上游这一段容易被忽略：请求到底发去了哪。调用境外模型时内容会出境，涉及个人信息或行业数据的业务有明确限制；平台若能标注哪些模型是国内推理，选型时就能规避。另外要问清上游是否把调用数据用于训练，答案通常写在服务条款里，不在宣传页上。

　　日志是留存风险的大头。请求时间、凭证、token 消耗、状态码这类元数据，记下来是必要的，用于对账和排障。问题出在请求体：把完整 prompt 和回复都记进日志，等于把业务数据复制了一份，保留周期一长、访问权限一松，就是现成的泄露面。合理的做法是只留元数据，内容按天清理。

　　删除能力值得单独问。有没有自助删除、到期是否自动清理、备份里的副本怎么处理。数据能进不能出的平台，合规审查时很难交代。

　　技术之外还有合同。白皮书讲的是加密和架构，合同讲的是责任：平台在这条链上扮演什么角色、上游供应商是否披露、出了事多久内通知、删除义务怎么约定。不少团队把精力全放在技术核查上，协议条款一眼没看，真出问题才发现没抓手。

　　部署形态决定数据要不要离开自己的网。走公网转发，数据必然经第三方基础设施；内网部署形态把中转层放进自有环境，请求从内网直发上游，经手方少一个，代价是要自己运维。数据敏感度和运维能力，这两项摆在一起权衡。

　　还有一处风险常常是团队自己造成的：为了排查方便，把生产环境的请求全量打到日志系统里。中转站再规范，也挡不住这个口子。

　　沿数据走一遍，问题会具体很多。像 moxing.tuidc.com 这样把多家模型收在一个 Key 下的平台，提供内网部署形态可选，日志侧只保留元数据，适合按上述几项逐条核对。数据安全没有一劳永逸的答案，能说清每个环节怎么处理，才算风险可控。