在 AWS 买方账户内运行的 PHI 检测与去标识化
Octoryn Privacy Platform (Octopus Core internal platform)
问题
将涉及健康的文本送入 AI 与数据流程的机构,必须在数据向下游流转前找出并移除受保护健康信息(PHI),并留下可追溯的检查与放行证据。仅靠人工或单一检测器容易留下漏洞,且很难产生可举证的记录。把这类数据送出机构自有云边界之外本身也存在风险。
此前的做法
在没有专用平台的情况下,团队通常拼接脚本、单一检测服务和人工抽查,对冲突与低置信度情形的处理并不一致。证据分散甚至缺失,难以还原某条记录为何被接收或放行。数据往往需离开买方自有账户才能处理。
范围
该平台以产品边界(而非医疗应用)的形式,提供安全接入、PHI 检测、去标识化、证据留存与人工复核。医疗只是其版本化接入与放行契约的一个可选消费方。它部署进买方自有的 AWS 账户,使数据留在客户云内。
架构
安全接入对 schema、来源、MIME、恶意软件与指纹进行校验,并记录不可变的接收或拒绝证据。三层检测阶段结合确定性规则、Amazon Comprehend Medical 与自托管的专用检测器;其后由隐私网关执行归一化、重叠消解、优先级、替换、二次验证与残余风险评分,并以 fail-closed 方式放行。证据与审计存储以不可变导出方式保留哈希、偏移、版本、策略、检测器身份、复核证据与时间戳,人工复核队列则处理需要人来判断的情形。初期目标是运行在 ECS/Fargate 上的 Linux 容器产品,配套买方账户部署模板,部署在买方 AWS 账户内,EKS 选项计划在后续提供。
治理
放行采用 fail-closed:若残余风险无法消解,记录即不放行。每一步都写入不可变证据——哈希、偏移、版本、策略、检测器与复核者身份及时间戳——并可导出以供审计。全部处理在买方自有的 AWS 账户内进行,使数据边界留在客户一侧。
人的角色
低置信度、冲突、残余发现、检测器失败、不支持的语言或策略例外等情形会被路由到人工复核队列。由复核者作出决定,其决定以私有的复核者签名证据形式留存。平台负责呈现发现,由人作出最终判断。
成果
在一次独立 staging 验证中(日期为 2026-07-17/18),ECS 运行为 1/1,两个 SageMaker 端点为 1/1,由真实的五路流量驱动,配合运行时自有指标与八个失败可见的告警。人工复核队列在全部六条触发通道上以真实接入与私有复核者签名决定独立通过。在一次逆境队列对账中,全部 85 条保留的 release-candidate-DLQ 消息在不清除的情况下经由 worker 重放,之后全部八个产品 DLQ 均为 0/0/0,全部七个编排容器均为 HEALTHY。
已验证的内容
- 独立 staging(2026-07-17/18):ECS 1/1,两个 SageMaker 端点 1/1,真实五路流量,八个失败可见告警
- 全部 85 条保留的 release-candidate-DLQ 消息在不清除的情况下经 worker 重放;之后八个产品 DLQ 均为 0/0/0,七个编排容器均为 HEALTHY
- 人工复核队列以真实接入与私有复核者签名决定,在全部六条触发通道上独立通过
- 运行时镜像:固定 digest、SBOM/SLSA 证明、非 root 用户、staging ECR 扫描干净
局限
← 返回案例研究
