PHI Boundary Gate：给医疗 AI 装一道"运行时护栏"

一句话

它是一个 Python CLI + 库，专门盯住 PHI（受保护健康信息）在 AI 系统各层之间的流动：检测、拦截、脱敏、出报告。

一个真实会发生的场景

保险公司的 AI 理赔助手接入了客服渠道。用户说"我上周那笔理赔被拒了"，后端工具查库后返回一串数据：claim_id=CLM-SYN-44501、member_id=MBR-SYN-8842、mrn=MRN-SYN-22091。这些值本身看起来"没什么问题"，但它们接下来会进入模型提示词、会话记忆、调试日志，最后原样发给模型供应商。

传统做法是在网络出口做一次 DLP 扫描。但 PHI 真正跑丢的地方往往不是出口，而是层与层之间：值进了 debug_log、被写进 memory、被塞进 RAG 上下文。PHI Boundary Gate 的出发点正是这里——标识符匹配只是开始，它要回答的是：这个值从哪一层进来、来自哪个字段、正在流向哪里、策略对这条路径说了什么。

项目背景

tigerless-labs 于 2026 年 7 月开源了这个包，MIT 协议，Python 3.11+，当前版本 0.8.3，204 star、32 fork。定位很清楚：面向 healthcare 与 insurance 的 AI 工作流。它不声称自己是合规产品，也不提供 HIPAA 保证——仓库里明确写着"检测结果只是 PHI 候选，需要人工复核"。这种克制反而让它成为一个可以放心放进 CI 的检查工具。

一个类比

把它想成机场安检。传统 DLP 只在登机口（网络出口）扫一遍行李；而这个工具在每一道转盘之间都做交接检查：谁把行李放上传送带（source）、哪个传送带接走了它（destination）、这份行李上贴的标签（category）在当前环节是否被允许。deny_layers 就是"这一段传送带禁止携带此类行李"，redact_layers 是"可以过，但必须贴上 [REDACTED_MEMBER_ID] 这样的替代标签"。

核心功能

分层 trace 模型。 每条 JSONL 事件记录一个上下文片段：来源层（user_message、rag_context、tool_output、model_input、memory、debug_log）、去向层（可指向 model_provider）、内容与路径。工具支持外部适配器把通用 Agent JSONL 归一化成自己的 trace schema。

混合检测。 内置正则规则覆盖电话、传真、邮箱、SSN、街道地址、邮编、医疗日期、会员/订户 ID、理赔与授权 ID、MRN 等合成变体；可选 --enable-presidio 叠加本地 Presidio + spaCy 的 NER 实体识别。

策略驱动。 YAML 策略按类别 × 层级给出 allowed / redact / violation 三态判定。判定逻辑是纯规则、可解释、可审计的，不依赖 LLM。

边界视角的报告。 这点是它最有想法的地方：报告不只罗列匹配项，而是把同一个 PHI 候选在多个 trace 事件中的出现聚合成"边界暴露"，按最严重的处置排序，违规项自动浮到顶部。同时记录 JSON 内容路径（$.tool.response.claim_id）与外部适配器路径，方便回溯原始负载。

暴露变化分析。 exposure-diff 可以对比两份审计报告，列出新出现的路径、已消失的路径、处置等级变化的路径与频次变化的路径，并附带可比性诊断。

合规守卫。 guard_compliance 依据组织自己提供的合规策略 YAML（BAA 状态、受覆盖服务、模型、功能、日志策略、存储策略）判断是否允许把 PHI 发往供应商。它只执行文件里的事实，不会去替用户查合同。

审计安全默认值。 报告默认不输出原始匹配值，可用 --report-values redacted 或 hashed；对真实 trace 还可输出脱敏后的 JSONL。

上手门槛

CLI 形态：pip install phi-boundary-gate 后运行 phi-boundary-gate scan-trace --trace trace.jsonl --policy config/phi-policy.yml --out report.md --json report.json。使用者必须自己提供策略 YAML，init 命令只能生成模板骨架。启用 Presidio 还需要额外下载 spaCy 的 en_core_web_lg 模型，体积不小。

库形态：from phi_boundary_gate import guard_text, load_policy，在业务服务里做 report_only / redact / block_on_violation 三种模式的拦截。

争议与局限

它不解决"检测不出来"的问题——脱敏是检测器驱动的，正则没匹配到的值它就漏掉，生产环境仍需调用方自己加控制和人工复核。它也不做医疗决策，不做厂商合同发现。仓库里只有合成数据，合成 PHI 的变体分布与真实病历之间必然存在落差，规则覆盖率需要按行业持续调优。此外，策略文件的正确性完全依赖使用者——如果把 debug_log 写进了允许列表，工具不会报警，只会忠实地放行。

行业意义

当 AI 真正进入医疗和保险，合规就从"上线前的一次审批"变成"每一条上下文都要守"的运行时问题。这类"边界治理"层工具是 RAG 架构落地后的必然增量：模型侧的安全对齐解决不了"值被写进了日志"这种问题。目前这类项目还处在早期，204 star、2 位贡献者，但它提出的"按层判定、按路径报告"这套模型，正在成为 AI 审计方向的一个通用范式。