结论先说
如果你的医疗或生命科学团队已经在处理涉及 ePHI 的重复性浏览器工作，AWS 2026-05-21 的公告让 Amazon Nova Act 成为 HIPAA 范围工作负载中的可选方案。这不代表浏览器智能体会自动合规。它只表示：在组织具备必要 AWS 协议并正确配置工作负载时，这项服务可以用于相关场景。
第一版上线只把 Nova Act 用在范围窄、可重复的流程上，例如保险资格核验、理赔状态查询、转诊查询或门户数据录入。先从一个工作流、一个账号边界、一个复核队列和一套日志方案开始。如果任务需要开放式医疗判断、面向患者的建议，或跨多个系统的无人监督操作，不要从 Nova Act 开始。
截至 2026-05-22，最安全的上线顺序是：
- 确认 AWS Business Associate Addendum 和 HIPAA 账号设置
- playground 和 API key 原型只使用合成或去标识数据
- 选择一个有明确开始和停止条件的浏览器工作流
- 生产运行前落实最小权限 IAM、加密和审计日志
- 对异常、失败运行和敏感下游动作要求人工复核
- 在非生产或低风险队列中证明可靠性后再扩大范围
2026-05-21 发生了什么
2026-05-21，AWS 宣布 Amazon Nova Act is now HIPAA eligible，并且该服务已经出现在 AWS HIPAA Eligible Services Reference 中。对医疗团队来说，关键变化是：当账号受 AWS Business Associate Addendum (BAA) 覆盖，并且客户把工作负载配置到符合 HIPAA 要求时，Nova Act 可以用于 HIPAA 范围内的 AWS 工作负载。
实际边界比标题更窄。基于浏览器的 AI 智能体现在可以放进 HIPAA 范围的 AWS 架构中，但 AWS 的 Shared Responsibility Model 仍然把身份、数据处理、应用配置和运营控制留给客户负责。
Nova Act 实际做什么
AWS 文档把 Amazon Nova Act 定义为用于构建和管理浏览器自动化智能体集群的服务。它可以处理生产 UI 工作流，把自然语言任务和 Python 代码结合起来，在需要时升级给人工监督者，并集成 API 调用、remote MCP 和智能体框架。
当真正瓶颈还卡在网页门户或 UI 驱动系统里，而且没有干净的内部 API 时，才使用 Nova Act。
当工作流长这样时，可以考虑 Nova Act：
- 打开基于浏览器的门户
- 找到正确记录或任务
- 从一个系统读取字段
- 在另一个系统填写字段
- 提交或抓取状态
- 状态不清楚时停止或升级
不要因为任务里包含医疗数据就使用 Nova Act。只有当任务是人类已经在以相对可重复方式执行的浏览器工作流时，才考虑它。
HIPAA Eligibility 最有帮助的地方
AWS 官方公告点名了预约排期、保险核验、预授权、理赔状态查询、申诉、报销跟踪和转诊等医疗工作流。这些适合作为第一批候选项，因为它们通常重复、依赖 UI，而且完全人工处理成本高。
第一个试点的主要收益是减少交接和复制粘贴，尤其是在没有稳定 API 自动化的系统里。
优先把 Nova Act 用在同时满足这些条件的工作流上：
| 检查项 | 适合 Nova Act | 不适合 Nova Act |
|---|---|---|
| 工作流形态 | 步骤稳定的重复门户工作 | 开放式个案管理或医疗推理 |
| 输入质量 | 结构化字段或可预测的文档查询 | 经常需要判断的混乱记录 |
| 风险级别 | 延迟或返工可以通过复核恢复 | 一个错误动作就会造成患者、法律或账单风险 |
| 退出条件 | 有明确成功、失败或升级状态 | 无法可靠判断任务是否完成 |
| 监督 | 人工团队可以抽样和复核输出 | 没有人负责异常处理 |
如果团队无法把工作流描述成有边界的清单，Nova Act 很可能不是第一个应该上的智能体。
HIPAA Eligibility 没有改变什么
不要把 “HIPAA eligible” 翻译成 “默认安全” 或 “默认合规”。HIPAA Eligible Services Reference 明确说客户仍必须按照 HIPAA 要求配置服务。AWS 的 Shared Responsibility Model 也划清了同样边界：AWS 保护云基础设施，客户仍负责自己的数据处理、身份控制、应用配置和运营流程。
具体到 Nova Act，AWS 的公告并没有替你决定这些问题：
- 哪些账号和环境可以处理 ePHI
- 哪些身份可以启动、检查或修改工作流
- 智能体可以读取、存储或导出哪些数据
- 哪些动作必须先经过人工批准才能完成
- 日志、密钥和运行产物如何保留和保护
如果这些决定还没定下来，不要只因为服务已经 eligible，就从实验推进到生产。
构建第一个工作流前要确认什么
在任何真实患者相关工作负载接触 Nova Act 前，先确认这些前置条件。
| 要求 | 2026-05-22 要核验什么 | 为什么重要 |
|---|---|---|
| AWS 协议 | 组织已经签署 AWS BAA，并且相关账号已指定为 HIPAA 用途 | Nova Act eligibility 依赖 AWS 合规框架，而不只是功能本身 |
| 服务 eligibility | Amazon Nova Act 出现在 AWS HIPAA Eligible Services Reference 中 | 这是上线决策背后的 eligibility 触发点 |
| Region | Nova Act 文档列出 US East (N. Virginia) 支持 | Region 会影响架构，以及 ePHI 工作流可以在哪里运行 |
| 接口边界 | Nova Act setup 文档区分 web playground/API key 和 AWS IAM/已部署服务路径 | playground/API key 实验只用合成或去标识数据；真实 ePHI 只放进 BAA 覆盖的 AWS 账号路径 |
| 访问控制 | IAM 角色限制在最小操作员和服务集合 | 浏览器智能体如果权限过大，会很快触达敏感系统 |
| 数据轨迹 | 已审阅 Nova Act 加密文档中关于 Agent Trajectory、截图和响应数据的内容 | 提示、页面截图和智能体响应都可能成为复核产物 |
| 加密和日志 | 设计中记录 Nova Act 加密 与 CloudTrail 日志 的限制 | 你需要可复查性，不只是自动化；部分控制不由客户管理 |
| 异常路径 | 人工复核人员能检查不确定或失败运行 | 浏览器智能体应该升级，而不是在模糊状态下即兴处理 |
AWS 针对此次发布的 getting-started 指引要求在涉及 ePHI 的工作负载上线前，完成 BAA 流程、审阅 Nova Act 安全文档、规划 IAM、KMS、CloudTrail，并用 AWS Well-Architected Tool 做设计审查。对 Nova Act 来说，不要把快速 playground 测试当成 HIPAA 试点。Playground 和 API key 路径适合学习接口；涉及 ePHI 的运行应该进入你的 BAA 和安全团队批准过的 AWS 账号、身份和日志边界。
选择安全的第一个工作流
如果团队还没有自动化更简单的门户工作，不要从预授权提交开始。先选决策面最小的工作流。
第一个工作流要同时满足五个条件：
- 一个操作员团队已经按标准清单操作
- 只涉及一个或两个门户
- 运行开始前已知所有必需字段
- 最终结果是状态抓取、草稿准备或队列路由；不可逆交易不进入第一版运行
- 人工能在一分钟内复核结果
更适合第一版上线的例子：
- 保险资格核验
- 理赔状态收集
- 转诊状态查询
- 内部员工使用的预约空位查询
- 从 payer 门户抽取结构化状态数据到内部队列
第一版应避免的例子：
- 生成面向患者建议的任何流程
- 判断医疗必要性的工作流
- 未经复核就提交最终治疗或账单决策的动作
- 每个网站经常变化且没有 fallback 的多门户流程
一个真的能试点的最小 Nova Act 工作流
第一个医疗试点要缩小 Nova Act 表面：一个会话、一个门户、一个 act() 目标，以及四种输出状态。AWS 的 Nova Act 文档把工作流定义为会话内的 act() statements 加 Python 编排，所以第一版接近生产的工作流应该先做到可复核，再追求聪明。
你可以在网页 playground 或 IDE extension 中原型化工作流契约，但只能使用合成或去标识数据。任何真实 ePHI 出现在运行中之前，都要把工作流迁移到属于 HIPAA 范围账号和日志设计的 AWS IAM/已部署服务路径。
| 部分 | 第一次运行的最小契约 | 为什么这是合适底线 |
|---|---|---|
| 会话 | 一个指定操作员账号和一个 payer 或 provider 门户 | 限制影响范围，简化审计复核 |
| 输入载荷 | 内部队列 ID、门户名称、允许任务范围，以及最小批准搜索字段 | 把 ePHI 暴露控制在必需字段内 |
act() 指令 |
使用批准搜索字段，抓取状态字段，并在不匹配或未知页面状态时停止 | 告诉智能体什么是成功和失败，同时避免把标识符写进指令文本 |
| 输出状态 | success、needs_review、portal_changed、failed |
给复核人员一个小而稳定的验证契约 |
| 证据 | 运行 ID、时间戳和已抓取字段 | 让异常复核和 QA 可执行 |
初始 act() 指令可以窄到这样：
Open the assigned payer portal with the approved workflow account, use only the search fields supplied by the controlled workflow input, capture eligibility status, plan name, and effective date, and stop immediately if the returned record does not match the expected identifiers, MFA is requested outside the approved flow, or the page layout no longer matches the reviewed path.
把工作流结果当成契约，而不是聊天回复。示意输出可以小到这样：
{
"status": "needs_review",
"capturedFields": {
"eligibilityStatus": "active",
"planName": "example-plan",
"effectiveDate": "2026-05-01"
},
"exceptionReason": "manual_review_required",
"reviewRequired": true
}
如果你无法在构建前定义停止条件和输出 schema，这个工作流对第一个 HIPAA 范围试点来说还不够窄。
不能跳过的数据边界
Nova Act 的数据处理需要单独清单，因为浏览器智能体会产生 API 集成没有的产物。截至 2026-05-22，AWS 的 Nova Act 加密文档说明 Agent Trajectory 是临时数据，可能包含输入提示、访问页面截图和智能体响应。
在 HIPAA 范围运行前，先设置这些边界：
| 边界 | 第一版试点规则 | 要核对的来源 |
|---|---|---|
| Playground 和 API key 测试 | 只使用合成或去标识数据 | Getting started with Nova Act |
act() 和自由文本字段 |
不要把患者标识符、密钥或凭据写进自然语言指令 | Nova Act data protection |
| 截图和 trajectories | 把运行产物当成敏感复核记录；真实测试前定义保留策略和复核人员访问权限 | Nova Act encryption |
| CloudTrail | 显式启用 Nova Act data events；不要只依赖 Event history 做工作流步骤审计 | Logging Nova Act API calls |
| 加密和网络控制 | 围绕 AWS-owned KMS keys、无 customer-managed KMS keys、当前无 PrivateLink 支持来设计 | Nova Act encryption |
Nova Act 仍然可以用于 HIPAA 范围工作。第一版设计要先尽量减少提示、截图、产物和日志里出现的内容，再讨论模型可靠性。
实用的 Nova Act 上线模式
第一版接近生产的上线中，让智能体处理可重复的中间段，让人类负责批准和异常。
按这个方式建模第一版上线：
| 阶段 | 智能体做什么 | 人做什么 |
|---|---|---|
| 接收任务 | 接收只包含必需字段的预定义任务载荷 | 确认该工作流应该运行 |
| 执行 | 打开目标门户、导航、读取字段，并执行脚本化浏览器工作流 | 只在运行命中异常状态时介入 |
| 输出 | 返回 success、failed、needs_review 或已抓取状态等结构化结果 |
批准敏感下一步并纠正边界情况 |
| 审计 | 写入运行元数据和结果日志 | 抽样运行、复核异常并更新控制项 |
在医疗场景中，更大的失败模式是静默漂移：错误患者上下文、过期门户假设或不完整审计证据。
处理 ePHI 的浏览器智能体防护栏
如果工作流可能接触 ePHI，第一版设计要保守。
第一版保留这些防护栏：
- 使用专用 HIPAA 范围 AWS 账号或环境边界
- 将工作流限制在指定门户和指定任务类型
- 只传入运行必需的最少字段
- 尽可能避免把患者标识符写入
act()文本和其他自由文本指令 - 页面状态陌生时要求明确停止条件
- 阻止向未批准目的地自由导出数据
- 记录工作流启动、批准、异常和最终结果
- 通过标准 AWS 控制项轮换凭据和密钥，不要嵌进工作流代码
Nova Act 的吸引力在于它可以在同一工作流中结合自然语言和 Python。这种灵活性有用，但也意味着团队要检查工作流哪里是确定性执行，哪里在让模型即兴处理。在 HIPAA 范围工作中，尽量缩小即兴空间。
Nova Act 什么时候优于传统 RPA
只有在一个窄场景里，才优先选择 Nova Act 而不是传统 RPA 工具：UI 自动化经常因为脆弱选择器而失效，但任务仍足够结构化，人类可以定义明确目标和升级规则。
这些情况下，比起传统脚本自动化，更适合 Nova Act：
- 门户布局经常变化，脆弱选择器维护成本高
- 员工依赖可见 UI 上下文，而不是 API
- 工作流需要轻量解释，而不是深度领域判断
- 可以定义明确成功、失败和升级状态
这些情况下，更适合传统集成或规则引擎：
- 系统已经有稳定 API
- 任务确定性强，不需要 LLM 也容易建模
- 合规政策要求尽可能小的模型足迹
- 浏览器执行成本相对简单 API 调用不划算
截至 2026-05-22，Amazon Nova pricing page 把 Nova Act 工作流运行时间列为 agent-hour 计费，并说明等待人工输入的时间不计费。把它只当作预算输入，不要把它当作自动化高风险工作流的理由。如果稳定 API 能以更低成本和更少产物完成任务，先用 API。
Amazon Connect Health 可能更适合的情况
Nova Act 是浏览器智能体选项。如果真实目标是更大的医疗联络中心、EHR 连接或患者访问工作流，在把浏览器自动化塞进设计前，先和 Amazon Connect Health 对比。
第一次架构评审可以按这个拆分：
| 需求 | 先看什么 |
|---|---|
| 自动化没有稳定 API 的现有 payer 或 provider 门户 | Nova Act |
| 构建更广的患者访问、排期、联络中心或 EHR 连接工作流 | Amazon Connect Health |
| 在已有 approved APIs 的系统之间移动数据 | API 集成或规则引擎 |
| 运行几乎不需要语言解释的固定 UI 步骤 | 传统 RPA 或确定性浏览器自动化 |
这些红旗出现就暂停
测试中出现这些情况就暂停上线：
- 操作员无法就精确工作流边界达成一致
- 同一任务经常需要未写下来的判断
- 不同门户要求对同一字段做不同解释
- 团队没有异常队列负责人
- 日志不完整，或无法快速复核
- 唯一成功指标是 “demo 看起来还行”
这些首先是流程问题。Nova Act 会放大它们，而不是解决它们。
14 天试点计划
前两周保持范围窄。
第 1-3 天：合规与范围
- 确认 BAA 和 HIPAA 账号设置
- 确认 Nova Act region fit 和环境边界
- 选择一个有书面清单和升级路径的工作流
- 定义试点永远不会做什么
第 4-7 天：工作流构建与干跑
- 用测试或低风险数据实现浏览器工作流
- 定义
success、failed、needs_review、portal_changed等结构化输出 - 在批量测试前加入日志和复核人员访问权限
- 记录每个异常，不要悄悄绕过
第 8-11 天：人工监督试运行
- 在低风险任务上跑小批量
- 对比周期耗时、失败原因、复核人员投入和人工流程
- 复核失败来自门户变化、缺失输入，还是工作流边界薄弱
第 12-14 天：上线或暂停决策
- 只有工作流保持有边界且可复核时才扩大范围
- 如果流程仍依赖未文档化判断，就停止
- 如果最佳结果是部分自动化加人工完成，就重新设计
扩大前使用硬性门槛：
| 门槛 | 最低通过条件 |
|---|---|
| 错误患者或错误记录动作 | 0 incidents |
| 未复核最终提交 | 0 incidents |
| 审计证据 | 100% sampled runs 包含运行 ID、时间戳、门户、输出状态和复核状态 |
| 异常处理 | 100% 的 needs_review、portal_changed、failed runs 在下游动作前都有负责人 |
| 运行对账 | 队列数量等于 success + needs_review + portal_changed + failed；没有隐藏的 unknown bucket |
| 复核人员投入 | 范围扩大前，已把复核人员耗时和返工与人工基线对比 |
如果提交仍依赖人工判断，第一版生产发布就停在数据检索或状态抓取。
FAQ
Amazon Nova Act 现在会自动符合 HIPAA 吗？
不会。截至 2026-05-22，AWS 说 Nova Act 是 HIPAA eligible，意思是它可以在 AWS 合规框架下用于 HIPAA 范围工作负载。你的组织仍需要正确配置账号、访问控制、日志、加密和运营流程。
医疗团队第一个 Nova Act 工作流应该选什么？
从已经有稳定清单且失败可以恢复的重复浏览器工作流开始，例如保险核验、理赔状态查询或转诊状态查询。第一版避免开放式临床或财务决策工作流。
Nova Act 应该替代受监管工作流中的人工操作员吗？
不应该。更安全的模式是监督式自动化。让智能体处理重复浏览器工作，让人类负责批准、异常和政策敏感决策。
什么时候不应该用 Nova Act？
如果任务已经有稳定 API，如果一个错误动作会造成不可接受的法律或患者风险，或者团队还无法定义清晰停止条件和异常队列，不要从 Nova Act 开始。
可以在 Nova Act playground 里测试真实患者数据吗？
第一版医疗上线不可以。Playground 和 API key 路径只使用合成或去标识数据。真实 ePHI 只在 IAM、日志、数据保留和复核人员控制获批后，放入 BAA 覆盖的 AWS 账号路径。
核验说明
官方来源核验于 2026-05-22：
- AWS Machine Learning Blog: Amazon Nova Act is now HIPAA eligible
- AWS Docs: What is Amazon Nova Act?
- AWS Docs: Getting started with Amazon Nova Act
- AWS Docs: Data protection in Amazon Nova Act
- AWS Docs: Encryption at rest in Amazon Nova Act
- AWS Docs: Logging Amazon Nova Act API calls with AWS CloudTrail
- AWS Compliance: HIPAA Eligible Services Reference
- AWS Compliance: Shared Responsibility Model
- AWS Pricing: Amazon Nova pricing
- AWS: Amazon Connect Health