医疗行业从不缺少创新。但在这个全球监管最严格的数据环境中之一,规模化创新一直是其面临的挑战。
随着人工智能深入医疗运营的各个环节,这种紧张关系变得越来越明显。从临床文档记录到患者互动,再到收入周期管理,AI已不再被视为一项新兴技术。它正逐渐成为医疗机构每天依赖的基础设施的一部分,不再是试点项目,而是运营基础设施。这引发了一个大多数机构尚未完全解答的问题:在如此大规模的应用中,AI能否在不严重违反合规要求的情况下处理受保护健康信息?
真正成功实施的机构并非拥有最强大模型的那些,而是将合规视为架构设计而非事后考虑的机构。
行业数据清楚地表明了紧迫性:
- 医疗AI在2026年已成为一个512亿美元的市场,预计到2035年将达到7440亿美元。在这个规模下,合规失败是最大的风险。
- 麦肯锡估计,美国医疗系统内部存在1万亿美元的未实现改进潜力,AI可以释放这部分潜力。
- 63%的美国医生现在在临床实践中使用AI,比九个月前的47%大幅上升。这些AI中的大多数在没有真正合规架构支持的情况下接触患者数据。
- 2024年,725起医疗数据泄露事件暴露了2.75亿条记录,相当于美国人口82%的健康数据,在一年内。
- 患者数据的向量嵌入在HIPAA下被视为PHI。大多数构建检索增强生成(RAG)系统的团队是从光学字符识别(OCR)中发现这一点的,而不是从他们的工程负责人那里得知。
- 业务伙伴协议(BAA)使您的供应商在合同上承担责任。但它不能修复架构缺陷。这部分仍然需要您自己解决。
规则已经改变,但大多数团队仍在遵循旧规则
2026年医疗AI的监管环境已不再是2022年的样子。大多数团队快速部署并假设合规会随之而来。但事实并非如此,在某些情况下,规则在他们仍在构建时就已经发生了变化。这特别昂贵的原因是,这些变化没有一个是微妙的。它们被公布、讨论和执行。然而,大多数团队根本没有注意到。
2024年12月,美国卫生与公众服务部(HHS)办公室民权(OCR)发布了自2013年以来HIPAA安全规则的首次拟议更新。核心变化是:组织长期以来一直试图规避的控制措施——多因素认证(MFA)、审计日志记录、网络分段——将成为硬性要求,没有解释空间。该规则尚未最终确定,但OCR在最终确定前就已加强执法。
OCR还启动了自2016年以来的首次HIPAA审计周期,针对50个受保实体和业务伙伴,重点关注网络安全和勒索软件暴露。如果您的AI系统缺乏记录的安全架构,这就是您发现问题的方式。
2024年3月带来了另一个大多数AI团队完全忽视的转变。国家卫生信息技术协调员办公室(ONC)的HTI-1最终规则现在要求电子健康记录(EHR)开发商展示其任何AI临床决策支持工具的工作原理,包括训练数据来源、算法如何评估风险以及如何在不同患者群体中表现。如果您的AI位于认证的EHR内部,这一义务已经属于您,而大多数团队是在事后才发现这一点的。
4个真正决定您的医疗AI是否合规的因素
大多数合规计划关注错误的层面。以下是真正重要的因素。
1) PHI在您的技术栈中实际流向
大多数团队将签署的BAA视为合规对话的结束。这甚至连开始都算不上。
BAA告诉您当出现问题时谁在合同上负责。它没有说明您的患者数据是否真正受到保护;这完全取决于您的系统如何构建。根据45 CFR §164.504(e),每个代表您处理PHI的供应商都是业务伙伴,包括您的AI平台、云提供商和链条中的每个工具。与它们都签订合同并不意味着它们都能正确处理这些数据。
以下是主要平台的HIPAA合规情况:
| 平台 | BAA可用性 | 如何激活 | AI模型覆盖范围 |
|---|---|---|---|
| Microsoft Azure / Azure OpenAI | 是 | 通过数据保护附录自动包含 | GPT-4o, GPT-4, GPT-3.5 on Azure |
| AWS Bedrock/SageMaker | 是 | 通过AWS Artifact自助服务 | Claude, Llama, Titan —仅限HIPAA合格服务 |
| Google Cloud/Vertex AI | 是 | 通过Google Cloud医疗保健协议 | 仅Vertex AI上的Gemini |
| OpenAI Enterprise | 是 | 企业层级协议 | GPT-4o, GPT-4 |
| 消费版ChatGPT / Claude.ai / Gemini | 否 | 不可用 | 绝对不要与PHI一起使用 |
2) 当您的模型遇到患者数据时会发生什么
在未先对患者记录进行去标识化的情况下在患者记录上训练AI会带来大多数团队意想不到的问题。PHI在训练完成后不会消失;它可能持续存在于模型权重中。研究人员已经证明,大型语言模型(LLM)在特定提示条件下会逐字复制训练数据。基于您EHR构建的模型实际上是以标准访问控制从未设计解决的形式携带患者信息。
两种真正有效的方法:
联邦学习从源头解决了这个问题。不是将患者数据移动到中央训练环境,而是将模型发送到数据。每家医院本地训练并仅发送回模型更新;基础记录永远不会移动。
NVIDIA FLARE是实际部署此功能的开源框架,包括在71个国际医疗站点运行的计划,其结果发表在《自然医学》杂志上。联邦模型的表现优于集中训练的模型。马萨诸塞州总医院和美国放射学院都使用此框架。
差分隐私更进一步,在模型更新离开每个站点之前添加校准的噪声,使得无法从共享数据中重建个人患者记录。Google的DP库和Meta的PyTorch Opacus都是可投入生产的。权衡是模型准确性略有下降;大多数医疗应用认为这是可以接受的。
去标识化听起来很简单,直到您意识到在45 CFR §164.514下有两种法律上不同的方法,而大多数团队无法告诉您他们实际上使用的是哪一种:
**安全港(Safe Harbor)**要求去除18个特定标识符,包括姓名、社保号、电话号码、IP地址、日期、地理数据等。邮政编码是让大多数人绊倒的一个:如果该区域覆盖的人口至少为20,000,您只能保留前三位数字。遗漏任何一个标识符,数据仍然是PHI,无论其他部分看起来多么干净。
**专家判定(Expert Determination)**则采取完全不同的方法。合格的统计学家评估从数据中重新识别某人的实际风险,并签署结论认为风险确实很小。它在您可以保留的内容上给予更多灵活性,但需要记录的方法论和准备在结论上署名的人。Amazon Comprehend Medical和Google Cloud Healthcare API在实践中都很好地处理了安全港自动化,包括剥离直接烧入DICOM放射图像中的标识符,这比您预期的会更多地让团队措手不及。
3) 控制谁和什么访问您的AI系统
多年来,医院IT基于一个简单的假设运行:如果流量在内部网络中,就可以信任。AI完全打破了这一假设,不是因为它引入了新的威胁,而是因为它创建了从未成为原始安全模型一部分的新访问点。
这正是零信任(Zero Trust)的构建目的。根据NIST SP 800-207,没有任何东西仅仅因为位于正确的网络上就能获得访问权限。对AI系统的每个请求都会得到全新验证——谁在请求、他们在什么设备上、他们需要访问什么。即使是在医院Wi-Fi上的临床医生仍然必须证明是他们自己、在干净的设备上、有正当理由在那里。
微分段(Micro-segmentation)使其在大规模上变得实用。每个组件都位于自己隔离的段中——AI模型容器、FHIR连接器、EHR集成。如果放射AI工具被攻破,它会被限制住。它无法访问计费基础设施、药房记录或其边界之外的任何内容。VMware NSX和Illumio是生产医疗环境中最常用的解决方案。听起来像是一个大项目,但此时这已经是标准了。
4) HIPAA实际要求的审计跟踪
大多数团队设置了日志记录。但更少团队设置了能够通过OCR调查的日志记录类型。
根据45 CFR §164.312(b),每个包含或使用患者数据的系统必须记录和检查活动,而对于AI,这一范围比大多数工程团队考虑的更广:
- 每个包含或引用PHI的提示——谁发送的、何时发送、包含什么数据
- 每个包含PHI的模型输出——生成了什么以及它从什么来源获取
- 每个身份验证事件、数据访问和模型版本更改
- 包含患者嵌入的向量数据库的访问日志
AWS CloudTrail、Azure Monitor和Google Cloud Audit Logs自动处理API级别的捕获。这部分通常没问题。大多数团队不足的地方是应用层——记录AI查询中包含哪些特定患者记录,而不仅仅是发生了查询。
根据45 CFR §164.316,这些日志需要保留六年,与应用数据分开存储,仅追加以确保不能悄悄删除,并且静态加密。但大多数组织遗漏的部分是最后的要求:必须主动审查这些日志。没有人查看的日志服务器不是一个合规的审计计划,只是存储。OCR知道区别,在任何调查中的第一个请求就是查看审计跟踪。
目前实际在生产中运行的内容
Doximity 2026报告发现,75%目前使用AI的医生表示它已经减少了行政负担。65%估计它可以将每周额外一到五小时重新分配给直接患者护理。需求是真实的,这也是生产部署加速的原因。
Microsoft Dragon Copilot——基于Azure OpenAI构建的环境AI临床文档——已在Intermountain Health、Mercy Health和Yale New Haven等数千名临床医生中投入使用。Intermountain报告称,每次预约的笔记时间减少了27%,拥有2500多名活跃临床用户。Mercy的护士报告称,每12小时轮班在记录上节省了大约2小时——供应商报告的数字,但在独立医疗机构中一致。
Epic覆盖3.25亿患者记录,并为其平台上的每个医疗系统提供环境AI文档。如果您最近看过医生,很有可能这项技术已经在那个诊室中。这些部署的共同点是,合规性不是在最后添加的,而是从一开始就设计的。
Aidoc拥有17个FDA批准的算法在1600多家医院中运行。Cedars-Sinai的放射科医生看到ICU停留时间下降了23%。在芝加哥大学,检测脑出血的时间减少了35%。这些数字不是来自营销材料——它们发表在《放射学:人工智能》和《脑科学》杂志上。在供应商经常过度宣传成果的领域,这一区别很重要。
审计时没人提及的三件事
您的向量数据库可能在不知不觉中存储PHI。大多数团队认为去标识化解决了数据问题。确实如此——直到患者记录存储在向量数据库中。这些数字嵌入不会因为格式改变而失去其PHI状态。它们与源记录一样需要相同的加密要求、访问控制和六年保留义务。当患者请求删除时,大多数向量数据库缺乏在没有从一开始就构建的完整来源映射的情况下删除特定记录的能力。在需要之前构建该映射。
RAG系统提取的患者数据比必要多。最小必要标准是HIPAA中最被忽视的要求之一,RAG系统持续违反它。为后续预约安排AI没有理由拉取完整的患者病历,但当检索未在查询级别限定时,这正是发生的情况。应用层控制无法解决此问题。检索本身必须限制在任务实际需要的范围内。
影子AI已经存在于您的组织中。IBM的2025年数据泄露成本报告发现,63%经历过AI相关安全事件的组织没有治理政策。Doximity 2026报告发现,只有8%的医生表示其组织的AI政策足够清晰可以遵循。一名临床医生使用错误的ChatGPT层级与患者记录一起操作就是违规行为,而这种情况正在大规模发生,而组织确实相信他们符合规定。
合规是基础
医疗保健中的HIPAA合规AI不是是否构建的问题。而是如何正确构建的问题。成功的组织将是那些将合规、安全和数据治理视为起点而非最后一步的组织。
也有强有力的经济案例。根据微软-IDC研究,正确构建合规层的医疗组织在14个月内每投资1美元可获得3.20美元的回报。但只有当合规架构真正有效时,这些回报才会实现。
这不是让医疗AI更难构建。而是确保它真正实现其承诺:更好的患者结果、更强的机构信任,以及在最需要时能够支撑的系统。
在医疗保健中,构建最强大的模型不是目标。构建临床医生信任、患者信任和监管机构接受的模型才是,而没有从一开始就内置合规性,这些都不会发生。
常见问题解答
2026年什么使AI系统符合HIPAA规定?
与云供应商的BAA只是起点。每个实际接触患者数据的供应商都需要一个,而一旦您追踪PHI在您的技术栈中实际移动的位置,这个列表会变得更长。访问控制和审计日志需要满足HIPAA安全规则,而不仅仅是通过内部审查。训练数据必须在到达模型之前根据45 CFR §164.514进行去标识化,遗漏18个必需标识符中的一个,它仍然是PHI,无论其他部分看起来多么干净。保留六年日志。
团队很晚才发现的一件事:自2024年3月以来,任何在认证EHR内运行的AI临床决策支持必须展示其工作原理、训练数据来源、风险基础以及如何在不同患者群体中表现。ONC的HTI-1最终规则使其成为法律要求,而不是未来路线图项目。如果您的产品位于EHR内部且未处理此问题,则已经不符合规定。
Azure OpenAI有HIPAA BAA吗?
是的,它是行业中设置最清晰的之一。Microsoft通过数据保护附录将BAA直接捆绑到标准Azure许可中,因此如果您已经是Azure客户,您已经受到保护,无需单独合同,无需谈判。当您在HIPAA配置的帐户内运行时,Azure OpenAI服务属于该覆盖范围。
可以使用ChatGPT或Claude处理患者数据吗?
消费者版本绝不能使用。标准ChatGPT和Claude.ai不携带HIPAA BAA,这意味着使用它们处理患者数据不是一个灰色区域;这是一种违规行为。企业层级则不同:OpenAI Enterprise和Anthropic的Claude Enterprise都为企业客户提供BAA。层级在这里非常重要,因此在任何PHI接近AI系统之前确认这一点。
向量嵌入在HIPAA下是否被视为PHI?
是的,这让许多团队感到惊讶。当您为RAG系统或语义搜索从患者记录生成嵌入时,这些向量不会因为格式改变而失去其PHI状态。它们需要与源数据相同的加密、相同的访问控制和相同的六年保留期。另一个问题:大多数向量数据库不提供BAA,因此在存储患者嵌入之前检查您的供应商,并从第一天开始构建删除安全的来源映射,而不是在患者提交记录请求之后。
【全文结束】

