使用 Amazon Bedrock Data Automation 构建无服务器 PII 脱敏流水线

每天处理数千份扫描文档（包括医疗表格、保险理赔和财务记录）的组织面临一个反复出现的合规需求：在文档与第三方共享或进入下游处理之前，必须对个人身份信息（PII）进行脱敏。

手动脱敏无法规模化：它消耗人力、引入人为错误，并带来合规风险。脱敏不仅是一个检测问题，更是一个精确性问题。单页文档可能包含多个姓名、日期和地址，但其中只有部分信息对当前用例敏感。传统脱敏方案将光学字符识别（OCR）与模式匹配或自定义机器学习（ML）模型相结合。然而，当文本质量下降时这些方法存在局限性，难以表达字段级业务逻辑，且在文档格式变化时需要 ML 专业知识来构建和重新训练自定义模型。

在本文中，我们演示如何在 AWS 上大规模自动化实现端到端的 PII 检测和脱敏。我们为 PII 脱敏设计了一个自定义蓝图，并展示了使用 Amazon Bedrock Data Automation（BDA）、AWS Step Functions 和 AWS Lambda 进行批量处理的无服务器批处理架构。流程如图 1 所示。

图 1：端到端无服务器 PII 脱敏工作流

生成式 AI 文档理解有助于打破传统脱敏的制约。基础模型可以从整体上解读文档页面，包括其布局、字段标签和上下文，并可以使用自然语言指令区分字段所属的信息主体，而无需训练实体模型。Amazon Bedrock Data Automation 是 Amazon Bedrock 的一项服务，能够从非结构化文档、图片、音频和视频中智能提取结构化信息。

利用 BDA 的自定义蓝图功能，你可以使用自然语言指令声明用于精确提取的命名文档字段。通过 BDA，你可以获得目标字段内容、置信度分数以及每个实例的边界框坐标，用于下游后处理。通过为批量 PII 脱敏用例定制自定义蓝图，你可以将 BDA 用作规模化脱敏的定制 PII 检测引擎。

要了解更多关于 Amazon Bedrock Data Automation 蓝图和自定义输出模式的信息，请参阅 Amazon Bedrock Data Automation 文档。有关在生成式 AI 应用中更广泛地管理 PII 的指导，请参阅生成式 AI 安全范围矩阵。

该解决方案包含两部分：一个定义脱敏内容的自定义 BDA 蓝图，以及一个在批处理规模上应用它的无服务器流水线（使用我们在本文中概述的最佳实践）。同一无服务器流水线可以使用独特的蓝图满足多种用例。

设计 PII 脱敏蓝图

为文档处理用例设计自定义脱敏蓝图需要四个范围界定问题：什么是敏感信息、什么不是敏感信息、它在哪里、以及如何移除它？在本文中，我们通过在下游理赔处理之前对主治医师声明执行 PII 脱敏的用例来演示这一过程。

从用例的上下文出发，我们在表 1 中建立了脱敏需求。

表 1：自定义脱敏蓝图的需求

利用捕获的需求，通过 AWS 管理控制台、AWS 命令行界面（AWS CLI）或开发者 SDK 创建 BDA 蓝图，指定目标蓝图模式。控制台提供了基于示例文档生成蓝图模式的演练选项。最终模式必须枚举符合脱敏条件的字段、其数据类型、简要自然语言描述以及适用的转换（例如，如果使用推断推理类型，则为日期格式）。显式推理类型提供无需预期转换的提取。

例如，以患者出生日期字段为例。它是一个日期类型字段，但并非文档中所有日期都需要脱敏，例如预约日期和签名日期。蓝图指令告诉 BDA 要提取哪些日期子类型，只关注目标字段。

该指令将字段范围限定为患者，使 BDA 能够将出生日期与预约日期和签名日期区分开来，即使同一页面上出现不同格式的日期。相同的设计过程将主治医师的打印姓名和签名排除在脱敏集之外。图 2 显示了使用此 PII 脱敏流水线前后脱敏效果的对比示例。图 3 显示了控制台上呈现的蓝图。

图 2：手写主治医师声明脱敏前后对比

图 3：Amazon Bedrock Data Automation 控制台提取视图，展开了 EmergencyContact、FamilyMembers、GovernmentIDs 和 InsuranceIdentifiers 字段组

以下摘录显示了蓝图模式中的一个代表性字段组。主治医师声明 PII 脱敏的完整蓝图模式定义了 9 个字段组共 37 个字段。字段组是一种结构，用于将相关结果组织到提取结果中的单一位置。

{
  "PatientIdentity": {
    "type": "object",
    "properties": {
      "patient_first_name": {
        "type": "string",
        "inferenceType": "explicit",
        "instruction": "The patient's given or first name."
      },
      "patient_last_name": {
        "type": "string",
        "inferenceType": "explicit",
        "instruction": "The patient's surname or family name. Look carefully in all sections including signature areas."
      },
      "patient_date_of_birth": {
        "type": "string",
        "inferenceType": "explicit",
        "instruction": "The patient's date of birth in any format (dd-mm-yyyy, mm/dd/yyyy, etc.)."
      },
      "patient_mrn": {
        "type": "string",
        "inferenceType": "explicit",
        "instruction": "The patient's Medical Record Number (MRN)."
      }
    }
  }
}

每个字段使用 inferenceType: "explicit" 进行无需转换的提取，并使用自然语言指令来限定检测范围。字段组是一种将相关结果组织到提取结果中单一位置的结构。

我们建议为每个文档处理用例的脱敏需求设计自定义 BDA 蓝图。用例蓝图定制依赖于连续的实验结果，进一步的自动化实验是未来工作的主题。

在最终部署中，所需蓝图的 Amazon Resource Name（ARN）用作输入参数，允许同一批处理流水线基础设施被编排和部署，以扩展多个脱敏用例。在流水线中，我们每次 API 调用向 BDA 发送一个文档页面，以将生成式 AI 请求范围聚焦到一页上下文。

在单个请求中，BDA 处理完整文档页面来解读布局、字段标签和上下文，不依赖字符级 OCR。由此，BDA 可以定位 OCR 引擎可能难以转录的手写患者姓名，并能更有效地处理输入文档质量较差的边缘情况。

评估蓝图

设计蓝图后，通过针对人工脱敏真实文档计算脱敏 PII 实例的精确率和召回率来评估其脱敏性能。我们在用例中测试了跨越六个文档质量级别的文档样本，从清晰的打印表单到低分辨率 100 DPI 扫描件（表 2）。

表 2：文档质量测试级别

在样本测试用例上的初步测试表明，蓝图在我们的 12 份文档（47 页）样本集中至少识别了每个 PII 实例一次，但偶尔会遗漏叙事文本和手写医师记录中的重复实例。为了在不影响精确率的情况下提高召回率，我们引入了使用 BDA 标准输出的第二次检测通过，并通过图 4 所示的后处理令牌匹配步骤合并结果。

通过单次 API 调用，BDA 返回两个输出：

• 自定义输出：来自蓝图的带有边界框的 PII 字段
• 标准输出：完整提取，包括每个单词的边界框

response = self._runtime.invoke_data_automation_async(
    inputConfiguration={"s3Uri": input_s3_uri},
    outputConfiguration={"s3Uri": output_s3_uri},
    dataAutomationProfileArn=profile_arn,
    dataAutomationConfiguration={
        "dataAutomationProjectArn": project_arn,
        "stage": stage,
    },
)

Token 匹配将每个检测到的 PII 值规范化为词级 Token，然后扫描页面词级标准输出中规范化形式与 PII Token 匹配的文字。新匹配的非重叠项被添加到最终坐标集中进行涂抹。通过这种方式，无论 PII 在页面上何处再次出现——包括自由文本段落和手写内容——都能被捕获。

图 4：质量检查流程。单个 BDA API 调用产生自定义输出和标准输出，馈送给匹配器生成最终 PII 字段集

由于两次处理都依赖同一次 API 调用，质量检查在不需要第二次调用延迟的情况下增加了覆盖率。我们评估了一组包含六个质量等级的 12 份文档（47 页），将流水线输出与人工涂抹的真实基准进行了对比。结果如表 3 所示。

图 5：患者姓名在标注字段和叙述文本中均被涂抹的文档页面

表 3：该用例中针对人工涂抹真实基准的涂抹质量评估

将 BDA 标准输出调用引入作为质量检查步骤，使涂抹召回率从 89.3% 提升至 95.2%。在图 5 中，蓝图处理涂抹了包含患者姓名的标注表单字段（图中红色部分）。标准输出 Token 匹配则捕获了该姓名在页面下方叙述段落中再次出现的位置（图中蓝色部分）。将蓝图性能与 BDA 置信度分数结合评估，可以帮助您根据用例将边缘案例路由至人工审核。

流水线架构

这里我们演示如何构建一个无服务器流水线，以批量文档处理的方式推广经过验证的 PII 涂抹蓝图。出席医师声明涂抹的生产文档量每晚可达约 25,000 页。在保持成本效率的同时最大化涂抹工作负载并发是一个重要的设计考量。

该流水线作为五个 AWS Lambda 函数的无服务器工作流运行，由 AWS Step Functions 状态机编排。多个 AWS Step Functions 分布式 Map 状态在页面级别并发发散 BDA API 调用。文档 PDF 通过 Amazon Simple Storage Service（Amazon S3）前缀输入。如果节流失败影响您的工作流，可以使用原生 Step Functions 重驱动（redrive）功能继续处理。

图 6 概述了生产流水线架构。

图 6：无服务器 PII 涂抹流水线架构

架构图展示了一个 AWS Step Functions 状态机编排五个顺序执行的 Lambda 函数：Initialize、Preprocessing、Redaction、Reassembly 和 Reporting。两层嵌套的分布式 Map 处理并行：外层 Map 迭代文档，内层 Map 迭代每个文档内的页面。Amazon S3 提供输入和输出存储，Amazon Bedrock Data Automation 处理每个页面图像进行 PII 检测。

Step Function 有三个输入：

包含一组未涂抹 PDF 输入的 S3 输入前缀。

配置结果写入位置的 S3 输出前缀。

蓝图 ARN，即为该涂抹用例开发的经验证 BDA 蓝图 ID。

涂抹工作流包括以下步骤：

Initialize – 验证输入、解析蓝图、从 Amazon S3 列出源文档，并为文档级分布式 Map 写入清单。

Preprocess – 将每个 PDF 转换为逐页 PNG 图像。图像文档作为单页 PNG 直接传递。

Detect and redact – 将每个页面图像发送至 Amazon Bedrock Data Automation 进行 PII 检测，然后在每个检测到的区域坐标上应用黑色方框。

Reassemble – 将涂抹后的页面图像合并为每个文档的单个涂抹 PDF，并构建文档级元数据。

Report – 聚合文档摘要为作业级报告，并运行对账检查。

Step Functions 运行两层嵌套的分布式 Map：外层 Map 迭代文档，内层 Map 迭代每个文档内的页面。您的文档级和页面级并发设置必须适合您的账户级服务配额（InvokeDataAutomationAsync）。根据您的工作负载特性优化并发，并请求适合您用例的配额增加。

Preprocessing Lambda 函数将每个输入文档转换为逐页 PNG 图像。它从 Amazon S3 下载文档、检测文件类型、将每个 PDF 页面渲染为 PNG，然后写回 S3。

Redaction Lambda 函数对每个页面执行四项操作：调用 BDA、解析结果、涂抹图像、上传至 S3。

BDA 返回每个检测到的字段及其值、置信度分数和归一化坐标的边界框（left、top、width、height 为 0 到 1 之间的分数）。该函数将这些转换为像素坐标，稍微扩展每个框以考虑方差，然后在区域上绘制填充的黑色矩形（图 7）。涂抹会覆盖图像本身的像素数据，因此被覆盖的内容不会出现在输出文件中。这与基于注释的方法不同——在后者的情况下，原始文本仍可在覆盖层下恢复。

图 7：涂抹前后的医师声明

该流水线采用分层方式进行故障恢复。第一层使用原生 Step Functions 指数退避重试和抖动处理节流峰值。第二层在允许成功同伴继续处理的同时，呈现损坏输入文档的错误。如果中断持续，运维人员可以使用 Step Functions 重驱动功能，而无需重新处理已完成的工作。

应用两种隔离策略：

文档级故障（即 PDF 损坏或重组装错误）。流水线将故障记录在作业报告中，而其他文档继续处理。输出包含成功执行的涂抹 PDF 以及逐项故障记录。

页面级故障（即持续节流耗尽重试）。恢复使用 Step Functions 内置重驱动。运维人员可以看到哪些页面在选择恢复之前失败了。

最终的作业报告聚合了按文档的明细、时序数据和对账摘要。当 fully_reconciled 为 true 时，每份提交的文档都产生了涂抹 PDF。如果所有文档都失败，则执行以专门的 PipelineNoOutput 故障结束。

{
  "documents_submitted": 12,
  "documents_output": 12,
  "documents_failed": 0,
  "fully_reconciled": true,
  "total_pages": 47,
  "total_pii_fields": 331,
  "total_pii_blueprint_count": 294,
  "total_pii_match_count": 37,
  "average_confidence": 0.8079,
  "pipeline_duration_seconds": 290.7
}

该流水线构建于其使用的 AWS 服务的安全控制之上：

IAM 范围访问：每个 Lambda 函数都有专用的最低特权 AWS Identity and Access Management（IAM）角色，范围限定在流水线 bucket 及其所需的操作上。

静态和传输中加密：Amazon S3 默认加密使用 AES-256 帮助保护每个文档和 Lambda 构件。流水线通过 Transport Layer Security（TLS）连接到 Amazon S3、AWS Step Functions 和 Amazon Bedrock。

私有网络：Lambda 函数支持通过基础设施即代码变量进行虚拟私有云（VPC）部署。启用后，流向这些服务的流量通过 VPC 端点离开公共互联网。

可审计性：AWS CloudTrail 记录整个流水线的 API 活动，您可以用它来支持合规审查。

选择正确的 PII 涂抹方案

这种 BDA 蓝图方法非常适合文档已退化或格式混合的场景、需要字段级业务逻辑的场景（例如，涂抹患者姓名但不涂抹医师姓名），或需要像素级边界框坐标进行图像涂抹的场景。

在这篇文章中，我们展示了如何使用 Amazon Bedrock Data Automation、AWS Step Functions 和 AWS Lambda 设计并构建一个无服务器流水线，从扫描文档中检测和涂抹 PII。通过自定义 BDA 蓝图，您可以使用自然语言指令声明要涂抹的特定字段（如患者姓名），而不会过度涂抹医师姓名或临床内容。

在我们针对人工涂抹真实基准的评估中，蓝图涂抹达到了 97.0% 的精确率，将 BDA 标准输出作为 Token 匹配质量检查使召回率从 89.3% 提升至 95.2%，覆盖数字 PDF、手写表单和低分辨率传真，仅需一次 API 调用。

将您的 BDA 蓝图视为配置。您可以通过更改蓝图架构和 S3 输入前缀，将同一生产流水线指向新的文档类型，使部署成为可复用的模式，以帮助跨医疗记录、金融开户表单、政府申请或其他文档密集型、PII 敏感型工作负载进行批量 PII 涂抹。

我们鼓励你在 Amazon Bedrock Data Automation 控制台中构建你的第一个蓝图，并从今天开始实现 PII 自动脱敏。入门请参阅 Amazon Bedrock Data Automation 文档中的创建蓝图部分，以及进一步了解使用 BDA 进行智能文档处理，以及 BDA 如何与 Bedrock Guardrails 交互。