HIPAA、SOC2 与你的智能体：合规性对架构产生的实际约束

典型的 AI 团队在面对合规性时的经历通常是这样的：智能体（Agent）已经上线，用户非常喜欢，然后法务部门转来一封邮件，询问系统是否符合 HIPAA 标准。被指派回答这个问题的工程师发现，上下文窗口（context windows）包含 PHI，没有足够粒度的审计日志，LLM 提供商没有签署商业伙伴协议（BAA），而且智能体的工具权限超出了最低必要标准所允许的范围。修复工作需要三个月，并且需要重写部分代码。

这种模式并非特例。根据 2024 年的一项行业调查，78% 的企业高管无法在 90 天内通过 AI 治理审计，而 2025 年有 42% 的公司放弃 AI 项目主要是由于合规性和治理失败——而非技术原因。所构建的内容与合规性实际要求之间的差距是架构层面的，并且在第一轮迭代（sprint 1）中就已经形成。

合规性究竟在关注什么

HIPAA 的安全规则（Security Rule）和 SOC2 信托服务标准（Trust Services Criteria）都适用于访问、处理或传输受保护健康信息（PHI）的 AI 系统——包括上下文窗口中的瞬时信息。“模型从未存储数据”并不是辩解的理由。如果 PHI 在推理过程中出现在上下文中，该系统就在监管范围内。

2025 年 1 月的 HIPAA 安全规则制定建议通知（NPRM）——这是 20 年来的首次重大更新，计划于 2026 年年中定稿——明确规定了这一点。创建、接收、维护或传输 ePHI 的 AI 软件必须作为技术资产列入清单，纳入组织的年度风险分析，并接受强制性的合规审计。拟议的规则还消除了“要求项”和“可选项”安全保障之间的区别，将大多数以前可选的控制措施转变为强制性要求。

SOC2 Type II 审计评估的是 6 到 12 个月观察窗口内的运营有效性，而不仅仅是某个时间点的情况。这意味着控制措施需要在整个审计期间到位并正常运行——你无法追溯性地为智能体安装工具来产生证据。如果你从第一个月起就没有日志，再多的补救也无法满足 Type II 评审员的要求。

团队在第一次审计前常犯的六个错误

上下文窗口在任务结束后仍保留 PHI

智能体在推理过程中处理患者记录。推理追踪（reasoning trace）——包括精确的字段值、药物清单、诊断代码——被持久化在没有 TTL（生存时间）设置的向量数据库中。当下一个用户提交请求时，智能体可能会将该追踪作为相关上下文提取出来。

HIPAA 的最低必要标准 (45 CFR 164.502(b)) 要求，对 PHI 的访问必须限制在每次特定用途所必需的范围内。为了获得更好的回复而优化为提取广泛上下文的智能体，在结构上与此要求存在冲突。最低必要标准适用于操作层面：完成一项任务并不意味着授权继续保留用于完成该任务的数据。

工具权限是系统级的，而非操作级的

一个智能体被授予了“对患者数据库的读取权限”。在实践中，这意味着它可以读取数据库中的任何患者记录。权限决策是在集成层做出的，而不是在操作层。

2024 年美国卫生与公众服务部民权办公室（OCR）的一次执法行动导致了针对一家涵盖实体的 119 万美元和解，原因正是非 AI 系统中的这种模式：一个被配置为读取文件夹的账户自动继承了下载文件、触发批量操作和移动记录的权限。当这种设计出现在 AI 智能体中时——模型可以请求任何它认为相关的记录——违规范围会随着每一次推理而扩大。

缺乏智能体决策的审计追踪

一个计费智能体根据自动策略评估拒绝了一项保险索赔。但没有关于智能体访问了哪些记录、应用了哪个版本的策略、决策输入是什么，或者谁授权智能体做出该调用的日志。“智能体在下午 2:30 运行”记录在应用日志中，而其他所有信息都缺失了。

HIPAA 的审计控制标准 (45 CFR 164.312(b)) 要求在操作层面检查包含 PHI 的系统上的所有活动。SOC2 的处理完整性（Processing Integrity）准则要求提供 AI 输出正确且受控的证据。审计员会要求提供显示 AI 智能体做出的所有影响客户的决策的日志。如果日志不存在，该发现将是关键性的，而不仅仅是信息性的。

瞬时内存和持久内存使用相同的存储

会话智能体的工作内存——当前任务状态、提取的上下文片段、中间推理过程——被写入与长期用户偏好相同的持久数据库中。每个会话的所有内容都会无限期累积。

当患者根据 HIPAA 的访问权条款提交删除请求，或者当 SOC2 审计员询问敏感数据如何保留和删除时，没有明确的答案。瞬时数据本不应该持久化，但没有技术手段上的隔离来强制执行这一初衷。

访问管理中的职责分离违规

一个具有管理权限范围的智能体在分析了助理的功能需求后，为一名新助理授予了数据仓库的访问权限。整个过程中没有人工批准该权限变更。该智能体自主做出了访问管理决策。

职责分离是 SOC2 安全准则下的核心控制点。AI 智能体的自主访问管理——无论其决策逻辑多么合理——都会被自动判定为审计发现项。审计人员关注的问题不是“决策是否正确”，而是“谁授权了该决策？”

缺乏超范围查询检测

一个面向患者的智能体被授权处理账单问题。一名用户请求它检索完整的精神病史以用于研究目的。由于底层模型拥有数据库凭据和宽泛的系统提示词，智能体执行了该操作。

在 HIPAA 协议下，受保护健康信息（PHI）的每一次使用都需要与覆盖实体的许可用途相关的独立正当理由。“用户发出了请求且智能体有能力执行”并不属于许可用途。智能体必须能够检测请求何时超出了其授权范围，并进行升级处理，而不是直接执行。

满足实际审计需求的架构模式

明确区分瞬时内存与持久化内存

最基本的合规模式是在工作内存（working memory）和持久化存储之间建立严格的边界。瞬时内存保存当前任务的上下文：检索到的文档、中间推理过程、工具调用结果。它永远不会被写入永久存储，并在任务结束时失效。

持久化内存保存经过明确治理后提升（promoted）的事实：用户偏好、长期状态、历史决策。这种提升是一种操作，而不是推理过程中的自动产物。

像 LangChain 和 Semantic Kernel 这样的框架都支持多种内存后端。使用一个后端处理工作上下文，另一个独立的、受治理的后端处理持久化事实——并配合 TTL（生存时间）和删除工作流——可以满足 HIPAA 的“最少必要标准”，因为执行一项任务所需的 PHI 不会持久存在并被下一项任务访问。

具有元数据驱动调度的操作级工具权限

与其给智能体一套宽泛的工具并信任模型会恰当地使用它们，不如在注册表中定义工具权限，明确其范围、只读标志和审批要求：

read_patient_summary:
  scope: current_patient
  fields: [name, dob, current_medications]
  readonly: true
  requires_approval: false

download_full_chart:
  scope: current_patient
  fields: ["*"]
  readonly: true
  requires_approval: true
  approval_timeout: 300

schedule_appointment:
  scope: current_patient
  fields: [calendar, appointment_history]
  readonly: false
  requires_approval: false

加载中…