Huntington Bank: 使用 AWS 从超 4 亿份文档中编辑敏感数据 | 人工智能
Huntington Bank: 使用 AWS 从超 4 亿份文档中编辑敏感数据 | 人工智能
作者：Rob Carnell、Bobby Lumpkin、Angus Ferguson、Randy Patrick、Ryan Doty、Timothy Gorman 和 Xuelei Yuan
发布日期：2026年6月24日
当你的文档库包含近十年积累的数亿份文件时，如何在不花费数年时间的情况下，系统地查找并编辑敏感客户数据？这正是美国十大银行之一 The Huntington National Bank（Huntington）所面临的挑战。
大规模编辑敏感信息
自 2015 年以来，Huntington 的文档管理系统已在本地安全存储了数亿份文档。2025 年，作为一项主动合规计划的一部分，Huntington 着手处理该系统内的文档并编辑敏感数据。这些文档格式各异，因此解决方案需要具备灵活处理各种文件类型的能力，同时还要提供快速处理数百万份文档所需的吞吐量。
最初的估算显示，这项工作需要数年时间。然而，通过使用 Amazon Textract、Amazon SageMaker、AWS Step Functions 和 AWS Lambda 设计可扩展的编辑工作流，Huntington 将这一时间缩短至数月。
解决方案概述
在详细了解技术实现之前，我们先看一下 Huntington 为此项目确立的核心需求。如果你也面临类似的大规模文档处理挑战，这些需求可以作为你自己解决方案设计的起点：
- 数据在静态和传输过程中必须加密。
- 数据存储或访问的位置必须符合严格的访问要求。
- 所使用的服务必须 属于 PCI DSS 合规范围。
- 输出结果必须复制回本地数据存储。
- 编辑准确率必须达到或超过 95%，以满足合规要求。
下图展示了高级解决方案架构。
安全、可靠地迁移数据
Huntington 的首要目标是将文档从本地文件共享迁移到 Amazon Simple Storage Service（Amazon S3）存储桶。迁移文档本身并不复杂，但这项工作需要传输超过 4 亿份文档，并且要在传输中和静态时进行加密。为此，Huntington 使用了 AWS DataSync、AWS Direct Connect、Amazon S3 和 AWS Key Management Service（AWS KMS）。
AWS DataSync 可以作为代理部署在本地数据中心，用于监控已配置的源（例如 SMB 文件共享）。虽然将文档传输到 AWS 是处理的关键，但 AWS DataSync 还支持将数据同步回本地，这也是该项目另一个关键需求。
使用 Amazon Textract 检测敏感数据
Amazon Textract 是一项 AWS 机器学习服务，可从扫描文档中提取文本、表格和表单。金融机构使用它来自动处理银行对账单或贷款申请等文档，然后识别敏感数据，例如社会安全号码、账号和个人地址。下面的示例发票演示了这一功能。
Amazon Textract 从文档中检测各种字段，并在 JSON 输出中提供检测到的字段的坐标及其他元数据。
Huntington 将 Amazon Textract 与 AWS Step Functions 结合在编排流程中使用。这种方法减少了人工审查时间，同时提高了在大量文档中检测敏感信息的准确性。
扩展检测吞吐量
用于文档处理的自动化管道很有价值，但按顺序处理文档会使项目时间延长至数年。为了实现目标，Huntington 需要每天处理数百万份文档。
扩展到这一级别需要解决两个主要问题：在服务配额内最大化并发 Amazon Textract 作业的数量，以及控制请求速率以避免限流。
AWS 服务有配额，可以通过软限制和硬限制进行调整。Amazon Textract 的每秒作业数配额可通过 AWS Service Quotas 控制台提交请求来增加。
为了在服务配额内最大化吞吐量，Huntington 使用了 AWS Step Functions 内置的映射状态，该状态可处理 JSON、CSV 或其他格式的输入集合。团队将 Amazon S3 中的文档组织成 JSON 集合，并以分布式模式运行映射状态，以获得更高的并发性。为了跟踪管道进度，他们使用了 AWS Step Functions 映射运行执行摘要以及 Amazon CloudWatch 仪表板来监控响应时间、节流次数、成功率和错误率。
为解决潜在的节流问题，Huntington 监控其 CloudWatch 仪表板，以验证 Amazon Textract 的成功请求计数和节流计数。根据需要，他们调整子工作流执行的并发限制，确保保持在 Amazon Textract 服务配额之下，同时维持高吞吐量。当作业成功完成时，检测到的字段和元数据会被写入一个存储桶以供后续审查。下图展示了这一方法：
Step Function 中的等待块验证进程已准备就绪，可以继续写入作业元数据并继续下一次 Amazon Textract 调用。当没有失败时，状态机以通过状态结束。当发生失败时，AWS Step Functions 会写入日志供人工审查和重新处理。
编辑检测到的敏感信息
到目前为止，流程的重点是检测敏感数据并将其编目到写入 Amazon S3 的元数据文件中。最后一步是编辑文档并将其传输回本地存储。
有多个开源和专有工具支持图像和 PDF 编辑。常见的开源 Python 库包括 PyMuPDF 或像 PIL 这样的图像绘制库。下图显示了前面展示的发票的示例编辑效果。Amazon Textract 支持检测各种字段，您还可以使用正则表达式创建自定义分类。结合编辑软件，您可以自信地编辑检测到的字段。如果您想设置人工干预的阈值，Amazon Textract 提供的置信度分数可以触发验证工作流。
再次，Huntington 面临相同的架构挑战：如何实现规模化？AWS Step Functions 提供了处理数百万文档的解决方案，同时提供了错误处理和重试逻辑的钩子。随着文档处理管道编目需要编辑的对象，Huntington 对其运行了一个简单的流程：
为了验证准确性和完整性，在编辑前，Huntington 双重检查检测到的字段是否与预期模式匹配，随后为每个文件更新元数据。编辑后的文件被放置在一个由 AWS DataSync 监控的 Amazon S3 位置，以便传输回本地文件存储。
结论
通过使用 AWS，Huntington 每天处理约 1000 万份文档，将预计处理时间从数年缩短至仅几个月。处理整个文档库的成本约为原始估算的 5%。编辑准确率超过 95%，满足合规要求并支持数据安全目标。
该项目展示了 AWS 服务如何支持大规模数据处理和合规计划。Huntington 计划继续使用此框架处理高量编辑需求，例如并购。
要了解更多关于此解决方案中使用的服务，请访问 Amazon Textract 详情页面或探索 AWS Step Functions 文档。
致谢
特别感谢以下个人和团队所做的贡献：Xuelei Yuan、Robert Carnell、Jeanne Keith、Debbie Montgomery、Bill Gross、Jodi Pettiford、Jon Glazer、Marshall Doss、Bob Wojasinski、Tami Wolf、Marijane Eldridge、Pradeep Kumar Tata、Michael Burkhardt、Nirmal Antony、Trevor Pease、Bryan Griffith、Angus Ferguson (AWS)、Randy Patrick (AWS)、Stephanie Brenneman (AWS)、Art Steele、Kevin Owen。