En esta cuarta automatización del Laboratorio AF probamos cómo gestionar tareas y avisos con IA y n8n. El flujo consulta una tabla interna, selecciona las tareas pendientes cuya fecha límite es hoy o anterior y utiliza Gemini para redactar un aviso que envía por correo.
Comprobamos el filtrado con tres tareas ficticias y realizamos un envío programado. También documentamos un problema de autenticación del correo que provocó el rechazo inicial de Gmail. El flujo no modifica las tareas ni evita avisos repetidos; al terminar las pruebas, detuvimos su programación.
1. Objetivo de la automatización
El objetivo fue comprobar si n8n podía consultar tareas, detectar cuáles requerían un aviso según su estado y fecha límite, redactar un mensaje con IA y enviarlo por correo.
Definimos dos condiciones que debían cumplirse a la vez:
- La tarea debía tener el estado pendiente.
- Su fecha límite debía ser hoy o anterior, tomando como referencia la fecha de Madrid.
Las tareas futuras y las completadas debían quedar fuera del envío.
La selección se realizó mediante reglas en el nodo Filter. Gemini intervino después, únicamente para redactar el aviso. No utilizamos un agente autónomo para decidir qué tareas seleccionar ni configuramos cambios en sus estados.
2. Herramientas utilizadas para gestionar tareas y avisos con IA y n8n
- n8n instalado en Windows mediante Docker Desktop: para conectar y ejecutar los pasos.
- Data tables de n8n: una tabla interna con tres tareas ficticias.
- Filter: para seleccionar las tareas según su estado y fecha límite.
- Gemini mediante API: utilizamos Gemini 3.5 Flash Lite para redactar el aviso.
- Send Email mediante SMTP: para enviar el mensaje desde nuestra cuenta de correo al buzón de prueba de Gmail.
- Schedule Trigger: para comprobar una ejecución programada con un intervalo de cinco minutos.
- cPanel: para revisar y corregir la autenticación del correo del dominio.
Reutilizamos la instalación de n8n y la credencial de Gemini. Las contraseñas del correo se introdujeron en las credenciales de n8n y no se incluyen en este artículo
3. Tareas utilizadas en la prueba
Creamos la tabla interna AF_Tareas_Prueba con tres columnas de texto: tarea, estado y fecha_limite. Introdujimos las fechas con el formato AAAA-MM-DD.
La prueba se realizó el 18 de octubre de 2026, tomando como referencia la fecha de Madrid.
| Tarea ficticia | Estado | Fecha límite | Resultado esperado |
|---|---|---|---|
| Preparar la reunión de prueba | pendiente | 2026-10-18 | Generar aviso: vence hoy |
| Revisar el artículo de prueba | pendiente | 2026-10-20 | Excluir: fecha futura |
| Ordenar las notas de prueba | completada | 2026-10-17 | Excluir: ya completada |
Los registros se introdujeron manualmente. No conectamos un calendario ni una aplicación externa de gestión de tareas.
4. Cómo configuramos el flujo
Organizamos la versión programada en cinco pasos:
- Schedule Trigger: inicia el flujo cada cinco minutos durante la prueba.
- Leer tareas: consulta los registros de la tabla AF_Tareas_Prueba.
- Filter: conserva únicamente las tareas pendientes con fecha límite de hoy o anterior.
- Basic LLM Chain: utiliza Gemini para redactar un aviso con los datos de la tarea seleccionada.
- Send an Email: envía el aviso como texto plano al correo de prueba mediante SMTP.
Conectamos Google Gemini Chat Model a la entrada de modelo de Basic LLM Chain.
Primero utilizamos un activador manual para revisar el filtro y el mensaje. Después lo sustituimos por Schedule Trigger para comprobar el funcionamiento programado.
El envío se configuró con el servidor SMTP del proveedor, el puerto 465 y SSL/TLS activado.
5. Condiciones para seleccionar las tareas
Configuramos Filter con dos condiciones unidas mediante AND: ambas debían cumplirse.
La primera comprobaba que estado fuera exactamente pendiente. La segunda comparaba fecha_limite con la fecha actual en la zona Europe/Madrid, para conservar las tareas que vencían ese día o antes.
Como las fechas estaban escritas en el formato AAAA-MM-DD, utilizamos una comparación de texto. Esta prueba presupone fechas válidas y con ese formato; no añadimos validación para valores vacíos o incorrectos.
Al ejecutar el filtro con las tres tareas, únicamente pasó «Preparar la reunión de prueba». La tarea futura y la completada quedaron descartadas.
No probamos por separado una tarea pendiente con fecha anterior: el registro con fecha pasada estaba completado y fue excluido por su estado.
6. Instrucciones y revisión del aviso
Pedimos a Gemini un aviso en español, en texto plano y con un máximo de 60 palabras. Debía conservar exactamente el nombre de la tarea y su fecha límite, indicar si vencía ese día o ya estaba vencida y evitar inventar horarios, prioridades o consecuencias.
También indicamos que no afirmara haber completado la tarea, enviado el mensaje o creado un recordatorio.
La respuesta fue:
AVISO DE PRUEBA. La tarea "Preparar la reunión de prueba" tiene fecha límite 2026-10-18. Su estado es pendiente y vence hoy. Datos ficticios del Laboratorio AF.
El texto respetó el límite de palabras, conservó los datos y describió correctamente el vencimiento. Su generación todavía no demostraba la entrega: comprobamos el envío y la recepción por separado.
7. Primer envío: aceptado por SMTP y rechazado por Gmail
Ejecutamos el nodo de envío y n8n mostró que el servidor SMTP había aceptado el destinatario, sin rechazos en esa respuesta inicial. Sin embargo, el mensaje no apareció en Gmail.
Revisamos el buzón del remitente y encontramos una devolución con el código 550-5.7.26. Gmail indicaba que el mensaje no había superado las comprobaciones SPF ni DKIM.
Esto permitió distinguir dos resultados diferentes: el servidor del proveedor había aceptado el correo para enviarlo, pero el servidor de destino lo rechazó después.
Por tanto, el estado correcto del nodo no bastaba para confirmar la recepción. Fue necesario comprobar el buzón de destino y revisar el mensaje de devolución.
8. Corrección de la autenticación del correo
En Entregabilidad del correo electrónico, cPanel indicaba que faltaban la clave DKIM local y el registro SPF del dominio.
Generamos la clave DKIM e instalamos el registro sugerido. Para SPF, revisamos los registros TXT existentes en el editor de zonas y, al comprobar que no había ninguno de ese tipo, añadimos el valor recomendado por cPanel.
Durante la introducción del registro, el formulario estaba configurado como tipo A y mostró un error de dirección IP. Lo cambiamos a TXT antes de guardar.
Al finalizar, cPanel mostró SPF, DKIM y DMARC como válidos. No atribuimos su configuración anterior al flujo: el envío de prueba permitió detectar el problema.
Repetimos el envío y el mensaje llegó a Spam de Gmail. Lo marcamos como «No es spam», sin dar por garantizada la ubicación de futuros mensajes.
9. Prueba de envío programado
Publicamos el flujo con un intervalo de prueba de cinco minutos. Sin pulsar Execute, apareció una nueva ejecución que el usuario comprobó como correcta.
Después verificamos la llegada de un nuevo correo correspondiente a esa ejecución. Su contenido conservaba el nombre «Preparar la reunión de prueba», la fecha 2026-10-18 y la indicación de que vencía ese día.
La prueba confirmó el recorrido completo: consulta de tareas, filtrado, redacción con Gemini y recepción del aviso enviado mediante SMTP.
Al terminar, retiramos la publicación del flujo para detener la programación. No lo dejamos enviando mensajes cada cinco minutos.
El flujo no registra qué tareas ya han recibido un aviso. Si permaneciera activo con los mismos datos, podría repetir los envíos en ejecuciones posteriores.
10. Limitaciones y costes
La prueba utilizó tres tareas ficticias en una tabla interna de n8n. No conectamos herramientas externas de productividad ni configuramos cambios de estado, prioridades o fechas.
El filtro seleccionaba tareas mediante reglas. La IA únicamente redactaba el mensaje: no decidía qué tareas gestionar ni actuaba como un agente autónomo.
No incorporamos un control de avisos repetidos, validación de fechas incorrectas ni confirmación automática de entrega. La recepción se comprobó manualmente, porque la aceptación del servidor SMTP no garantizó que Gmail admitiera el primer mensaje.
Utilizamos Gemini con la cuenta configurada en el nivel gratuito. No medimos tokens ni coste por aviso. Tampoco calculamos los costes del alojamiento o de mantener la instalación local funcionando.
La programación dependía del ordenador, Docker Desktop y n8n. Al terminar, el flujo quedó sin publicar para evitar nuevas llamadas a la API y envíos repetidos.
11. Qué hemos aprendido
La prueba mostró que podemos gestionar tareas y avisos con IA y n8n combinando reglas de selección, redacción con Gemini y envío por correo.
El filtro distinguió entre una tarea pendiente que vencía ese día, otra futura y una completada. Después comprobamos que una ejecución programada podía generar un aviso y que este llegaba al buzón de destino.
También aprendimos que un envío aceptado por SMTP no equivale a una entrega confirmada. El rechazo inicial permitió detectar problemas de autenticación del correo y revisar su configuración.
El resultado es un prototipo de avisos probado con datos ficticios. Para utilizarlo de forma habitual, quedarían pendientes el control de envíos repetidos, la validación de fechas y la supervisión de errores y entregas.
Preguntas frecuentes
¿La IA decide qué tareas deben generar un aviso?
No. El nodo Filter aplica las condiciones de estado y fecha. Gemini redacta el mensaje después de esa selección.
¿Se avisa de todas las tareas pendientes?
No. Solo pasan las pendientes cuya fecha límite es hoy o anterior, según la fecha de Madrid.
¿El flujo completa o modifica las tareas?
No. Consulta sus datos y envía avisos, pero no cambia sus estados ni sus fechas.
¿Puede enviar el mismo aviso varias veces?
Sí. No implementamos un registro de avisos enviados. Por eso detuvimos la programación después de la prueba.
¿Un envío correcto en n8n garantiza que el correo llegue?
No. El servidor SMTP aceptó el primer mensaje, pero Gmail lo rechazó después. Comprobamos la recepción por separado.
¿Por qué el primer mensaje no llegó a Gmail?
La devolución indicó que no había superado SPF ni DKIM. Corregimos la autenticación del dominio y repetimos la prueba.
¿Los mensajes llegan siempre a Recibidos?
No podemos garantizarlo. El primer mensaje recibido tras la corrección apareció en Spam.
¿Cuánto cuesta cada aviso?
No lo medimos. No registramos los tokens ni calculamos el coste por mensaje.
¿La automatización sigue enviando correos?
No. Retiramos la publicación del flujo al terminar la prueba programada.
Fuentes oficiales
- Filter de n8n: condiciones para seleccionar las tareas.
- docs.n8n.ioSend Email de n8n: envío de correo mediante SMTP.
- docs.n8n.ioRequisitos de Gmail para remitentes: autenticación del correo y requisitos de entrega.
También puedes aprender
Continúa con estos contenidos del Laboratorio AF:
- Clasificar correos con IA y n8n: recepción de mensajes mediante IMAP y clasificación con Gemini.
- Generar informes con IA y n8n: lectura de dos tablas internas, ejecución programada y creación de un archivo descargable.
- Crear borradores en WordPress con IA y n8n: generación de contenido y envío a WordPress para revisión.
- Proyecto 4 · Crear un agente IA para organizar tareas: planificación de actividades y comprobación de sus límites.
Ver todas las entradas del blog
⚠️ Aviso importante
Esta automatización es una prueba educativa con tareas ficticias. Los datos de las tareas seleccionadas se envían a la API de Gemini para redactar los avisos. Revisa las condiciones del proveedor antes de utilizar información real.
Comprueba el destinatario y el contenido antes de activar los envíos. Una programación puede repetir mensajes y consumir recursos mientras permanezca activa; nuestro flujo no incluye un control de duplicados.
La aceptación de un mensaje por el servidor SMTP no garantiza su entrega. Revisa las devoluciones y comprueba la recepción cuando sea necesario.
No utilices este prototipo como único sistema de aviso para obligaciones importantes. Al terminar las pruebas, dejamos su programación detenida.