A Oracle acaba de tornar concreta a sua resposta à pergunta da IA corporativa: parar de enxertar sistemas de IA separados em ERP e CRM e transformar o próprio banco de dados no lugar onde os agentes são construídos, lembrados e executados. A empresa chama a metodologia envolvente de AIBS, AI Business Success, e aplica um teste de três portões a cada projeto: o trabalho precisa chegar à produção, gerar receita ou redução de custos mensuráveis e ser replicável. Essa é uma resposta rara e explícita à pergunta mais embaraçosa do setor: cadê o ROI?
O banco de dados deixa de ser um armazém
O Oracle AI Database 26ai é a base. Ele é multimodelo, ou seja, tabelas relacionais, JSON, vetores e dados de grafo vivem em um único motor — e o tipo grafo importa mais do que parece. Em um cenário de fábrica, quando aparece um defeito em um produto, um agente pode percorrer as relações de negócio para rastrear se a falha veio de uma etapa do processo, de uma máquina ou da matéria-prima, em vez de ter todas as regras fixadas no código da aplicação.
Sobre essa base, a Oracle está impulsionando três capacidades voltadas a agentes:
- Agent Memory — memória de longo e curto prazo armazenada no banco de dados, com upload de documentos, chunking, embedding e geração aumentada por recuperação, tudo executado dentro do banco.
- Agentes construídos com SQL — o Select AI Agent permite que equipes construam agentes por meio de SQL para dados que já residem na Oracle, chamando modelos e ferramentas externos e coordenando múltiplos agentes.
- Private Agent Factory — um caminho sem código para montar agentes sem mover os dados para fora.
A Oracle também suporta o MCP (Model Context Protocol), de modo que operações e administração do banco em linguagem natural se tornam acionáveis por agentes. Isso coloca a Oracle em uma trilha de evolução rápida: o próprio MCP está evoluindo para gateways stateless, e os fornecedores de banco de dados que o adotarem cedo poderão definir como os agentes conversam com os dados corporativos.
Para onde vão o processamento e a segurança
Agentes dentro do banco de dados levantam duas questões operacionais: onde a inferência é executada e quem controla o acesso?
Quanto ao processamento, a Oracle pressupõe um futuro híbrido, com modelos públicos e modelos privados ou locais coexistindo. O Private Services Container descarrega de forma transparente cargas de trabalho de IA para nós dedicados capazes de executar modelos privados, para que o servidor do banco de dados não sofra com picos de inferência.
Quanto à segurança, a fronteira se desloca para baixo. Agentes e ferramentas de IA geram SQL e código dinamicamente, o que amplia a superfície de ataque do banco de dados muito além do que uma camada de aplicação consegue fiscalizar. A resposta da Oracle tem três partes: o Deep Data Security vincula usuários finais a controles refinados no lado do banco; um firewall embutido no banco inspeciona padrões e regras de SQL antes de permitir o acesso; e o ritmo de patches acelerou de trimestral para mensal, com recuperação sem perda de dados para cenários de ransomware.
Multi-cloud como produto, não como cabo
No lado da infraestrutura, a OCI se posiciona como um hub de conectividade, e não apenas uma linha de rede. A Oracle mantém interconexões diretas com Azure, Google Cloud e AWS, com taxas de egresso isentadas nas direções do GCP e da AWS. A precificação de egresso há muito é a alavanca silenciosa de lock-in das plataformas de nuvem, cobrando o movimento de dados entre nuvens como se fosse um pedágio. Ao transformar o roteamento multi-cloud em um serviço gerenciado com uma interface unificada de suporte, a Oracle mira as cargas de trabalho entre nuvens que antes eram tecnicamente possíveis, mas impossíveis no orçamento.
O que isso realmente sinaliza
Removendo os nomes de produtos, a verdadeira afirmação é estrutural: o centro de gravidade da IA corporativa está se deslocando do modelo para a plataforma de dados. A aposta da Oracle é que agentes são menos parecidos com aplicações e mais com novos funcionários: precisam de memória, permissões e um entendimento compartilhado do negócio. O banco de dados é onde os três já vivem.
Duas consequências se seguem. Primeiro, a escolha do modelo se torna um componente substituível: se a camada semântica e a memória vivem no banco de dados, trocar de um modelo para outro é uma mudança de configuração, não uma rearquitetura. Segundo, os três portões do AIBS reposicionam discretamente como as empresas devem avaliar projetos de IA — produção, resultado mensurável, replicabilidade — um filtro que eliminaria a maioria dos proofs of concept de hoje.
O que fazer com isso
- Se você financia ou aprova projetos de IA: aplique o teste dos três portões antes do primeiro real. Um projeto que não consegue nomear seu ambiente de produção, seu resultado mensurável e seu caminho de replicação não está pronto.
- Se você é arquiteto: audite se sua plataforma de dados pode hospedar memória de agentes e agentes construíveis via SQL. As equipes que já mantêm sua camada semântica próxima aos dados adotarão agentes mais rápido.
- Se você está escolhendo um stack: trate o suporte a MCP e o roteamento híbrido de modelos como o mínimo indispensável, porque ambos estão se tornando critérios de aquisição.
