北京
“别把敏感数据放进AI提示词。”这句话你大概率听过。道理没错，但它把问题简化了。
随着越来越多应用开始用生成式AI做文档摘要、客服问答、员工支持或客户信息处理，敏感数据出现在这些交互里几乎是必然的。与其只纠结“该不该放”，不如换个更实际的问题：数据一旦进了提示词，接下来到底会经历什么？
一个简单的客服请求，藏着多少数据副本？
假设你有一个客服应用，用大语言模型（LLM）来总结客户投诉。一个典型的请求长这样：
“总结这条客户投诉：客户Sarah Williams，邮箱sarah.williams@example.com，账号839274，投诉内容：我的订阅被重复扣费了。”
这里面显然有敏感的个人身份信息（PII）。第一反应通常是去查模型提供方：它会不会保留提示词？数据会不会用于训练？存储多久？这些问题很重要，但远不是全部。
模型只是数据旅程的一站。真实应用里，请求周围还围着应用日志、API日志、追踪系统、监控平台、对话历史，以及各种存储。把整条链路摊开看，一些跟模型本身毫无关系的风险反而更容易暴露出来。
问题可能出在你自己的日志代码里
看这行常见的调试语句：
logger.info(f"Sending prompt: {prompt}")
就这么一行，客户的姓名、邮箱、账号、投诉内容，全被复制进了你的日志平台。AI服务商可能对自己的API数据有很强的保护，但你亲手多出来的这份副本，它管不着。
多数情况下，排查问题根本不需要完整的提示词。更稳妥的写法是只记录请求ID和模型名称这类元数据：
logger.info("Sending AI request", extra={"request_id": request_id, "model": model_name})
不是说提示词绝对不能记日志，有些场景确实有合理理由。怕的是六个月前有人随手加了一行调试语句，之后再没人回头看它一眼——数据就这么意外地流出去了。
先问一句：模型真的需要这些信息吗？
在琢磨怎么保护数据之前，更该问的是：模型到底需不需要它？回到刚才的例子，如果只是要总结投诉内容，其实只需要“客户说订阅被重复扣费了”这一句就够了。同样的任务，发送的数据量少得多。
这个思路值得展开。很多场景下，提示词里塞进去的敏感字段，模型根本用不上。姓名、邮箱、账号，对生成摘要这件事毫无帮助。把它们从提示词里拿掉，任务照常完成，风险却少了一大截。
数据流视角：比“模型是否安全”更值得关注
围绕AI提示词的讨论，大多集中在模型提供方的数据政策上。但把视角拉远到整条数据流，你会发现风险点远不止模型那一环。应用日志、API网关、监控系统、第三方调试工具，每一站都可能留下敏感数据的副本。
这些副本的留存时间、访问权限、删除策略，往往比模型提供方的政策模糊得多。更麻烦的是，它们分散在不同系统里，由不同团队维护，很难统一管控。
最小化原则：能不放就不放
应对思路其实不复杂：
- 先做减法：提示词里只保留完成任务必需的信息，能去掉的敏感字段一律去掉
- 再查日志：检查所有可能记录提示词的地方，确认没有意外复制
- 最后看链路：从请求发出到响应返回，梳理数据经过的每一个节点
这个顺序很重要。先减少数据暴露面，再排查意外副本，最后才是依赖外部服务商的保护措施。顺序反了，容易把精力花在控制不了的地方，却忽略了自己能掌控的风险。
敏感数据进提示词这件事，与其当成一个“能或不能”的判断题，不如当成一个“数据会流向哪里”的追踪题。模型只是其中一站，真正的风险往往藏在你自己搭建的管道里。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
