缺乏充分的 Security Rule 风险分析,是 HHS OCR 明确列为 2026 年首要执法重点的问题,也是已公布执法措施中遥遥领先的最大类别。这一范围如今已包括创建、接收、维护或传输 PHI 的 AI 智能体——不仅仅是人类用户和传统系统。如果 OCR 已经开启审查或要求提交 Corrective Action Plan,最有力的证据是关于您的智能体接触过什么、何时接触的可验证记录。VeriSwarm 的 Vault 能生成这份记录;但它无法生成 CAP 结案结果或合规认定——详见本方案不涵盖的内容。
45 CFR §164.308(a)(1)(ii)(A) 要求对实体所持有的 ePHI 的机密性、完整性和可用性面临的潜在风险与漏洞,进行准确、彻底的评估。HHS OCR 明确列出的 2026 年重点领域,按优先顺序依次为:缺乏充分的安全风险分析、缺乏政策与流程、缺乏员工培训、访问权履行,以及违规报告。风险分析位居该列表之首——而且遥遥领先。2025 年公布的执法措施中,引用风险分析失误的比例相对于所有其他 HIPAA 违规类别之和约为 3:1。
OCR 正在打击的模式并非文书上的疏漏。而是那些从未更新其风险分析、以反映 PHI 如今实际如何在其系统中流动的实体——包括通过原始风险分析编写时尚不存在的自动化主体流动的情况。
为人类员工编写的风险分析,假定接触 ePHI 的是一个已知且有限的主体集合。AI 智能体打破了这一假设。同一个智能体可以调用某个 LLM 提供商,调用预约或账单集成,写入对话日志,并在出错时升级到某个备用提供商——这是传统风险分析从未设计用于覆盖的四个 PHI 可能流动的新地点,也是发生事件时 OCR 审查人员会询问的四个新问题点。
这正是 Datavant 2026 年 5 月医疗隐私简报直接指出的攻击向量:围绕人类用户构建的风险分析,会忽略威胁行为者正是智能体本身、依据有缺陷指令行事的情况,而不是外部攻击者或恶意内部人员。
无论您是在主动加强风险分析,还是在回应 OCR 出具的 Corrective Action Plan,要求都是一样的:证明发生了什么、何时发生、在何种控制下发生——并且这种证明的形式不能是事后被悄悄改写过的。Vault 会为每一个智能体决策、每一次工具调用、每一个 PHI 令牌化事件生成这份记录,并通过 SHA-256 链接与其前序事件相连。
GET /v1/suite/vault/verify
→ {
"ok": true,
"events_verified": 41_902,
"first_event_id": "evt_...",
"last_event_id": "evt_...",
"errors": []
}除了原始链条之外,按框架划分的合规报告还会将同样的底层证据打包成一种认证格式:
GET /v1/compliance/42-cfr-part-2
→ {
"framework": "42-cfr-part-2",
"status": "technical_preview",
"controls": [ /* per-control pass/warn/fail with evidence counts */ ],
"generated_at": "2026-08-05T..."
}链条中的断裂,或被报告为失败的控制项,会准确告诉您在审计人员之前应该查看哪里。这正是在截止日期压力下重建证据、与直接回放证据之间的区别。
Vault 和合规报告是一层证据,而不是法律结论。它们并不构成一份已完成的风险分析、HIPAA 合规认证,或对一份尚未结案的 OCR Corrective Action Plan 的解决方案。风险分析本身——识别威胁、评估可能性与影响、记录整改措施——仍然是贵组织必须完成的工作,通常在 OCR 正式介入后需要法律顾问参与。VeriSwarm 生成的是风险分析和任何 CAP 回应都可以引用的底层记录:关于智能体接触过什么、何时接触、在何种控制下接触的可验证证据,而不是一份无法验证的日志或重建的表格。
Vault 和 Guard 是 Max 方案的功能(299美元/月)——不包含在仅涵盖智能体信任评分与事件摄取的 VeriSwarm 免费层级中。
HIPAA 的 Security Rule 要求受保护实体和业务伙伴「对电子受保护健康信息的机密性、完整性和可用性所面临的潜在风险与漏洞进行准确、彻底的评估」(45 CFR §164.308(a)(1)(ii)(A))。HHS OCR 已将缺乏充分风险分析列为其 2026 年明确宣布的首要执法重点,并且这一直是已公布执法措施中遥遥领先于所有其他 HIPAA 违规类别之和的最大类别。
需要,只要该智能体创建、接收、维护或传输 ePHI。仅限于人类用户和传统系统的风险分析,会忽略智能体的整个攻击面:它调用的 LLM 提供商、它调用的工具集成、它写入的日志与对话记忆,以及它在出错时升级到的备用提供商。OCR 的执法模式并未为自动化主体设置例外——处理 PHI 的智能体与人类员工一样,同样属于分析范围。
Corrective Action Plan(CAP)通常要求该实体证明已完成风险分析、按既定时间表整改已识别的差距,并——根据 2026 年的执法模式——接受为期 2 年的 OCR 监管义务。在这一过程中,最有力的证据是可验证的记录:智能体接触了哪些 PHI、何时接触、在何种控制下接触。可编辑的日志在 CAP 审查中是薄弱的证据;而可验证地证明事后未被篡改的哈希链账本则是更有力的证据,不过它并不能替代风险分析或整改工作本身。
Vault 用 SHA-256 链接将每一个记录的事件——智能体决策、策略评估、PHI 令牌化与还原——与其前序事件相连接。GET /v1/suite/vault/verify 会遍历整条链,并在出现断裂时返回 pass/fail 以及断裂发生的确切事件。这使得风险分析审查(或 CAP 回应)能够就「你能否证明这份日志未被编辑过」这一问题,获得一个机器可验证的答案,而不只是一句断言。
不等同。VeriSwarm 的合规端点(GET /v1/compliance/{framework})会针对指定框架生成按租户划分的认证报告,其中的证据计数取自 Vault 和 Guard。这是一份结构化的证据材料包,而不是 OCR 的认定结果。这些证据是否满足特定的 OCR 审查或 CAP 要求,是由 OCR——或您的法律顾问——做出的法律与事实判断,而不是由 VeriSwarm 做出的。
这是风险分析可以引用的一项控制措施,而不是执行分析本身的替代品。Guard 的 PII 令牌化(POST /v1/suite/guard/pii/tokenize)降低了实际暴露风险——PHI 永远不会以未令牌化的状态到达 LLM 或工具调用——并且每一个令牌化事件都会记录在 Vault 中,这本身就是风险分析可以引用的证据。令牌化的详细运作方式在《符合 HIPAA 的 AI 智能体》页面中有深入介绍。
要了解 PHI 令牌化在智能体边界处的实际运作方式——即这条证据追踪所依赖的控制机制——请参见《符合 HIPAA 的 AI 智能体:在模型看到 PHI 之前将其令牌化》。要了解 2026 年 OCR 执法优先事项与 VeriSwarm 能力的完整对应关系,请从《面向医疗健康行业的 VeriSwarm》开始。
一场 30 分钟的现场演示,基于您真实的智能体舰队——而非演示数据。请带上您实际面临的 OCR 优先事项或 CAP 要求。