有没有人注意到企业级AI+PII处理实际上有多糟糕？
摘要
作者描述了一个常见的企业问题：在将数据发送给LLM之前进行PII脱敏会破坏输出，而他们正在构建一种解决方案，能够在不暴露原始数据的情况下恢复响应内容。
过去几个月我们一直在构建一个AI网关，但遇到了一个意料之外的问题。我们接触过的大多数企业要么完全禁用LLM工具，要么悄悄使用它们并希望合规部门不会注意到。当我们深入研究原因时，问题总是指向同一个点——他们无法将原始的客户或患者数据发送给外部LLM，而那些声称能解决此问题的工具只完成了一半工作。它们在发送前进行脱敏。没问题。但LLM返回的响应中带有占位符，现在必须有人手动修复才能使用。医生笔记系统、HR工具、财务报告——如果没有原始值，输出就是有问题的。我们花了很长时间解决这个问题，构建了一个在返回时恢复响应的方案。数据从未以原始形式离开你的基础设施，但输出仍然可以端到端使用。目前仍在压力测试中。发现了漏洞。正在修复。好奇这里有没有人真正遇到过这个具体问题——不是泛泛的"AI和数据隐私"焦虑，而是特指脱敏破坏了工作流。你们是怎么处理的？
相似文章
向大语言模型发送PII数据
讨论向大语言模型发送个人身份信息（PII）的风险和注意事项。
我们的AI代理在生产环境中的链断了。以下是我们的修复方案，以及为什么说这次断裂正是关键所在。
一篇博客文章，描述了作者的生产级AI代理（PiQ）在服务器重启后遇到哈希链断裂的问题，以及他们如何构建了一套工作流，用于检测、人工审核解决和持久化审计追踪，将失败转化为功能。
我们让AI代理访问数据库、邮件系统和支付API。然后我们只是……信任它们。
本文强调了当前对能够访问数据库、邮件系统和支付API的AI代理严重缺乏治理层，指出目前在没有监督的情况下信任LLM的做法危险且不足。
企业AI的下一个失败模式不是提示词。而是所有权、工具访问和过度信任代理。
文章认为，企业AI的下一个失败模式将源于代理工作流的所有权不明确和过度信任，而非模型故障，并引用了被投毒的MCP工具和缺乏监控的例子。
企业是否将AI用错了地方？
这项分析质疑了将AI机械地插入所有企业工作流程的做法，指出确定性系统往往需要传统软件而非概率性模型。它主张采取一种战略方法，区分AI能够创造杠杆效应的领域与成熟架构仍占据优势的领域。