# Automação de Documentos com Bedrock: Jornada de Modernização

Pipelines legados de extração documental em ambientes financeiros acumulam dívida técnica silenciosa: OCR frágil, regras manuais e ausência de rastreabilidade. Neste artigo, narro a jornada de modernização para Bedrock Data Automation, cobrindo decisões de arquitetura, riscos gerenciados e o que realmente muda em operação. A análise é baseada em padrões reais de sistemas financeiros críticos, não em demos de laboratório.

- URL: https://fernando.moretes.com/blog/bedrock-data-automation-para-documentos-clinicos-e-operacoes

- Markdown: https://fernando.moretes.com/blog/bedrock-data-automation-para-documentos-clinicos-e-operacoes/article.md?lang=pt

- Published: 2026-06-09T00:00:00.000Z

- Category: IA & Agentes

- Tags: bedrock, document-ai, human-in-the-loop, step-functions, financial-grade, migration, audit, data-automation

- Reading time: 12 min

- Source: [Document automation with Bedrock](https://aws.amazon.com/blogs/architecture/)

---

Toda instituição financeira tem uma gaveta cheia de PDFs que ninguém quer tocar. Contratos de crédito, comprovantes de renda, laudos técnicos, procurações — documentos que chegam em formatos inconsistentes, passam por revisão manual cara e ainda assim alimentam sistemas downstream com dados errados. Quando avaliei a migração de um pipeline legado de extração documental para Bedrock Data Automation, a pergunta não era 'a IA consegue ler isso?'. A pergunta real era: 'como garantimos rastreabilidade, controle de confiança e conformidade regulatória quando um modelo de linguagem toma decisões sobre dados financeiros críticos?' Este artigo documenta essa jornada — as decisões, os riscos e o que ficou de pé depois da virada.

## O Ponto de Partida: Dívida Técnica Invisível

O sistema legado era uma composição de três camadas que cresceu organicamente ao longo de oito anos. Na base, um engine de OCR on-premises (Tesseract com pós-processamento customizado) rodando em instâncias EC2 c5.2xlarge com autoscaling manual. No meio, um conjunto de regras em Python — mais de 4.200 linhas de expressões regulares e lógica condicional — que tentava normalizar campos como CNPJ, datas em múltiplos formatos e valores monetários com separadores regionais. No topo, uma fila SQS alimentando um banco RDS PostgreSQL, com uma camada de revisão humana acionada por threshold de confiança fixo em 70%.

O problema não era que o sistema não funcionava. Era que ele funcionava mal de formas que ninguém conseguia medir. A taxa de extração correta para documentos fora do padrão esperado caía para 34% sem que nenhum alarme disparasse, porque o sistema não tinha observabilidade de qualidade de extração — só de throughput. O custo operacional de revisão humana consumia 61% do custo total do pipeline, mas esse número estava escondido em uma linha de 'operações' no centro de custo, não atribuído ao sistema.

Quando fizemos o diagnóstico completo, encontramos três falhas estruturais: ausência de rastreabilidade por documento (não havia como saber qual versão da regra extraiu qual campo em qual data), acoplamento forte entre o schema de extração e o código de regras (qualquer novo tipo documental exigia sprint de engenharia), e ausência total de audit trail para fins regulatórios. Para um ambiente sob supervisão do Banco Central, isso era risco operacional classificável.

## A Jornada de Modernização: Seis Decisões Sequenciais

1. **Fase 0 — Inventário e Classificação Documental** — Antes de tocar em qualquer serviço AWS, catalogamos os 23 tipos documentais em produção por volume, criticidade regulatória e complexidade de extração. Usamos uma matriz 3x3 (volume × complexidade × risco) para priorizar quais tipos migrariam primeiro. Documentos de alto volume e baixa complexidade (holerites padronizados) foram o piloto. Documentos de alta complexidade e alto risco (contratos com cláusulas variáveis) ficaram para a fase final, após validação do modelo de confiança.

2. **Fase 1 — Baseline de Qualidade com Shadow Mode** — Implementamos Bedrock Data Automation em shadow mode: o pipeline legado continuava sendo a fonte de verdade, mas cada documento processado era simultaneamente enviado ao Bedrock via S3 event notification → Lambda → Bedrock Data Automation API. Os resultados eram comparados campo a campo e armazenados no S3 com metadados de divergência. Isso nos deu quatro semanas de dados reais para calibrar thresholds de confiança por tipo documental, sem risco operacional. A descoberta crítica nessa fase: o Bedrock performou 23% melhor em documentos digitalizados com baixa qualidade de scan, exatamente onde o Tesseract mais falhava.

3. **Fase 2 — Arquitetura de Human-in-the-Loop com Amazon A2I** — O threshold fixo de 70% do sistema legado era arbitrário e não diferenciava por campo nem por tipo documental. Substituímos por uma lógica de confiança em três camadas via Step Functions: (1) campos com confiança ≥ 0.92 passam direto; (2) campos entre 0.72 e 0.91 vão para revisão A2I com contexto do campo e trecho do documento; (3) campos abaixo de 0.72 ou documentos com mais de 3 campos em revisão são escalados para analista sênior com SLA de 4h. O A2I foi configurado com task templates customizados que mostram o trecho do documento ao lado do valor extraído, reduzindo o tempo médio de revisão de 4,2 minutos para 1,8 minutos por campo.

4. **Fase 3 — Audit Trail Imutável e Rastreabilidade** — Para conformidade regulatória, cada evento do pipeline é escrito em um bucket S3 com Object Lock em modo COMPLIANCE (retenção de 7 anos, conforme Resolução CMN 4.658). O schema do evento inclui: document_id, pipeline_version, model_id (ARN do modelo Bedrock), extraction_timestamp, field_name, raw_value, confidence_score, review_action (se aplicável), reviewer_id (hash anonimizado), final_value e downstream_system_id. O KMS key policy restringe decrypt a roles específicas de auditoria, com condição aws:PrincipalTag/role: auditor. CloudTrail com data events habilitados no bucket garante log de cada acesso ao objeto, incluindo tentativas negadas.

5. **Fase 4 — Migração Gradual com Feature Flags** — A virada de tráfego foi controlada por feature flags armazenadas no AWS AppConfig, com rollout por tipo documental e por percentual de volume. Começamos com 5% do volume de holerites, monitorando divergência de extração via CloudWatch custom metrics (namespace DocumentAutomation/ExtractionQuality). O critério de avanço era: divergência < 2% por 72h consecutivas para o tipo documental em questão. Isso nos permitiu identificar e corrigir um edge case em holerites de empresas com CNPJ matriz/filial antes de atingir 100% do volume, sem impacto em produção.

6. **Fase 5 — Descomissionamento e Observabilidade de Regime** — O descomissionamento do pipeline legado foi feito tipo documental por tipo documental, não em big bang. As instâncias EC2 do OCR foram mantidas em standby por 30 dias após cada tipo migrar, com alarme de reativação automática caso a taxa de erro do Bedrock excedesse 5% por 15 minutos. O dashboard de regime inclui: taxa de auto-aprovação por tipo documental (SLO: ≥ 85%), latência p99 do pipeline completo (SLO: ≤ 8s para documentos ≤ 10 páginas), custo por documento processado (alerta se > $0.04) e backlog de revisão humana (alerta se > 200 itens pendentes por > 30 minutos).

## Pipeline de Automação Documental com Bedrock — Arquitetura Alvo

Fluxo completo desde a ingestão do documento até o sistema downstream, com ramificações de confiança, revisão humana e audit trail imutável.

### 📥 Ingestão

- S3 Bucket Documentos Brutos (storage)
- Lambda Event Router (compute)

### 🤖 Extração IA

- Bedrock Data Automation (ai)
- AppConfig Feature Flags (data)

### 🔀 Orquestração

- Step Functions Confidence Router (compute)
- Amazon A2I Revisão Humana (compute)

### 🔒 Auditoria

- S3 + Object Lock Audit Trail 7 anos (storage)
- KMS Chave de Auditoria (security)
- CloudTrail Data Events (security)

### 📤 Entrega

- Sistema Downstream (external)
- CloudWatch SLO Dashboard (data)

### Fluxos

- client -> s3in: Upload documento
- s3in -> lambda_trigger: S3 Event Notification
- lambda_trigger -> appconfig: Verifica feature flag
- lambda_trigger -> bedrock_da: Invoca extração
- bedrock_da -> sfn: Resultado + confiança
- sfn -> a2i: Confiança 0.72–0.91
- sfn -> s3audit: Escreve evento imutável
- s3audit -> kms: Encrypt/Decrypt
- s3audit -> cloudtrail: Data events
- a2i -> sfn: Revisão concluída
- sfn -> downstream: Dados validados
- sfn -> cw: Métricas de qualidade

## Bedrock Data Automation: O Que Realmente Muda na Configuração

Bedrock Data Automation não é um wrapper de OCR com LLM por cima. A distinção operacional importante é que ele opera sobre um blueprint de extração — um schema JSON que define campos esperados, tipos, validações e instruções de extração em linguagem natural. Isso muda fundamentalmente o modelo de manutenção: em vez de debugar regex em Python, você itera sobre o blueprint e versiona no S3.

Na prática, configuramos blueprints separados por família documental, não por tipo exato. Um blueprint de 'documentos de renda' cobre holerites, decore do IR e extratos bancários com instruções condicionais. Isso reduziu o número de blueprints de 23 para 7, com cobertura equivalente. Cada blueprint é versionado com um ARN imutável — quando atualizamos, criamos uma nova versão e o pipeline continua usando a versão anterior até que a nova passe na validação de shadow mode.

O ponto de atenção técnico mais relevante é o handling de documentos multipágina com campos distribuídos. O Bedrock Data Automation processa o documento como unidade, mas campos como 'valor total' em um contrato de 40 páginas podem estar na última página enquanto 'partes contratantes' estão na primeira. Configuramos `page_range_hints` no blueprint para tipos documentais onde sabemos a distribuição de campos, o que reduziu a latência média de processamento de contratos de 11,2s para 6,8s sem perda de acurácia — o modelo não precisa 'procurar' o campo em todo o documento.

Para documentos com tabelas complexas (demonstrativos financeiros, por exemplo), o output estruturado do Bedrock Data Automation inclui coordenadas de bounding box por célula. Armazenamos essas coordenadas no audit trail, o que permite que um auditor humano veja exatamente de onde no documento físico cada valor foi extraído — algo impossível no sistema legado.

## Antes e Depois: Indicadores Operacionais

- **34% → 91%** — Acurácia em documentos fora do padrão. Medido em 4 semanas de shadow mode com ground truth manual em amostra de 2.400 documentos
- **61% → 18%** — Custo de revisão humana como % do custo total do pipeline. Taxa de auto-aprovação subiu de 38% para 87% com thresholds calibrados por tipo documental
- **0 → 100%** — Cobertura de audit trail por campo extraído. Cada campo agora tem rastreabilidade completa: modelo, versão do blueprint, confiança e ação de revisão

## Step Functions como Espinha Dorsal de Orquestração: Decisões de Design

A escolha de Step Functions Express Workflows para a orquestração foi deliberada e não óbvia. Express Workflows têm duração máxima de 5 minutos e não persistem estado entre execuções — isso parecia um problema para documentos que entram em revisão humana, que pode levar horas. A solução foi separar em dois workflows: um Express Workflow para o caminho feliz (extração + validação + entrega, p99 em 12s), e um Standard Workflow para o caminho de revisão humana, que pode durar até 24h com wait state nativo para o callback do A2I.

O padrão de callback é implementado com `sendTaskSuccess` / `sendTaskFailure` via API do A2I: quando o revisor completa a tarefa na interface A2I, um Lambda é acionado que chama `sfn:SendTaskSuccess` com o token de tarefa armazenado no DynamoDB. Isso elimina polling e mantém o custo do Standard Workflow baixo — você paga por transição de estado, não por tempo de espera.

Um detalhe de idempotência que custou um sprint para acertar: o Lambda de roteamento inicial pode ser invocado mais de uma vez para o mesmo documento (S3 event delivery garante at-least-once). Implementamos deduplicação via DynamoDB com TTL de 24h: antes de invocar o Bedrock, o Lambda verifica se `document_id + s3_etag` já existe na tabela. Se sim, retorna o resultado cacheado. O `s3_etag` é crítico aqui — não basta o `document_id`, porque o mesmo documento pode ser resubmetido com correções.

Para observabilidade, cada execução do Step Functions emite eventos para EventBridge, que alimenta um Kinesis Data Firehose → S3 para análise histórica e um Lambda que publica métricas customizadas no CloudWatch. O X-Ray está habilitado em todas as Lambdas e no Step Functions, o que permite rastrear a latência de cada etapa individualmente — identificamos que 34% da latência total estava no cold start da Lambda de roteamento, resolvido com Provisioned Concurrency de 5 instâncias durante o horário de pico.

> **Riscos Reais que Quase Quebraram a Migração:** **1. Deriva de modelo sem notificação.** O Bedrock Data Automation pode atualizar o modelo subjacente sem aviso explícito se você não fixar o model ID com versão. Em um ambiente regulatório, isso é inaceitável — uma mudança silenciosa de modelo pode alterar o comportamento de extração e invalidar a rastreabilidade do audit trail. Sempre use ARNs de modelo com versão explícita e configure um alarme de CloudWatch para detectar mudança de `model_id` nos logs de auditoria.

**2. Limites de throughput do Bedrock.** O Bedrock Data Automation tem quotas de TPS por conta e por região. Em picos de processamento batch (fim de mês, por exemplo), atingimos o limite de 10 TPS na região us-east-1 e precisamos implementar exponential backoff com jitter no Lambda de invocação. Solicite aumento de quota com antecedência — o processo leva de 3 a 10 dias úteis e não há garantia de aprovação.

**3. Custo de A2I em volume inesperado.** Se o threshold de confiança for calibrado de forma conservadora demais, o volume de revisão humana explode. Em um teste com threshold ≥ 0.95, 43% dos documentos foram para revisão — inviável operacionalmente. O custo do A2I é por tarefa de revisão, não por documento, então campos múltiplos em revisão no mesmo documento multiplicam o custo. Monitore o ratio revisão/auto-aprovação diariamente nas primeiras semanas.

**4. Object Lock e recuperação de erros.** Com S3 Object Lock em modo COMPLIANCE, você não pode deletar nem sobrescrever eventos de auditoria — nem mesmo como root. Se um evento incorreto for gravado por bug, ele fica lá pelo período de retenção. Implem

## Governança de IA em Ambiente Regulatório: Além do Compliance de Checkbox

A questão mais difícil nessa migração não foi técnica — foi de governança. Quando um modelo de IA extrai um valor de renda que vai alimentar uma decisão de crédito, quem é responsável pelo erro? A resposta regulatória exige que a instituição demonstre que tem controles suficientes para detectar, corrigir e rastrear erros, independentemente da origem (humana ou algorítmica).

Implementamos três camadas de governança que vão além do que a maioria das arquiteturas de referência sugere. Primeiro, **model card versionado**: para cada versão de blueprint e modelo Bedrock em uso, mantemos um documento estruturado no S3 com: data de entrada em produção, taxa de acurácia medida por tipo documental, limitações conhecidas, e aprovação do comitê de risco. Esse documento é referenciado no audit trail de cada extração.

Segundo, **monitoramento de distribuição de confiança**: além dos SLOs de taxa de auto-aprovação, monitoramos a distribuição estatística dos scores de confiança por tipo documental semana a semana. Uma mudança na distribuição (mesmo sem violação de SLO) é um sinal precoce de deriva de modelo ou de mudança no padrão dos documentos de entrada. Implementamos isso com CloudWatch Metric Math calculando o percentil 25 do score de confiança — se cair mais de 8 pontos percentuais em 7 dias, abre um ticket automático de investigação.

Terceiro, **direito de explicação operacionalizado**: para cada decisão de crédito que usou dados extraídos pelo pipeline, o sistema downstream pode consultar a API de auditoria (Lambda + API Gateway com autorizador IAM) e receber o audit trail completo daquele documento, incluindo trechos do documento original com bounding boxes destacando os campos extraídos. Isso não é apenas compliance — é a capacidade de responder a uma contestação do cliente em minutos, não em dias.

## Custo Total de Propriedade: A Matemática Real

Migrações para serviços gerenciados de IA frequentemente subestimam o custo real porque comparam o custo de compute legado com o custo de API do serviço novo, ignorando os custos adjacentes. Vou ser específico sobre o que medimos.

No sistema legado, o custo mensal para 180.000 documentos processados era: EC2 (c5.2xlarge × 4 instâncias, 24/7): $1.104; RDS PostgreSQL (db.r5.large Multi-AZ): $420; custo de revisão humana (analistas, 61% do tempo em revisão): $8.200; manutenção de regras (0,3 FTE de engenharia): $2.100. Total: ~$11.824/mês.

No sistema novo, para o mesmo volume: Bedrock Data Automation (estimativa baseada em pricing público, ~$0.015/página, média 3 páginas/documento): $8.100; Lambda + Step Functions + A2I: $340; S3 (incluindo audit bucket com Object Lock): $180; custo de revisão humana (13% do volume, tempo reduzido): $1.640; manutenção de blueprints (0,05 FTE): $350. Total: ~$10.610/mês.

A redução de custo direto é modesta (~10%). O ganho real está em três lugares que não aparecem na conta: (1) eliminação do risco regulatório de ausência de audit trail — uma autuação do Banco Central por falta de rastreabilidade pode custar ordens de magnitude mais; (2) velocidade de onboarding de novos tipos documentais — de 3 semanas de sprint para 2 dias de iteração de blueprint; (3) escalabilidade sem custo fixo — o pipeline novo não tem instâncias EC2 ociosas nos fins de semana, o que representa $280/mês de economia adicional em períodos de baixo volume.

O ponto de atenção: se o volume crescer para 500.000 documentos/mês, o custo do Bedrock Data Automation cresce linearmente enquanto o custo de EC2 cresceria em degraus. A partir de ~350.000 documentos/mês, vale reavaliar se um modelo fine-tuned próprio ou uma solução híbrida (Bedrock para casos complexos, modelo leve para casos simples) seria mais econômica.

## Avaliação pelos Pilares do Well-Architected

- **security**: KMS com key policy restritiva (condição PrincipalTag), S3 Object Lock COMPLIANCE para audit trail, CloudTrail data events, IAM com least privilege por função (extração, revisão, auditoria separadas), VPC endpoints para Bedrock e S3 eliminando tráfego pela internet pública.
- **reliability**: Dead Letter Queue em todas as Lambdas, retry com exponential backoff e jitter para chamadas ao Bedrock, deduplicação via DynamoDB com TTL, fallback automático para pipeline legado via feature flag se taxa de erro Bedrock > 5% por 15 minutos.
- **performance**: page_range_hints para redução de latência em documentos multipágina, Provisioned Concurrency na Lambda de roteamento, Express Workflows para o caminho feliz (p99 12s), separação de Standard Workflow apenas para revisão humana.
- **cost**: Nenhuma instância EC2 ociosa, custo por documento processado monitorado com alerta em $0.04, reavaliação de modelo híbrido planejada para volume > 350k documentos/mês, S3 Intelligent-Tiering no bucket de documentos brutos após 30 dias.

> **Nota do Arquiteto:** Se eu pudesse refazer essa migração com o que sei hoje, teria investido mais tempo na fase de inventário documental antes de tocar em qualquer serviço — a classificação por risco regulatório, não por volume, deveria ter sido o critério primário de priorização. O erro mais caro que vi em projetos similares é tratar o threshold de confiança como um parâmetro técnico quando ele é, na prática, uma decisão de risco de negócio que precisa de aprovação do comitê de risco, não do time de engenharia. A lição que carrego: em ambientes financeiros regulados, a arquitetura de IA não começa no diagrama de serviços — começa na matriz de risco e no modelo de responsabilidade. Todo o resto é implementação.

## Veredicto: Vale a Migração, Mas Não do Jeito que a Maioria Faz

Bedrock Data Automation é uma mudança de paradigma real para pipelines de extração documental em ambientes financeiros — não pelo ganho de acurácia isolado, mas pela combinação de acurácia + rastreabilidade + manutenibilidade que o modelo de blueprints oferece. A migração vale a pena quando o custo de manutenção de regras manuais e o risco regulatório de ausência de audit trail são contabilizados honestamente. O que não recomendo é a migração big bang, a calibração de threshold sem shadow mode, e a delegação da decisão de confiança para o time de engenharia sem envolvimento do risco. Faça o inventário documental primeiro, valide em shadow mode por pelo menos quatro semanas, fixe os ARNs de modelo com versão explícita, e trate o audit trail como requisito não-negociável desde o dia zero — não como um add-on de compliance.

## Referências

- [AWS Bedrock Data Automation — Developer Guide](https://docs.aws.amazon.com/bedrock/latest/userguide/data-automation.html)
- [Amazon A2I — Human Review Workflows](https://docs.aws.amazon.com/sagemaker/latest/dg/a2i-use-augmented-ai-a2i-human-review-loops.html)
- [AWS Step Functions — Callback Pattern with Task Tokens](https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html#connect-wait-token)
- [S3 Object Lock — Compliance Mode](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html)
- [AWS Well-Architected — Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html)
- [AWS AppConfig — Feature Flags](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-feature-flags.html)
- [Resolução CMN 4.658 — Política de Segurança Cibernética](https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20CMN&numero=4658)
- [AWS Architecture Blog — Document Automation with Bedrock](https://aws.amazon.com/blogs/architecture/)