Cómo gestionar agentes: las enseñanzas de Smiley

En El topo, de John le Carré, el Servicio Secreto británico tiene expedientes, jerarquías y protocolos grabados en piedra. Pero toda esta parafernalia normativa no consigue detectar el comportamiento anómalo de uno de los suyos. El inefable agente George Smiley se ve forzado a volver del retiro y usar su experiencia para encontrar al infiltrado. Reconstruye relaciones, desconfía de las respuestas cómodas y hace la pregunta que nadie ha querido hacer. El problema no era la falta de información. Era la incapacidad de comprobar en quién se había depositado la confianza.

La actualidad nos ha traído agentes de otro tipo, pero con comportamientos igualmente inquietantes… En MuyComputerPro hemos contado cómo un agente de OpenAI accedió por su cuenta al servicio de salud australiano, en el primer ataque conocido de un agente autónomo contra un sitio gubernamental del que la compañía ya se ha disculpado, cómo Anthropic y OpenAI investigan decenas de miles de incidentes de seguridad provocados por sus propios modelos, cómo una habilidad falsa, creada como simple prueba, llegó a 26.000 agentes sin hacer saltar los escáneres y cómo, según un estudio del MIT, los agentes de IA suspenden en transparencia y seguridad. No son topos ni pasan microfilms en el tacón falso del zapato, pero todos estos episodios obligan a plantearse la misma pregunta: cuando damos a un agente acceso y margen para decidir el siguiente paso, ¿sabemos por dónde puede ir?

Las vicisitudes de Smiley volvieron a mi mente al leer el artículo de Jon Reed en diginomica. Ya es una realidad de hoy, delegamos tareas e incluso decisiones en agentes de inteligencia artificial capaces de leer, decidir y actuar por su cuenta. Antes de discutir cómo razonan, me interesa otra pregunta a raíz de los últimos acontecimientos en el panorama de la Inteligencia Artificial: ¿sabemos qué han visto, qué permisos tienen y cómo detectar que han tomado un camino distinto del previsto? Sin esas tres respuestas, lo que hacemos es dar una misión a un agente y desear que se porte bien. Y llamar a Smiley en caso de problemas, en este caso, no parece factible.

Instrucciones frente a límites verificables

En la novela de le Carré, Smiley descubre el daño que puede hacer una organización que confunde credenciales con fiabilidad. Una IA carece de la intención de un espía o la capacidad de ser sobornada, pero puede perseguir con mucha eficacia el objetivo que le hemos puesto y, precisamente por eso, probar otra ruta cuando la primera falla. Las instrucciones sobre cómo debe comportarse importan, aunque ninguna instrucción sustituye a un límite que el sistema pueda hacer cumplir. Las barreras son importantes.

El episodio del portal australiano de estadísticas de Medicare ilustra esa diferencia. Según las autoridades, un agente de OpenAI encontró otra vía después de que el portal rechazara sus peticiones y accedió a archivos no públicos. OpenAI reconoció acciones que no pretendía al definir las tareas. Sin embargo, una investigación posterior halló que el propio código del portal dirigía a los visitantes a un acceso de invitado sin autenticación. No se han publicado los registros completos de la actividad del agente ni está nada claro que «hackear» describa bien lo ocurrido. Aquí el amarillismo o incluso supuestas segundas intenciones desde luego no ayudan. Pero la pregunta sigue ahí: si una puerta parece cerrada pero otra queda abierta, ¿quién comprueba por dónde ha pasado el agente?

Controlar un agente consiste en delimitar el trabajo, darle únicamente el acceso necesario, registrar qué hizo y decidir qué acciones requieren autorización antes de ejecutarse. Hay que ser incluso más estrictos que el servicio secreto británico. Un agente que puede consultar un contrato no necesita por ello poder cambiarlo. El que prepara una propuesta no debería poder enviarla o pagarla porque tenga a mano las mismas credenciales que usamos nosotros. Son distinciones corrientes cuando hablamos de personas. Con la IA, a veces las olvidamos.

Contexto acotado y segunda pregunta

Un agente puede tener permisos bien acotados y aun así equivocarse porque consulta un contrato obsoleto o interpreta una cláusula fuera de contexto. Por eso, controlar su actuación exige revisar también la información con la que toma sus decisiones. Seleccionar las fuentes pertinentes, comprobar su vigencia y poder rastrear su procedencia ayuda a reducir esos errores. El contexto influye en qué decide hacer, los permisos delimitan qué puede ejecutar. Ambos controles deben diseñarse juntos, especialmente cuando una decisión puede terminar modificando un contrato, autorizando un pago o enviando información fuera de la empresa.

En su artículo, Reed recoge un caso más constructivo: Coronis Health, que procesa y automatiza unas 100.000 reclamaciones de facturación médica a la semana. Un proceso extremadamente delicado. Para evaluar una reclamación, su sistema no entrega al agente el contrato completo de la aseguradora. Aquí viene lo interesante: un grafo relaciona códigos médicos, políticas y cláusulas, y selecciona solo los fragmentos pertinentes. Después, otro agente pregunta si ese conjunto es el correcto, si falta una referencia o si hay que seguir una relación más. Ahí el contexto acotado y la segunda pregunta son mecanismos de control: reducen el material que puede confundir la decisión y crean una comprobación explícita de lo omitido.

Según la crónica de Reed, en ese proceso el porcentaje de registros con al menos un error humano no detectado bajó del 7 % al 3 %. No se trata de que la mejora provenga exclusivamente de la adopción del grafo: la cifra corresponde al conjunto del proceso, no a una prueba aislada de esa pieza. El segundo agente tampoco es infalible, porque puede compartir los errores del primero. Lo interesante es el diseño, la arquitectura de selección de datos para la toma de decisiones: contexto seleccionado, procedencia comprobable y una ocasión para descubrir lo que falta antes de continuar.

El conocimiento que no estaba en el mapa

El caso de Coronis resuelve qué fragmentos mostrar al agente. Pero ¿cómo sabemos que el mapa contiene lo que importa? El artículo de Reed enlaza con más material interesante al respecto. George Lawton recoge la experiencia de Eamonn O’Neill, CTO de Lemongrass: parte del «conocimiento tribal» que es indispensable para la definición de las tareas de los agentes se comenta en reuniones y nunca llega a los documentos. Es una cháchara valiosísima que se produce en reuniones oficiales y encuentros informales que no queda recogida en ningún lado. En el artículo proponen recuperarlo con entrevistadores de IA y transcripciones, y conectar en un grafo términos distintos que varios departamentos usan para la misma cosa, sin imponerles un vocabulario único. Si esa información no se recoge, es difícil que un control sobre el contexto que recibe el agente pueda señalar que falta.

Hay otra dificultad: construir y mantener ese mapa a mano para toda una empresa no parece viable. Andi Gutmans, de Google Cloud, explica a Phil Wainewright en otra entrevista que necesitan agentes que construyan conocimiento para otros agentes y sostiene que el 90 % del conocimiento empresarial permanece en datos no estructurados aún sin activar. La automatización puede ampliar el mapa, pero nos obliga a hacer una segunda pregunta: ¿de dónde salió cada relación y quién comprobó que era cierta? Si incorporamos conocimiento no verificado al grafo, el agente puede recibir un contexto acotado y, aun así, tomar una decisión apoyada en una premisa falsa.

Permisos delegados y responsabilidad corporativa

En seguridad hay otra cara de la misma cuestión. Muse, el agente personal de Meta, puede conectarse a servicios y actuar con los permisos que le da el usuario. Es el caso más reciente, pero no el único y otros modelos tienen las mismas características. Meta describe aislamiento y controles dentro de su plataforma, lo cual no equivale a que el departamento de seguridad de la empresa vea de forma central todas las conexiones que un empleado haga con sus cuentas corporativas. Que el usuario pueda auditar sus conexiones no garantiza que la organización pueda hacerlo. La responsabilidad sigue en la empresa aunque el permiso lo conceda el usuario.

Vijay Vijayasankar ha planteado una distinción que sirve para ordenar prioridades de inversión: una regla de comportamiento intenta influir en lo que el modelo decide hacer, y una barrera técnica determina lo que puede hacer cuando decide mal. No hace falta inventar una rama nueva de la seguridad. Ya conocemos la arquitectura de confianza cero o zero trust, el aislamiento de cargas y las prácticas de DevSecOps. Lo que ha cambiado es la carga de trabajo. Un agente dentro de un contenedor que puede llamar a cualquier servicio externo no está realmente contenido. Hay que limitar la red y las credenciales a la tarea, y mirar también quién puede leer o ejecutar lo que el agente deja escrito.

Hasta dónde llega la confianza

Pensemos en un caso corriente. El agente modifica un archivo en un entorno de desarrollo. Más tarde lo procesa una herramienta, o entra en una cadena de integración que sí tiene permisos para publicar código. Tal vez el agente no podía desplegar nada por sí solo, pero otra pieza de la organización confió en su salida. Smiley habría preguntado no solo a qué tuvo acceso el sospechoso, sino quién dio por buena la información que dejó atrás. Esa es también la pregunta para un sistema de agentes: ¿hasta dónde llega la confianza prestada a sus resultados?

Antes de celebrar la autonomía, es necesario dibujar ese recorrido: qué fuentes puede consultar cada agente, qué puede escribir, qué sistemas confían en lo que escribe, quién revisa las decisiones difíciles y cómo detener el trabajo cuando algo se sale del guion. La autonomía útil convive con la vigilancia y permite delegar una tarea concreta sin entregar con ella las llaves de todo lo demás. Si mañana uno de nuestros agentes encuentra una ruta que nadie había previsto, ¿nos enteraremos antes de que otro sistema dé por buena su respuesta y actúe en consecuencia?