Agentes de IA nativos de dados: por que os agentes precisam ir até os seus dados

A maioria dos pilotos de AI corporativos supera a mesma barreira simples: conectar um LLM aos seus dados, adicionar um banco de dados vetorial e fazer uma demonstração para a liderança. A parte difícil vem depois. A segurança sinaliza as falhas de governança. A latência em agentes de várias etapas destrói a experiência do usuário. A conta do seu provedor de modelos não para de subir. Esses problemas geralmente se originam de uma única decisão: extrair dados de sistemas governados e levá-los para uma pilha de AI que nunca foi criada para aplicar suas políticas.

Este post defende uma direção de arquitetura diferente: mover os modelos e agentes para os dados, e não o contrário. Em vez de criar uma infraestrutura de AI paralela e conectá-la de volta ao seu lakehouse, você trata os agentes como cargas de trabalho nativas que são executadas dentro da sua plataforma de dados, sob os mesmos controles de governança, segurança e observabilidade em que você já confia para seus dados.

O lakehouse ofereceu a você um único lugar para governar seus dados. A próxima questão é se seus agentes vivem dentro ou fora desse limite. Existem dois paradigmas emergentes.

Agentes externos

Agentes e LLMs são executados em uma pilha de AI separada. Os dados são exportados ou consultados pela rede em bancos de dados vetoriais externos, SaaS LLMs ou camadas de serviço personalizadas. Governança, segurança e observabilidade são reimplementadas para a AI de forma paralela.

Agentes nativos de dados

Agentes, modelos, ferramentas, recuperação e memória de agentes são executados dentro da mesma plataforma que os próprios dados, sob uma camada unificada de governança e segurança. A AI se torna mais uma carga de trabalho na sua pilha de dados existente.

O custo oculto dos agentes externos

Os dados têm gravidade. A computação é barata de realocar; os dados não, especialmente à medida que os volumes crescem e as modalidades se multiplicam. Extraí-los introduz um conjunto familiar de penalidades:

• A governança enfraquece. Reimplementar o controle de acesso, a linhagem e a residência de dados em cada integração deixa lacunas que as auditorias encontram.
• A latência se acumula. Cada salto para um repositório vetorial externo, LLM e de volta se soma em agentes de várias ferramentas.
• Os custos se fragmentam. Saída de dados (egress), armazenamento duplicado e preços por token entre diferentes fornecedores afetam o orçamento de três direções.
• O ciclo de vida se torna uma coordenação de fornecedores. Esquemas, índices e modelos sofrem desvios (drift) entre sistemas que não compartilham um pipeline de implantação.
• A observabilidade se fragmenta. Rastrear uma solicitação de ponta a ponta significa juntar logs de três ou quatro ferramentas.
• O contexto de negócios fica para trás. Definições de métricas, glossário de negócios e agrupamentos de domínio vivem na sua camada de governança; um agente externo os reconstrói a partir de nomes de colunas ou por adivinhação.

Por que a governança a posteriori falha para agentes

De todas essas penalidades, a governança merece atenção especial porque é a única que não pode ser corrigida depois do fato. A maioria das abordagens de governança de AI a trata como um filtro aplicado depois que o agente já acessou os dados, por exemplo, ocultando campos confidenciais da resposta, bloqueando certos tópicos na camada de saída e auditando logs após o ocorrido. Isso funciona para demonstrações simples de Q&A. Mas falha no momento em que os agentes começam a computar dados.

Considere um agente que calcula um resumo financeiro em linhas sujeitas à segurança em nível de linha (row-level security). A agregação em si (a soma, a média, a tendência) é um valor derivado que é moldado por quais linhas são incluídas. Se a governança não for aplicada antes da execução da consulta, o resultado já codificará dados que o usuário não deveria ter influenciado. Nenhuma ocultação posterior pode desfazer esse cálculo. A decisão de política precisava acontecer no momento do planejamento da consulta, não no momento da renderização da resposta.

Essa é a lacuna fundamental na governança baseada em perímetro ou a posteriori: ela assume que os dados podem ser censurados com segurança após chegarem ao agente. Na prática, uma vez que uma agregação ou transformação ocorreu, a intenção de governança já foi perdida. Controles retroativos são fundamentalmente incompletos.

Há um segundo custo em errar nisso, e ele aparece na conta. O problema não é apenas o que o agente tem permissão para acessar, embora isso faça parte. Quando a governança é resolvida após o fato em vez de na origem, o agente acaba fazendo a reconciliação por conta própria: percorrendo logs de auditoria, unindo fragmentos em sistemas externos, extraindo o mesmo registro de vários lugares para descobrir se pode usá-lo, raciocinando novamente sobre cada resultado parcial. Nada disso é a tarefa dele. É o agente compensando uma resposta governada que nunca foi entregue de antemão. Saídas bloqueadas ou ocultadas apenas alimentam a espiral, já que o agente as interpreta como falhas e tenta novamente. As sessões se prolongam, cada salto carrega mais contexto no modelo e uma única solicitação silenciosamente se transforma em milhares de tokens cobrados. Esse é o ciclo de queima de tokens, e a governança a posteriori é o que o faz girar.

Os agentes nativos de dados enfrentam esses desafios incorporando a aplicação de políticas diretamente no planejamento e na computação de consultas. Cada resultado intermediário reflete as mesmas restrições de governança. A governança deve ser avaliada antes e durante a execução, algo que você não pode se dar ao luxo de aplicar como uma reflexão tardia após a conclusão da computação. Os Custom Guardrails no Unity AI Gateway são a forma concreta disso: políticas combináveis e determinísticas que o gateway aplica a cada solicitação e resposta, e não filtros que o modelo deve obedecer após o fato. Decidir a política no momento do planejamento, em relação a dados que já vivem em um único local governado, também significa que o agente obtém uma resposta limpa em uma única passagem, em vez de explorar diversos sistemas para montar ou justificar uma.

O estado e a memória do agente precisam de governança

Até agora, focamos em como os agentes leem dados. Mas os agentes em produção também escrevem: histórico de conversas, progresso de tarefas, preferências do usuário, resultados em cache e saídas de ferramentas para auditoria posterior. À medida que os agentes assumem mais funções, a camada de estado importa tanto quanto a camada de dados. Deixe-a fora do limite de governança e toda promessa de auditabilidade de ponta a ponta terá uma falha.

O estado é o rascunho de curto prazo do agente: a conversa ativa, a tarefa em andamento, o cache que ele acabou de preencher. A memória é o que sobrevive à sessão: com quais clientes um agente lidou, o que um usuário prefere, quais saídas anteriores valem a pena reutilizar. Ambos precisam de armazenamento transacional e ambos perdem governança no momento em que saem da plataforma. Uma memória como "o usuário X é um cliente da EU de alto valor" é, por si só, um dado confidencial, sujeito às mesmas regras de acesso e residência que o registro que ela resume. E é uma carga de trabalho transacional: as tabelas Delta são criadas para grandes varreduras analíticas, mas o estado do agente precisa de leituras e gravações rápidas por linha, buscas por chave e atualizações atômicas.

A solução alternativa comum é um Postgres ou Redis externo. Mas isso traz você de volta ao problema contra o qual este post argumenta: o estado do agente sai do perímetro governado para um sistema que sua camada de governança não consegue ver, com sua própria segurança e ciclo de vida para gerenciar. Você criou um agente nativo de dados com uma dependência não governada.

E o problema cresce no momento em que um agente se torna muitos. Um enxame trabalhando em direção a um resultado maior (um planejador delegando para especialistas, um supervisor reconciliando seus resultados) precisa de memória compartilhada, e manter o alinhamento nela é onde esses sistemas falham. Quando cada agente mantém um estado privado e passa o contexto ponto a ponto (peer-to-peer), não há uma única fonte da verdade. Os agentes divergem, as gravações colidem e cada transferência é mais um canal não governado que se multiplica à medida que o enxame cresce. Compartilhar memória acaba sendo a parte difícil.

O Lakebase fecha essas lacunas. É um armazenamento PostgreSQL totalmente gerenciado dentro da plataforma Databricks, sob o mesmo plano de governança que todo o resto. O estado do agente se torna um ativo governado: ele herda os controles de acesso da plataforma, vive ao lado dos dados e ferramentas do agente e não precisa de uma equipe de infraestrutura separada. E como cada agente lê e escreve nessa mesma camada transacional, ela funciona também como a única fonte da verdade do enxame. O estado permanece consistente, atualizações atômicas evitam que dois agentes corrompam a mesma tarefa, uma política na visualização de um agente é transferida para o que quer que ele escreva para o próximo, e qualquer memória pode ser rastreada pelo enxame: qual agente a escreveu, qual a leu, como uma conclusão profunda chega à sua origem.

Os argumentos a favor dos agentes nativos de dados

O argumento da governança é o mais forte, mas as vantagens vão além. Quando os agentes são executados dentro da pilha de dados, as vantagens se acumulam em todas as dimensões operacionais: segurança, qualidade, observabilidade, implantação, latência e custo. Ferramentas e dependências de dados são configuradas e registradas junto com o modelo, de modo que todo o sistema é versionado, auditável e reproduzível por padrão.

A comparação a seguir resume como esses dois paradigmas diferem nas dimensões que mais importam para sistemas em produção:

Como os agentes nativos de dados realmente se parecem no Databricks

A Data Intelligence Platform coloca isso em prática. Em vez de criar uma "stack de IA" separada e conectá-la aos seus dados, você cria agentes de IA dentro da própria stack de dados. Um agente nativo de dados no Databricks é aquele que:

• Roteia todo o tráfego de modelos e agentes pelo Unity AI Gateway, onde cada solicitação é verificada antes da execução e cada resposta é inspecionada depois, com políticas determinísticas de ALLOW / DENY / ASK substituindo a filtragem de melhor esforço após o fato. O controle de acesso, a limitação de taxa, o log de payload e o rastreamento de custos residem no mesmo plano de controle, incluindo chamadas para provedores externos de LLM e agentes de codificação.
• Trata cada primitiva de IA (modelos, agentes, MCPs, habilidades e as ferramentas que eles chamam) como um ativo do Unity Catalog ao lado de tabelas e funções, de modo que a identidade, a linhagem e os controles de acesso se apliquem uniformemente a toda a superfície de IA.
• Captura rastreamentos completos de solicitações por meio do MLflow 3: cada chamada de LLM, invocação de ferramenta, pontuações, avaliações (evals), documentos recuperados e loop de monitoramento de ponta a ponta tornam-se auditáveis para conformidade e observáveis para depuração.
• Executa a inferência dentro do seu perímetro de segurança do Databricks no Model Serving, sem movimentação não governada de dados para stacks de IA de terceiros.
• Recupera o contexto de índices baseados em Delta que respeitam as ACLs do Unity Catalog e rastreiam automaticamente a linhagem, com tecnologia do AI Search.
• Lembra-se das informações entre as sessões por meio de estado e memória baseados no Lakebase: o contexto de conversa de curto prazo, o progresso de tarefas de várias etapas, as preferências do usuário de longo prazo e a recordação episódica de chamadas de ferramentas anteriores residem ao lado dos dados sobre os quais o agente raciocina.
• Fundamenta o raciocínio em um contexto de negócios por meio do Unity Catalog Semantics (Métricas, Glossário de Negócios, Domínios) e da Ontologia do Genie, um gráfico de conhecimento mantido automaticamente e extraído das tabelas, consultas, dashboards e aplicativos que a equipe já usa.
• Delega o raciocínio especializado a outros agentes, incluindo o Genie para perguntas sobre dados estruturados, com coordenação de várias etapas e domínios cruzados dentro do limite da plataforma.
• Estende a mesma governança para agentes de codificação por meio do Omnigent, um meta-harness que roteia o Claude Code, o Codex e o Cursor pelo Unity AI Gateway com sessões compartilhadas e uma trilha de auditoria comum.

Por onde começar

Algumas empresas já estão desenvolvendo dessa forma. Seus agentes são executados dentro do mesmo limite que seus dados, com políticas do Unity Catalog cobrindo ambos, estado no Lakebase e tráfego pelo Unity AI Gateway. Nenhuma delas chegou lá com um único projeto de migração de plataforma. Elas eliminaram a barreira entre o lakehouse e a stack de IA um piloto de cada vez, e depois pararam de abrir novos.

Para as equipes que estão no início do caminho, o trabalho não é drástico. A maioria das peças já existe no lado da plataforma: Model Serving, Unity Catalog, Lakebase, MLflow. O que falta é a decisão de tratá-los como o lar do agente, em vez de apenas fontes de dados para uma stack paralela. Essa decisão costuma ser a parte mais difícil.

O ponto de partida mais útil é um inventário do que já está em execução fora do perímetro. É daí que virá o próximo incidente de governança, e esse é o trabalho que torna todo o resto possível.

Se você quiser se aprofundar em como operacionalizar agentes nativos de dados com as proteções e os padrões corretos, estes recursos são um ótimo próximo passo:

• Para traduzir a estratégia em controles concretos, leia Um framework prático de governança de IA para empresas, que mostra como transformar objetivos de alto nível em funções, políticas e fluxos de trabalho na Databricks Data Intelligence Platform.
• Para uma visão mais ampla da IA responsável na prática, Melhores práticas de governança de IA: como criar programas de IA responsáveis e eficazes apresenta princípios e modelos operacionais que você pode adotar em todas as equipes.

Para explorar os recursos da plataforma discutidos nesta publicação:

• Unity AI Gateway: novidades no Data + AI Summit 2026 — um único plano de controle para todo o tráfego de modelos e agentes, com Custom Guardrails determinísticas de ALLOW/DENY/ASK.
• Agent Bricks: Data + AI Summit 2026 — agentes otimizados automaticamente fornecidos como cargas de trabalho governadas de primeira classe na plataforma.
• Omnigent: um meta-harness para combinar, controlar e compartilhar seus agentes — roteia agentes de codificação (Claude Code, Codex, Cursor) pelo Unity AI Gateway com uma trilha de auditoria compartilhada.
• Apresentando o Genie One, Genie Agents e Genie Ontology — o gráfico de conhecimento mantido automaticamente que fundamenta os agentes no seu contexto de negócios.
• Escalonamento de memória para agentes de IA — como o estado e a memória do agente são escalonados no Lakebase, governados pelo Unity Catalog dentro da plataforma.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original