Como construir um pipeline serverless de redação de IPI com o Amazon Bedrock Data Automation

O problema da redação de IPI em escala

Organizações que processam milhares de documentos digitalizados por dia — formulários médicos, solicitações de seguros, registros financeiros — enfrentam um desafio recorrente de conformidade: a necessidade de redigir Informações de Identificação Pessoal (IPI) antes de compartilhar esses documentos com terceiros ou encaminhá-los para processamento interno.

A redação manual simplesmente não escala. Ela consome horas de trabalho, introduz erros humanos e cria exposição regulatória. Além disso, redação é tanto um problema de detecção quanto de precisão: uma única página pode conter múltiplos nomes, datas e endereços, onde apenas alguns são sensíveis para aquele caso de uso específico.

As abordagens tradicionais combinam Reconhecimento Óptico de Caracteres (OCR) com correspondência de padrões ou modelos de Aprendizado de Máquina (ML) customizados. Essas soluções têm limitações claras quando o texto está degradado, quando há lógica de negócio no nível de campo, ou quando os formatos de documento mudam e exigem retreinamento de modelos.

A AWS publicou um guia técnico detalhado mostrando como automatizar de ponta a ponta a detecção e redação de IPI em documentos e imagens usando o Amazon Bedrock Data Automation (BDA), o AWS Step Functions e o AWS Lambda.

Como a IA generativa resolve as limitações tradicionais

Modelos de fundação conseguem interpretar uma página de documento de forma holística — incluindo layout, rótulos de campos e contexto — e distinguir a quem pertence cada informação usando instruções em linguagem natural, sem precisar de modelos de entidades treinados.

O Amazon Bedrock Data Automation é um serviço do Amazon Bedrock que extrai informações estruturadas de documentos não estruturados, imagens, áudio e vídeo. Por meio do recurso de blueprints personalizados, é possível declarar campos nomeados para extração precisa usando instruções em linguagem natural. Para cada campo, o BDA retorna o conteúdo detectado, uma pontuação de confiança e as coordenadas da caixa delimitadora (bounding box) para pós-processamento.

Para saber mais sobre blueprints e esquemas de saída personalizados, a AWS disponibiliza a documentação oficial do Amazon Bedrock Data Automation. Para orientações mais amplas sobre gestão de IPI em aplicações de IA generativa, a AWS também publicou a Generative AI Security Scoping Matrix.

Desenhando um blueprint de redação de IPI

A solução proposta tem duas partes: um blueprint BDA personalizado que define o que deve ser redigido, e um pipeline serverless que aplica esse blueprint em escala.

Para criar um blueprint adequado, o artigo recomenda responder a quatro perguntas de escopo:

• O que é informação sensível? — Nome do paciente, data de nascimento, endereço residencial, informações de contato
• O que não é informação sensível? — Nome do médico, datas de exame, endereço do consultório, notas clínicas
• Onde essa informação aparece na página? — Em campos estruturados, texto manuscrito, múltiplas instâncias ao longo do documento
• Como removê-la? — Identificar as coordenadas da bounding box, converter PDF para PNG e aplicar blocos pretos nas regiões correspondentes

O caso de uso demonstrado no artigo é a redação de IPI em Attending Physician Statements (declarações de médicos assistentes) antes do processamento de sinistros. O blueprint final define 37 campos distribuídos em 9 grupos de campos (field groups), cobrindo identidade do paciente, contatos de emergência, familiares, documentos de governo e identificadores de seguro.

Abaixo está um trecho representativo do esquema de blueprint, mostrando o grupo PatientIdentity:

{
  "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)."
      }
    }
  }
}

Cada campo usa inferenceType: "explicit" para extração sem transformação e uma instrução em linguagem natural para delimitar o escopo da detecção. Isso permite, por exemplo, que o BDA distinga a data de nascimento do paciente das datas de consulta ou assinatura — mesmo quando diferentes formatos aparecem na mesma página.

Avaliando o blueprint: precisão e recall

Após projetar o blueprint, o artigo recomenda avaliá-lo calculando precisão e recall contra documentos redigidos manualmente como referência (ground truth). Os testes cobriram seis níveis de qualidade de documento:

• Formulários digitados limpos
• Documentos impressos e enviados por fax
• Fax com baixa qualidade de impressão
• Formulários manuscritos
• Documentos manuscritos, impressos e reescaneados
• Digitalizações de baixa resolução (100 DPI)

Os testes iniciais em 12 documentos (47 páginas) mostraram que o blueprint identificava cada instância de IPI ao menos uma vez, mas ocasionalmente perdia instâncias repetidas em blocos de texto narrativo e anotações manuscritas de médicos.

Para aumentar o recall com impacto mínimo na precisão, a solução introduz uma segunda passagem de detecção usando a saída padrão do BDA, combinando os resultados por meio de uma etapa de correspondência de tokens. Uma única chamada à API do BDA retorna dois tipos de saída:

• Saída personalizada (custom output): campos de IPI com bounding boxes detectados pelo blueprint
• Saída padrão (standard output): extração completa com bounding box para cada palavra da página

O trecho de código abaixo mostra como a chamada assíncrona é feita:

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,
    },
)

A lógica de correspondência de tokens normaliza cada valor de IPI detectado em tokens no nível de palavra e varre a saída padrão da página buscando palavras cuja forma normalizada corresponda a algum token de IPI. Novos matches não sobrepostos são adicionados ao conjunto final de coordenadas a redigir. Com isso, instâncias repetidas de IPI são capturadas onde quer que reapareçam na página — inclusive em parágrafos de texto livre e manuscritos.

Como ambas as passagens usam uma única chamada à API, a verificação de qualidade adiciona cobertura sem latência extra de uma segunda invocação. Os resultados da avaliação mostram:

• Blueprint apenas: precisão de 97,0% e recall de 89,3%
• Blueprint + saída padrão + lógica de correspondência: precisão de 96,5% e recall de 95,2%

A pontuação de confiança retornada pelo BDA também pode ser usada para encaminhar casos-limite para revisão humana, conforme necessário para cada caso de uso.

Arquitetura do pipeline serverless

O pipeline é estruturado como um fluxo de trabalho serverless com cinco funções AWS Lambda orquestradas por uma máquina de estados do AWS Step Functions. Dois níveis aninhados de distributed maps do Step Functions paralelizam as chamadas à API do BDA no nível de página. Os documentos PDF de entrada são fornecidos por um prefixo do Amazon S3.

O pipeline recebe três entradas na Step Function:

• Um prefixo S3 de entrada com os PDFs não redigidos
• Um prefixo S3 de saída para os resultados
• O ARN (Amazon Resource Name) do blueprint BDA validado para o caso de uso

As cinco etapas do fluxo são:

• Initialize (Inicialização): valida a entrada, resolve o blueprint, lista os documentos no S3 e gera um manifesto para o mapa distribuído no nível de documento
• Preprocess (Pré-processamento): converte cada PDF em imagens PNG por página
• Detect and Redact (Detecção e Redação): envia cada imagem de página ao BDA para detecção de IPI e aplica blocos pretos sobre as coordenadas detectadas
• Reassemble (Remontagem): combina as páginas redigidas em um único PDF redigido por documento e gera metadados
• Report (Relatório): agrega os resumos dos documentos em um relatório de job e executa uma verificação de reconciliação

A função de Redação realiza quatro operações por página: invoca o BDA, analisa o resultado, redige a imagem e faz upload para o S3. O BDA retorna coordenadas normalizadas (esquerda, topo, largura e altura como frações entre 0 e 1), que são convertidas para coordenadas de pixel. A função expande levemente cada caixa para compensar variações e desenha um retângulo preto preenchido sobre a região. Diferente de abordagens baseadas em anotação, essa técnica sobrescreve os dados de pixel da própria imagem — o conteúdo coberto não está presente no arquivo de saída e não pode ser recuperado.

Recuperação de falhas e relatório final

O pipeline usa uma abordagem em camadas para recuperação de falhas. A primeira camada lida com picos de throttling usando o mecanismo nativo de retry com backoff exponencial e jitter do Step Functions. A segunda camada isola erros de documentos corrompidos sem interromper o processamento dos demais.

Dois tipos de isolamento se aplicam:

• Falhas no nível de documento (PDF corrompido, erro de remontagem): o pipeline registra a falha no relatório enquanto os outros documentos continuam sendo processados
• Falhas no nível de página (throttling persistente que esgota as tentativas): a recuperação usa o recurso de redrive nativo do Step Functions, sem reprocessar o trabalho já concluído

O relatório final agrega estatísticas por documento, dados de tempo e um resumo de reconciliação. Um exemplo de saída:

{
  "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
}

Segurança do pipeline

A solução é construída sobre os controles de segurança dos serviços AWS utilizados:

• Acesso com escopo mínimo via IAM: cada função Lambda tem uma função de Gerenciamento de Identidade e Acesso (IAM) dedicada com privilégios mínimos, restrita ao bucket do pipeline e apenas às ações necessárias
• Criptografia em repouso e em trânsito: a criptografia padrão do S3 protege todos os documentos com AES-256; a comunicação com os serviços usa Segurança da Camada de Transporte (TLS)
• Rede privada: as funções Lambda suportam implantação em Nuvem Privada Virtual (VPC) via variáveis de infraestrutura como código; quando habilitado, o tráfego permanece fora da internet pública por meio de VPC endpoints
• Auditabilidade: o AWS CloudTrail registra toda a atividade de API no pipeline, suportando revisões de conformidade

Quando usar essa abordagem

O artigo destaca que a abordagem com blueprints BDA é especialmente adequada para casos onde os documentos estão degradados ou em formatos mistos, onde há lógica de negócio no nível de campo (como redigir o nome do paciente mas não o do médico), ou onde coordenadas de bounding box no nível de pixel são necessárias para a redação em imagens.

O mesmo pipeline de produção pode ser reutilizado para diferentes tipos de documento simplesmente alterando o schema do blueprint e o prefixo S3 de entrada — tornando a solução um padrão reutilizável para redação de IPI em prontuários médicos, formulários de onboarding financeiro, requerimentos governamentais e qualquer workload intensivo em documentos com dados sensíveis.

Para começar, a AWS disponibiliza documentação sobre criação de blueprints no Amazon Bedrock Data Automation e um artigo complementar sobre como o BDA interage com o Bedrock Guardrails.

Fonte

Build a serverless PII redaction pipeline with Amazon Bedrock Data Automation (https://aws.amazon.com/blogs/machine-learning/build-a-serverless-pii-redaction-pipeline-with-amazon-bedrock-data-automation/)