LLM 系统治理四件套：护栏、脱敏、审计、记忆

写 demo 的时候，LLM 应用最怕的是效果不好；上了生产，最怕的是没人说得清它做过哪个决定。Stack Overflow Blog 10 月 7 日发布的生产环境 LLM 系列第四篇，讲的就是这部分最容易被写代码的人略过的治理工程。

一、发生了什么

这是系列作者观点文，主题是安全和治理要设计进去，不能事后补。四条纪律：第一，护栏要纵深分层，从输入清洗到输出校验再到二次模型复核，共六道检查点，并且失败即阻断——护栏自己挂了就升级人工，绝不能放行，每次阻断都要记成报警指标。第二，隐私信息在边界处理：字段分四级，没登记过的字段一律按敏感信息对待，跨界前先脱敏，存档用带密钥的哈希而不是裸哈希，因为手机号这类低熵数据能被猜出来。第三，审计用只增不删的账本：每个决策一行，带输入摘要、模型版本和路由结果，修正用追加新行，数据库层面直接收回改和删的权限，再用哈希链防篡改。第四，记忆要分类隔离，六个类别各自规定谁能读、能不能含个人信息；多租户场景下，决策 agent 绝不能读到别的用户的会话——那种「AI 怎么知道我的事」的横向泄漏，是最隐蔽的一种。文章还划了一条线：提示词和规则是你发布的种子，运行时学来的记忆是系统赚的，学习必须走评审，系统永远不能自己改种子。

二、跟你有什么关系

后端工程师：这四件事不写，出事那天你连复盘材料都没有。安全合规人员：审计轨迹和记忆隔离是验收清单上可以直接抄的条目。创业团队：上线前设计数据边界，比出事后补救便宜得多。

判断一家供应商治理做得怎么样，有个省力的问法：让对方演示「模型答错之后」的完整流程——怎么发现、谁被通知、记录存在哪里、能不能导出。答得顺的大概率真做过，答不出的多半只有 demo。

三、怎么用

读到这儿，可以顺路看 open-slopware：给「沾了 AI」的开源软件列一份替代清单 开源社区志愿者维护的 open-slopware 清单，逐条收录接受 LLM 的软件项目并配上无 AI 替代品，每条附证据。读完能了解它的判定标准、代表条目和正确用法。

护栏先做「失败即阻断」。判断标准很朴素：护栏报错时，系统是拦下来还是照常跑？后者等于没装。
脱敏做成唯一通道。不提供写原始数据的接口，开发者想忘都忘不了，比靠代码评审盯着强。
审计账本放到数据库层锁死。收回改删权限，再加哈希链——出了纠纷，这是一行行拿得出来的证据。
会话记忆加防火墙。任何跨用户读取直接报错，从第一天就写跨界测试。测试用例至少覆盖：同用户换设备、跨租户角色、管理员查普通用户数据三类场景。

四、三个别信的说法

「日志就是审计。」 日志会丢、会改、格式随代码变。审计账本要的是防篡改、只追加、能独立验证，是另一种东西。日志丢了没人发现，账本少一行就是对不上的账。

「哈希一下就不算存储隐私。」 不带密钥的哈希对手机号、身份证这类可枚举数据毫无保护，别人才不是暴力破解不动它。

「护栏一层大模型过滤就够。」 单层过滤器会漏，也会被模型绕过；正确做法是约束输出空间，让违规内容根本没法被表达。

五、一句话结论

经得起审计的系统，不是出了事会道歉，而是每个决定都有一行改不掉的记录。

信息来源

Part 4: Safety and governance for LLM systems: guardrails, PII, audit, and memory（Stack Overflow Blog，2026 年 10 月 7 日，作者观点）

功能与价格以官方公告为准。本文写于 2026 年 10 月 20 日。