Algunas notas de Databricks Data + AI Summit 2026: por qué la capa de datos vuelve a importar
Después de la Databricks Data + AI Summit de este año, me encontré pensando menos en un anuncio concreto y más en una pregunta que lleva un tiempo rondándome:
Cuando la IA realmente pasa a producción, ¿en qué se convierte la capa de datos?
Mi respuesta actual es sencilla, aunque sus implicaciones no lo son: en este ciclo, la capa de datos es la parte de la pila de IA que más lentamente ha sido revalorizada. Eso está empezando a cambiar.
Datos: la parte de la pila de IA que el mercado aún no ha valorado
Los algoritmos han sido revalorizados públicamente. Los modelos mejoran rápidamente, y la industria puede ver el progreso casi cada semana. La computación ha sido revalorizada por NVIDIA, los proveedores de la nube y los mercados de capitales. Todo el mundo entiende que las GPU importan.
Los datos han avanzado más lentamente. No porque importen menos. Lo contrario es cierto. Los datos tardan en revalorizarse porque es difícil hablar de ellos y aún más difícil arreglarlos. Los datos empresariales son desordenados, están dispersos, duplicados, obsoletos y llenos de permisos que nadie entiende del todo. Las semánticas de negocio no encajan limpiamente entre sistemas. Lo que la gente llama “tiempo real” a menudo sigue siendo una tarea programada que se ejecutó en algún momento de la noche anterior.
Ese trabajo es doloroso. También es poco glamuroso. Pero una vez que la IA pasa de las demostraciones a producción, el dolor se vuelve imposible de ocultar.
En conversaciones con personas que construyen y entrenan modelos, incluidas las de OpenAI y Anthropic, la discusión suele volver al mismo punto. Los modelos están convergiendo. La computación puede comprarse, al menos si tienes suficiente dinero. La capa defendible se está convirtiendo cada vez más en los datos: su calidad, su frescura, los permisos que los rodean y la velocidad a la que pueden convertirse en contexto útil.
Esto no es solo un problema de la capa de aplicación. Dentro de las empresas de modelos, la calidad del modelo todavía depende en gran medida del pipeline de datos. Una ejecución de entrenamiento puede requerir días de preparación antes de que comience el primer experimento serio. Si un campo aguas arriba está sucio, un lote está mal etiquetado o una regla de filtrado es incorrecta, pueden desaparecer días de computación y espera antes de que alguien note que la curva de pérdida se ha desviado.
Los agentes de IA hacen que el problema de los datos sea imposible de ocultar
Los agentes exponen el mismo problema de una forma más operativa.
Cuando los agentes de IA fallan en producción, la primera causa a menudo no es que el modelo sea incapaz. Es que el modelo está actuando con el contexto equivocado: un registro al que no puede acceder, un documento que expiró hace seis horas, una fuente de datos que cambió silenciosamente durante la noche o una ruta de recuperación demasiado cara para usarse con la frecuencia suficiente. Hace poco vi a un equipo sólido perder casi una semana por un pipeline de contexto obsoleto. El agente estaba respondiendo con confianza a la pregunta de ayer. El modelo no era tonto. El contexto era incorrecto, y el sistema no tenía una forma limpia de demostrar dónde entró el error en el bucle.
Ese es el modo de fallo que importa. El próximo cuello de botella de infraestructura no es simplemente un mejor razonamiento. Es contexto fresco, fiable, barato y auditable en el momento en que un modelo o agente toma una decisión.
Por eso creo que la capa de datos es la próxima parte de la pila de IA que será revalorizada.
Databricks apunta al problema correcto
Soy escéptico ante muchos productos que se autodenominan “plataformas de datos de IA.” Con demasiada frecuencia, la historia llega antes que el sistema.
Databricks es lo suficientemente diferente como para que creo que merece una atención seria. Dos cosas me llamaron la atención en la Summit.
La primera sigue siendo la cultura de ingeniería. A la escala de Databricks, sería fácil que la empresa se volviera puramente impulsada por las ventas. Sin embargo, los fundadores siguen subiendo al escenario para hablar sobre motores de ejecución, transacciones, analítica en tiempo real y las tuberías bajo el producto. Respeto eso. Se nota cuando una empresa todavía tiene intuición de producto e ingeniería en su núcleo. Se manifiesta en pequeñas decisiones arquitectónicas mucho antes de aparecer en una keynote.
Lo segundo es la base de clientes. Los usuarios con los que hablé en la Summit no hablaban de la IA como una capa de demostración. Intentaban llevar la IA a sistemas de producción, y los problemas que describían eran mucho más concretos: los agentes necesitan leer y escribir el estado del negocio; la analítica en tiempo real no puede seguir pagando el coste de mover datos; los pipelines necesitan volverse más autónomos; el comportamiento de los agentes necesita gobernanza en tiempo de ejecución, no solo a posteriori.
Por eso importan anuncios como Lakebase, Lakehouse//RT, data agents y AI governance. Los nombres son menos importantes que la dirección. Acercar las transacciones al lake. Llevar la analítica en tiempo real de vuelta hacia la misma base de datos. Automatizar más del pipeline. Extender la gobernanza desde “quién puede ver este dataset” hasta “qué se le permite hacer a este agente en este paso específico”.
No lo veo como un giro equivocado. Lo veo como evidencia de que muchos de nosotros estamos mirando el mismo futuro desde diferentes ángulos.
La base de datos se está expandiendo. Ya no es solo un lugar para almacenar y consultar datos. Se está convirtiendo en la base para hechos, estado, semántica, gobernanza y acción.
El mapa es bueno. Pero no está terminado.
Databricks va en la dirección correcta. Eso no significa que la arquitectura haya alcanzado su forma final.
Foto: The Known Data Realm · Databricks Data + AI Summit 2026
Veo tres áreas en las que el mapa aún está incompleto.
El lakebase en sí.
Empezar con Postgres es un punto de entrada inteligente. Los desarrolladores lo conocen. El ecosistema es enorme. La compatibilidad reduce la fricción de adopción. Eso importa.
Pero la arquitectura que hace que la gente entre por la puerta no siempre es la arquitectura que gana la carga de trabajo final.
Los sistemas operacionales de la era de la IA necesitan transacciones, memoria, vectores, datos multimodales, trazas, ramificación, rollback y aislamiento de tenants muy granular. Un núcleo relacional tradicional puede exponer algunas de estas capacidades mediante extensiones y servicios circundantes, pero eso no las convierte en nativas. Classic Postgres no fue diseñado para la escala distribuida nativa de la nube, ni para agentes que crean bases de datos de corta duración, bifurcan estado, escriben en memoria, generan trazas y desaparecen.
Acercar Postgres al almacenamiento de objetos no elimina esas preguntas. El almacenamiento de objetos es barato y fiable, pero no es de baja latencia por defecto. Para que se perciba rápido, se necesita una capa de caché que sea tanto agresiva como correcta. Una caché que se mantenga estable bajo una carga transaccional real es uno de los problemas de sistemas más difíciles en bases de datos. Así que mi pregunta honesta sobre Lakebase no es si la demo es impresionante. Es si el sistema puede soportar cargas de trabajo OLTP reales a escala de producción sin convertir esa caché en lo que despierta a la gente a las 3 de la mañana.
Los datos multimodales.
Databricks ha trazado un mapa sólido a través de OLTP, almacenamiento analítico, analítica en tiempo real, ciencia de datos y gobernanza. Pero las aplicaciones de IA consumen cada vez más texto, imágenes, audio, video, embeddings, registros de comportamiento y trazas de agentes. Esos no son solo objetos situados junto a tablas. Son los datos que los agentes recuperan, razonan, transforman y vuelven a escribir.
Si los datos multimodales permanecen fuera del mapa central, entonces los activos de datos de IA más importantes siguen viviendo en los márgenes.
El usuario predeterminado.
Gran parte de la superficie del producto todavía asume un usuario humano: dashboards, BI en lenguaje natural, flujos de trabajo al estilo de Excel y experiencias orientadas a analistas. Todo eso es valioso. Pero los agentes usan las bases de datos de manera diferente.
Un agente no abre un dashboard una vez al día. Se ejecuta en un bucle. Recupera contexto, toma una decisión, llama a una herramienta, escribe estado, verifica una política y repite. Cada paso puede necesitar ser auditado. Cada recuperación puede influir en la siguiente acción. Cada escritura puede necesitar rollback. Cada verificación de permisos puede necesitar ocurrir en tiempo de ejecución.
Esa es una carga de trabajo de base de datos diferente.
Foto: Unity AI Gateway · Gobernanza —— Databricks Data + AI Summit 2026
Cuando el usuario de la base de datos es un agente
Durante décadas, una base de datos podía centrarse principalmente en una pregunta: cómo ejecutar esta consulta correcta y rápidamente.
En la era de los agentes, la pregunta se vuelve más amplia:
¿Cómo obtiene un agente el contexto más reciente, más confiable, de menor costo y más auditable en el momento en que toma una decisión?
Eso no es solo un problema de optimización de consultas. Es un problema de sistemas que abarca almacenamiento, indexación, gobernanza, linaje, reproducción, control de costos y aplicación de políticas en tiempo de ejecución.
Aquí es donde la categoría empieza a cambiar. Un sistema de datos ya no puede ser solo un sistema de inteligencia: haces una pregunta y devuelve una respuesta. Tiene que convertirse en algo más cercano a un sistema operativo para la IA: el lugar donde los agentes leen contexto, toman decisiones, llaman herramientas, escriben estado y dejan un rastro que humanos y otros sistemas pueden inspeccionar.
La auditabilidad no puede añadirse después. Si un agente da la respuesta equivocada, toma la acción equivocada o gasta demasiado dinero, la primera pregunta será: ¿qué vio exactamente en ese momento?
Para responder a eso, el sistema necesita saber qué documentos se recuperaron, qué vectores coincidieron, qué filtros de metadatos se aplicaron, qué reranker cambió el orden, qué herramienta se llamó, qué política se aplicó y qué estado se volvió a escribir. La depuración y la gobernanza se convierten en el mismo flujo de trabajo.
Esa es la arquitectura que no creo que nadie haya resuelto por completo todavía.
Qué debería significar realmente “AI-native”
“AI-native” se está convirtiendo en una de esas frases que pueden significar casi cualquier cosa. No creo que exista todavía una definición clara. Pero si trabajamos hacia atrás desde cargas de trabajo reales de agentes, un sistema de datos AI-native tiene que hacer bien al menos algunas cosas.
Los datos multimodales tienen que ser de primera clase
Texto, imágenes, audio, video, embeddings, logs y trazas no deberían estar dispersos entre una tabla relacional, una columna vectorial, un bucket de objetos y varios índices laterales. Necesitan vivir en un único sistema lógico donde la recuperación, el filtrado, la clasificación y la gobernanza puedan ocurrir juntas.
La parte difícil no es almacenar estos activos. La parte difícil es hacer que puedan consultarse juntos sin convertir la arquitectura en otro problema de pipelines.
La elasticidad tiene que partir de la carga de trabajo
El tráfico de agentes es irregular. Un sistema puede estar tranquilo durante una hora y luego recibir una avalancha de solicitudes de recuperación, memoria y uso de herramientas. El data lake o el almacenamiento de objetos debería convertirse en la base duradera: barata, fiable y desacoplada del cómputo.
Pero el cómputo no debería seguir siendo caro solo porque el corpus existe. Si nadie está buscando, el sistema debería gastar muy poco. Si una carga de trabajo se despierta, el cómputo debería llegar rápidamente. En ese mundo, la unidad natural de precios no siempre es un clúster permanente. Puede ser la consulta, la sesión o el minuto de cómputo activo.
La multi-tenencia tiene que pasar al nivel del agente
Los sistemas multi-tenant tradicionales suelen asumir un número manejable de grandes tenants. Los sistemas agénticos pueden crear millones o miles de millones de estados diminutos, efímeros y aislados. Cada agente puede llevar su propia memoria, permisos, trazas, ramas temporales y rutas de escritura.
Un diseño construido para miles de grandes tenants tendrá dificultades cuando el tenant se convierta en la propia ejecución del agente.
La ramificación y la reversión se convierten en funciones centrales de la base de datos
Los agentes escribirán lo incorrecto. Eso no es un caso límite. Es parte de la carga de trabajo.
Una capa de datos de IA útil necesita ramificación al estilo Git y reversión rápida para el estado de los datos. Una ejecución de agente debería poder bifurcar una rama de trabajo, probar una acción, escribir estado temporal y descartarlo o promoverlo. Si llega una mala actualización, el sistema debería poder volver rápidamente a un punto bueno conocido.
El versionado ya no es solo una comodidad analítica. Se convierte en un mecanismo de seguridad operativa.
La traza y la reproducción determinista son obligatorias
Cuando un agente falla, la pregunta no es solo “¿cuál fue la respuesta final?” Es “¿qué vio, recuperó, clasificó, decidió, llamó y escribió el agente?”
Eso requiere un rastro de cada paso significativo. Más importante aún, requiere reproducción. El sistema debería poder reconstruir el contexto de decisión tal como existía en ese momento, no como se ve después de que un documento haya cambiado o un índice se haya reconstruido.
Para los agentes, auditabilidad y depurabilidad se reducen al mismo requisito.
Los permisos tienen que gobernar acciones, no solo filas
La autorización tradicional pregunta quién puede leer una tabla, una columna o una fila. Los sistemas agénticos necesitan una pregunta más dinámica: ¿qué tiene permitido recuperar, llamar, modificar, divulgar y gastar este agente en este paso específico?
La parte difícil se traslada de la ruta de lectura a la ruta de acción. La aplicación de políticas tiene que ocurrir mientras el agente está ejecutándose, no solo cuando un humano abre un panel.
Las operaciones tienen que volverse autónomas
La escala a nivel de agentes rompe la infraestructura operada por humanos. Ningún equipo puede gestionar manualmente índices, compactación, calentamiento de caché, ubicación de inquilinos, recuperación y programación de recursos en millones de cargas de trabajo pequeñas y de rápido movimiento.
El sistema tiene que operarse a sí mismo. De lo contrario, la arquitectura puede funcionar en un diagrama pero fallar en el único lugar que importa: producción.
SQL no es suficiente como interfaz final
Hay otro tema en el que pienso cada vez más: la interfaz en sí.
SQL fue la interfaz adecuada para la era del analista. Sigue siendo esencial. Pero para las empresas construidas alrededor de bases de datos y analítica, SQL también puede convertirse en una forma de dependencia de trayectoria. La superficie del producto, el modelo de usuario e incluso la organización a menudo asumen que el usuario principal es alguien que sabe escribir una consulta.
La interfaz final para los datos de la era de la IA no será un editor de SQL ligeramente mejor. Tampoco será un chatbot pegado delante de la base de datos.
El punto final más interesante es un sistema de datos headless, nativo de lenguaje natural: uno en el que una persona o un agente pueda expresar la intención directamente y el sistema pueda responder, actuar o preparar el plan de ejecución correcto sin exponer cada paso interno como un ejercicio de escritura de consultas.
Pero esto tiene que ser nativo de la base de datos, no un agente separado situado delante de ella.
Si el lenguaje natural es solo una capa de aplicación, el sistema reintroduce precisamente las costuras que intenta eliminar: un paso más de traducción, una ventana de contexto obsoleta más, una brecha de gobernanza más. La propia base de datos necesita entender la pregunta, los datos, las políticas y la ruta de ejecución.
Eso es mucho más difícil que construir una interfaz amigable. Significa que la base de datos tiene que ser dueña de la semántica.
El foso defensivo que aún importa
No tengo una conclusión perfectamente limpia. Quizá eso sea apropiado. El mercado se está moviendo demasiado rápido, y demasiadas suposiciones antiguas se están agotando más rápido de lo esperado.
Un dialecto de consulta propietario ya no es el foso defensivo que solía ser. El coste de migración es más débil cuando los agentes pueden reescribir código de integración. Una interfaz de usuario familiar importa menos cuando el próximo usuario puede no ser humano. Incluso la ventaja discreta de simplemente poseer los datos es más débil cuando los formatos de tabla abiertos, las interfaces de lenguaje natural y los agentes que usan herramientas facilitan el movimiento.
El foso defensivo en el que todavía creo es menos glamuroso: la capacidad de crear valor real para el usuario durante un largo periodo de tiempo, con paciencia y de forma repetida.
Por eso salí del Summit tomándome en serio a Databricks. Creo que Databricks tiene una oportunidad real de convertirse en la próxima empresa de datos valorada en un billón de dólares. No porque cada anuncio de producto sea la respuesta final. Algunos cambiarán. Algunos probablemente estarán equivocados. Eso es normal. Lo que importa es que la empresa siga caminando de vuelta hacia el problema correcto.
Y el problema correcto ya no es solo analítica, almacenamiento de datos o almacenamiento transaccional. Es la base de datos para sistemas de IA que actúan.
Desde el lado de Zilliz, hemos llegado a una conclusión similar desde otra dirección. Las bases de datos vectoriales no están desapareciendo. Se están convirtiendo en el motor de serving dentro de una arquitectura más amplia para datos no estructurados y multimodales. Por eso pensamos en términos de Vector Lakebase: no como un reemplazo de las bases de datos vectoriales, sino como la siguiente arquitectura construida en torno a ellas a medida que las cargas de trabajo de IA se vuelven más continuas, elásticas y agénticas.
El mapa no está terminado. Esa es la mejor parte.
Lo barato vence a lo caro. Lo fiable vence a lo poco fiable. Lo cuidadoso vence a lo descuidado. Lo paciente vence a lo impaciente.
La base de datos nativa de IA aún se está dibujando. Para todos los que construyen en este espacio, eso es una muy buena noticia.
Una cosa más: Zilliz Vector Lakebase está disponible en vista previa pública
Hemos lanzado la vista previa pública de Zilliz Vector Lakebase — una evolución importante de Zilliz Cloud, que pasa de ser una base de datos vectorial pura a convertirse en una base de datos lake-native para IA, combinando serving vectorial de baja latencia con la apertura, escalabilidad y economía de un data lake.
Capacidades principales de Zilliz Vector Lakebase:
- Serving por niveles optimizado para diferentes equilibrios entre rendimiento en tiempo real y coste
- Búsqueda bajo demanda para cargas de trabajo exploratorias o a gran escala sin cómputo siempre activo
- Búsqueda en data lake externo — indexa y busca directamente sobre tus datos existentes en el lake
- Búsqueda de espectro completo en vectores, texto, JSON y datos geoespaciales con recuperación híbrida y reranking
- Almacenamiento unificado lake-native basado en Vortex, un formato abierto con lecturas aleatorias más rápidas y económicas que Lance o Parquet
Si tu stack actual separa serving y descubrimiento en sistemas distintos, quizá valga la pena echar un vistazo a Vector Lakebase. Pruébalo en Zilliz Cloud — los nuevos registros con correo electrónico de trabajo reciben $100 en créditos gratis — o habla con nosotros sobre tu caso de uso.
Sigue leyendo
How to Build an Enterprise-Ready RAG Pipeline on AWS with Bedrock, Zilliz Cloud, and LangChain
Build production-ready enterprise RAG with AWS Bedrock, Nova models, Zilliz Cloud, and LangChain. Complete tutorial with deployable code.
Democratizing AI: Making Vector Search Powerful and Affordable
Zilliz democratizes AI vector search with Milvus 2.6 and Zilliz Cloud for powerful, affordable scalability, cutting costs in infrastructure, operations, and development.
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.