Entre el 23 y el 28 de julio Snowflake ha ido soltando una tanda de novedades que, leídas juntas, dibujan una idea clara: el agente de IA pasa a ser un principal de seguridad de primera clase dentro del almacén. El 23 de julio alcanzó disponibilidad general el tipo de usuario SERVICE_AGENT, pensado para operaciones automatizadas, y el 27 de julio se añadió la columna agent_type a las vistas QUERY_HISTORY, de modo que el historial de consultas distingue qué agente ejecutó qué sentencia.
La combinación resuelve un problema que hasta ahora se parcheaba con convenciones internas. Cuando decenas de agentes lanzan consultas contra el almacén bajo un usuario técnico compartido, la auditoría se vuelve inservible: no hay forma de atribuir un coste, un acceso o una consulta anómala a su origen real. Separar el tipo de usuario y etiquetar el historial permite responder a las preguntas que un responsable de gobierno del dato necesita responder —quién ha consultado qué, cuánto ha consumido y con qué permisos— sin montar un sistema de trazabilidad paralelo.
En la misma semana llegaron otras piezas de calado desigual. El 27 de julio pasaron a disponibilidad general las dynamic tables incrementales personalizadas, que permiten definir estrategias de refresco propias en lugar de conformarse con las automáticas: un cambio útil para cargas donde el criterio de actualización no encaja en el modelo estándar. El 23 se ampliaron los proyectos dbt con soporte de variables de entorno SQL y paquetes Git privados, y el comando SHOW CORTEX BASE MODELS alcanzó GA. El 28, las sugerencias de código con IA en Workspaces llegaron también a disponibilidad general.
Para un equipo de ingeniería de datos, lo relevante no es cada anuncio por separado sino el patrón. Snowflake está aplicando a los agentes el mismo tratamiento que en su día dio a los usuarios y a los roles: identidad diferenciada, permisos acotados y registro auditable. Es la respuesta previsible a un año en el que las plataformas han competido por anunciar agentes y ahora tienen que explicar cómo se gobiernan. Sin esa capa, cualquier despliegue serio de agentes contra datos corporativos es un riesgo de cumplimiento difícil de justificar ante una auditoría.
La recomendación práctica es adoptar SERVICE_AGENT desde el principio en los despliegues nuevos, en lugar de reutilizar usuarios de servicio genéricos que después habrá que desenredar, y construir sobre agent_type los cuadros de mando de consumo por agente. Sobre las dynamic tables personalizadas conviene la cautela de siempre: una estrategia de refresco propia da control, pero también traslada al equipo la responsabilidad de que el resultado sea correcto y el coste, razonable.
Más en Dataprix: Análisis de plataformas de datos y almacenes cloud.
Fuente: Snowflake Documentation.