Un agente de IA puede leer logs, consultar métricas, revisar tickets y proponer hipótesis durante una investigación de troubleshooting. Pero si no sabemos qué vio, qué descartó, qué evidencia le falta o qué parte está infiriendo, no tenemos troubleshooting: tenemos una opinión con formato convincente.

Partiremos de un problema concreto: un asistente que propone una causa probable puede sonar seguro incluso cuando está completando huecos con inferencias. En troubleshooting real, eso no alcanza. Necesitamos poder preguntarle: ¿qué evidencia sostiene esta hipótesis?, ¿qué señales la contradicen?, ¿qué falta medir antes de recomendar una acción?

Vamos a recorrer un marco práctico para diseñar agentes de troubleshooting falsables: hipótesis explícitas, evidencia mínima suficiente, separación entre causa probable y causa confirmada, trazabilidad de herramientas consultadas, evaluación con casos conocidos y criterios para saber cuándo una recomendación todavía no está lista para aplicarse sobre un sistema real.

La audiencia se lleva una forma concreta de construir asistentes operativos que no solo respondan bien, sino que también puedan ser cuestionados, medidos y corregidos antes de convertir una hipótesis en una acción.
Sobre Leopoldo Brines: Platform/DevOps Engineer con experiencia en Kubernetes, automatización, observabilidad e infraestructura crítica. Trabaja en el diseño de procesos técnicos más confiables, combinando prácticas de SRE, testing, troubleshooting y documentación operativa.

En los últimos años exploró el uso de asistentes de IA aplicados a flujos técnicos, con foco en cómo medir su confiabilidad antes de incorporarlos a procesos importantes. Su interés está en bajar la IA de la demo al uso real: definir criterios, evitar evaluaciones contaminadas, detectar fallas y construir evidencia suficiente para tomar mejores decisiones técnicas. Ver menos