Los equipos de datos empresariales que trasladan la IA del agente a la producción están llegando a un punto constante de falla en la capa de datos. Los agentes creados sobre un almacén de vectores, una base de datos relacional, un almacén de gráficos y una casa del lago requieren canales de sincronización para mantener el contexto actualizado. Bajo carga de producción, este contexto se vuelve obsoleto.
Oracle, cuya infraestructura de base de datos ejecuta los sistemas de transacciones del 97% de las empresas Fortune Global 100 según el propio recuento de la empresa, ahora está presentando un argumento arquitectónico sencillo de que la base de datos es el lugar adecuado para resolver este problema.
Oracle anunció esta semana un conjunto de Capacidades de IA de la agencia para Oracle AI Databaseconstruido alrededor de un contraargumento arquitectónico directo a este patrón.
El núcleo del lanzamiento es Unified Memory Core, un único motor transaccional ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) que procesa datos vectoriales, JSON, gráficos, relacionales, espaciales y en columnas sin una capa de sincronización. Además, Oracle anunció Vectors on Ice para la indexación de vectores nativos en tablas Apache Iceberg, un servicio de base de datos de vectores de IA independiente y un servidor MCP de base de datos de IA independiente para acceso directo de agentes sin código de integración personalizado.
La noticia no es solo que Oracle esté agregando nuevas funciones, sino que el proveedor de bases de datos más grande del mundo se da cuenta de que las cosas han cambiado en el mundo de la IA y van más allá de lo que proporcionaba la base de datos del mismo nombre.
“Por mucho que me encantaría decir que hoy en día todo el mundo almacena todos sus datos en una base de datos de Oracle, usted y yo vivimos en el mundo real”, dijo Maria Colgan, vicepresidenta de gestión de productos para datos de misión crítica y motores de IA de Oracle. VentureBeat. “Sabemos que eso no es cierto”.
Cuatro capacidades, una apuesta arquitectónica contra el stack de agentes fragmentado
El lanzamiento de Oracle abarca cuatro características interconectadas. Juntos, plantean el argumento arquitectónico de que un motor de base de datos convergente es una mejor base para la IA del agente de producción que una pila de herramientas especializadas.
Núcleo de memoria unificada. Los agentes que razonan en múltiples formatos de datos simultáneamente (vectoriales, JSON, gráficos, relacionales, espaciales) requieren canales de sincronización cuando estos formatos residen en sistemas separados. El Unified Memory Core los coloca a todos en un único motor transaccional ACID. Detrás de escena, hay una capa API encima del motor de base de datos Oracle, lo que significa que la coherencia ACID se aplica a todos los tipos de datos sin un mecanismo de coherencia independiente. “Al tener la memoria en la misma ubicación que los datos, podemos controlar a qué tiene acceso de la misma manera que controlaríamos los datos dentro de la base de datos”, explicó Colgan.
Vectores sobre hielo. Para los equipos que ejecutan arquitecturas de lago de datos en el formato de tabla de código abierto Apache Iceberg, Oracle ahora crea un índice vectorial dentro de la base de datos que hace referencia directamente a la tabla Iceberg. El índice se actualiza automáticamente a medida que cambian los datos subyacentes y funciona con tablas Iceberg administradas por Databricks y Snowflake. Los equipos pueden combinar la búsqueda de vectores Iceberg con datos relacionales, JSON, espaciales o gráficos almacenados en Oracle en una sola consulta.
Base de datos de vectores de IA autónoma. Un servicio de base de datos vectorial gratuito y totalmente administrado construido sobre el motor Oracle 26ai. El servicio está diseñado como un punto de entrada para desarrolladores con una ruta de actualización con un solo clic a la base de datos autónoma de IA completa cuando aumentan los requisitos de carga de trabajo.
Servidor MCP de base de datos de IA independiente. Permite que agentes externos y clientes MCP se conecten a la base de datos autónoma de AI sin un código de integración personalizado. Los controles de acceso a nivel de fila y columna de Oracle se aplican automáticamente cuando un agente se conecta, independientemente de lo que solicite el agente. “Aunque esté realizando la misma llamada API estándar que haría con otras plataformas, los privilegios de ese usuario continúan apareciendo cuando LLM hace estas preguntas”, dijo Colgan.
Las bases de datos vectoriales independientes son un punto de partida, no un destino
La base de datos autónoma de vectores de IA de Oracle ingresa a un mercado ocupado por servicios vectoriales especialmente diseñados, incluidos Pinecone, Qdrant y Weaviate. La distinción que hace Oracle se refiere a lo que sucede cuando el vector por sí solo no es suficiente.
“Una vez que haya terminado con los vectores, realmente no tendrá otra opción”, dijo a VentureBeat Steve Zivanic, vicepresidente global de bases de datos y servicios autónomos, marketing de productos de Oracle. “Con esto, puedes obtener series gráficas, series espaciales, series temporales, lo que necesites. No es un callejón sin salida”.
Holger Mueller, analista principal de Constellation Research, dijo que el argumento arquitectónico es creíble precisamente porque otros proveedores no pueden hacerlo sin mover primero los datos. Otros proveedores de bases de datos exigen que los datos transaccionales se transfieran a un lago de datos antes de que los agentes puedan razonar al respecto. En su opinión, el legado convergente de Oracle le otorga una ventaja estructural que es difícil de replicar sin una reconstrucción completa.
No todo el mundo ve el conjunto de funciones como diferenciado. Steven Dickens, director ejecutivo y analista principal de HyperFRAME Research, dijo VentureBeat que la búsqueda vectorial, la integración RAG y el soporte de Apache Iceberg son ahora requisitos estándar en las bases de datos empresariales: Postgres, Snowflake y Databricks ofrecen capacidades comparables.
“La decisión de Oracle de etiquetar la base de datos como una base de datos de IA es principalmente una reelaboración de su estrategia de base de datos convergente para que coincida con el actual ciclo de exageración”, dijo Dickens. En su opinión, la verdadera diferenciación que afirma Oracle no está en el nivel de características, sino en el nivel de arquitectura, y el Unified Memory Core es donde ese argumento se mantiene o cae.
Donde realmente fallan las implementaciones de agentes empresariales
Las cuatro características que Oracle lanzó esta semana son una respuesta a un modo de falla de producción específico y bien documentado. Las implementaciones de agentes empresariales no se detienen en la capa del modelo. Se están descomponiendo en la capa de datos, donde los agentes creados en sistemas fragmentados sufren latencia de sincronización, contexto obsoleto y control de acceso inconsistente cuando aumentan las cargas de trabajo.
Matt Kimball, vicepresidente y analista principal de Moor Insights and Strategy, dijo VentureBeat la capa de datos es donde surgen primero las limitaciones de producción.
“La dificultad es ponerlos en producción”, dijo Kimball. “La brecha se ve casi de inmediato en la capa de datos: acceso, gobernanza, latencia y coherencia. Todo esto se convierte en una limitación”.
Dickens plantea la incompatibilidad central como un problema entre apátridas y apátridas. La mayoría de los marcos de agentes empresariales almacenan la memoria como una lista simple de interacciones pasadas, lo que significa que los agentes efectivamente no tienen estado, mientras que las bases de datos que consultan tienen estado. La brecha entre los dos es donde las decisiones salen mal. “Los equipos de datos están agotados por la fatiga de la fragmentación”, dijo Dickens. “Administrar un almacén de vectores, una base de datos de gráficos y un sistema relacional separados solo para alimentar a un agente es una pesadilla de DevOps”.
Esta fragmentación es precisamente para lo que se diseñó el Unified Memory Core de Oracle. La cuestión del plano de control sigue directamente. “En un modelo de aplicación tradicional, el control reside en la capa de aplicación”, dijo Kimball. “Con los sistemas de agentes, el control de acceso se rompe rápidamente porque los agentes generan acciones dinámicamente y necesitan una aplicación consistente de las políticas. Al llevar todo este control a la base de datos, todo se puede aplicar de manera más uniforme”.
Qué significa esto para los equipos de datos empresariales
La cuestión de dónde reside el control en la pila de IA de un agente empresarial no está resuelta. La mayoría de las organizaciones todavía están construyendo sistemas fragmentados, y las decisiones arquitectónicas que se toman ahora (qué mecanismo ancla la memoria del agente, dónde se aplican los controles de acceso, cómo se introducen los datos de la casa del lago en el contexto del agente) serán difíciles de deshacer a escala.
El desafío de los datos distribuidos sigue siendo la verdadera prueba. “Los datos se distribuyen cada vez más entre plataformas SaaS, lagos y sistemas controlados por eventos, cada uno con su propio plano de control y modelo de gobernanza”, dijo Kimball. “La oportunidad ahora es ampliar este modelo a conjuntos de datos más amplios y distribuidos que definen la mayoría de los entornos empresariales actuales”.
