医疗组织错误的合规假设
每个部署云AI工具的医疗组织都从他们的法律团队那里得到相同的建议：与供应商签署商业伙伴协议（BAA），您就受HIPAA保护。
BAA的要求是真实的。HIPAA的隐私规则要求受保护实体与商业伙伴签署BAA——这些商业伙伴是代表他们创建、接收、维护或传输受保护健康信息的供应商。在处理您的临床记录之前，处理您数据的AI供应商需要BAA。
但BAA的要求只涉及组织之间的合同关系。它并没有解决合同签署后PHI在供应商基础设施上的处理情况。
关键问题不是您是否有BAA，而是供应商是否可以以明文访问您的PHI——以及当他们发生泄露时，这些数据会发生什么。
商业伙伴协议实际上涵盖了什么
BAA规定商业伙伴将：
- 仅为协议中指定的目的使用PHI
- 实施适当的保护措施以保护PHI
- 向受保护实体报告任何PHI泄露
- 在协议终止时归还或销毁PHI
BAA是一种合同义务。商业伙伴承诺负责任地处理PHI，实施合理的安全措施，并在出现问题时通知受保护实体。
BAA不做的事情：
- 防止商业伙伴的系统被攻击
- 消除商业伙伴对解密形式PHI的技术访问
- 在商业伙伴被攻击时保护受保护实体免于HIPAA责任
当云AI供应商被攻击，并且他们的服务器端存储包含您患者的可解密形式的PHI时，BAA满足了泄露通知的义务——但PHI暴露是真实的，患者受到伤害，受保护实体无论签署了什么合同都面临HIPAA执法调查。
服务器端PHI问题
处理医疗数据的云AI工具基于一种基本架构：数据传输到供应商的服务器，由AI模型在那处理，然后结果返回给用户。为了使这一切正常工作，供应商的基础设施必须能够以AI模型可以处理的形式访问数据。
这意味着数据要么在供应商的服务器上是未加密的，要么加密由供应商使用供应商控制的密钥进行处理。
供应商控制的加密不是端到端加密。如果供应商持有密钥，供应商就可以解密。如果供应商可以解密，受损的供应商服务器将以可读形式暴露您的数据。
这就是BAA没有解决的架构。BAA要求供应商使用“适当的保护措施”——但由供应商控制的服务器端加密在合同上满足了这一要求，尽管它并没有提供对供应商端泄露的保护。
在这些条件下，云AI处理的医疗数据具有特定的风险特征：用于生成AI辅助的临床文档、账单代码或护理计划的PHI以可以被读取的形式存在于供应商基础设施中，如果该基础设施被攻破。
HIPAA执法并不区分“我们被攻击了，但我们有BAA”和“我们被攻击了”。受保护实体患者的PHI被曝光。受保护实体有责任保护它。保护的技术实施决定了这一义务是否得到满足——而不是合同。
零知识架构的变化
零知识架构在架构层面解决了服务器端访问问题。
在零知识实施中，PHI在离开受保护实体的环境之前被匿名化。AI供应商接收匿名数据——临床记录中的患者标识符被结构化令牌替换，账单记录中的姓名和账户号码被替换，护理计划中的人口信息被移除。
AI模型处理匿名内容并返回结果。受保护实体使用从未传输给供应商的令牌映射将结果重新关联到原始患者记录。
这改变了什么：
供应商从未接收PHI。 通过零知识匿名化处理的临床记录不包含姓名、出生日期、地址、医疗记录号码或其他HIPAA定义的PHI标识符。供应商的AI模型在匿名数据上运行。
供应商泄露不会暴露PHI。 如果AI供应商的基础设施被攻破，存储在那里的数据包含匿名内容，没有患者可识别的信息。泄露不会导致PHI暴露，因为PHI从未被传输。
BAA要求在更高标准下得到满足。 受保护实体实施的技术保护措施超出了合同最低要求——这不是因为BAA要求，而是因为架构使PHI暴露在技术上不可能，而不仅仅是合同上禁止。
实际有效的合规标准
HHS民权办公室下的HIPAA执法关注受保护实体是否实施了合理和适当的保护措施以保护PHI。“合理和适当”是根据PHI的风险、妥协的可能性和可用保护措施的成本进行评估的。
在BAA下处理PHI的云AI供应商经历了泄露。风险不是假设的。执法调查员询问的问题是受保护实体是否实施了应对其供应商关系已知风险特征的保护措施。
依赖BAA和供应商控制的服务器端加密的受保护实体采取了合同方法来解决技术问题。部署零知识匿名化以在将任何PHI传输给AI供应商之前的受保护实体采取了消除暴露的技术方法。
第二种方法解决了执法问题：PHI从未以可用形式在供应商的持有中。没有泄露可报告，没有患者可通知，没有执法调查可回应——因为架构使失败模式不可能。
对于评估云AI采用的医疗组织而言，合规框架不是“获得BAA并继续”。而是“确保PHI从未以可恢复的形式到达供应商环境。”BAA满足了合同要求。零知识架构满足了技术要求。
来源：