KYC Moderno: Serverless, IA e Trilhas de Auditoria em Serviços Financeiros

O movimento em direção a pipelines de KYC serverless não é uma novidade tecnológica, é uma convergência de pressões que finalmente tornaram a arquitetura viável e necessária ao mesmo tempo.

Primeiro, a maturidade das ferramentas. O AWS Step Functions Express Workflows atingiu um ponto onde orquestrar um pipeline de 15 etapas com ramificações condicionais, retries exponenciais e compensações é operacionalmente sustentável. O limite de 5 minutos por execução do Express Workflow é irrelevante para KYC em tempo real, se seu fluxo de verificação demora mais que isso, o problema não é o orquestrador, é o design.

Segundo, o Amazon Textract e o Bedrock mudaram a equação de extração de documentos. Antes, você precisava de um pipeline de ML customizado para extrair dados de CNH, passaporte ou comprovante de renda com precisão aceitável. Hoje, uma combinação de Textract com AnalyzeDocument (modo FORMS + QUERIES) e um modelo Bedrock para validação semântica entrega precisão comparável a um analista humano em documentos limpos, com latência de 3-8 segundos por documento e custo na ordem de frações de centavo por página.

Terceiro, e talvez mais importante para ambientes financeiros regulados: o modelo de responsabilidade compartilhada da AWS evoluiu com certificações específicas para o setor financeiro (PCI DSS Level 1, SOC 2 Type II, ISO 27001, BACEN Resolution 4.893 alignment). Isso não elimina o trabalho de compliance, mas reduz drasticamente o escopo de auditoria quando você usa serviços gerenciados com controles documentados.

O erro mais comum que vejo em arquiteturas de KYC, mesmo em times experientes, é tratar a trilha de auditoria como um efeito colateral: você salva o resultado da decisão em algum lugar e chama isso de audit log. Reguladores como o BACEN, a CVM e o COAF não aceitam isso. Eles querem saber por que a decisão foi tomada, quais dados estavam disponíveis no momento da decisão e quem ou o quê executou cada etapa.

A arquitetura que proponho inverte essa lógica: a trilha de auditoria é um output de primeira classe do pipeline, não um log de aplicação. Cada execução do Step Functions gera um ARN de execução único que serve como chave primária de rastreabilidade. Cada Lambda que participa do fluxo persiste seu input, output e metadados (versão do modelo Bedrock, versão da função Lambda, timestamp com precisão de milissegundo) no DynamoDB com uma chave de partição kyc#customerId#executionId. O DynamoDB Streams então propaga cada mutação para um bucket S3 com Object Lock em modo COMPLIANCE: isso significa que nem o root account pode deletar o registro antes do período de retenção configurado (mínimo 5 anos para KYC no Brasil).

Um detalhe crítico: quando você usa Bedrock como co-piloto de decisão, o prompt enviado ao modelo, a resposta completa e o modelo utilizado (incluindo versão) devem ser parte do registro de auditoria. Isso não é opcional, é o que permite reconstituir a decisão meses depois durante uma auditoria regulatória. Use modelId explícito nas chamadas Bedrock (nunca latest) e persista o campo usage.inputTokens + usage.outputTokens para rastreabilidade de custo e reprodutibilidade.

Antes de recomendar essa arquitetura para qualquer cliente, preciso ser honesto sobre onde ela falha ou exige cuidado extra.

Cold start em fluxos críticos: Lambda com runtime Java ou .NET pode ter cold starts de 800ms-2s. Para KYC em tempo real, isso é inaceitável se ocorrer no caminho crítico. A solução não é migrar para Go ou Python cegamente, é usar Provisioned Concurrency para as funções no caminho crítico (extração e decisão), com Application Auto Scaling configurado para escalar com base em ProvisionedConcurrencyUtilization. O custo adicional é real (~$0.015/GB-hora para concorrência provisionada vs $0.0000166667/GB-segundo para on-demand), você precisa modelar o perfil de carga antes de decidir.

Limites do Textract em documentos de baixa qualidade: O Textract AnalyzeDocument tem precisão degradada em documentos digitalizados com resolução < 150 DPI, iluminação irregular (foto de documento com celular em ambiente escuro) ou documentos plastificados com reflexo. Em produção, você precisa de um pré-processamento de imagem (Lambda com OpenCV ou Amazon Rekognition DetectText como fallback) e um limiar de confiança mínimo por campo extraído, se Confidence < 85 em campos obrigatórios como nome ou CPF, o documento deve ser rejeitado para resubmissão, não processado com dados incertos.

Custo de Bedrock em escala: Uma chamada ao Claude 3 Sonnet para scoring de risco com contexto de 2000 tokens custa aproximadamente $0.003-0.006 por chamada. Em 100.000 onboardings/mês, isso é $300-600/mês apenas em inferência, gerenciável. Mas se você usar Bedrock para cada etapa de validação sem critério, o custo escala rapidamente. A regra que aplico: Bedrock entra apenas quando regras determinísticas não conseguem resolver, não como primeira linha de processamento.

Throttling de APIs externas de sanções: Listas OFAC, PEP e CSNU são consultadas via APIs de terceiros que têm rate limits agressivos (tipicamente 10-50 req/s por conta). Em picos de onboarding, isso cria gargalo. A solução é um cache TTL de 24h no ElastiCache Redis para entidades já verificadas, com invalidação forçada quando as listas são atualizadas, reduz chamadas externas em 70-80% em fluxos com re-verificação periódica.

O gap mais crítico que observo não é tecnológico, é organizacional. Times que operam KYC legado têm analistas de compliance que entendem as regras mas não entendem o pipeline técnico, e engenheiros que entendem o pipeline mas não entendem as implicações regulatórias de cada decisão de design. A arquitetura serverless + IA amplifica esse gap se não for gerenciada.

A primeira mudança que recomendo é criar um KYC Design Authority: um grupo pequeno (3-5 pessoas) com representação de engenharia, compliance e produto que revisa e aprova mudanças no pipeline de decisão. Não é burocracia: é o mecanismo que garante que uma mudança no prompt do Bedrock não inadvertidamente viole uma política de crédito ou crie um viés discriminatório não intencional.

Segundo, invista em observabilidade de decisão, não apenas de infraestrutura. CloudWatch Metrics para latência de Lambda é necessário mas insuficiente. Você precisa de métricas de negócio: taxa de aprovação por segmento de cliente, distribuição de scores de risco ao longo do tempo, taxa de discordância entre IA e analista humano em casos de revisão. Essas métricas são o sinal de que o modelo está driftando ou que as regras de negócio mudaram sem atualização do pipeline.

Terceiro, trate prompts do Bedrock como código de infraestrutura: versionados em Git, revisados via PR, testados com um conjunto de casos de teste curado (incluindo edge cases regulatórios) antes de qualquer deploy. Um prompt que muda o critério de aprovação de crédito sem passar por revisão de compliance é equivalente a um deploy de código que muda a lógica de precificação sem aprovação, inaceitável em ambiente financeiro regulado.

Finalmente, planeje para multi-region desde o início se você opera em mercados com requisitos de residência de dados. No Brasil, dados de KYC com PII devem residir em sa-east-1 (São Paulo). Se você precisar de DR ativo-ativo, a replicação de DynamoDB Global Tables funciona, mas você precisa de key policies KMS que restrinjam descriptografia à região primária, a réplica pode armazenar mas não deve descriptografar sem aprovação explícita.