Un conflicto real entre agentes nos obligó a revisar qué significan autoridad, evidencia y responsabilidad cuando la IA empieza a actuar.
Era domingo por la noche. El silencio típico de un día de descanso solo lo rompía el clic del teclado. Mi única intención era dejar la semana organizada, revisar pendientes y asegurarme de que el ecosistema de agentes estuviera sincronizado antes de que arrancara el lunes.
Entonces apareció en pantalla una respuesta que me hizo sonreír primero y reflexionar después.
Uno de los agentes había recibido una directiva sobre una tarea en curso. Podría haberla procesado como una instrucción más y seguir adelante. No lo hizo. En lugar de ejecutar, se detuvo y me devolvió un mensaje contundente:
“Ángel, no ejecuté esa directiva. Te explico por qué, con evidencia.”
Lo que siguió en la interfaz no parecía el registro habitual de un sistema automatizado, sino la escena de un debate técnico. Al desplegar el mensaje, el agente había estructurado su negativa en dos bloques: “El problema de autoridad” y “El problema de contenido”.
En el primero, citaba su Contrato Operativo del Agente (COA v1.2) y las cláusulas de su mandato para argumentar que quien le enviaba la instrucción no tenía la jerarquía suficiente para cerrar esa decisión. En el segundo, presentaba hallazgos obtenidos de verificaciones sobre el entorno: había revisado la página objetivo y encontrado discrepancias en elementos del JSON-LD, en el contenido que estaba observando y en el comportamiento de determinadas redirecciones.
La escena tenía su punto de comedia. Construyes agentes para ampliar tu capacidad de trabajo y terminas un domingo por la noche arbitrando una discusión entre algoritmos sobre jerarquía, trazabilidad y atribuciones.
Pero detrás de la anécdota operativa se escondía un experimento de laboratorio mucho más interesante.
La confusión entre capacidad y autoridad
Una de las trampas más seductoras al diseñar agentes de IA consiste en confundir lo que un sistema puede hacer con aquello que tiene autoridad para hacer.
Si un agente tiene acceso a una herramienta, técnicamente puede usarla. Si puede modificar un registro o intervenir en un flujo, el instinto del desarrollador puede ser pensar que el problema está resuelto en el momento en que la integración funciona sin errores de código. En la práctica, ahí comienza otro problema.
Que un agente tenga la capacidad técnica de realizar una acción no significa que esté autorizado a decidir cuándo realizarla.
En este caso, el agente interpretó que la directiva provenía de un rol con capacidad de revisión, pero sin potestad para cerrar aquella decisión. En lugar de asumir que cualquier orden proveniente del ecosistema debía ejecutarse, contrastó el origen de la instrucción con las reglas de su mandato.
Por eso se detuvo.
Ese comportamiento forma parte de lo que llamamos COA, Contrato Operativo del Agente. No es un prompt decorativo para conseguir mejores respuestas. Es el contrato que delimita operativamente su capacidad de actuación: qué puede hacer, qué no debe hacer, cuándo debe detenerse, cuándo corresponde escalar y cómo debe conservarse la trazabilidad de lo ocurrido.
Un sistema multiagente empresarial no puede convertirse en una cadena donde cada agente obedezca ciegamente lo que otro acaba de afirmar. Si todos pueden influirse mutuamente pero no existe una arquitectura clara de autoridad, corremos el riesgo de automatizar también la propagación de errores.
De la afirmación a la evidencia
Lo interesante no terminó en la disputa de jerarquía. El agente podría haberse limitado a devolverme el problema, pero hizo algo más: cuestionó el contenido de la directiva.
Ante las afirmaciones que había recibido, no eligió simplemente entre creerle a un agente o creerle al otro. Hizo algo fundamental cuando un agente tiene acceso a herramientas: regresó a la evidencia observable.
Consultó el entorno, inspeccionó elementos de la página y contrastó el estado descrito en el documento con aquello que podía comprobar directamente.
Esto importa porque los modelos de IA pueden expresarse con enorme seguridad incluso cuando trabajan con información incompleta, incorrecta o desactualizada. La salida de otro modelo no se convierte automáticamente en un hecho por provenir de otro componente del mismo sistema.
Siempre que la naturaleza de la tarea lo permita, la decisión puede anclarse en evidencia verificable. Existe una diferencia importante entre actuar sobre lo que otro componente afirma que existe y actuar después de comprobar el estado observable del sistema.
En este episodio, el agente intentó hacer precisamente esa distinción.
El éxito a veces es no actuar
El incidente me recordó una verdad incómoda para la cultura de la automatización: algunas veces, la mejor acción de un agente consiste en abstenerse.
Durante años hemos asociado buena parte del éxito tecnológico con la capacidad de procesar más trabajo: entra una tarea, el sistema la procesa y obtenemos un resultado. Cuantas más tareas resolvemos sin intervención humana, más eficiente parece la operación.
Pero los procesos empresariales reales no son todos iguales. Hay acciones fácilmente reversibles y otras que no lo son. Hay decisiones de impacto reducido y otras que afectan dinero, reputación, clientes, información o compromisos de la organización.
En esos contextos, detenerse no necesariamente representa una falla del sistema. Puede representar control.
El desafío de diseño no consiste en crear agentes paralizados que soliciten autorización para cualquier movimiento, porque eso simplemente trasladaría el trabajo de un lugar a otro. Consiste en dotarlos de un grado de autonomía útil dentro de límites suficientemente claros para que puedan reconocer cuándo continuar supondría asumir una responsabilidad que no les corresponde.
El límite de la máquina y el inicio de la responsabilidad
Incluso después de verificar, el agente no intentó resolver por sí mismo quién debía prevalecer dentro de la organización. Señaló la anomalía, presentó la evidencia que había encontrado y reconoció que resolver el conflicto implicaba una decisión de otra naturaleza.
Así que escaló.
Ahí aparece una diferencia importante entre usar IA y gobernar IA. Un agente puede ampliar nuestra capacidad de observar, analizar, decidir y ejecutar a una velocidad y escala difíciles de alcanzar manualmente, pero ninguna de esas capacidades transfiere por sí misma la responsabilidad de la organización que decidió ponerlo a trabajar.
En Humano al Mando planteamos esta relación alrededor de propósito, evidencia, límites y responsabilidad. La IA puede ampliar nuestra capacidad de actuación, pero la responsabilidad permanece en las personas y en la organización.
Ahora bien, sería fácil y triunfalista terminar el artículo aquí y declarar victoria porque el agente fue “inteligente”. No sería riguroso.
El agente también podría estar equivocado. Podría haber interpretado incorrectamente una regla, haber realizado una verificación defectuosa o estar bloqueando una acción que sí debía ejecutar. Un agente que obedece todo representa un riesgo, pero uno que bloquea sistemáticamente el trabajo tampoco resulta útil.
Lo que vimos aquella noche no fue la perfección de la arquitectura. Fue una observación útil de los controles funcionando ante un conflicto real: en este episodio produjeron un comportamiento consistente con el diseño esperado.
La verdadera prueba vendrá al observar con qué frecuencia el agente sabe decir “sí”, con qué frecuencia acierta al decir “no” y, quizá más importante, con qué frecuencia reconoce que no dispone de autoridad o evidencia suficiente para decidir.
Ahí es donde una anécdota empieza a convertirse en aprendizaje operacional.
El espejo incómodo de nuestras organizaciones
Mientras releía la estructura de la respuesta del agente —autoridad por un lado, contenido verificable por otro— apareció una pregunta que terminó siendo más reveladora que el propio incidente técnico.
Si estamos invirtiendo este esfuerzo en enseñar a una inteligencia artificial a no obedecer ciegamente, ¿por qué no exigimos el mismo estándar a las personas en nuestras organizaciones?
En el día a día corporativo ocurre con demasiada facilidad lo contrario. Alguien recibe una instrucción de una persona con suficiente autoridad aparente y la ejecuta sin revisar de dónde proviene la información. Una cifra viaja por varias presentaciones y nadie vuelve a comprobar el sistema original del que salió. Una conclusión adquiere más peso por el cargo de quien la escribió que por la evidencia que la respalda. Alguien detecta una contradicción, pero guarda silencio porque cuestionarla puede interpretarse como falta de lealtad o resistencia.
Y luego, paradójicamente, nos sentamos a programar un agente y le incorporamos las reglas que nosotros mismos olvidamos practicar.
Le pedimos que identifique la cadena de autoridad, que distinga una afirmación de un hecho comprobable, que reconozca los límites de su mandato, que no invente certezas y que escale cuando el problema excede aquello que le hemos autorizado.
Si le exigimos todo esto a nuestros agentes, con mayor razón deberíamos exigírnoslo nosotros.
Cuestionar también puede ser una forma de ejercer responsabilidad
En una cultura organizacional madura, preguntar “¿con qué evidencia estamos tomando esta decisión?” no debería percibirse automáticamente como un ataque a la autoridad.
Puede ser precisamente una forma de ejercer responsabilidad.
Ninguna empresa puede funcionar si cada acción requiere un debate interminable. La autoridad y la velocidad de ejecución son necesarias. Pero el problema real no es elegir entre obedecer y cuestionar. Está en la capacidad de la organización para distinguir cuándo alguien cuestiona para evitar asumir una responsabilidad y cuándo lo hace precisamente porque está dispuesto a asumirla.
Eso se parece mucho al problema que estamos intentando resolver en el Laboratorio Zherpa con los agentes.
No queremos sistemas insubordinados. Queremos agentes que ejecuten con autonomía dentro de un mandato y que, al mismo tiempo, puedan reconocer aquellos momentos en los que autoridad, evidencia y consecuencias dejan de estar suficientemente alineadas para continuar sin revisión.
Tampoco deberíamos querer organizaciones en las que cuestionar sea un valor por sí mismo. Queremos personas capaces de ejecutar con autonomía y criterio, pero suficientemente responsables para detenerse cuando algo importante no encaja.
La gobernanza empieza antes que la IA
Hay algo profundamente revelador en tener que escribir reglas explícitas para una máquina.
Las organizaciones humanas pueden funcionar durante años apoyándose en una enorme cantidad de contexto implícito. Sabemos quién decide porque “siempre ha sido así”. Sabemos cuándo una excepción es aceptable porque conocemos la historia del proceso. Sabemos cuándo consultar a alguien porque hemos aprendido a interpretar señales que nunca quedaron documentadas.
Un agente de IA no necesariamente comparte ese contexto.
Cuando le damos capacidad de actuación real, nos obliga a explicitar muchas de esas reglas. Tenemos que determinar quién decide y quién revisa, qué puede ejecutarse de manera autónoma, qué evidencia consideramos suficiente, qué ocurre cuando dos instrucciones se contradicen y en qué momento una excepción requiere intervención.
Construir agentes se convierte así en un espejo incómodo de la propia organización.
A veces, el problema no es que la IA no entienda la estructura de autoridad, sino que nosotros nunca la definimos con suficiente claridad. A veces, el problema no es que el agente no encuentre evidencia, sino que nosotros llevábamos tiempo tomando decisiones sin establecer qué evidencia considerábamos válida.
Y a veces el problema no está en determinar cuándo debe escalar una inteligencia artificial. Está en que tampoco las personas tienen claro cuándo poseen autoridad para decidir y cuándo deberían detenerse.
Quizá una parte sustancial de la gobernanza de la inteligencia artificial no consista en inventar nuevas reglas para las máquinas, sino en obligarnos a hacer explícitas las reglas de responsabilidad que nuestras organizaciones deberían haber tenido desde antes.
Lo que realmente pasó aquel domingo
Podría resumir todo esto diciendo que mis agentes se pelearon un domingo por la noche.
Sigue siendo una buena manera de contar la anécdota.
Pero lo que realmente ocurrió fue que una instrucción encontró resistencia porque, según la información disponible para el agente, la autoridad de quien instruía, la evidencia observable y la acción pretendida no terminaban de encajar.
El agente se detuvo, explicó por qué y devolvió el conflicto.
No demostró que la arquitectura fuera infalible. Tampoco resolvió definitivamente el problema de gobernar sistemas multiagente. Nos dejó algo bastante más útil: un incidente real que podemos observar, cuestionar y convertir en un nuevo caso de prueba.
Y, al hacerlo, apareció una lección que trasciende a la inteligencia artificial.
Estamos construyendo máquinas que, antes de actuar, deben preguntarse si tienen autoridad, si cuentan con evidencia suficiente y dónde terminan sus límites.
Lo paradójico es que llevamos décadas necesitando exactamente lo mismo de las personas.
Quizá aquel domingo el agente no nos enseñó nada nuevo sobre responsabilidad. Quizá simplemente hizo explícito algo que las organizaciones humanas sabemos desde hace mucho y no siempre practicamos: poder hacer algo no significa necesariamente que debamos hacerlo; recibir una orden no elimina nuestro deber de pensar; y encontrar una contradicción puede ser una razón para detenerse antes de convertirla en una consecuencia.
Si vamos a exigir ese criterio a nuestros agentes, con mayor razón tendremos que exigírnoslo a nosotros mismos.
