我构建了一个不存储日志的 AI 事件 Copilot
每个工程师都会这样做。
生产环境出故障了。你抓取日志。你把它们粘贴到 AI 对话框中。你寻求帮助。AI 给出了一个不错的答案。
大多数人认为这很正常。其实不然。这是一个巨大的安全风险。
生产日志包含敏感数据。它们包含客户 ID、身份验证错误、堆栈跟踪（stack traces）和 API 响应。有时甚至包含密钥（secrets）。
目前的调试方式是将私密数据粘贴到聊天框中，然后听天由命。我想要 AI 的帮助，但又不想要数据泄露的风险。
于是我构建了一个 AI 事件 Copilot。我遵循一个原则：即使我们拒绝存储你的数据，这个应用也必须是有用的。
该应用充当一个 AI 应急指挥部。你粘贴日志、追踪（traces）或错误。它能帮你：
• 总结变更 • 寻找故障点 • 对杂乱日志进行分组 • 解释堆栈跟踪 • 提供缓解步骤建议 • 起草复盘（postmortem）时间线
大多数开发者构建应用的方式是： 输入 → 后端 → 数据库 → LLM → 数据库 → UI。
这是一种危险的构建方式。现在你的应用拥有了每一次生产故障的存档。你不得不担心数据泄露、备份和管理员权限问题。
我想要的是一个私密的草稿本，而不是一个 SaaS 控制面板。
我的设计原则是：处理数据，而不是收集数据。
架构的工作方式有所不同：
- 对话历史保留在你的浏览器中。
- 后端不保存提示词（prompts）。
- 后端不保存模型响应。
- 每个请求都是一次性的。
我使用了 Icelake AI API，因为它符合这种隐私模型。服务器执行三个步骤：
- 脱敏敏感值。
- 向 API 发送精简后的提示词。
- 返回答案且不存储请求。
脱敏（Redaction）会有所帮助，但它不是万能护盾。它无法捕捉到所有内容。真正的胜利在于减少请求结束后你所保留的数据量。
脱敏降低了调用过程中的风险。而不存储日志则能永久降低风险。
大多数 AI 应用会问：我们可以收集什么？ 而这个应用会问：我们可以避免收集什么？
这种方法让产品变得更好。用户会感到安全。他们愿意在真实的突发事件中使用它，因为他们知道他们的想法不会被存档到我的数据库中。
下一波 AI 应用的竞争点不应仅仅在于它们有多聪明，而应在于它们的“克制”。
问问你自己： • 你拒绝存储什么？ • 你让自己无法访问什么？ • 当会话结束时，什么会消失？
AI 工具之所以有用，是因为它们不会记住一切。
Optional learning community: https://t.me/GyaanSetuAi