La guerra real entre Snowflake y Databricks ya no va de almacenar datos: va de gobernar agentes de IA

Durante años hemos explicado la rivalidad entre Snowflake y Databricks con una especie de chuleta mental bastante cómoda: warehouse contra lakehouse, SQL contra Spark, analítica contra ciencia de datos, plataforma gestionada contra ecosistema abierto. Era una forma rápida de ordenar el debate y, siendo justos, durante un tiempo funcionó razonablemente bien.

Pero esa conversación empieza a quedarse pequeña.

No porque el almacenamiento, el rendimiento, los formatos abiertos, el coste de cómputo o la experiencia de desarrollo hayan dejado de importar. Siguen importando. Mucho. La diferencia es que el tablero se está moviendo hacia una capa bastante más delicada: la capa donde una empresa decide qué puede hacer la inteligencia artificial con sus datos, sus permisos, sus herramientas y sus procesos.

Ese matiz lo cambia todo.

Porque una cosa es decidir dónde vive una tabla y otra muy distinta es decidir bajo qué identidad actúa un agente, qué contexto de negocio recibe, qué herramientas puede invocar, qué trazas deja, qué coste puede generar y cómo explicas después por qué ha hecho lo que ha hecho.

La pelea interesante entre Snowflake y Databricks empieza a estar ahí. En el plano de control de la IA empresarial.

Y conviene hablar de esto justo ahora, no dentro de tres años cuando ya tengamos el problema encima de la mesa con el presupuesto gastado, los pilotos abandonados y alguien diciendo en una reunión que “la IA no ha funcionado”.

En 2025 y 2026 han pasado varias cosas que apuntan en la misma dirección. Snowflake llevó Cortex Agents a disponibilidad general en noviembre de 2025. Después ha ido añadiendo observabilidad, evaluaciones y presupuestos de recursos para controlar el comportamiento y el coste de esos agentes. Databricks, por su parte, ha empujado Unity Catalog y Unity AI Gateway hacia el gobierno de agentes, modelos, herramientas y servidores MCP, con managed MCP servers en Public Preview durante 2026. Mientras tanto, McKinsey habla en su State of AI 2025 de una adopción más amplia de IA, pero también de una dificultad persistente para pasar de pilotos a impacto escalado. Deloitte ya había previsto que una cuarta parte de las empresas que usan IA generativa desplegarían pilotos o pruebas de agentes en 2025, creciendo hacia la mitad en 2027. Gartner, bastante menos festivo, advirtió en 2025 que más del 40% de los proyectos de agentic AI podrían abandonarse antes de acabar 2027 por costes crecientes, valor poco claro y bastante “agent washing”.

Así que no, no estamos hablando de agentes porque sea la palabra bonita del trimestre. Estamos hablando de agentes porque las plataformas de datos están moviéndose hacia ahí, las empresas están probando cosas y el riesgo de construir otra capa de humo encima de datos mal gobernados es bastante real.

La demo no es el problema. El problema empieza cuando la demo toca la empresa

Montar un agente sencillo ya no impresiona demasiado a nadie que haya trasteado un poco con esto. Puedes hacer un chatbot contra documentación interna, conectar un modelo a una base de datos, darle unas herramientas, pedirle que genere SQL, que resuma un informe, que clasifique incidencias o que proponga una acción comercial. Con un poco de cuidado, una demo puede quedar bastante convincente.

La trampa está en que muchas empresas confunden una demo convincente con un sistema preparado para operar. Ahí empieza la parte incómoda.

Cuando un agente entra en una organización real, deja de vivir en ese mundo limpio donde todo es una prueba controlada. De repente aparecen usuarios con permisos distintos, datos sensibles, definiciones contradictorias, procesos a medio documentar, excepciones que solo conoce una persona, métricas que significan cosas diferentes según el departamento y sistemas que llevan años funcionando más por costumbre que por diseño.

Entonces la pregunta ya no es si el agente responde bien en una presentación. La pregunta es qué demonios está haciendo realmente.

Puede parecer una diferencia menor, pero no lo es. En una empresa, un agente que responde mal puede generar una mala recomendación. Un agente que actúa mal puede abrir un ticket equivocado, modificar un registro, lanzar un proceso, consultar información que no debería ver, enviar datos fuera de contexto o apoyar una decisión en una métrica que nadie había definido bien.

Y lo peor es que todo puede venir envuelto en una respuesta perfectamente escrita.

Ese es uno de los riesgos más desagradables de la IA generativa aplicada a negocio: no siempre falla haciendo ruido. A veces falla con educación, con sintaxis impecable y con una seguridad que hace que la respuesta parezca más sólida de lo que realmente es.

Por eso me interesa mucho más la discusión sobre gobierno, trazabilidad, permisos, contexto y observabilidad que la enésima demo de “mira cómo mi agente consulta una tabla”. Consultar una tabla lo puede hacer casi cualquiera. Hacerlo bien, con identidad correcta, semántica clara, control de costes, logs útiles y límites operativos ya es otra historia.

La IA empresarial está chocando con problemas que ya estaban ahí

El entusiasmo actual con los agentes tiene un punto bastante previsible. Muchas organizaciones llevan años acumulando procesos manuales, reporting caótico, datos duplicados, definiciones inconsistentes y decisiones que dependen demasiado de personas concretas. Cuando aparece una tecnología que promete entender lenguaje natural, conectar herramientas y automatizar tareas, es normal que alguien piense: “esto nos puede arreglar mucho”.

Puede ayudar.. pero también puede acelerar el desastre.

Si una empresa no sabe qué significa exactamente “cliente activo”, el agente no va a resolver esa ambigüedad por inspiración divina. Usará una definición, la que encuentre, la que le des, la que aparezca en una tabla, la que esté en un documento o la que parezca más probable. Si existen cinco definiciones de ventas, el agente no va a convocar un comité de gobierno del dato antes de responder. Si los permisos están mal planteados, no va a sentir una inquietud ética espontánea antes de consultar información sensible. Si el proceso está roto, lo envolverá en una capa conversacional más cómoda.

Esto ya lo vimos con los dashboards (pásate por este reciente post: El dashboard ha muerto como destino final: ahora el dato quiere ejecutar acciones).

Durante años, cualquier problema de gestión acababa convertido en “necesitamos un dashboard”. Problemas de seguimiento, de ventas, de operaciones, de dirección, de productividad. Todo se resolvía, supuestamente, con una pantalla llena de gráficos. Y a veces hacía falta, claro. Pero muchas otras veces el dashboard era una forma elegante de no reconocer que nadie tenía claro el proceso, la métrica, la decisión ni la acción posterior.

Ahora el agente corre el riesgo de ocupar ese mismo lugar.

La nueva frase será “necesitamos un agente”. Sonará más moderna, más ambiciosa y más alineada con la dirección del mercado. Pero en muchos casos significará exactamente lo mismo de siempre: no hemos ordenado el problema, pero queremos una interfaz más inteligente encima.

Y esa interfaz puede ser muy peligrosa si la base está torcida.

Gartner lo resumió de una forma bastante cruda al hablar de proyectos agentic que podrían abandonarse por costes, valor poco claro y mucho maquillaje comercial. No hace falta estar de acuerdo con cada porcentaje para ver el patrón. Hay una diferencia enorme entre probar agentes y obtener valor real, sostenido, medible y gobernado. McKinsey apunta algo parecido desde otro ángulo: el uso de IA se amplía, pero pasar de pilotos a impacto escalado sigue siendo una asignatura complicada. La parte técnica visible avanza rápido; la parte organizativa, de datos y de gobierno se mueve bastante más despacio.

Por qué Snowflake está intentando quedarse cerca del agente

Snowflake ha entendido algo importante: si la IA empresarial va a operar sobre datos de negocio, la plataforma donde viven esos datos puede aspirar a mucho más que almacenarlos y procesarlos.

Cortex Agents encaja en esa dirección. La idea, simplificando, es permitir que un agente orqueste tareas usando herramientas como Cortex Analyst para datos estructurados y Cortex Search para información no estructurada. No se trata solo de preguntar a una tabla, sino de combinar razonamiento, búsqueda, contexto y análisis dentro del entorno Snowflake.

Lo relevante no es que Snowflake tenga otra funcionalidad de IA. Eso sería quedarse en la superficie. Lo relevante es que está intentando que la IA se conecte al dato empresarial sin sacar todo el gobierno fuera de la plataforma. Ahí entran piezas como observabilidad, trazas, evaluaciones y presupuestos de recursos. En 2025 Snowflake declaró la disponibilidad general de AI Observability en Cortex, y en 2026 añadió resource budgets para Cortex Agents y presupuestos para varias features de IA. Traducido a lenguaje menos de nota de producto: ya no basta con que el agente conteste; hay que poder mirarlo, medirlo y ponerle límites.

Esto es bastante más importante de lo que parece.

En una empresa, el coste de la IA no es solo el coste del modelo. Es el coste de cada consulta, cada token, cada búsqueda, cada ejecución, cada herramienta, cada repetición absurda y cada usuario probando cosas sin saber muy bien qué está disparando por debajo. Si vas a poner agentes delante de equipos reales, necesitas controlar consumo. Si no, la “innovación” te puede aparecer a final de mes en forma de factura con cara de broma pesada.

También necesitas observabilidad. No observabilidad como palabra bonita en una slide, sino capacidad real de reconstruir qué ha pasado. Qué petición llegó. Qué plan siguió el agente. Qué herramienta eligió. Qué datos consultó. Qué respuesta produjo. Dónde falló. Qué coste tuvo. Qué usuario estaba detrás. Qué rol se aplicó.

Sin eso, cualquier agente que pase de piloto a producción se convierte en una caja negra con permisos.

Y una caja negra con permisos no es una arquitectura seria.

Snowflake quiere situarse precisamente en ese cruce: datos, seguridad, contexto, agentes, trazabilidad y coste dentro de una misma plataforma. Para organizaciones que ya tienen mucha carga analítica en Snowflake, la propuesta es evidente. Si el dato vive ahí, si la seguridad vive ahí, si buena parte de la lógica analítica vive ahí, tiene sentido intentar que la IA empresarial no se convierta en una capa externa pegada con cinta aislante.

Ahora bien, conviene mantener los pies en el suelo. Ninguna plataforma te va a arreglar una empresa que no sabe definir sus métricas, que documenta tarde y mal, que no tiene responsables claros del dato o que resuelve permisos con parches históricos. Snowflake puede darte piezas útiles. Lo que no puede darte es madurez organizativa por suscripción.

Y ahí muchas empresas se van a confundir.

Comprarán una plataforma seria y pensarán que eso las convierte automáticamente en serias. No funciona así. La herramienta puede sostener un buen sistema. No sustituye el criterio necesario para diseñarlo.

Databricks está jugando una partida parecida desde su propio terreno

Databricks llega al mismo problema desde otro sitio. Su lenguaje natural es Unity Catalog, lakehouse, modelos, datos abiertos, gobierno transversal y ahora una capa cada vez más clara alrededor de agentes y herramientas.

Lo interesante de su movimiento con managed MCP servers, Unity Catalog y Unity AI Gateway es que asume una realidad incómoda: el mundo de los agentes va a ser desordenado.

No vamos a vivir en empresas con un único agente oficial, perfectamente diseñado, revisado por arquitectura, seguridad, datos, legal y negocio antes de tocar nada. Eso queda muy bien en un documento de estrategia, pero la realidad suele tener bastante menos elegancia.

Habrá agentes internos, agentes comprados, agentes dentro de herramientas SaaS, agentes creados por equipos técnicos, agentes montados por negocio con plataformas low-code, agentes experimentales que nadie sabe si siguen vivos y agentes que aparecen porque una herramienta que ya usabas decidió añadir IA en una actualización.

Unos estarán hechos con un framework. Otros con otro. Algunos usarán MCP. Otros irán por API directa. Algunos accederán a datos. Otros a documentos. Otros a funciones. Otros a sistemas externos. Y, si no hay una capa de gobierno común, cada uno traerá su pequeño universo de permisos, credenciales, logs, costes y riesgos.

Eso no escala. O escala como escalan las malas decisiones: hasta que revientan.

Databricks está intentando que Unity Catalog no gobierne solo tablas, modelos o activos de datos, sino también parte de ese ecosistema agentic. Sus managed MCP servers conectan agentes con Genie, datos gobernados en Unity Catalog, Vector Search y funciones personalizadas. La documentación insiste en algo que no es decorativo: los permisos de Unity Catalog se aplican, y Unity AI Gateway sirve como punto para visibilidad, acceso y monitorización.

La palabra importante aquí es “aplican”.

Porque muchas empresas tienen políticas. Documentos de gobierno. Principios. Comités. PDFs. Presentaciones. Todo eso está muy bien para tranquilizar a alguien, pero el gobierno que importa de verdad es el que se ejecuta cuando un sistema intenta acceder a un dato, llamar a una herramienta o cruzar una frontera que no debería cruzar.

El gobierno escrito en Confluence no bloquea una mala llamada.
El gobierno integrado en la plataforma, al menos, puede intentarlo.

Y este es el giro relevante: Databricks no está vendiendo solo agentes. Está intentando vender la capa desde la que los agentes pueden actuar sin que cada experimento se convierta en una isla. Para una empresa con ecosistema Databricks fuerte, eso tiene bastante sentido. Si ya gobiernas datos, modelos, lineage y permisos con Unity Catalog, extender ese gobierno hacia agentes y herramientas es una evolución natural.

La pelea con Snowflake, vista desde aquí, deja de parecer una comparativa clásica de plataforma de datos. Se parece más a una carrera por decidir dónde se sienta la IA cuando entra en la empresa.

MCP acelera el problema porque convierte al agente en algo que puede tocar sistemas

MCP se está convirtiendo en una pieza relevante porque ofrece una forma estandarizada de conectar agentes con herramientas. En términos prácticos, facilita que un agente descubra capacidades externas y las use sin que cada integración sea una artesanía distinta.

Eso es útil. También es el tipo de cosa que debería hacer que alguien de seguridad levante un poco la ceja.

Mientras un agente solo responde texto, el riesgo tiene un perímetro más contenido. Sigue habiendo riesgos, por supuesto: fuga de información, respuestas incorrectas, hallucinations, exposición de datos sensibles. Pero cuando el agente puede invocar herramientas, la conversación cambia de temperatura.

Consultar clientes. Abrir tickets. Lanzar procesos. Ejecutar funciones. Modificar registros. Interactuar con un CRM. Leer documentación interna. Acceder a índices vectoriales. Pedir datos a un sistema. Enviar información a otro. Encadenar pasos. Tomar decisiones intermedias.

Cada una de esas acciones necesita límites. Y no límites en plan “le hemos dicho en el prompt que sea responsable”. Eso no es un límite, es una esperanza escrita en lenguaje natural.

Un límite serio vive en permisos, credenciales, políticas, controles de red, auditoría, validaciones, presupuestos, revisiones humanas cuando toca y capacidad de parada.

Aquí es donde empiezan a tener sentido los movimientos recientes de las plataformas. Snowflake no habla de budgets y observability por casualidad. Databricks no empuja MCP bajo Unity Catalog y Unity AI Gateway por estética. Ambos están viendo venir el mismo problema: en cuanto los agentes empiezan a usar herramientas, el gobierno deja de ser una capa administrativa y se convierte en infraestructura operativa.

Y esto conecta con algo que IBM destaca en su Cost of a Data Breach Report 2025: acelerar la adopción de IA sin seguridad y gobierno adecuados aumenta el riesgo sobre datos y reputación. No hace falta dramatizarlo demasiado. Basta con imaginar agentes desplegados en áreas de negocio con acceso a documentos, datos, credenciales o sistemas sin inventario claro, sin ownership y sin trazabilidad suficiente.

Olvídate de «innovación avanzada»: eso es shadow IT con modelo de lenguaje.

El mercado está corriendo, pero la transparencia todavía va por detrás

Hay otro dato que conviene meter en la conversación, porque ayuda a bajar el entusiasmo a tierra. El AI Agent Index 2025, publicado en 2026, analiza 30 sistemas agentic y señala una realidad bastante incómoda: el ecosistema es complejo, evoluciona rápido y está documentado de forma irregular. También observa diferencias importantes en transparencia y que muchos desarrolladores comparten poca información sobre seguridad, evaluaciones e impacto social.

Esto importa bastante para empresas.

Porque una organización no debería adoptar agentes como quien instala un plugin de productividad. Si el sistema va a interactuar con datos, herramientas o procesos internos, necesitas saber más que “funciona bien en la demo”. Necesitas entender cómo se evalúa, qué controles ofrece, qué logs genera, cómo maneja permisos, qué información conserva, qué datos salen del entorno, cómo se audita y qué ocurre cuando falla.

Y aquí hay una tensión evidente.

El mercado quiere velocidad. Las empresas quieren pilotos rápidos. Los proveedores quieren colocar su narrativa agentic cuanto antes. Los equipos técnicos reciben presión para enseñar algo. Dirección quiere ver IA aplicada a procesos reales. Y en medio de todo eso quedan las preguntas aburridas, que casi siempre son las importantes.

¿Qué dato es fiable? ¿Qué definición se usa? ¿Qué rol consulta? ¿Qué herramienta se invoca? ¿Qué queda registrado? ¿Qué coste tiene? ¿Qué se puede explicar después?

La madurez real de la IA empresarial dependerá mucho menos del entusiasmo inicial y mucho más de cómo se contesten estas preguntas cuando el piloto deje de ser piloto.

La arquitectura de agentes va a necesitar gente de datos más que nunca

Hay una idea que me parece especialmente relevante para perfiles técnicos de datos: todo este movimiento no reduce la importancia de la ingeniería de datos. La desplaza hacia una zona todavía más estratégica.

Durante años, una parte del trabajo de datos ha sido invisible para la organización. Modelar bien. Crear capas limpias. Definir reglas. Construir pipelines. Controlar calidad. Documentar. Auditar. Revisar rendimiento. Preparar permisos. Mantener procesos. Detectar inconsistencias. Resolver incidencias raras que nadie entiende hasta que dejan de funcionar.

Pero es justo lo que necesita la IA empresarial para no convertirse en una máquina de generar respuestas convincentes sobre una base dudosa.

Un agente necesita datos fiables. Necesita definiciones. Necesita contexto semántico. Necesita permisos. Necesita trazabilidad. Necesita observabilidad. Necesita criterios de validación. Necesita entender qué herramienta puede usar y cuándo. Necesita límites de coste. Necesita saber cuándo debe parar y pedir intervención humana. Necesita que alguien haya pensado el sistema completo, no solo el prompt.

Ese trabajo lo resuelve arquitectura, ingeniería y criterio.

Por eso el perfil técnico de datos que entiende negocio, producto interno, automatización, gobierno y operación real tiene aquí una oportunidad enorme. No como “el que hace pipelines”, sino como la persona que diseña la capa de confianza sobre la que la IA puede operar.

Porque la pregunta importante ya no será solo si sabes mover datos de A a B. Será si sabes exponer esos datos para que sistemas inteligentes los usen sin romper permisos, sin inventar significados, sin disparar costes y sin dejar a la empresa ciega cuando algo falla.

Esa es una evolución mucho más interesante que la fantasía barata de que la IA va a sustituir todo el trabajo técnico.

Sustituirá tareas. Automatizará partes. Hará más accesibles ciertas operaciones. Pero también va a elevar el coste de tener una arquitectura mediocre.

Antes, una métrica mal definida podía acabar en un dashboard confuso. Ahora puede alimentar un agente que responde con seguridad, a más gente, más rápido y con más capacidad de acción. El error no desaparece. Se distribuye mejor.

La guerra de plataformas va de confianza operativa

Snowflake y Databricks están vendiendo IA, sí. Pero debajo de la narrativa comercial hay algo más serio: ambas plataformas quieren ser el sitio donde una empresa pueda decir “este agente puede hacer esto, con estos datos, bajo estas reglas y dejando esta evidencia”.

Ese es el territorio de verdad; ni del chatbot, ni la pantalla bonita, ni del vídeo de producto. El territorio serio es la confianza operativa.

Una empresa necesita saber que sus agentes respetan permisos, usan datos correctos, heredan políticas, generan trazas, pueden evaluarse, tienen costes controlados y no viven como piezas sueltas imposibles de auditar. Sin eso, cada agente será una pequeña aventura. Y las aventuras están muy bien para un hackathon. Bastante peor para operar una compañía.

Snowflake juega esa partida desde la proximidad al dato gobernado, Cortex, Cortex Search, Cortex Analyst, observabilidad y presupuestos. Databricks la juega desde Unity Catalog, Unity AI Gateway, MCP, modelos, funciones y gobierno transversal del lakehouse. Cada uno lo cuenta con su idioma, con sus fortalezas y con su maquinaria comercial detrás.

Pero el fondo es parecido: la IA empresarial necesita una capa de control.

Y quien consiga quedarse con esa capa tendrá una posición muy fuerte en la arquitectura futura de las organizaciones.

Porque esa capa no solo toca datos. Toca decisiones, procesos, seguridad, costes, cumplimiento y automatización. Toca la forma en que la empresa convierte conocimiento en acción. Y eso es muchísimo más valioso que ser simplemente “el sitio donde están las tablas”.

La conclusión incómoda

Me cuesta bastante comprar el entusiasmo simple alrededor de los agentes. No porque no sean importantes. Precisamente porque lo son.

Un agente conectado a datos y herramientas puede ser muy útil. Puede reducir fricción, acelerar análisis, automatizar tareas, mejorar soporte interno, asistir decisiones y convertir sistemas complejos en experiencias mucho más accesibles. Sería absurdo negar eso.

Pero también puede convertirse en una demo cara, en un escaparate, en una capa de riesgo con lenguaje natural o en otra forma elegante de no arreglar lo que estaba roto debajo.

La diferencia entre una cosa y otra no estará solo en el modelo elegido. Estará en la arquitectura: el dato, la semántica, los permisos, las herramientas, las trazas, los costes, la observabilidad, etc.

En la capacidad de decir “esto ha pasado por este motivo” cuando alguien pregunte.

Por eso la guerra entre Snowflake y Databricks ya no se entiende bien si la reducimos a warehouse contra lakehouse. Esa lectura se queda corta para el momento actual. La pelea importante está en quién gobierna la capa donde la IA empresarial empieza a actuar.

Y las empresas que no entiendan esto van a repetir el patrón de siempre: comprarán el juguete, montarán la demo, ignorarán la base técnica y luego culparán a la tecnología cuando el valor no aparezca.