Empresas gastaron millones en IA y acabaron con un caro generador de tonterías. Snowflake explica por qué.

Snowflake considera que el principal freno para los agentes de IA hoy no está en los modelos en sí, sino en los datos con los que trabajan esos agentes. Si los datos están dispersos en distintos sistemas, se duplican, se abren mediante herramientas incompatibles o se gestionan mal, el agente comienza a equivocarse, gastar tokens de más y obtener un contexto incompleto. Por eso la empresa ahora apuesta por estándares abiertos y por la compatibilidad entre distintas plataformas.

Esa postura la expresó el director de gestión de productos de Snowflake, James Rowland-Jones. Según él, para la era de la IA lo más importante no es solo almacenar los datos, sino mantenerlos en una forma con la que se pueda trabajar de manera rápida, transparente y sin copias infinitas. Cuantas más copias innecesarias y almacenes fragmentados haya en la infraestructura, más difícil será construir un sistema en el que la IA realmente se base en los mismos datos actuales.

Tras la cumbre de Apache Iceberg, Snowflake explicó con más detalle cómo ve el desarrollo futuro de su plataforma. La empresa quiere construir una pila compatible alrededor de Apache Iceberg —un formato tabular abierto que permite a varios sistemas trabajar con los mismos datos. La idea es no tener que mover tablas de un motor a otro ni multiplicar copias por cada nueva tarea.

Un agente no necesita un volumen de información grande de forma abstracta, sino un contexto claro y coherente. Si en el sistema existen varias versiones de los mismos datos, si las tablas se actualizan en distintos momentos y si las reglas de acceso dependen del motor por el que el usuario accede, la calidad de las respuestas y acciones del agente cae rápidamente.

La empresa opina que reducir el gasto en tokens y al mismo tiempo mejorar el funcionamiento de la IA solo es posible en un caso: cuando los datos están disponibles a través de una capa de gestión unificada. Entonces el agente no recibe un conjunto aleatorio de fragmentos, sino una imagen coherente. Para los sistemas corporativos esto es especialmente importante, porque la IA se usa cada vez más no para consultas aisladas, sino para operar sobre datos de trabajo —desde analítica hasta automatización de procesos.

Pero con un mayor acceso a los datos aumenta también la carga sobre el nivel de control. Si distintos sistemas y agentes obtienen acceso directo al almacén, hay que definir de antemano quién puede leer, quién puede escribir y quién solo ejecutar cálculos sobre los datos. Rowland-Jones subraya por separado que abrir el acceso no basta. También hacen falta reglas que impidan que ese acceso se convierta en un caos. Además, si una empresa abre acceso directo a los datos, debe simultáneamente establecer límites, permisos y mecanismos de control claros.

Snowflake ve la base técnica de ese esquema en el estándar de catálogo REST de Iceberg. La empresa lo describe como una forma neutral respecto a proveedores de organizar el acceso a los datos. En este modelo las tablas están en formato abierto, y distintos motores de cómputo pueden conectarse a ellas sin dependencia total de un único proveedor.

Snowflake también apuesta por la combinación de varios componentes abiertos. Para el almacenamiento y la estructura de las tablas se usa Apache Iceberg. Para el acceso —Iceberg REST. Para la gestión y catalogación —soluciones basadas en Apache Polaris. Como resultado, la empresa busca obtener una arquitectura en la que los mismos datos puedan leerse y modificarse mediante distintos motores sin perder el control común sobre las políticas de acceso.

Para los clientes el beneficio práctico es bastante sencillo. Las tablas pueden almacenarse, por ejemplo, en Amazon S3 u otro almacenamiento de objetos, y tanto las herramientas de Snowflake como sistemas externos, incluyendo Apache Spark, podrán trabajar con ellas. El cliente no tendrá que elegir entre la gestión por parte de Snowflake y el acceso directo desde otras plataformas. Esa es la arquitectura que la empresa intenta promover.

La propia Snowflake llama a este enfoque compatibilidad sin compromisos. La expresión es de marketing, pero la idea queda clara: la empresa quiere conservar una capa de gestión, catálogos y políticas de acceso, sin encerrar al cliente dentro de su propio entorno de cómputo. Para el mercado de datos es un argumento importante, porque muchas empresas llevan tiempo cansadas de la fuerte dependencia de un único proveedor.

En la hoja de ruta de Snowflake ya se señalan los siguientes pasos. La empresa planea llevar a estado público el soporte de Iceberg v3, desarrollar lectura y escritura compatibles a través de Snowflake Horizon Catalog para cualquier motor, y también ofrecer un almacenamiento gestionado para tablas Iceberg. Es decir, no se trata de un soporte puntual del formato, sino de intentar convertirlo en una de las piezas clave de toda la plataforma.

Snowflake añade que no quiere limitarse a usar los resultados de la comunidad open source. Según Rowland-Jones, la empresa tiene la intención de participar en el desarrollo de Iceberg y considera que el trabajo con código abierto debe ser bidireccional. Para los grandes proveedores, esta tesis también es importante en términos reputacionales: el mercado observa con atención quién realmente contribuye al desarrollo de los estándares y quién simplemente los utiliza como un rótulo conveniente.

El soporte de Iceberg v3 por parte de la empresa ya está en fase de pruebas públicas previas. Los representantes afirman que, en cuanto a alcance de funciones, su implementación de Iceberg v3 es ahora una de las más amplias entre los proveedores.