Democratizando Dados Financeiros: Como a GenAI Transformou a Adoção de Analytics na CERC

Por Davi Campos, André Tayer, Guilherme Oliveira, Robson Sampaio · Mar 30, 2026

TL;DR — A CERC opera uma plataforma de dados financeiros de 7 PB com ~2.000 tabelas transacionais. A adoção do Databricks estagnava abaixo de 15% — não porque a plataforma estava quebrada, mas porque os usuários não conseguiam encontrar ou entender os dados. Construímos uma camada de catalogação AI-first usando Dataplex Universal Catalog, Cloud Asset Inventory e Gemini para descobrir, enriquecer e governar metadados automaticamente. Os donos de dados aprovam catálogos gerados pela IA em minutos; a GenAI então gera automaticamente pipelines completos de ingestão a partir desses metadados. O resultado: aumento de 400% nos usuários ativos mensais, 70% da CERC fazendo self-service analytics no Databricks e o tempo de catalogação reduzido de 2–3 semanas para 2 dias. O esforço técnico foi gerenciável. O desafio operacional não foi — e é sobre isso que este post realmente fala.

O Problema de Adoção que Ninguém Fala

Dois anos atrás, o ambiente Databricks da CERC era tecnicamente sólido e operacionalmente subutilizado. Tínhamos investido em infraestrutura, integrado times e construído uma arquitetura Delta Lake sobre uma plataforma de 7 PB. A adoção estava em 15%.

O ponto de falha não foi o que esperávamos. Os engenheiros não evitavam o Databricks porque era difícil de usar. Eles o evitavam porque não conseguiam responder a uma pergunta mais simples antes: quais dados estão disponíveis, onde vivem e o que significam?

A plataforma da CERC abrange ~2.000 tabelas transacionais no Google Cloud Spanner, Cloud SQL (PostgreSQL e SQL Server) e BigQuery — cada uma mantida por times diferentes, documentada em diferentes níveis de qualidade e catalogada manualmente quando catalogada. A catalogação manual levava de duas a três semanas por fonte. Nesse ritmo, a cobertura nunca conseguiria acompanhar o crescimento da plataforma. O resultado foi um catálogo de dados sempre incompleto, frequentemente desatualizado e nunca confiado.

A adoção estagna quando os usuários não conseguem se autoatender. Eles não conseguem se autoatender quando não encontram os dados. E não encontram os dados quando o catálogo é um projeto paralelo de melhor esforço mantido por quem tinha tempo livre no último trimestre.

Por Que Fomos AI-First — E Por Que Ficamos no GCP-Native

O espaço de soluções para catalogação de dados é concorrido. Avaliamos abordagens que iam desde processos manuais aprimorados com melhores ferramentas, até produtos de catálogo de terceiros, até um pipeline de metadados totalmente customizado construído internamente.

Abordagem	Motivo Considerado	Motivo Rejeitado
Catalogação manual aprimorada	Baixo investimento em ferramentas	Não escala; o gargalo é o tempo humano, não as ferramentas
Catálogo de terceiros (Collibra, Alation)	Produtos maduros, recursos de governança comprovados	Custo de integração com o stack GCP-native; superfície adicional de fornecedor; overhead de licenciamento
Pipeline de metadados customizado	Controle total	Custo de construção alto; integração com LLM requer infraestrutura significativa de engenharia de prompt
Dataplex + Gemini (GCP-native)	✅ Integração nativa em todo o nosso stack; plano de controle único; sem egresso de dados	—

A decisão de permanecer GCP-native foi direta dado onde nossos dados já vivem. O Dataplex Universal Catalog tem conectores de primeira classe para Spanner, Cloud SQL e BigQuery — os três sistemas que compõem nossa camada transacional. O Cloud Asset Inventory nos dá metadados de projetos GCP sem uma integração separada. E o Gemini opera dentro do mesmo perímetro de segurança que nossos dados, o que importa em um ambiente financeiro regulamentado onde residência de dados e controle de acesso não são opcionais.

Escolher o Gemini em vez de outros modelos não foi uma decisão puramente de capacidade. Foi uma decisão de arquitetura: manter o pipeline de enriquecimento dentro do GCP eliminou toda uma classe de questões de compliance sobre quais dados saem do nosso ambiente e para onde vão.

A Arquitetura: Quatro Camadas, Um Catálogo

O sistema que construímos tem quatro camadas distintas, cada uma resolvendo uma parte diferente do problema de cobertura.

Camada 1 — Descoberta Automática (Dataplex Universal Catalog)

O Dataplex Universal Catalog escaneia continuamente todas as fontes de dados registradas — instâncias Spanner, bancos Cloud SQL e datasets BigQuery — e extrai metadados técnicos completos: schemas, tipos de colunas, tipos de dados, nulabilidade e estimativas de cardinalidade. Criticamente, também executa classificação de PII automaticamente, sinalizando colunas que contêm dados sensíveis com base em templates DLP predefinidos.

Antes dessa camada, os metadados técnicos existiam isoladamente em cada sistema fonte. Depois, existem em um único catálogo consultável — atualizado por agenda, não por iniciativa humana.

A varredura é executada por três DAGs independentes no Apache Airflow, agendados diariamente às 3h (horário de Brasília). Cada DAG escreve em tabelas de staging próprias no BigQuery, com timeout configurado individualmente. A separação em módulos independentes garante resiliência: se o exporter do Dataplex falhar por problema de API, os outros dois continuam normalmente — sem efeito cascata.

Camada 2 — Mapeamento de Proprietários (Cloud Asset Inventory)

Saber o que uma tabela contém não é suficiente. Os usuários também precisam saber quem a possui e quem contatar quando algo está errado. O Cloud Asset Inventory mapeia automaticamente donos de dados e stewards a partir de metadados de projetos GCP — os mesmos metadados que já governam controle de acesso e alocação de faturamento.

Essa camada não exigiu nenhuma entrada manual dos times de dados. A propriedade já estava implícita em nossa estrutura de projetos GCP; tornamos explícita no catálogo.

Além de donos e stewards, o exporter captura labels de negócio já presentes em cada projeto GCP — como business_unit, team e domain — que passam a ser pesquisáveis no catálogo sem nenhuma entrada manual adicional. Um exporter dedicado a IAM complementa esse mapeamento: analisa permissões por recurso e identifica quem tem acesso de leitura em cada tabela, dado que alimenta as revisões de compliance trimestrais.

Camada 3 — Enriquecimento de Negócios (Gemini + Confluence)

Os metadados técnicos dizem o que uma coluna é. Não dizem o que ela significa no contexto do domínio de negócios da CERC. Uma coluna chamada op_type significa algo específico para o negócio de registro de recebíveis — e esse significado vive no Confluence, não no schema do banco de dados.

Demos ao Gemini acesso ao nosso corpus interno do Confluence e construímos um pipeline que gera descrições de camada de negócios para cada tabela e coluna sem documentação. O contexto do prompt inclui o schema da tabela, documentação existente de entidades relacionadas e glossários de domínio mantidos pelos nossos times de negócios. O resultado é uma descrição fundamentada em nosso domínio real — não uma inferência genérica a partir dos nomes das colunas.

Descrições geradas não são publicadas automaticamente. Elas entram em um fluxo de aprovação humano no loop onde os donos de dados revisam e aprovam ou editam antes que os metadados enriquecidos entrem em vigor.

O modelo usado é o Gemini 2.5 Flash via Vertex AI, com temperatura 0.0 para respostas determinísticas. Os assets são enviados em lotes de 100, com até 5 requisições concorrentes e retry automático em caso de falha.

Antes de acionar o modelo, o pipeline aplica filtros para evitar processamento desnecessário: assets com reviewed: true e sem mudanças estruturais são ignorados; diretórios com template __base.yaml geram metadados a partir do template sem chamar a IA; e um detector de órfãos remove automaticamente arquivos YAML cujos assets foram deletados das fontes.

Após a geração, um merge hierárquico combina três camadas via COALESCE:

wrk — edições humanas no YAML atual (prioridade máxima)
gem — descrição gerada pelo Gemini (preenche o que estiver vazio)
prd — valores existentes em produção no BigQuery (baseline)

Edições feitas manualmente nunca são sobrescritas pela IA em execuções futuras.

O fluxo de revisão é implementado como um pull request automático no Azure DevOps: o pipeline gera os YAMLs, abre o PR e o time de Data Governance revisa o diff antes do merge. Marcar reviewed: true no YAML protege o campo de qualquer sobrescrita automática subsequente.

description: "Tabela de recebíveis registrados com informações do cedente."
reviewed: true    # protegido — a IA não sobrescreve em próximas execuções
has_pii_data: true
has_confidential_data: true
columns:
  - name: "cedente_cpf"
    description: "CPF do cedente do recebível."
    has_pii_data: true
    has_confidential_data: false
    is_primary_key: false
  - name: "valor_nominal"
    description: "Valor nominal do recebível em reais."
    has_pii_data: false
    has_confidential_data: true
    is_primary_key: false

Camada 4 — Geração de Pipelines

Uma vez que uma tabela é catalogada e aprovada, a GenAI gera automaticamente o pipeline completo de ingestão — mapeamentos de tipos dos tipos nativos do sistema fonte para tipos Delta Lake, estratégias de particionamento baseadas em cardinalidade de colunas e padrões de consulta, e dicas de otimização para o ambiente Databricks alvo. O que antes exigia que um engenheiro de dados lesse o schema, mapeasse os tipos e escrevesse o pipeline manualmente agora leva minutos.

Os Resultados

O catálogo entrou em produção incrementalmente, fonte por fonte. A adoção seguiu a cobertura — à medida que mais tabelas se tornavam descobríveis e compreensíveis, mais usuários se engajavam com o Databricks pela primeira vez.

Métrica	Antes	Depois
Usuários ativos mensais no Databricks	Baseline	+400% de aumento
Adoção do Databricks na CERC	~15%	70%
Tempo de catalogação por fonte	2–3 semanas	2 dias
Efetividade do Genie data room	Baixa (metadados ruins)	Alta (metadados precisos)
Cobertura de classificação PII	Manual, incompleta	Automatizada, contínua

O número mais significativo é o de 70% de adoção. Esse não é um número sobre o catálogo — é um número sobre confiança. Quando os usuários podem encontrar dados, entender o que significam, saber quem os possui e ver que estão classificados e governados, eles os usam. O catálogo não era o destino. O self-service analytics era. O catálogo foi o que tornou o destino alcançável.

O Que Erramos: A Realidade Operacional

A arquitetura técnica não foi a parte difícil.

Construir o pipeline de descoberta e enriquecimento levou menos tempo do que antecipamos. Dataplex e Cloud Asset Inventory se integram naturalmente; o pipeline de enriquecimento com Gemini, uma vez que a engenharia de prompt foi estabilizada, roda de forma confiável. A infraestrutura não é complexa.

O fluxo de aprovação humana no loop é onde a complexidade operacional vive.

Cada descrição gerada por IA requer que um dono de dados a revise e aprove. Em 2.000 tabelas, são 2.000 decisões de aprovação distribuídas por dezenas de times com diferentes níveis de engajamento, diferentes interpretações de “bom o suficiente” e prioridades concorrentes. Alguns donos de dados aprovam rápida e completamente. Outros deixam a fila crescer. Alguns se opuseram ao conceito inteiro — não se sentiam confortáveis com uma IA gerando a descrição autoritativa de dados pelos quais eram responsáveis.

Subestimamos quanto gerenciamento de mudanças o fluxo de aprovação exigia. O sistema funciona quando os donos de dados se engajam. Quando não o fazem, as tabelas permanecem em estado pendente — tecnicamente descobertas mas não enriquecidas, o que significa que aparecem nos resultados de busca sem contexto de negócios. Uma tabela parcialmente catalogada que aparece em uma busca pode ser pior do que nenhum resultado, porque cria a impressão de cobertura sem a substância.

As lições que carregamos:

SLAs de aprovação precisam ter consequências. Sem um caminho de escalada para aprovações estagnadas, a fila enche e a promessa de cobertura do catálogo se quebra.
O engajamento varia por cultura de time, não apenas por carga de trabalho. Times com uma cultura de propriedade de dados aprovavam rapidamente. Times onde a responsabilidade pelos dados era difusa precisavam de facilitação mais ativa.
A qualidade da descrição gerada pela IA importa mais do que você espera. Quando o Gemini produzia uma descrição claramente genérica ou levemente errada, os donos de dados perdiam confiança no sistema inteiro — mesmo que a correção fosse uma única edição. A qualidade do prompt não é um nice-to-have; é a linha de base de confiança.

O Que Vem a Seguir

O catálogo está agora estável e crescendo. Nossos próximos investimentos:

Aplicação automatizada de SLA para o fluxo de aprovação — surfaceando aprovações estagnadas para líderes de time automaticamente, com caminhos de escalada
Pontuação ativa de qualidade de metadados — uma métrica por tabela que reflete cobertura, recência e status de aprovação, visível tanto para consumidores quanto para donos de dados
Expansão da geração de pipelines para lidar com evolução de schema automaticamente — hoje, mudanças de schema requerem revisão manual do pipeline gerado; isso deve ser automatizado
Expansão da adoção de Genie data rooms — o salto na qualidade dos metadados tornou o Genie significativamente mais eficaz; habilitação estruturada é o próximo alavancador

Tecnologias

Camada	Tecnologia
Descoberta de Metadados	Dataplex Universal Catalog
Mapeamento de Proprietários	Cloud Asset Inventory
Enriquecimento com IA	Gemini 2.5 Flash via Vertex AI
Classificação PII	Cloud DLP (integrado ao Dataplex)
Fontes Transacionais	Spanner, Cloud SQL (PostgreSQL, SQL Server)
Destino Analítico	Databricks (Unity Catalog, Delta Lake, Genie Data Rooms)
Geração de Pipelines	GenAI (schema-to-pipeline a partir de metadados)
Orquestração	Apache Airflow (3 DAGs diários, Data-Aware Scheduling)
Revisão Humana	Azure DevOps (pull requests automáticos)

A CERC opera a infraestrutura do mercado financeiro brasileiro para registro de recebíveis — um sistema onde qualidade de dados, governança e auditabilidade são requisitos regulatórios, não escolhas de engenharia. Se você quer trabalhar em problemas onde a plataforma de dados é o produto — estamos contratando.

Este post foi escrito pelo time de Engenharia de Dados da CERC: Davi Campos, André Tayer, Guilherme Oliveira, e Robson Sampaio.