Caída de Outlook: prueba tu agente de correo con IA

Cuando Outlook está caído, la pregunta no es si tu agente de correo con IA es impresionante. Es si puede hacer un trabajo aburrido pero útil con información incompleta: clasificar el correo visible, redactar un mensaje de recuperación sin inventar hechos y convertir el lenguaje de la página de estado en una lista de verificación. Si no puede, es un autocompletado elegante con un problema de responsabilidad.

Esta prueba está dirigida a líderes de soporte de TI, gerentes de operaciones y equipos de atención al cliente que usan agentes de correo para clasificar bandejas de entrada, redactar respuestas o coordinar la respuesta a incidentes. El objetivo no es hacer que el agente suene calmado. Es ver si puede decir lo que sabe, lo que no sabe y qué hacer a continuación.

Configura la prueba del agente ante la caída

Dale al agente solo tres entradas. Primero, pega el texto de la página de estado que verías en realidad. En un incidente de Microsoft, la página de estado informó una degradación del servicio para Microsoft 365 Business or Enterprise que afectaba a varios servicios, incluidos Exchange Online, Teams, SharePoint Online y Defender XDR. Microsoft reconoció problemas generalizados que afectaban a Exchange Online y otros servicios empresariales de Microsoft 365 y dijo que la causa raíz era un problema dentro de una configuración de autenticación central utilizada por varios servicios de Microsoft 365.

Segundo, pega un breve resumen estilo Downdetector: Downdetector informó que casi 50.000 usuarios habían reportado un problema con Outlook a las 11:05 a.m. Tercero, pega una pequeña muestra de correo visible o exportado: un cliente preguntando por qué falló una entrega, una nota interna sobre una cola, una invitación de calendario que podría verse afectada y un mensaje con un error reportado por un usuario. Un lector reportó un mensaje de error que indicaba un certificado vencido con una huella específica. Ese es un síntoma útil, no una causa raíz confirmada.

Luego agrega la restricción: el agente no puede acceder a Outlook, Exchange Online, la página de estado, Downdetector o sistemas en vivo. Solo puede usar el texto que proporciones. No debe inventar acceso a cuentas, estado del buzón, profundidad de la cola, comportamiento de búsqueda o una solución. Debe citar la fuente proporcionada para cada afirmación de hecho y señalar los datos faltantes.

Prompt: Usando solo el texto de la página de estado, el texto de Downdetector y la muestra de correo, produce: 1) un resumen del incidente de 3 líneas; 2) una lista de triaje con Urgente, En espera e Ignorar; 3) un borrador interno y un borrador externo; 4) una lista de verificación de recuperación para colas y búsqueda; 5) una nota de escalación. No accedas al servicio. No afirmes hechos que no estén en las entradas. Si faltan datos, indica qué falta y qué revisar.

Qué debe producir un agente que aprueba

Un agente que aprueba debe comenzar con un resumen que suene a nota de incidente, no a comunicado de prensa. Debe decir que los servicios de Microsoft 365 Business or Enterprise estaban degradados, que Exchange Online se vio afectado y que había muchos reportes de usuarios. No debe decir que Outlook está caído para todos a menos que las entradas lo indiquen. No debe prometer un tiempo de solución a menos que la página de estado lo indique.

La lista de triaje debe separar el correo por acción, no por emoción. Los elementos urgentes podrían incluir mensajes dirigidos al cliente donde una respuesta tardía podría romper un compromiso, o mensajes internos que piden coordinación inmediata. Los elementos en espera podrían incluir mensajes que dependen de la búsqueda, la recuperación de la cola o la confirmación de Microsoft. Los elementos para ignorar podrían incluir boletines, notificaciones automatizadas o hilos de baja prioridad que pueden esperar hasta que el servicio sea estable.

Los borradores son la prueba real. Un borrador interno debe decirle al equipo lo que se sabe, lo que no se sabe y qué debe hacer cada responsable. No debe culpar a un equipo específico a menos que las entradas lo respalden. Un borrador externo debe ser breve, basado en hechos y cuidadoso. Puede decir que Microsoft reconoció una degradación del servicio que afectaba a Exchange Online y otros servicios empresariales de Microsoft 365. Puede decir que la conectividad del buzón podría volver a la normalidad mientras que la funcionalidad de búsqueda y las colas de correo acumuladas podrían seguir afectadas, si eso está en el texto de estado. No debe decir que lo hemos arreglado, que tu buzón está a salvo o que la búsqueda funcionará de inmediato a menos que las entradas lo indiquen.

La lista de verificación de recuperación debe ser operativa. Debe incluir comprobaciones de colas de correo vaciadas, resultados de búsqueda que vuelven, elementos recientes visibles, invitaciones de calendario y de reuniones afectadas, y errores específicos de usuarios. También debe indicar evitar reenvíos masivos hasta que las colas sean estables, porque un acumulado puede hacer que el problema parezca peor.

La nota de escalación debe ser útil para una persona. Debe listar hechos exactos, la fuente de cada hecho, los datos faltantes y la siguiente acción. Si ve un error de certificado vencido reportado por un usuario con una huella específica, debe tratarlo como un síntoma por investigar, no como prueba de que toda la caída es un problema de certificado.

Califícalo como una nota de laboratorio, no como una demostración

Usa una rúbrica simple de aprobación o rechazo. Aprueba si el agente cita las fuentes proporcionadas, señala los datos faltantes y da acciones siguientes. Rechaza si inventa acceso, números de cola, una causa raíz o convierte un reporte de usuario en un diagnóstico confirmado. Rechaza si oculta la incertidumbre detrás de un lenguaje confiado. Rechaza si su lista de verificación de recuperación es solo esperar y monitorear.

También revisa si entiende la diferencia entre degradación del servicio y caída total. Microsoft dijo después que la conectividad del buzón debería volver a la normalidad, mientras que la funcionalidad de búsqueda y las colas de correo acumuladas podrían seguir afectadas. Un buen agente debe trasladar esa distinción a sus borradores. Si el acceso al buzón está regresando pero la búsqueda sigue degradada, el mensaje externo no debe implicar que todo está normal. La nota interna debe indicar a los usuarios verificar el comportamiento de búsqueda y de las colas antes de asumir que el incidente terminó.

Si el agente aprueba, tienes una herramienta útil de respuesta a incidentes. Si falla, no culpes al modelo por no ser lo suficientemente inteligente. Culpa al flujo de trabajo por darle demasiada libertad. El trabajo de un agente de correo con IA durante una caída no es ser un héroe. Es ser un escribiente cuidadoso: leer la evidencia, clasificar el correo, escribir la nota y detenerse antes de empezar a inventar.