AWS IDP 提取 PII 信息踩坑记录
用 AWS 搞一套智能文档处理（IDP）来自动分类邮件并提取 PII（个人敏感信息），理论上跑通很简单，但实际部署时对权限和触发机制的坑深得离谱。
下一篇
用SHAP找Bug比用它写汇报PPT有用得多 →
最让我头疼的是 Lambda 触发器和权限策略的配置。如果你直接按默认配置跑，很容易在读取 S3 触发的邮件流时报 Access Denied，即便你觉得已经给了 S3FullAccess。
排查后发现，关键在于执行角色（Execution Role）必须精准包含对特定 S3 Bucket 的 s3:GetObject 权限，并且得在信任关系里明确定义触发源。
一个比较稳的权限配置参考：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-email-bucket",
"arn:aws:s3:::your-email-bucket/*"
]
}
]
}另外，在处理 PII 提取时，如果依赖 Textract，要注意文档格式的干扰。有些邮件转 PDF 后的布局极其混乱，导致提取出的关键信息字段偏移，直接用默认配置提取结果几乎不可用。建议在调用接口时，强制开启 QUERIES 功能，通过具体的自然语言问题去定位 PII 字段，而不是死磕布局分析。
这套实操下来，感觉 AWS 的 IDP 链路虽然完整，但配置成本太高，每一个环节的衔接都像在走钢丝。
