TranFu
返回

Huntington 成为 AI 产业观察信号

TFTranFu 精选2026/06/24 18:24

Huntington Bank: Redacting sensitive data from 400M+ documents with AWS: When your document repository contains hundreds of millions of files accumulated over nearly a decade, how do you systematically find and redact se

Huntington 成为 AI 产业观察信号
图片来源:aws.amazon.com
文章作者、来源:aws.amazon.com

正文

当你的文档仓库里积累了近十年、数以亿计的文件时,如何系统地查找并清除其中的敏感客户数据,而且不会耗费数年时间才能完成?这正是美国十大银行之一的 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 可以作为 agent 部署在本地数据中心,用于监控已配置的数据源,例如 SMB 文件共享。虽然将文档传送到 AWS 对处理工作至关重要,但 AWS DataSync 也支持将数据同步回本地,这也是该项目的另一项关键需求。

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 内置的 map 状态,它可以处理 JSON、CSV 或其他格式的输入集合。团队将 Amazon S3 中的文档整理为一个 JSON 集合,并以分布式模式运行 map 状态,以获得更高的并发性。为跟踪流水线进度,他们将 AWS Step Functions 的 map run 执行摘要与 Amazon CloudWatch 仪表板结合使用,以监控响应时间、限流次数、成功率和错误率。

为了应对潜在的限流,Huntington 通过监控 CloudWatch 仪表板来核实 Amazon Textract 的成功请求数和限流计数。必要时,他们会调整子工作流执行的并发限制,确保其保持在 Amazon Textract 服务配额之内,同时维持较高吞吐量。作业成功完成后,检测到的字段和元数据会写入一个存储桶,供后续审查。下图展示了这一方法:

步进函数中的 wait 块用于确认流程已准备好继续写入作业元数据,并接着执行下一次 Amazon Textract 调用。在没有失败的情况下,状态机以 pass 状态结束。发生失败时,AWS Step Functions 会写入日志,供人工审查和重新处理。

到目前为止,这一流程的重点是检测敏感数据,并将其整理到写入 Amazon S3 的元数据文件中。最后的步骤是对文档进行脱敏,并将其传回本地存储。

图像和 PDF 脱敏已有多种开源和商业工具可用。常见的开源 Python 库包括 PyMuPDF,或者像 PIL 这样的图像绘制库。下图展示了对前面所示发票进行脱敏的示例。Amazon Textract 支持检测多种字段,你也可以使用 regex 模式创建自定义分类。结合脱敏软件,你可以放心地对检测到的字段进行脱敏。如果你希望设置人工介入阈值,Amazon Textract 还提供可触发校验工作流的置信度分数。

Huntington 再次面临同样的架构挑战:这套方案如何扩展?AWS Step Functions 为处理数百万份文档提供了方案,同时还提供错误处理和重试逻辑的挂钩。随着文档处理流水线对需要脱敏的对象进行编目,Huntington 运行了一个简单的流程来处理它们:

为确保准确性和完整性,Huntington 在脱敏前再次核对检测到的字段是否与预期模式匹配,随后为每个文件更新元数据。完成脱敏的文件会被放入 Amazon S3 中的一个位置,并由 AWS DataSync 监控,用于传回本地文件存储。

借助 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。

阅读原文

AI解读

这是一条雷达解读:它可能反映 AI 产品、开发者工具、模型基础设施或研究方向的新变化。

对销售 / 客户成功团队来说,可以作为后续选题、产品观察或技术调研的线索。

建议打开原文核对细节,并观察是否有同类信号在其他来源重复出现。