主题
第 15 章 合规与数据主权
前四章处理的是"系统内部怎么把事做对"。合规提出的是另一类问题，它不关心实现是否优雅，只关心四件事能不能被回答：数据在哪里、谁能读到、能不能删干净、能不能证明。
四个问题的共同点是：它们的答案不能由工程单方面给出。数据在哪里取决于部署形态与合同，谁能读到取决于身份体系与权限模型，能不能删干净取决于第 13 章的四层语义是否落实，能不能证明取决于第 12 章的审计链是否成立。合规审查实际上是在检验前三章是否真的做到了。
本章先拆解合规对记忆系统提的四个硬问题，再分别处理数据驻留、导出与迁移、多用户隔离，然后说明定价与能力分层的关系——其中有一个容易被误读的点：门控默认关闭意味着自部署用户不受任何限制。最后把 12 至 14 章的机制串成一条可交付给审计方的证据路径。
15.1 合规提出的四个硬问题
15.1.1 数据在哪里
这个问题的答案不是一个地址，而是一组事实：数据存储的物理位置、备份的位置、日志的位置、导出副本的位置、以及任何处理数据的第三方系统的位置。
对自托管部署，答案是"在你的机房或你的云账户内"，且这个答案可以被网络拓扑验证。对托管 SaaS，答案取决于服务商的数据驻留配置，且需要合同确认。
问题在于多数团队只知道第一项（主存储位置），不知道后四项。而合规审查问的恰恰是后四项。
15.1.2 谁能读到
这个问题需要区分三个层次。
服务内部的权限：运维人员能否直接读数据库？如果能，"只有应用能访问"这句话就不成立。
应用层的权限：调用方能否读到不属于自己作用域的数据？这取决于隔离实现。
第三方的权限：服务商、云厂商、审计方、备份服务商各自能看到什么？
三层中，第一层最容易被忽略，因为它不在代码里，在运维流程里。
15.1.3 能不能删干净
第 13 章已经展开：删除是四层语义，且物理删除通常无法覆盖已导出的副本。
合规审查在这里通常会追问一个具体场景：用户要求删除，但三个月前做过一次防删除导出作为审计证据，这份导出是否也应删除？
答案取决于法务判断，而不是技术。技术能做的是把"哪些副本在删除范围内"这个事实清楚记录，让法务可以基于事实决策。
15.1.4 能不能证明
第 12 章已经展开：哈希链能证明未被篡改，不能证明已不存在。
因此合规沟通中最容易出错的一句话是"我们可以证明数据已删除"。正确的说法是"我们可以提供按约定流程完成的删除处理记录，覆盖以下范围"，并明确列出范围之外的部分。
这个区别不是文字游戏。前者在审查中被追问细节时会崩塌，后者经得起追问。
15.2 数据驻留
15.2.1 三种部署形态的驻留特征
| 形态 | 数据位置 | 驻留可控性 | 主要代价 |
|---|---|---|---|
| 自托管（本地或自有云账户） | 完全在自有环境内 | 完全可控，可由网络拓扑验证 | 需自担运维、备份、高可用 |
| BYOC（自带云） | 在自有云账户，由服务商管理软件层 | 较高，需确认管理通道的访问范围 | 合同复杂，故障责任边界需明确 |
| 托管 SaaS | 服务商环境 | 取决于服务商的数据驻留配置 | 数据出域，依赖服务商可用性与合规资质 |
表 15-1 三种部署形态的数据驻留特征
这张表第三列最值得注意：驻留可控性不是二值的，而是一个需要逐项确认的清单。BYOC 看起来是"数据在自己的云里"，但服务商的管理通道通常仍有访问能力，这一点必须在合同中明确。
15.2.2 自托管的真实含义
自托管常被当作合规的万能答案，但它只解决"数据在哪里"，不解决另外三个问题。
自托管环境下，"谁能读到"取决于你自己的权限体系；"能不能删干净"取决于你是否实现了级联删除；"能不能证明"取决于你是否有审计链。换句话说，自托管把合规责任从服务商转移到了自己身上，而不是消除了它。
这也是为什么成熟产品的开源版不应因自托管而削减功能：如果自托管版本缺少审计与级联删除，那么"自托管满足合规"这个说法就不成立。
Mnemosyne 的定位是开源版与 SaaS 引擎完全一致、无功能付费墙。这个选择的意义正在于此——自托管不是功能降级版。
15.2.3 数据驻留配置的边界
托管服务提供的"数据驻留配置"通常指选择存储区域。它不自动覆盖备份、日志、CDN 缓存与灾备副本。
因此使用这类配置时，需要逐项确认：备份是否同区域、日志是否同区域、灾备副本在哪里、跨区域复制是否开启。
这些细节通常不在产品文档的显眼位置，需要主动询问。把它们写进合同附件，比写进架构文档更有约束力。
15.3 导出与迁移
15.3.1 为什么导出是合规要求而非功能
数据可携带权要求用户能取走自己的数据。这意味着导出必须是完整、结构化、可被其它系统读取的格式，而不是一堆截图或 PDF。
同时，导出也是迁移的基础。锁定效应（数据取不出来）在采购评估中是一项实质风险，而它经常被"我们支持 API"这句话掩盖——有 API 不等于有完整导出。
15.3.2 Memory Exchange Protocol 的设计要点
一套可用的导出格式需要三个要素。
结构化记录。每条记忆的正文、元数据、时间轴、来源、置信度、验证状态。只导出正文的格式无法重建语义。
清单文件。记录导出范围、条数、生成时间、格式版本、校验和。清单让接收方能验证完整性。
可增量。支持按时间范围或作用域增量导出，否则全量导出在数据量大时不可行。
Mnemosyne 用 memory_export-v1 / memory_import-v1 实现 JSONL + manifest.json 的组合，memory_claim 用于接管外部导出的记忆。这个组合的关键在于 manifest 携带校验和——没有校验和，导入方无法判断文件是否完整。
15.3.3 防删除导出与删除权的冲突
防删除导出（deletion-proof export）用于保留审计证据：即使源记忆被删除，导出副本仍保留。
它与删除权天然冲突。解决方式不是技术，而是策略分层：
明确留存范围。哪些数据属于法定或合同约定的留存义务，哪些不属于。
隔离用途。留存副本只能用于审计，不得用于业务决策或训练。
记录隔离事实。在审计链中记录"该副本因何留存、由谁批准、留存至何时"。
到期处理。留存期满后自动清理，且清理动作同样入链。
四步都做到，才能说"我们在履行删除权的同时保留了必要的审计证据"。只做第一步，等于用"合规"当借口无限期保留数据。
15.3.4 迁移的验收清单
从任一系统迁出时，五项必须验证：
- 记录条数与清单一致，无静默丢弃
- 时间轴字段完整（
observation_date与写入时间都在） - 来源与验证状态保留
- 作用域关系保留（哪些记忆属于哪个用户/Agent）
- 导入后检索结果与导出前一致（同查询同 top-k 的命中集合重合度）
第五项最容易被跳过，也最能暴露问题：格式对了但索引重建错了，召回质量会悄悄下降。
15.4 多用户隔离
15.4.1 物理隔离与逻辑隔离的合规含义
从合规角度，两者的差别不是性能，而是可举证性。
逻辑隔离下，要证明"用户 A 读不到用户 B 的数据"，需要审查所有查询路径的过滤条件。这是一个覆盖面问题，无法穷举证明。
物理隔离下，要证明同一件事，只需证明"路径派生正确"与"文件权限正确"。这是一个点问题，可以逐项验证。
这就是为什么合规场景倾向物理隔离：不是因为更安全，而是因为更容易举证。
15.4.2 隔离验证的具体做法
三项测试，缺一不可。
跨租户读取测试。用 A 的凭据尝试读 B 的数据，期望得到空结果。注意期望是空结果而不是报错——报错说明系统意识到了越权，空结果说明数据根本不在可及范围内。
删除爆炸半径测试。删除 A 的一条记忆，验证 B 的数据完全不受影响，包括缓存与摘要。
备份恢复后隔离测试。从备份恢复后，重新执行前两项测试。这一项最容易被跳过，而恢复过程恰恰是最容易破坏隔离的环节。
15.4.3 隔离的边界
物理隔离防的是默认路径下的数据交叉。它不防配置错误——如果 namespace 被写死成固定值，所有作用域会落到同一个库。
这个风险无法靠隔离机制本身消除，只能靠检测：写入后核对返回的 namespace 是否与预期一致，不一致立即告警。
把这条检测做成常规监控，比在代码审查中靠人眼发现要可靠得多。
15.5 定价与能力分层
15.5.1 一个容易被误读的设计
Mnemosyne OS 的托管版有四档，但其中有一个关键设计需要说明：门控默认关闭。
具体含义是：自部署与从 PyPI 安装的用户不受任何层级限制。MNEMOSYNE_TIER_GATE 不设置即为关闭。门控只在出口做结果投影过滤，不改检索参数、不改 SQL、不改存储。
这个设计的合规含义是：开源版没有任何功能付费墙。审计、级联删除、物理隔离、无损压缩这些与合规直接相关的能力，在自托管版本中完整可用。
如果反过来设计——把审计与级联删除放在付费层——那么"自托管满足合规"就不成立，因为合规所需的能力需要额外付费。这是一个真实存在的行业做法，但它与"本地优先、数据主权"的定位矛盾。
15.5.2 四档的实际差异
| 层级 | 价格 | 主要差异 |
|---|---|---|
| Free | $0 / ¥0 | 全部 52 个工具；冷层召回窗口 30 天；单命名空间；审计窗口 7 天 |
| Pro | $6.9/月 或 ¥9.9/月（年付 $69 / ¥99） | 冷层永久；跨命名空间召回；审计历史不限；完整导出 |
| Team | $19.9/席/月 或 ¥29.9/席/月（年付 $199 / ¥299） | Pro 全部；多用户命名空间；团队策略；审计报告导出 |
| Compliance Add-on | $9.9/月 或 ¥19.9/月 | 仅月付、仅加购，须叠加在 Pro 或 Team 上：定期完整性报告、防删除导出、数据驻留配置 |
表 15-2 Mnemosyne OS 托管版层级（截至 2026 年 10 月）
这张表的关键在最后一行：Compliance Add-on 不是独立层级，必须叠加在 Pro 或 Team 之上。把它当作一个可单独购买的套餐，会在采购时产生误解。
第二点值得注意的是 Free 层的审计窗口只有 7 天。这意味着免费用户无法回溯一个月前的操作记录。对个人开发者够用，对任何需要举证的组织都不够——这是 Free 与 Pro 之间最实质的差异，而不是"冷层窗口"。
15.5.3 年付与试用的细节
年付按"付 10 个月用 12 个月"计价，约 16.7% 折扣。新账号含 30 天 Team 试用，无需绑卡。
美元经 PayPal Subscriptions 订阅扣款，人民币经微信扫码由运营方确认。这个差异在采购流程上会带来实际影响：美元走自动续订、可随时在 PayPal 取消；人民币走人工确认，续订需要主动操作。
15.6 合规不是功能清单，而是证据链
15.6.1 把四章串起来
合规审查要的不是"你有哪些功能"，而是"给我看证据"。证据链由四段组成，分别来自前四章。
| 审查问题 | 需要的证据 | 对应机制 |
|---|---|---|
| 数据在哪里 | 部署拓扑、备份与日志位置、第三方清单 | 自托管拓扑或驻留配置 + 合同附件 |
| 谁能读到 | 权限模型、跨租户读取测试结果 | 物理隔离 + 三项隔离测试 |
| 能不能删干净 | 删除处理记录、覆盖范围声明 | 四层删除语义 + dry_run 预览 + 级联处理记录 |
| 能不能证明 | 完整性校验结果、来源追溯链 | 哈希链 verify_integrity + memory_trace |
表 15-3 合规四问与对应证据
这张表的作用是把"合规"从一个抽象要求变成四份可准备的材料。每份材料都能被第三方复核，这才是证据；只能被自己陈述的，是说明。
15.6.2 一份可交付的合规材料包
按上表，一个团队应当能随时拿出五份材料：
- 部署拓扑图，标注数据存储、备份、日志、导出副本的位置
- 权限矩阵，列出各角色对各类数据的读写权限，含运维角色
- 隔离测试报告，三项测试的执行时间与结果
- 删除处理记录样本，含预览输出、执行记录、覆盖范围声明
- 完整性校验报告，含校验时间、总条数、校验结果
五份材料都不需要长篇论述，每份一到两页即可。关键是它们能被独立复核，而不是只能被相信。
15.6.3 常见的不合格形态
只有文档没有输出。 说明"我们支持级联删除"，但拿不出一次实际执行的记录。
只有功能没有范围。 声称"数据已删除"，但说不清覆盖了哪些副本。
只有结果没有过程。 提供校验结论"完整"，但没有校验时间、条数与执行方式。
只有当下没有历史。 能证明今天的状态，不能证明三个月前那次操作。
四种形态的共同点是：材料是自述性的，不是举证性的。审查方一旦追问细节，就会退回到"我们的实现是这样的"。
15.7 本章小结
本章确立了四条判断。
第一，合规提出的四个问题都不能由工程单方面回答。 数据在哪里取决于部署与合同，谁能读到取决于权限体系，能不能删干净取决于四层语义是否落实，能不能证明取决于审计链是否成立。合规审查实质上是在检验前三章。
第二，自托管转移合规责任而不消除它。 它解决"数据在哪里"，但"谁能读到""能不能删干净""能不能证明"仍需自己实现。这也是为什么自托管版本不应在审计与级联删除上做功能削减——削减之后"自托管满足合规"就不成立。
第三，防删除导出与删除权的冲突只能靠策略分层解决。 明确留存范围、隔离用途、记录隔离事实、到期处理，四步缺一不可。只做第一步，等于用合规当借口无限期保留数据。
第四，合规的交付物是证据链而不是功能清单。 五份材料（拓扑、权限矩阵、隔离测试、删除记录、完整性报告）都能被第三方复核，才构成证据。只有文档没有输出、只有功能没有范围、只有结果没有过程、只有当下没有历史，这四种形态在追问下都会崩塌。
本章结束了治理篇。前四章处理的都是"如何让系统可信"，而可信的前提是系统本身在被持续度量与改进。如果一个系统无法判断自己的召回质量是否在退化，那么再完整的审计链也只能证明它"一直错得很一致"。这是调优篇要解决的问题。