Automatizar tareas en Snowflake: tasks, alertas y Cortex con Claude

Dentro de Snowflake puedes automatizar tareas sin sacar los datos a otra herramienta con cuatro piezas nativas: tasks para ejecutar SQL o procedimientos con horario o por eventos, dynamic tables para mantener tablas al día, alertas para avisar cuando se cumple una condición y Cortex AI para meter un modelo como Claude en cualquiera de esos pasos. Con eso se cubre la mayor parte de lo que hoy una empresa en México resuelve con scripts sueltos, cron en un servidor y correos manuales. Esta guía explica qué hace cada pieza, cuándo usar cuál y cómo se conecta con Claude desde afuera.

¿Qué se puede automatizar dentro de Snowflake en México y en cualquier región?

Es lo mismo en cualquier país, pero el ahorro se nota más donde los equipos de datos son chicos y los procesos manuales abundan. Los casos que vemos con más frecuencia en empresas mexicanas, sobre todo en retail y consumo masivo:

• Cargar y transformar datos de ventas cada noche o cada pocos minutos.
• Avisar al área de operaciones cuando el inventario de una categoría cae por debajo de un umbral.
• Clasificar tickets, comentarios o descripciones de producto con un modelo de lenguaje.
• Generar un resumen diario para el gerente regional.

Todo esto se hace con objetos que viven en tu cuenta de Snowflake, con los mismos roles y permisos que ya tienes.

¿Cuándo usar tasks, dynamic tables o alertas?

Cada pieza responde a una pregunta distinta. La tabla resume cuándo usarlas, con base en la documentación oficial de tasks, dynamic tables y alertas, consultada el 13 de octubre de 2026.

Pieza	Qué hace	Úsala cuando
Task	Ejecuta SQL o un procedimiento con horario (intervalo o cron) o cuando un stream tiene datos nuevos	Necesitas lógica paso a paso, llamadas a procedimientos o acciones fuera de una simple consulta
Task graph	Encadena tareas en serie o en paralelo	El proceso tiene varias etapas con dependencias
Dynamic table	Mantiene el resultado de un SELECT dentro de un retraso objetivo que tú defines	La transformación se puede expresar como consulta y quieres que Snowflake maneje el orden y el refresco
Alerta	Revisa una condición con horario o ante filas nuevas y ejecuta una acción	Quieres notificar o reaccionar cuando algo pasa en los datos
Cortex AI (AI_COMPLETE y similares)	Llama a un modelo desde SQL	El paso requiere leer o clasificar texto, no solo calcular

La regla práctica: si puedes escribir el resultado final como un SELECT, empieza con una dynamic table; si necesitas lógica procedural o acciones, usa tasks; si necesitas avisar, usa una alerta. Según la documentación, las dynamic tables no son la opción cuando necesitas datos con menos de 60 segundos de retraso, garantías de horario de refresco o definiciones que dependan de procedimientos almacenados.

¿Cómo se ve una tarea programada?

Una task es un objeto SQL. Este ejemplo, adaptado de los patrones de la documentación, corre cada noche a las 2 a. m. hora de Ciudad de México y resume ventas por tienda:

CREATE TASK resumen_ventas_diario
  SCHEDULE = 'USING CRON 0 2 * * * America/Mexico_City'
AS
  INSERT INTO analitica.ventas_diarias
  SELECT tienda_id, SUM(importe), CURRENT_DATE()
  FROM ventas.tickets
  WHERE fecha = DATEADD(day, -1, CURRENT_DATE())
  GROUP BY tienda_id;

Dos detalles que ahorran sustos. Primero, según la documentación, Snowflake corre una sola instancia de una tarea programada a la vez: si la ejecución anterior sigue en curso, la siguiente se omite. Segundo, si omites el parámetro de warehouse la tarea usa cómputo serverless, y si lo indicas controlas tú el tamaño. Las tareas también pueden dispararse solo cuando un stream recibe datos nuevos, lo que evita consultar en vano. Es el patrón que usamos en cargas incrementales, como describimos en carga incremental delta de SAP a Snowflake.

¿Y las alertas?

Una alerta revisa una condición y actúa. Según la documentación oficial, se define con un horario, una condición IF (EXISTS ...) y una acción THEN, y nace suspendida hasta que la reanudas con ALTER ALERT ... RESUME:

CREATE OR REPLACE ALERT quiebre_de_stock
  SCHEDULE = '10 MINUTE'
  IF (EXISTS (SELECT 1 FROM inventario.stock WHERE existencia < 5))
  THEN CALL SYSTEM$SEND_EMAIL(...);

ALTER ALERT quiebre_de_stock RESUME;

La acción puede ser un correo (requiere una integración de notificaciones), una inserción en una tabla de eventos o la llamada a un procedimiento. También hay alertas que se disparan solo con filas nuevas. Un detalle útil: puedes configurar que se suspendan solas tras cierto número de fallos consecutivos, para que un error no se repita sin que nadie lo vea. Es el tipo de aviso que, en retail, ayuda a detectar quiebres de stock antes de perder la venta.

¿Cómo entra Claude en esa automatización?

Hay dos formas, y no son excluyentes.

1. Claude como un paso dentro del proceso (Cortex AI). Claude está disponible dentro de Snowflake con Cortex AI, y se llama desde SQL. Como una task ejecuta SQL, puede incluir una llamada al modelo. Ejemplo ilustrativo, con la sintaxis que usamos en nuestra guía de Snowflake y Claude:

CREATE TASK clasificar_tickets_nuevos
  SCHEDULE = '30 MINUTE'
AS
  INSERT INTO soporte.tickets_clasificados
  SELECT ticket_id,
         AI_COMPLETE('claude-sonnet-4-6',
           'Clasifica la urgencia (alta, media o baja) de este ticket: ' || descripcion)
  FROM soporte.tickets_nuevos;

Antes de producción, confirma que el modelo esté disponible en la región de tu cuenta y filtra siempre las filas que mandas al modelo; un AI_COMPLETE sobre toda la tabla en cada ejecución es la forma más rápida de gastar créditos sin necesidad. Para el panorama del producto, revisa qué es Snowflake Cortex AI.

2. Claude como quien dispara la automatización (servidor MCP). Snowflake ofrece un servidor MCP gestionado. Según su documentación, expone herramientas de varios tipos: Cortex Analyst, Cortex Search, agentes de Cortex, ejecución de SQL y herramientas genéricas basadas en funciones o procedimientos almacenados. Eso último es lo que convierte a Claude en operador: un procedimiento que ya existe, por ejemplo “recalcular el cierre de la tienda” o “reprocesar la carga de ayer”, se publica como herramienta y Claude lo invoca cuando alguien se lo pide en lenguaje natural.

Los límites de la documentación importan para el diseño: hasta 50 herramientas por servidor, respuestas truncadas a 250 KB y autenticación con OAuth de Snowflake por defecto. Además, tener acceso al servidor no da acceso a cada herramienta: cada función o procedimiento necesita su propio permiso. Y Snowflake recomienda exponer un agente de Cortex como única herramienta de cara al cliente en un servidor gobernado, porque ofrecer ejecución libre de SQL en el mismo servidor puede saltarse los controles del agente. Más contexto en MCP en analítica: agentes que consultan métricas.

¿Qué conviene no automatizar con un agente?

Un agente que ejecuta procedimientos es poderoso y por eso hay que acotarlo. Nuestra regla en proyectos:

• Lo repetitivo y predecible va en tasks y dynamic tables, no en un agente. Si corre todas las noches igual, no necesita un modelo decidiendo.
• Lo que modifica datos o dinero pasa por un procedimiento con validaciones y con rol de mínimo privilegio, nunca por SQL libre.
• Lo que requiere criterio humano se queda con una persona, y el agente prepara el resumen.
• Todo lleva monitoreo. Historial de tareas y de alertas, y un responsable que lo revise.

Y recuerda que automatizar un proceso mal definido solo lo hace fallar más rápido. Antes de programar una tarea, el proceso y los datos tienen que estar claros; por eso la arquitectura va primero.

¿Cómo empezar sin romper nada?

Una ruta de 4 a 6 semanas que funciona bien en empresas medianas en México:

1. Elige un proceso manual con dueño claro, por ejemplo el reporte diario de ventas o el aviso de inventario.
2. Defínelo como SELECT. Si cabe en una dynamic table, empieza ahí.
3. Añade una alerta para saber cuándo falla o cuándo se cumple la condición de negocio.
4. Introduce IA solo donde hay texto que clasificar o resumir, con un límite de filas y un presupuesto por caso de uso.
5. Expón un procedimiento como herramienta MCP solo cuando ya confías en el proceso y en los permisos.

Si tu información ya está o va a estar en Snowflake, en EGOS BI, partner Premier de Snowflake con sede en Monterrey, diseñamos esta capa dentro de una arquitectura de datos moderna: modelado, permisos, tareas, alertas y los primeros casos con Cortex. Para la primera llamada, lleva tres cosas: la lista de procesos manuales que más tiempo consumen, dónde viven hoy los datos de cada uno y quién es el dueño de cada proceso. Con eso, agenda una llamada de descubrimiento y definimos por cuál empezar.

Fuentes: documentación oficial de Snowflake sobre tasks, alertas, dynamic tables y el servidor MCP gestionado, consultadas el 13 de octubre de 2026. Las funciones y la disponibilidad por región cambian; confirma en la documentación vigente.