O que construí.

// Problema

Um data lake de ~900 TB em constante crescimento, com múltiplas squads gerando ETLs, tinha detecção de falhas puramente reativa — problemas só apareciam quando um usuário de negócio reportava dado incorreto ou ausente, muitas vezes dias depois da falha original.

// Solução

• → Liderei squad de 5-8 engenheiros na arquitetura e governança do lake, com padronização de camadas (bronze/silver/gold) e dos Glue Workflows/Jobs.
• → Implantei observabilidade do zero: biblioteca Python compartilhada entre os jobs Glue, com alertas via Lambda no Microsoft Teams (detalhes do erro + link direto para o CloudWatch).
• → Padronizei o processo de triagem: qualquer falha chega ao time com contexto suficiente para diagnóstico imediato.

// Problema

Dados cadastrais, de apólices e de reclamações precisavam chegar a sistemas de atendimento (CRM) em tempo próximo ao real, além de atender exigências regulatórias de troca de dados entre seguradoras (Open Insurance/SUSEP).

// Solução

• → Mantive e evoluí um pipeline de Change Data Capture com Apache Kafka, capturando mudanças em dados cadastrais, apólices e reclamações direto na origem.
• → Disponibilizei os dados processados em DynamoDB, servidos via APIs consumidas pelo CRM de atendimento.
• → Gerenciei a integração com o Open Insurance: recepção de dados de outras seguradoras e envio no padrão regulatório exigido pela SUSEP.

// Problema

A companhia nunca havia colocado um projeto de IA em produção. A análise de reclamações dependia de consulta manual a dados espalhados por múltiplos sistemas (cliente, apólice, histórico de reclamações), sem apoio sistematizado à decisão do analista.

// Solução

• → Conduzi a engenharia de dados e o MLOps do projeto: agregação de dados de cliente, apólice e reclamação em uma visão unificada.
• → Integrei o pipeline com o modelo de classificação desenvolvido pelo time de ciência de dados.
• → Entreguei recomendações fundamentadas em dashboard Power BI, com os dados que sustentam cada sugestão.

// Problema

Um estudo de ciência de dados havia validado hyperparameters promissores para análise de documentos com LLMs open-source, mas não existia caminho de produção: sem API de predição, sem orquestração de modelos/versões, sem infraestrutura para servir clientes externos.

// Solução

• → Construí o pipeline de produção para os 3 modelos, incluindo orquestração de qual modelo/versão atende cada predição.
• → Desenvolvi APIs de consumo e gerenciamento de predições, desacoplando o time de ciência de dados da complexidade de infraestrutura.
• → Gerencio a infraestrutura em nuvem que serve os modelos a clientes externos e integrei IA generativa (Claude e agentes) ao fluxo de engenharia — code review, qualidade, segurança e testes.

// Problema

Uma operadora de telecom de grande porte (~80 milhões de clientes) precisava consolidar dados de clientes, campanhas e segmentos vindos de fontes batch e streaming heterogêneas, e ativar jornadas de comunicação multicanal de forma confiável.

// Solução

• → Modelei schemas XDM com schema evolution e construí ingestões batch (BigQuery/CSV) e em streaming, configurando Kafka do lado do cliente integrado ao AEP.
• → Criei jornadas de ativação multicanal no Adobe Journey Optimizer (e-mail, push e SMS), incluindo estratégias de IP warming de domínios.
• → Construí pipelines de dados complementares com Airflow e Redshift em ambientes AWS e GCP.

// Problema

O cálculo de variáveis de similaridade e segmentação rodava em BigQuery com execuções que levavam dias, sujeitas a falhas e reinícios frequentes, gerando custos cloud elevados e atrasando a disponibilização de variáveis para os modelos.

// Solução

• → Refatorei o cálculo de variáveis de BigQuery para Spark/Scala, rodando em cluster Dataproc de 10 a 15 nós.
• → Criei uma Feature Store interna para cadastro e gestão de modelos e variáveis, com autenticação OAuth 2.0 integrada ao GCP.
• → Desenvolvi APIs REST em Flask e DAGs no Airflow para orquestrar o processamento, com deploys via CI/CD.