O desafio da IA corporativa não é colocar um chatbot na frente de um modelo: é conectar esse modelo a dados confiáveis, controlar o que ele pode acessar e impedir que os custos cresçam sem previsibilidade. É nesse problema que a Databricks está apostando ao anunciar mais de R$ 1,5 bilhão em investimentos no Brasil nos próximos três anos. Para quem desenvolve sistemas, o valor do anúncio está menos no número isolado e mais na arquitetura que a empresa quer vender: dados governados, agentes com memória e acesso a modelos sem dependência de um único fornecedor.
Segundo o Xataka.com.br, os negócios da Databricks no país quase triplicaram nos últimos dois anos, e pelo menos oito das dez maiores empresas de educação, varejo, saúde e serviços financeiros listadas no Valor 1000 usam a plataforma Data + AI. Banco do Brasil, Nubank, Petrobras, Vale e iFood aparecem entre os clientes citados. Isso não prova que a plataforma seja a escolha certa para qualquer equipe, mas mostra que o problema de operar IA em escala já chegou a ambientes com sistemas legados, dados sensíveis e requisitos sérios de governança.
Por que o investimento da Databricks no Brasil importa para quem desenvolve
O anúncio também inclui a capacitação de mais de 150 mil pessoas em dados e IA nos próximos três anos e meio, além de parcerias acadêmicas, treinamentos gratuitos e mais de 300 parceiros locais no ecossistema. Esse componente importa porque uma plataforma de dados não se sustenta apenas com contratos: empresas precisam de engenheiros que saibam modelar dados, configurar permissões, monitorar pipelines e avaliar aplicações de IA.
Na minha leitura técnica, a aposta brasileira acompanha uma mudança de pergunta dentro das empresas. A discussão deixou de ser apenas “qual modelo gera a melhor resposta?” e passou a incluir “qual dado ele consultou?”, “quem autorizou o acesso?”, “como audito o resultado?” e “quanto custa cada execução?”. Sem respostas para essas perguntas, um protótipo de IA pode funcionar bem numa demonstração e falhar quando recebe dados reais e usuários reais.
Genie, Unity Gateway e Lakebase: qual problema cada ferramenta tenta resolver
Genie: perguntas em linguagem natural sobre dados empresariais
O Genie é apresentado como uma interface para que pessoas consultem dados da empresa usando linguagem natural. Em vez de escrever SQL, um usuário poderia perguntar, por exemplo, “qual foi a receita por região no último trimestre?” e receber uma resposta baseada nos dados disponíveis.
O ponto crítico não é a frase em linguagem natural. É o contexto. Para responder corretamente, o sistema precisa entender o significado de “receita”, saber qual tabela representa vendas válidas, interpretar o calendário fiscal e respeitar as permissões daquele usuário. Se esse contexto estiver espalhado por planilhas, documentação desatualizada e conhecimento informal da equipe, o modelo pode produzir uma resposta convincente e errada.
Por isso, eu trataria ferramentas desse tipo como uma camada de acesso a dados, não como substitutas de modelagem, catálogo ou validação. Métricas bem definidas e dados documentados continuam sendo trabalho de engenharia. A IA pode tornar a consulta mais acessível; não consegue inventar uma definição de negócio confiável onde a empresa nunca a estabeleceu.
Unity Gateway: controle para ambientes com vários modelos e agentes
O Unity Gateway, segundo o material divulgado, busca centralizar aspectos como uso, segurança e custos entre modelos, agentes e ferramentas de IA. Isso responde a um problema comum: equipes diferentes começam a integrar APIs de modelos por conta própria, com credenciais, limites, registros e políticas distintos.
Uma camada de gateway pode padronizar a entrada para esses serviços e facilitar auditoria e acompanhamento de consumo. Mas ela não resolve automaticamente autorização de negócio. Saber que um usuário pode chamar determinado modelo não significa que ele pode consultar qualquer tabela ou enviar dados confidenciais para qualquer provedor. A política de acesso precisa continuar conectada à identidade, à classificação dos dados e ao fluxo da aplicação.
Lakebase: Postgres serverless para aplicações e agentes
O Lakebase é descrito como um banco Postgres serverless voltado a aplicações e agentes de IA, inclusive para armazenar a memória de que eles precisam durante a execução. A escolha de Postgres é pragmática: muita gente já conhece o modelo relacional, as ferramentas de operação e o ecossistema de drivers. Para uma aplicação, isso pode ser mais simples do que criar um serviço de estado do zero.
Memória de agente, porém, não é sinônimo de histórico infinito de conversa. Em geral, convém separar estado operacional, preferências, eventos e documentos recuperáveis por busca semântica. Postgres pode armazenar metadados e estado transacional; uma estratégia de recuperação pode envolver embeddings e busca vetorial, dependendo do produto. O desenho correto depende de latência, volume, retenção e requisitos de privacidade.
Como isso se compara a outras arquiteturas de dados e IA
Databricks não é a única rota. Uma equipe pode montar uma solução com Postgres, dbt, Airflow ou outro orquestrador, um provedor de modelos e uma camada própria de permissões. Também pode usar serviços integrados de nuvem, como opções de dados e IA da AWS, Google Cloud ou Microsoft Azure, ou avaliar plataformas concorrentes como Snowflake.
A diferença prática costuma estar na integração e no custo operacional, não em uma ferramenta ser universalmente superior. Uma plataforma integrada pode reduzir o trabalho de conectar componentes e oferecer governança mais uniforme. Em contrapartida, pode ampliar dependência de um ecossistema, exigir aprendizado específico e tornar a migração mais trabalhosa. Uma pilha aberta dá liberdade para trocar partes, mas a equipe passa a manter mais integrações e políticas.
- Databricks: faz sentido avaliar quando lakehouse, engenharia de dados e IA precisam operar próximos, e quando governança centralizada é prioridade.
- Postgres e ferramentas abertas: podem ser suficientes para produtos menores ou equipes que querem controle granular e já têm capacidade de operação.
- Serviços gerenciados de nuvem: podem simplificar a adoção dentro de uma nuvem já padronizada, mas vale conferir limites, custos de saída e integração com dados fora dela.
- Plataformas concorrentes de dados: devem ser comparadas com cargas de trabalho reais, não apenas por uma demonstração de consulta ou benchmark isolado.
Eu compararia soluções com um teste representativo: uma pergunta de negócio ambígua, um usuário com acesso restrito, dados atualizados em horários diferentes e um limite de custo por execução. Esse teste revela mais do que uma apresentação comercial, porque expõe problemas de semântica, permissão, latência e observabilidade.
Na Prática: persistindo memória de agente em Postgres
Este exemplo mostra uma parte pequena, mas real, de uma aplicação: salvar um estado JSON por empresa e sessão. Ele usa Psycopg 3 e funciona com PostgreSQL compatível, incluindo um serviço Postgres gerenciado. Não é uma integração específica com uma API proprietária do Lakebase; é um padrão que ajuda a separar a lógica da aplicação do fornecedor do banco.
- Crie uma tabela com chave composta para separar sessões por organização.
- Use parâmetros SQL, em vez de concatenar valores recebidos do usuário.
- Atualize o estado com upsert para que a primeira gravação e as seguintes usem a mesma operação.
- Carregue a conexão por variável de ambiente e configure TLS conforme os requisitos do serviço utilizado.
import os
import psycopg
from psycopg.types.json import Jsonb
DATABASE_URL = os.environ["DATABASE_URL"]
def save_agent_memory(tenant_id: str, session_id: str, memory: dict) -> None:
with psycopg.connect(DATABASE_URL) as conn:
conn.execute("""
CREATE TABLE IF NOT EXISTS agent_memory (
tenant_id TEXT NOT NULL,
session_id TEXT NOT NULL,
memory JSONB NOT NULL DEFAULT '{}'::jsonb,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
PRIMARY KEY (tenant_id, session_id)
)
""")
conn.execute("""
INSERT INTO agent_memory (tenant_id, session_id, memory)
VALUES (%s, %s, %s)
ON CONFLICT (tenant_id, session_id)
DO UPDATE SET
memory = EXCLUDED.memory,
updated_at = now()
""", (tenant_id, session_id, Jsonb(memory)))
save_agent_memory(
tenant_id="empresa-42",
session_id="sessao-abc",
memory={"idioma": "pt-BR", "filtros": {"regiao": "Sul"}}
)Esse exemplo é deliberadamente simples. Em produção, eu acrescentaria política de retenção, limites de tamanho, validação do conteúdo e observabilidade. Também verificaria se o identificador da empresa vem de uma identidade autenticada e confiável; não se deve aceitar um tenant_id arbitrário enviado pelo cliente e presumir que isso isola os dados.
Erros comuns ao colocar IA corporativa em produção
- Tratar linguagem natural como garantia de correção. A resposta pode soar segura mesmo quando a métrica ou a consulta está errada. Valide resultados importantes contra consultas e regras conhecidas.
- Deixar a autorização só no prompt. Instruções para o modelo não substituem controles de acesso no banco, na API e na camada de identidade. A aplicação deve bloquear acessos não autorizados antes de enviar dados ao modelo.
- Guardar todo o histórico sem política de retenção. Isso aumenta custo, risco de exposição e ruído no contexto. Defina o que precisa ser lembrado, por quanto tempo e com qual finalidade.
- Confundir gateway com governança completa. Centralizar chamadas ajuda, mas ainda é necessário classificar dados, controlar permissões e registrar decisões relevantes.
- Ignorar custo por fluxo. Uma chamada pode acionar busca, modelo, ferramentas externas e novas chamadas. Meça custo por tarefa ou usuário, não apenas o gasto agregado mensal.
- Começar escolhendo a ferramenta antes do caso de uso. Defina primeiro a tarefa, os dados necessários, o nível de risco e o resultado esperado. Depois compare plataformas com os mesmos critérios.
O que essa aposta pode significar para o mercado brasileiro
Se a promessa de capacitar mais de 150 mil pessoas se converter em profissionais preparados, o investimento pode ampliar a oferta de gente capaz de operar projetos de dados e IA — uma necessidade que frequentemente limita a adoção mais do que a falta de modelos. A presença de mais de 300 parceiros locais também pode facilitar implantação e suporte, embora a qualidade de cada projeto continue dependendo de arquitetura, escopo e execução.
Para desenvolvedores, o recado prático é acompanhar a camada de dados e governança com a mesma atenção que damos aos modelos. Saber integrar uma API de IA é útil; saber controlar acesso, custo, qualidade dos dados, estado da aplicação e avaliação de respostas é o que separa um protótipo de um serviço confiável. Eu avaliaria a Databricks, ou qualquer alternativa, por esses critérios e por uma prova de conceito ligada a um fluxo real da empresa.
Perguntas frequentes sobre Databricks, Lakebase e IA corporativa
O que é o Lakebase da Databricks?
É um banco Postgres serverless apresentado pela Databricks para atender aplicações e agentes de IA. Entre os usos possíveis está guardar estado e memória operacional, mas a arquitetura deve definir também retenção, segurança e separação entre clientes.
O Genie substitui analistas de dados ou SQL?
Não. Ele pode facilitar perguntas em linguagem natural, mas depende de dados organizados, métricas bem definidas e permissões corretas. SQL e análise continuam necessários para validar consultas e investigar resultados ambíguos.
O Unity Gateway impede vazamento de dados?
Não por si só. Uma camada de controle pode ajudar a aplicar políticas e acompanhar o uso de modelos, mas a prevenção depende de identidade, autorização, classificação dos dados e controles implementados no sistema completo.
Uma equipe pequena precisa da plataforma Databricks?
Nem sempre. Para uma aplicação simples, Postgres e serviços gerenciados podem ser suficientes. A plataforma ganha relevância quando a equipe precisa integrar engenharia de dados, governança e cargas de IA em escala; a decisão deve considerar custo total e esforço de operação.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.