Automatizaciones con IA: cómo evitar correos duplicados y tareas repetidas

Una automatización puede redactar un mensaje impecable y, aun así, enviarlo dos veces. El problema aparece cuando el proceso recibe el mismo evento de nuevo, alguien pulsa «reintentar» o una acción se completa pero la plataforma pierde la respuesta. La IA puede ayudar a preparar el texto; no sustituye los controles que determinan si una acción ya ocurrió.

Empieza por separar el borrador de la acción

Imagina una consulta que llega a una pequeña tienda. El flujo clasifica el mensaje, propone una respuesta y crea una tarea para el equipo. La secuencia segura es: recibir, identificar, preparar, revisar, ejecutar y registrar. El correo sugerido por un modelo debe permanecer como borrador hasta que una persona apruebe la versión y el destinatario. La documentación de aprobaciones de Power Automate describe una acción que espera la respuesta antes de continuar; esa capacidad sirve para colocar una barrera humana antes del envío.

La revisión debe abarcar datos personales, promesas comerciales y destinatarios, no solo ortografía. Si la clasificación es dudosa, el flujo puede asignar la consulta a alguien sin enviar nada. Es un diseño propuesto: no hemos medido su rendimiento ni probado una herramienta concreta en Gaia.

Da una identidad estable a cada trabajo

Una alerta no es necesariamente un trabajo nuevo. Anota un identificador de origen que sobreviva a los reintentos —por ejemplo, el ID de la consulta del sistema que la recibe— y combínalo con el tipo de acción: consulta-A104:respuesta-cliente. No uses únicamente la hora de ejecución; cambiaría en cada intento. Antes de crear la tarea o preparar el envío, consulta un registro compartido y reserva esa clave de forma atómica. Si ya existe, el flujo recupera el estado en lugar de empezar otra vez.

La idea se llama idempotencia: repetir la misma petición no debe repetir el efecto. Stripe documenta las claves de idempotencia para determinadas solicitudes a su API. Ese ejemplo muestra el principio, pero no significa que todos los conectores de correo ofrezcan la misma garantía. Si una plataforma no documenta idempotencia para «enviar correo», no la des por supuesta.

Registra estados, no solo un «hecho»

Un registro útil puede distinguir recibido, borrador listo, pendiente de aprobación, autorizado, enviado e incidencia. Guarda también quién aprobó, cuándo, qué contenido salió y el identificador que devolvió el servicio de destino, si existe. Esto permite responder a una pregunta concreta: «¿Falló antes o después del envío?».

Existe un caso difícil: el proveedor acepta un correo, pero el flujo falla antes de guardar «enviado». Un reintento automático ciego podría duplicarlo. Si no hay un identificador fiable ni garantía de idempotencia del proveedor, envía el caso a revisión humana y reconcilia con la bandeja de salida o el registro del proveedor antes de repetir. La guía de pruebas de Microsoft advierte expresamente que volver a ejecutar un flujo puede duplicar registros o correos.

Diseña qué pasa cuando falla cada paso

Un error temporal de red puede justificar un reintento; una dirección inválida necesita corrección. La guía de manejo de errores de Power Automate distingue políticas de reintento, ramas según resultado y avisos de fallo. Define un máximo de intentos, espera entre ellos y una salida visible para las incidencias. No escondas una excepción detrás de un «completado» general.

Si dos ejecuciones leen a la vez «no enviado», ambas podrían pasar. Para acciones con efectos externos, el control de concurrencia y la reserva atómica importan tanto como el identificador. Microsoft explica el control de concurrencia de los disparadores; la configuración exacta depende del conector y de cómo se almacenen los estados. Reducir ejecuciones paralelas ayuda, pero por sí solo no reemplaza un registro de unicidad.

Prueba el fallo antes de activar el envío

En un entorno de ensayo, prepara cuatro situaciones: dos eventos idénticos, una caída antes de aprobar, un error después de que el servicio acepte el envío y dos ejecuciones simultáneas. Para cada una, anota cuántas tareas y correos se generaron y qué quedó en el registro. La meta es poder explicar el resultado, no solo ver una pantalla verde.

Empieza con una acción reversible, como crear un borrador interno. Añade el envío real cuando puedas identificarlo, aprobarlo y auditarlo. Este artículo ofrece un diseño de control, no el resultado de una prueba de plataforma: los límites de reintentos, licencias y conectores deben verificarse en el sistema elegido antes de implantarlo.

Para elegir un primer caso de uso, consulta también nuestra guía de cinco flujos con n8n; toma sus ejemplos como puntos de partida y añade la comprobación de duplicados antes de cualquier envío real.

Fuentes y método

Guía documental revisada el 22 de octubre de 2026 con documentación oficial de Microsoft sobre errores, pruebas de flujos, aprobaciones y Stripe sobre idempotencia. El flujo de tienda es ilustrativo; no se ejecutó una campaña ni se midieron tasas de duplicados.