当依赖大型语言模型（LLM）的系统开始处理真实数据或作出具有重大影响的决策时，“通常能运行”不再是可接受的标准。Stack Overflow Blog 的文章指出，在 LLM 系统成熟度模型的第四级，应通过四项相互关联的实践，将安全性和治理构建在架构本身之中：多重安全防护、在系统每个边界控制个人数据、不可篡改的审计日志，以及范围受限且明确的记忆。
多重防护，而非单一保护点
文章反对仅依赖一个模型输出过滤器，并建议将每个安全防护设计成可独立测试和排序的小型软件契约。请求应依次经过多层检查：检查输入和提示注入尝试，检查落地约束和输出格式，清理违反政策或包含个人数据的结果，然后验证业务规则；对于看似正确但实际错误的情况，还应借助次级裁决器；最后评估置信度，并确定决策是直接执行还是需要人工升级处理。
基本原则是“故障时停止”：如果某个安全防护发生故障或不可用，就不得自动放行请求。同时，应将每次拦截记录为运行信号，因为指标突然上升可能意味着攻击、版本退化或部署故障。文章强调，实际约束应使不被允许的输出无法表示，而不是只依赖模型可能绕过的文本指令。
在边界处理个人数据
系统组件之间的每次传递都构成一个安全边界：数据进入系统、发送至模型、写入日志或决策簿，以及传递给另一项服务。文章建议建立集中式敏感性分类，并默认将未知字段视为个人数据，然后在跨越每个边界之前删除、隐藏或分段处理数据。
在决策日志中，不应为了证明决策依据而完整存储敏感载荷。替代方案是使用经过编辑的摘要，以及使用 HMAC 和每个租户专用密钥生成的 keyed hash。文章指出，对电子邮件地址或卡号等低随机性数据使用普通 SHA-256，会使逆向猜测成为可能。此外，还需要采用合法且稳定的 JSON 表示方式，例如 JCS 规范，以确保重新计算哈希时得到相同结果。
证明历史的审计日志，而不仅是保存日志
文章区分了运行日志和仅追加式审计簿：运行日志适合调试，可能会轮换，也可能缺乏结构；审计簿则记录每个决策及其原因。审计簿包括决策标识、租户、权限、模型版本、提示词版本、决策、置信度和路由路径，以及经过编辑的摘要和经过哈希处理的输入。
更正不会修改旧日志，而是创建一个指向被替代条目的新条目。为发现篡改，条目通过哈希链相互关联，并验证编号的顺序及完整性。但哈希链本身无法阻止删除末尾内容或完整重建日志；因此，文章建议对条目进行签名，并定期将检查点发布到外部存储中。同时，追加操作必须在锁定状态下执行，以防两个并发写入操作创建链的两个分支。
分类记忆，以及随系统交付与运行期间获取内容之间的边界
在多租户系统中，记忆是数据治理问题，而不仅是一项功能。文章建议设置彼此分离的类别，例如租户共享知识、代理空间、临时工作流上下文、审计日志、语义知识和用户对话。每个类别都应具有访问范围、敏感性政策和分区键，并在数据存储本身强制执行；必须禁止租户之间的任何读取或写入，并将一个用户的对话与其他用户的决策代理隔离。
文章还区分了由团队随系统交付的初始数据，例如提示词、规则、测试集和落地数据，以及系统获取的运行数据，例如记忆、偏差信号和会话上下文。前者应进行版本控制，并且在运行期间不可修改；后者可以在限定范围内清理，但不得删除审计日志。任何从运行数据中提取的新行为，都应在合并到后续版本之前经过审查和测试；按照文章的说法，学习应更接近软件变更请求，而不是不可追踪的副作用。
为什么这些实践很重要？
这一方案的实际价值不在于某一项单独的工具，而在于将信任分散到彼此独立的多个层次。输出清理无法替代业务规则验证，审计日志不能为保留原始数据提供正当理由，记忆也不会因为使用向量数据库就自动变得安全。仍需通过工程决策解决的开放性约束包括：为每个系统确定合适的数据类别，制定驻留和访问政策，确定哪些情况需要人工审查，以及证明记忆清理不会删除决策所必需的输入。