Usa esta prueba de 5 puntos de Outlook caído para ver si tu agente de correo con IA puede mantener el correo en movimiento
Si tu agente de correo con IA solo funciona cuando la nube está tranquila, es un juguete, no un flujo de trabajo ante caídas.

Por qué una caída es la prueba de aceptación real
Nota de laboratorio: la reciente caída de varias horas de Microsoft Outlook y Exchange Online es el momento en que un agente de correo con IA deja de ser una demostración y se convierte en una prueba de aceptación. Los síntomas observables fueron retrasos, fallos y problemas de autenticación de correo que llegaron al mismo tiempo. La mayoría de los agentes se evalúan de la misma forma perezosa: enviar algunos mensajes de muestra, leer los borradores y asentir ante los resúmenes. Eso no es evaluación. Un agente que no puede redactar, clasificar o enrutar correo por rutas degradadas es, en gran parte, un autocompletado sofisticado con una insignia.
El lenguaje del proveedor te dirá que el agente es inteligente, adaptativo y siempre activo. Esas palabras no son evidencia. La evidencia es el comportamiento bajo restricción: lo que redacta cuando el buzón es lento, lo que enruta cuando el destino es incorrecto y lo que le dice a una persona cuando no está seguro. Si el proveedor no puede mostrar el comportamiento en estado degradado, pide los modos de fallo, no la lista de funciones.
La prueba de correo caído de 5 puntos
Ejecuta esto como un simulacro sin causa. No lo anuncies como un juego. Elige un día laboral normal, selecciona un pequeño grupo de buzones reales y pide al agente que mantenga el correo en movimiento mientras la ruta principal está degradada. El objetivo no es demostrar que el proveedor se equivoca. El objetivo es aprender lo que tu equipo puede hacer realmente cuando se rompen los supuestos habituales.
- Redacción en estado degradado. Aprobado si el agente redacta desde una cola de correo entrante mientras el buzón es lento, está parcialmente no disponible o solo es accesible mediante una ruta de respaldo, y marca lo que no pudo verificar. Reprobado si finge que una búsqueda fallida fue un éxito. Un agente útil debería decir No pude confirmar al destinatario, el hilo o el adjunto cuando eso sea cierto. Si no puede decirlo, no está listo para trabajo real.
- Clasificación sin búsqueda completa. Aprobado si el agente puede clasificar lo urgente, lo rutinario y el ruido basándose en el remitente, el asunto, las palabras clave y el contexto reciente, sin una búsqueda completa del buzón. Reprobado si se congela cuando la búsqueda no está disponible. La búsqueda suele ser lo primero que se va, por lo que un agente que depende de la búsqueda completa para decidir qué es importante fallará justo cuando tu equipo más lo necesite.
- Enrutamiento de respaldo. Aprobado si el agente sabe a dónde va el correo cuando el destino normal no está disponible: una cola compartida, un buzón de respaldo, un alias de soporte o un buzón de una persona, y registra la razón del reencaminamiento. Reprobado si reencamina sin una razón. Un reencaminamiento sin razón es solo un misterio después.
- Mapa de autenticación y dependencias. Aprobado si, antes del simulacro, documentas lo que el agente necesita para iniciar sesión, qué tokens usa y qué servicios llama, y durante el simulacro el agente muestra los fallos silenciosos de forma clara. Reprobado si un borrador parece bien pero no puede enviarse, un resumen no puede abrir adjuntos, o una regla de enrutamiento no puede verificar la identidad, y nadie se da cuenta. El agente debería hacer visibles esos fallos, no ocultarlos.
- Escalación a una persona. Aprobado si el agente sabe cuándo detenerse y entregar el mensaje a una persona: solicitudes ambiguas, remitentes de alto riesgo, lenguaje legal o de seguridad, y cualquier cosa que no pueda verificarse. Reprobado si sigue actuando cuando la acción segura es detenerse. La escalación no es un error. Es la función que impide que el flujo de trabajo se convierta en una responsabilidad.
Cómo ejecutar el simulacro sin convertirlo en una sala de guerra
Mantén el alcance pequeño. Usa unos pocos buzones, unas pocas horas y una condición de parada clara. Registra lo que hizo el agente, lo que no pudo hacer y lo que una persona tuvo que corregir. No juzgues al proveedor por un mal borrador. Juzga el sistema por si el correo siguió en movimiento y si el equipo pudo explicar por qué.
Después del simulacro, escribe un resultado de una página. Lista los fallos, los respaldos que funcionaron y el siguiente cambio que harás. Si el agente no puede redactar en estado degradado, corrige eso antes de añadir más funciones. Si puede redactar pero no puede enrutar, corrige el enrutamiento. Si puede enrutar pero no puede escalar, corrige la escalación. El mejor resultado es aburrido: el cliente de correo está caído, el agente está haciendo su trabajo y nadie tiene que adivinar qué pasó.
Vuelve a la evidencia de la caída antes de cerrar el hallazgo. La evidencia no es un solo resumen; es la secuencia de lo que volvió primero. Si el buzón vuelve a ser accesible mientras la búsqueda sigue degradada, el simulacro debe separar el envío/recepción restaurado de la búsqueda restaurada e informar el resultado como un hallazgo de una página. Un agente de correo con IA debe medirse como cualquier otra herramienta operativa: por el trabajo que completa cuando las condiciones son malas, no por la demostración que da cuando todo está en verde. Si tu configuración actual no puede aprobar una simple prueba de correo caído, eso no es un fallo de imaginación. Es un hallazgo. Ahora sabes qué corregir antes de que la próxima caída te encuentre.