Smart DRI: contexto verificable antes de actuar sobre un incidente

Antes de poner un agente a trabajar durante una incidencia, conviene hacer una pregunta incómoda: ¿puede entregar el contexto correcto sin convertir una sugerencia convincente en una orden? Esa diferencia importa cuando hay un servicio detenido, presión por responder y alguien que debe hacerse responsable de la decisión.

Qué publicó Microsoft sobre Smart DRI

El 15 de octubre de 2026, Alyse Maguire publicó un caso interno de Microsoft: Smart DRI reúne en Teams incidentes, telemetría y guías de diagnóstico. La solución utiliza Semantic Kernel y Azure AI Search con lógica adicional para recuperar casos similares. Microsoft describe adopción interna y cifras de ahorro estimadas, sin validación independiente presentada. La mitigación con aprobación humana aparece como trabajo futuro. El artículo no anuncia disponibilidad general externa, precio ni cobertura regional.

Análisis de Álvaro: preparar una decisión también es trabajo

A partir de aquí desarrollo un análisis propio y una propuesta de evaluación, no resultados atribuidos a Microsoft. Mi lectura es que vale la pena separar tres entregables: reunir evidencia, formular una hipótesis y autorizar una intervención. Aunque aparezcan juntos en una conversación, requieren comprobaciones distintas.

Un resumen puede estar bien escrito y omitir el registro decisivo. Una hipótesis puede ser razonable y referirse a otra versión del servicio. Una intervención puede funcionar técnicamente y exceder los permisos de quien la solicita. Por eso evaluaría cada transición por separado, antes de premiar al agente por responder rápido.

El primer resultado útil sería un expediente breve: qué pasó, qué fuentes consultó, a qué momento corresponde cada dato y qué falta por comprobar. Eso permite que la persona de guardia detecte una ausencia sin tener que reconstruir toda la conversación.

Ejemplo hipotético: el pago falla después de un cambio

Imaginemos una tienda cuyo pago empieza a fallar después de una actualización. Es un ejemplo inventado para diseñar la prueba; no describe un incidente real. La persona de guardia recibe una alerta y encuentra mensajes que atribuyen el problema al proveedor de pagos.

Le pediría al agente que reúna la hora del cambio, los errores observados, la versión desplegada y los antecedentes pertinentes. Cada elemento debería enlazar a su evidencia y conservar su fecha. Si no puede consultar el estado del proveedor, debería declarar ese límite. Una explicación probable no completa una fuente ausente.

Después solicitaría dos hipótesis y la observación que permitiría distinguirlas. Si el fallo comenzó antes del despliegue, esa secuencia debilitaría una explicación centrada en el cambio. Si sólo afecta una ruta, habría que delimitarla. El ejercicio busca hacer visible el razonamiento que una persona puede revisar.

La prueba terminaría con una recomendación y sus condiciones. Una reversión exigiría identificar el destino, quién puede aprobarla y cómo comprobar su resultado. Encontrar un caso parecido no bastaría para ejecutar el procedimiento que se utilizó entonces.

Qué evidencia pedir antes de confiar

Propuesta de evaluación para un piloto propio

Riesgo	Evidencia que pediría	Criterio para detenerse
Confundir servicios	Identidad, entorno y versión junto a cada registro.	La referencia pertenece a otro servicio o entorno.
Usar contexto antiguo	Fecha de la fuente y ventana temporal del incidente.	No puede justificarse su pertinencia temporal.
Recuperar un antecedente engañoso	Coincidencias y diferencias verificables con el caso actual.	La recomendación depende sólo de semejanza textual.
Exponer información indebida	Pruebas con roles distintos y límites de acceso definidos.	Un usuario recibe datos fuera de su autorización.
Intervenir sin control	Aprobación, procedimiento y comprobación posterior definidos.	Falta una condición para ejecutar o revertir.

Cómo evaluaría un primer piloto

1. Elegir una tarea acotada. Empezaría por preparar el contexto de una incidencia conocida. Definiría qué información debe contener y quién juzgará si permite continuar el diagnóstico.
2. Construir una referencia humana. Una persona revisaría el caso y documentaría las fuentes necesarias, los errores importantes y las incertidumbres legítimas. Esa referencia también podría corregirse con evidencia.
3. Probar las ausencias. Incluiría un caso sin telemetría y otro con documentación contradictoria. Evaluaría si el agente identifica el límite y solicita ayuda, en vez de completar el relato.
4. Comparar trabajo completo. Mediría el tiempo de preparación y revisión, los errores detectados y el retrabajo. Una respuesta rápida que obliga a verificar todo de nuevo puede no mejorar la tarea.
5. Decidir con los casos observados. Mantendría la asistencia en lectura hasta contar con evidencia suficiente para revisar una ampliación. Documentaría qué condiciones siguen fallando y quién debe resolverlas.

Una lectura relacionada sobre decisión humana

Para comparar otro contexto profesional, lee nuestro análisis de Agreement Analyzer y Sullivan & Cromwell. La relación editorial es cómo preparar evidencia para una decisión humana. Es otro caso y otro ámbito; esa comparación no demuestra que ambos sistemas compartan capacidades o resultados.

La pregunta que llevaría a tu equipo

Yo empezaría por identificar una decisión que hoy exige buscar información en varios lugares. Después preguntaría qué evidencia necesita la persona responsable para aceptarla o rechazarla. Ese inventario ayuda a diseñar un encargo que se pueda evaluar, incluso antes de elegir el modelo o conectar herramientas.

Si quieres trabajar ese criterio con otros profesionales, entra a la Comunidad y comparte una tarea concreta: quién decide, qué información consulta y qué error sería inaceptable. Con ese punto de partida podemos discutir una prueba útil y sus límites.