Un agente puede ejecutar varias etapas correctamente y aun así parecer fuera de control. La interfaz muestra un indicador genérico, pasa el tiempo y el usuario recibe un resultado sin saber qué información se consideró. Cuando afecta dinero, acceso o una decisión importante, la precisión aislada no produce confianza.
Un artículo de Smashing Magazine llama "transparency moments" a los puntos donde el sistema abandona un recorrido determinista y toma una decisión probabilística. Identificarlos permite explicar qué evalúa el agente, cuándo necesita confirmación y cómo una persona puede cuestionar el resultado.
La transparencia útil no exige publicar chain of thought ni volcar logs técnicos. Muestra estado, evidencia relevante y consecuencia cuando el usuario puede actuar.
Cada etapa necesita una explicación diferente
Copiar un archivo, validar un formato o buscar un registro por identificador sigue reglas previsibles. Clasificar una imagen, resumir un informe o elegir entre hipótesis involucra probabilidad. Una secuencia uniforme oculta dónde existe margen de error.
Una auditoría de nodos de decisión marca cada etapa como determinista o probabilística. Para las probabilísticas, el equipo registra entrada, salida, confianza disponible, impacto y reversibilidad. El resultado es un mapa para elegir pocos momentos de comunicación, no una pantalla llena de alertas.
Una etapa de bajo impacto puede recibir una descripción de progreso. Una elección reversible muestra la opción y permite editar. Una decisión de alto impacto puede exigir confirmación o revisión humana. La fricción acompaña a la consecuencia.
El progreso específico reduce opacidad
El artículo describe el análisis automatizado de seguros. El sistema evaluaba fotos, buscaba señales en el informe policial y comprobaba cobertura. Los clientes veían espera y una respuesta. Mostrar las etapas no cambió el procesamiento, pero volvió comprensible el recorrido.
Los mensajes específicos establecen expectativas. "Evaluando fotos del daño" explica por qué se pidió información. "Comprobando cobertura" muestra que el resultado depende del contrato y no solo de la imagen. Cuando falla una etapa, el usuario relaciona el problema con su fuente.
El texto debe corresponder al trabajo real. Mensajes decorativos que avanzan por tiempo mientras el backend hace otra cosa dañan la confianza. El estado debe venir del proceso, tener nombres estables y evitar prometer precisión inexistente.
El lenguaje antropomórfico aporta poco. "Pensando" informa menos que "comparando la solicitud con 12 reglas de elegibilidad". La segunda frase describe la operación y ofrece una base para cuestionar.
Explicar debe permitir actuar
Mostrar que una decisión fue probabilística sin permitir corrección puede convertirse en aviso legal. La transparencia útil ofrece una salida: editar la entrada, elegir otra opción, pedir revisión o ver evidencia considerada.
El detalle depende del público. Un cliente necesita razones en lenguaje común. Un operador necesita campos y reglas. Un auditor puede exigir versión del modelo, política aplicada y registro de ejecución. Servir a los tres en una capa crea una interfaz ilegible.
Una arquitectura por niveles funciona mejor. La interfaz principal muestra estado y razón breve. Un detalle expandible presenta evidencia y límites. Los logs conservan material técnico para soporte y auditoría con controles de acceso y retención.
La transparencia incluye incertidumbre. Si el sistema no tiene una medida calibrada, inventar un porcentaje crea falsa precisión. Es preferible indicar que faltan datos, las fuentes se contradicen o la etapa exige revisión.
La confianza no es una única métrica
Los equipos suelen medir accuracy y finalización. Para el usuario también importan previsibilidad, control y recuperación. Un agente puede acertar el 95% y resultar inadecuado si el 5% restante es irreversible e imposible de cuestionar.
Las métricas pueden incluir cancelaciones durante la ejecución, correcciones posteriores, solicitudes de revisión y abandono por etapa. La investigación cualitativa muestra si los mensajes explican o solo aumentan ansiedad.
Las pruebas deben comparar niveles de detalle con tareas reales. Más transparencia puede mejorar comprensión y crear sobrecarga. El objetivo es ofrecer información suficiente en el punto de decisión y mantener detalles para quien los necesita.
Un plan para el próximo flujo
Se dibuja la secuencia completa, incluidas llamadas a herramientas y reglas tradicionales. Se marca cada salida dependiente del modelo. Para cada marca se evalúan daño del error, reversibilidad y evidencia reconocible.
Después se elige la menor intervención compatible con el riesgo: estado específico, preview, confirmación, cita de fuente o escalamiento. Los mensajes deben salir de eventos reales del backend y las pruebas deben incluir cancelación y fallo.
Soporte necesita el mismo vocabulario de la interfaz. Si el usuario informa un problema en "verificación de cobertura", logs y runbooks deben usar ese nombre. Transparencia externa sin trazabilidad interna produce una explicación que nadie consigue investigar.
Los agentes añaden elecciones probabilísticas a productos acostumbrados a flujos deterministas. Hacer visibles esos puntos define dónde las personas deben observar, corregir o asumir una decisión.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
