As equipes de dados corporativos que movem a IA de agente para a produção estão atingindo um ponto de falha consistente na camada de dados. Os agentes construídos em um armazenamento vetorial, um banco de dados relacional, um armazenamento gráfico e um lakehouse exigem pipelines de sincronização para manter o contexto atualizado. Sob carga de produção, esse contexto fica obsoleto.
A Oracle, cuja infra-estrutura de bases de dados gere os sistemas de transacções de 97% das empresas Fortune Global 100, segundo a própria contagem da empresa, está agora a apresentar um argumento arquitectónico directo de que a base de dados é o local certo para resolver esse problema.
A Oracle anunciou esta semana um conjunto de recursos de IA agente para Oracle AI Databaseconstruído em torno de um contra-argumento arquitetônico direto para esse padrão.
O núcleo da versão é o Unified Memory Core, um único mecanismo transacional ACID (Atomicidade, Consistência, Isolamento e Durabilidade) que processa dados vetoriais, JSON, gráficos, relacionais, espaciais e colunares sem uma camada de sincronização. Além disso, a Oracle anunciou Vectors on Ice para indexação de vetores nativos em tabelas Apache Iceberg, um serviço autônomo de banco de dados de vetores de IA autônomo e um servidor MCP de banco de dados de IA autônomo para acesso direto do agente sem código de integração personalizado.
A notícia não é apenas que a Oracle está adicionando novos recursos, é sobre o maior fornecedor de banco de dados do mundo perceber que as coisas mudaram no mundo da IA que vão além do que seu banco de dados homônimo fornecia.
“Por mais que eu adorasse dizer que hoje todo mundo armazena todos os seus dados em um banco de dados Oracle – você e eu vivemos no mundo real”, disse Maria Colgan, vice-presidente de gerenciamento de produtos para dados de missão crítica e mecanismos de IA, da Oracle. VentureBeat. “Sabemos que isso não é verdade.”
Quatro capacidades, uma aposta arquitetônica contra a pilha de agentes fragmentada
O lançamento da Oracle abrange quatro recursos interconectados. Juntos, eles formam o argumento arquitetônico de que um mecanismo de banco de dados convergente é uma base melhor para a IA de agente de produção do que uma pilha de ferramentas especializadas.
Núcleo de memória unificado. Os agentes que raciocinam em vários formatos de dados simultaneamente — vetorial, JSON, gráfico, relacional, espacial — exigem pipelines de sincronização quando esses formatos residem em sistemas separados. O Unified Memory Core coloca todos eles em um único mecanismo transacional ACID. Nos bastidores, há uma camada de API sobre o mecanismo de banco de dados Oracle, o que significa que a consistência ACID se aplica a todos os tipos de dados sem um mecanismo de consistência separado. “Ao ter a memória no mesmo local que os dados, podemos controlar o que ela tem acesso da mesma forma que controlaríamos os dados dentro do banco de dados”, explicou Colgan.
Vetores no gelo. Para equipes que executam arquiteturas de data lakehouse no formato de tabela de código aberto Apache Iceberg, a Oracle agora cria um índice vetorial dentro do banco de dados que faz referência direta à tabela Iceberg. O índice é atualizado automaticamente à medida que os dados subjacentes mudam e funciona com tabelas Iceberg gerenciadas por Databricks e Snowflake. As equipes podem combinar a pesquisa vetorial Iceberg com dados relacionais, JSON, espaciais ou gráficos armazenados no Oracle em uma única consulta.
Banco de dados autônomo de vetores de IA. Um serviço de banco de dados vetorial totalmente gerenciado e gratuito, criado no mecanismo Oracle 26ai. O serviço foi projetado como um ponto de entrada do desenvolvedor com um caminho de atualização com um clique para o Autonomous AI Database completo quando os requisitos de carga de trabalho aumentam.
Servidor MCP de banco de dados de IA autônomo. Permite que agentes externos e clientes MCP se conectem ao Autonomous AI Database sem código de integração personalizado. Os controles de acesso em nível de linha e em nível de coluna da Oracle se aplicam automaticamente quando um agente se conecta, independentemente do que o agente solicitar. “Mesmo que você esteja fazendo a mesma chamada de API padrão que faria com outras plataformas, os privilégios desse usuário continuaram a aparecer quando o LLM está fazendo essas perguntas”, disse Colgan.
Bancos de dados vetoriais independentes são um ponto de partida, não um destino
O Autonomous AI Vector Database da Oracle entra em um mercado ocupado por serviços de vetores desenvolvidos especificamente, incluindo Pinecone, Qdrant e Weaviate. A distinção que a Oracle está traçando é sobre o que acontece quando o vetor por si só não é suficiente.
“Depois de terminar com os vetores, você realmente não tem opção”, disse Steve Zivanic, vice-presidente global de banco de dados e serviços autônomos, marketing de produtos da Oracle, ao VentureBeat. “Com isso, você pode obter séries gráficas, espaciais, temporais – tudo o que precisar. Não é um beco sem saída.”
Holger Mueller, analista principal da Constellation Research, disse que o argumento arquitetônico é confiável precisamente porque outros fornecedores não conseguem fazê-lo sem primeiro mover os dados. Outros fornecedores de bancos de dados exigem que os dados transacionais sejam transferidos para um data lake antes que os agentes possam raciocinar sobre eles. O legado convergente da Oracle, na sua opinião, confere-lhe uma vantagem estrutural que é difícil de replicar sem uma reconstrução completa.
Nem todo mundo vê o conjunto de recursos como diferenciado. Steven Dickens, CEO e analista principal da HyperFRAME Research, disse VentureBeat que a pesquisa vetorial, a integração RAG e o suporte ao Apache Iceberg agora são requisitos padrão em bancos de dados corporativos – Postgres, Snowflake e Databricks oferecem recursos comparáveis.
“A decisão da Oracle de rotular o próprio banco de dados como um banco de dados de IA é principalmente uma reformulação de sua estratégia de banco de dados convergente para corresponder ao atual ciclo de hype”, disse Dickens. Na sua opinião, a verdadeira diferenciação que a Oracle está reivindicando não está no nível dos recursos, mas no nível da arquitetura – e o Unified Memory Core é onde esse argumento se mantém ou desmorona.
Onde as implantações de agentes corporativos realmente falham
Os quatro recursos que a Oracle lançou esta semana são uma resposta a um modo de falha de produção específico e bem documentado. As implantações de agentes corporativos não estão sendo interrompidas na camada de modelo. Eles estão quebrando na camada de dados, onde os agentes construídos em sistemas fragmentados atingem a latência de sincronização, o contexto obsoleto e o acesso inconsistente controlam o momento em que as cargas de trabalho aumentam.
Matt Kimball, vice-presidente e analista principal da Moor Insights and Strategy, disse VentureBeat a camada de dados é onde as restrições de produção surgem primeiro.
“A dificuldade é colocá-los em produção”, disse Kimball. “A lacuna é vista quase imediatamente na camada de dados: acesso, governança, latência e consistência. Tudo isso se torna uma restrição.”
Dickens enquadra a incompatibilidade central como um problema sem estado versus com estado. A maioria das estruturas de agentes corporativos armazena memória como uma lista simples de interações passadas, o que significa que os agentes são efetivamente sem estado, enquanto os bancos de dados que eles consultam têm estado. A defasagem entre os dois é onde as decisões dão errado. “As equipes de dados estão exaustas pela fadiga da fragmentação”, disse Dickens. “Gerenciar um armazenamento de vetores separado, um banco de dados gráfico e um sistema relacional apenas para alimentar um agente é um pesadelo de DevOps.”
Essa fragmentação é precisamente o que o Unified Memory Core da Oracle foi projetado para eliminar. A questão do plano de controle segue diretamente. “Em um modelo de aplicativo tradicional, o controle reside na camada do aplicativo”, disse Kimball. “Com sistemas de agentes, o controle de acesso é interrompido rapidamente porque os agentes geram ações dinamicamente e precisam de aplicação consistente de políticas. Ao empurrar todo esse controle para o banco de dados, tudo pode ser aplicado de maneira mais uniforme.”
O que isso significa para as equipes de dados empresariais
A questão de onde reside o controle em uma pilha de IA de agente empresarial não foi resolvida. A maioria das organizações ainda está construindo sistemas fragmentados, e as decisões arquitetônicas que estão sendo tomadas agora – qual mecanismo ancora a memória do agente, onde os controles de acesso são aplicados, como os dados do lakehouse são puxados para o contexto do agente – serão difíceis de desfazer em escala.
O desafio dos dados distribuídos ainda é o verdadeiro teste. “Os dados são cada vez mais distribuídos em plataformas SaaS, lakehouses e sistemas orientados a eventos, cada um com seu próprio plano de controle e modelo de governança”, disse Kimball. “A oportunidade agora é estender esse modelo aos conjuntos de dados mais amplos e distribuídos que definem a maioria dos ambientes empresariais atuais”.
