← Todos los insights

Nota de campoEnfoque: España y Latinoamérica4 min de lectura

Antes de operar un sistema, un agente debería poder explicarlo. Pocos sistemas guardan suficiente historial

El primer agente útil en un sistema complejo suele ser de solo lectura: explica qué pasó. Depende de cuatro registros que las plataformas guardan mal; encontrar los huecos es el primer entregable.

Escuche este artículo · 5 min

Narración completa del artículo, generada con IA.

Un plano de planta arquitectónico con un bolígrafo y una regla, en duotono La Madre, junto a las palabras Explicar antes de actuar
Foto: rawpixel (CC0)

La mayoría de los programas de agentes empiezan preguntando qué debería hacer el agente. En sistemas complejos, la primera pregunta mejor es qué puede explicar.

Bayer Crop Science dio un ejemplo nítido la semana pasada. Su plataforma ejecuta más de 500 configuraciones de modelos de machine learning para mejoramiento vegetal, y el problema no era ejecutarlas; era que nadie salvo los ingenieros podía decir por qué un resultado se veía como se veía. Los agentes que construyó Bayer son de solo lectura y explican qué hizo la plataforma. Bayer informa que cerca del 80% de las preguntas hoy se responden sin un ingeniero.

El patrón no es único. Minerva, de NVIDIA, mapea un clúster de GPU y sus trabajos en un solo grafo para que un operador pueda rastrear una ejecución lenta hasta un componente. Los agentes de operaciones de AWS y Microsoft producen un diagnóstico que es un punto de partida, no un hallazgo. Microsoft está construyendo modelos semánticos en Dataverse para que los agentes entiendan qué significan los registros antes de tocarlos. En cada caso, lo primero valioso que hace la IA es volver legible un sistema que ya existe.

Nuestra opinión, expresada como opinión: en un sistema operativo complejo, el agente que explica debería llegar antes que el agente que actúa, y lo principal que entrega en sus primeros meses no son respuestas. Es un mapa de lo que el sistema no puede explicar de sí mismo.

Una explicación necesita cuatro registros

Cuando alguien pregunta «¿por qué pasó esto?», un agente solo puede responder con lo que quedó registrado. Cuatro registros deciden si la respuesta es una explicación o una historia verosímil:

Qué se ejecutó. Historial de ejecuciones con entradas, parámetros, horas de inicio y fin y resultados, incluidos los fallidos y los reintentados. Muchas plataformas guardan el último estado exitoso y poco más.

Qué estaba configurado. Configuración versionada, para que «qué cambió desde la temporada pasada» tenga respuesta. Una configuración editada en el lugar, o guardada en el notebook de alguien, obliga al agente a adivinar.

De dónde vino el dato. Linaje desde el origen hasta la salida. Sin él, «¿la entrada era distinta?» se convierte en una búsqueda que el agente no puede hacer de forma fiable.

Qué significa y quién es su dueño. Definiciones de negocio y un responsable por componente. Un agente que puede nombrar a la persona responsable de un pipeline es más útil que uno que resume sus logs.

Un agente de explicación al que le falta uno de estos registros no falla de forma ruidosa. Produce respuestas fluidas con la pieza faltante rellenada por inferencia. Por eso los huecos hay que medirlos a propósito: registrar las preguntas que el agente no pudo responder, o que respondió sin una fuente, y clasificarlas según cuál de los cuatro registros faltaba.

Por qué este orden reduce el riesgo

Un agente de solo lectura evita las preguntas que bloquean la mayoría de los proyectos de agentes: quién aprueba una acción, cómo deshacerla, quién responde cuando sale mal. Puede entrar en producción antes, con permisos que un equipo de seguridad aprueba en una sola revisión.

También construye la evidencia de lo que viene después. Hemos sostenido que la autonomía se gana una clase de acción a la vez. Un agente que ha explicado mil fallos correctamente, con fuentes, es el mejor argumento para dejar que proponga una corrección. Un agente al que nunca se le ha pedido explicar nada se está confiando a una demo.

Y obliga a la reparación de datos que los agentes que actúan necesitarían de todos modos. Señalamos que el primer resultado duradero de un agente suele ser el dato que te obliga a arreglar. Un agente de explicación encuentra esos huecos sin haber actuado antes sobre ellos.

En el trabajo regulado, esto ya es el estándar

Los equipos de ciencias de la vida y de banca reconocerán los cuatro registros. Las expectativas de integridad de datos en la fabricación farmacéutica piden registros atribuibles, contemporáneos y originales; la gestión del riesgo de modelos en banca pide documentación que permita a otra persona reproducir un resultado. Un agente de explicación es, en la práctica, una prueba continua de si un sistema cumple ese listón, ejecutada por un lector que hace más preguntas que cualquier auditor.

Eso sugiere una secuencia práctica para cualquier sistema complejo que una organización quiera automatizar:

  1. Desplegar un agente de explicación de solo lectura para las personas que hoy esperan a los ingenieros.
  2. Registrar cada pregunta que no puede responder desde una fuente registrada y clasificar el hueco.
  3. Arreglar los registros, empezando por los huecos que bloquean más preguntas.
  4. Solo entonces dejar que un agente recomiende acciones y, más adelante, las tome, una clase de acción a la vez.

El atractivo de los agentes es que actúan. Los sistemas que vale la pena automatizar son los que primero pueden explicarse a sí mismos, y un agente es una buena forma de averiguar cuáles son.

¿Tiene un caso de uso de IA detenido entre el prototipo y la producción?

Cuéntenos qué quiere poner en marcha. Le respondemos con próximos pasos honestos.

Conversemos sobre un caso de uso