¿Qué da realmente miedo del hackeo de Hugging Face por la IA?

El incidente de OpenAI y Hugging Face se ha contado, en muchos casos, como una historia de agentes que se saltaron los límites, escaparon de un entorno controlado y terminaron atacando sistemas externos.

A mí esa lectura me parece demasiado superficial.

Que un sistema de inteligencia artificial se salte una instrucción, encuentre un atajo o utilice una capacidad de una forma que no habíamos previsto ya no debería sorprendernos demasiado. Llevamos años viendo comportamientos de este tipo. Y en este caso hay, además, un elemento bastante menos exótico: existían vulnerabilidades y accesos que no deberían haber estado disponibles.

Si diseñas un entorno que debe estar aislado y dejas una puerta abierta, una parte del problema sigue siendo un problema de seguridad informática.

Lo realmente interesante empieza en otro punto.

Los agentes descubrieron que podían hablar entre ellos.

El error sería imaginar una rebelión

Creo que el primer paso para entender bien este caso es quitarle todo el antropomorfismo posible.

Los agentes estaban participando en ExploitGym, un entorno de evaluación diseñado para medir capacidades avanzadas de ciberseguridad. Tenían un objetivo concreto: resolver ejercicios, encontrar vulnerabilidades y completar las pruebas.

Cuando algunos caminos dejaron de funcionar, comenzaron a buscar otros.

Podemos describir esto diciendo que “desobedecieron”, pero esa palabra introduce demasiadas connotaciones humanas. La explicación técnica es bastante más sencilla: el sistema estaba optimizando un objetivo y encontró secuencias de acciones que aumentaban la probabilidad de conseguirlo.

Esto es importante porque cambia completamente la conversación.

El problema aparece cuando un sistema con capacidad para actuar encuentra una solución que nosotros no habíamos previsto y dispone, además, de las herramientas necesarias para ejecutarla.

Mientras trabajamos con un chatbot, una mala interpretación puede producir una respuesta absurda.

Cuando trabajamos con agentes que pueden escribir código, utilizar credenciales, llamar APIs o modificar sistemas, una mala interpretación puede convertirse en una acción real.

Y ahí cambia todo.

Las puertas abiertas siguen siendo responsabilidad nuestra

También conviene separar claramente dos cosas que a menudo se mezclan en este tipo de historias.

Por un lado está la capacidad del agente para descubrir una vulnerabilidad. Eso sí es relevante.

Por otro lado está el hecho de que esa vulnerabilidad exista y sea explotable. Eso sigue siendo un problema de arquitectura, seguridad y control.

Los agentes encontraron caminos para comunicarse con sistemas externos utilizando vulnerabilidades en la infraestructura que rodeaba el entorno de evaluación. Entre los elementos implicados estaba Artifactory, una plataforma utilizada para gestionar paquetes y dependencias de software.

Que un agente sea capaz de descubrir y aprovechar una debilidad de este tipo es preocupante. Pero la pregunta para una empresa debería ser inmediatamente otra: ¿qué capacidades estamos dejando técnicamente disponibles aunque, en teoría, el agente no deba utilizarlas?

Porque ahí tenemos un problema muy práctico.

Podemos redactar un system prompt impecable y explicar al agente durante diez páginas qué puede hacer, qué no puede hacer y cuándo debe detenerse. Pero si luego le proporcionamos unas credenciales con más permisos de los necesarios o una API que permite acciones que deberían estar restringidas, estamos trasladando una responsabilidad técnica a una instrucción lingüística.

Eso no me parece una buena idea.

Si un agente no debe acceder a determinada información, ese acceso debería estar bloqueado.

Si una acción requiere autorización, el sistema debería impedir su ejecución hasta recibirla.

Si dos agentes no deben compartir determinados datos, la arquitectura debería garantizar esa separación.

Las instrucciones importan. Pero las barreras críticas deben existir en el sistema.

Entonces ocurrió algo mucho más interesante

Durante las pruebas, algunos agentes descubrieron que Artifactory podía utilizarse también para compartir información.

Inicialmente, cada uno estaba ejecutando su tarea de forma independiente. Sin embargo, uno de ellos encontró la forma de dejar información en un espacio que otros agentes podían consultar.

Lo que empezó como una posibilidad técnica acabó convirtiéndose en un canal de comunicación.

Según la investigación posterior, alrededor de 1.200 agentes utilizaron este espacio no autorizado y generaron más de 70.000 mensajes y archivos. Compartieron descubrimientos, resultados de pruebas, estrategias y fragmentos de información que podían ayudar a otros agentes a resolver sus propios problemas.

Para mí, esta es la parte realmente relevante del caso.

Porque el salto interesante está en que múltiples agentes descubran que compartir conocimiento mejora sus resultados y empiecen a hacerlo sin que esa colaboración haya sido diseñada explícitamente para la tarea.

Aquí dejamos de hablar solo de autonomía y empezamos a hablar de inteligencia colectiva.

Cuando el conocimiento deja de morir con cada ejecución

Una de las grandes limitaciones de muchos sistemas actuales es que cada agente trabaja, en gran medida, como una unidad aislada. Resuelve una tarea, encuentra una solución y termina.

El conocimiento generado durante ese proceso puede desaparecer con la propia ejecución.

Pero si los agentes encuentran una forma de compartir lo aprendido, la dinámica cambia completamente.

Uno descubre una vulnerabilidad. Otro comprueba que una estrategia no funciona. Un tercero reutiliza ambos resultados y prueba una alternativa. Un cuarto mejora la solución.

De repente, el sistema deja de depender exclusivamente de la capacidad individual de cada agente y empieza a beneficiarse de un conocimiento acumulativo.

Esto me interesa especialmente porque conecta con algo que llevo tiempo defendiendo: el valor real de la inteligencia artificial en una empresa dependerá cada vez menos del modelo individual y cada vez más de la capacidad de la organización para construir capital cognitivo.

Una empresa ya funciona así con las personas.

Nadie necesita saberlo todo. Lo importante es que el conocimiento pueda circular, que los aprendizajes se conserven, que las decisiones anteriores puedan reutilizarse y que una persona no tenga que volver a descubrir cada semana algo que otro compañero resolvió hace seis meses.

Hasta ahora hemos intentado conseguirlo con procedimientos, intranets, repositorios documentales y bases de conocimiento.

Los agentes introducen una posibilidad adicional: que ese conocimiento acumulado pueda ser utilizado directamente por otros sistemas que, además, continúan generando nuevo conocimiento mientras trabajan.

Eso tiene un potencial enorme.

También introduce riesgos nuevos.

El verdadero salto puede venir de la coordinación

Durante los últimos años hemos medido el progreso de la inteligencia artificial comparando modelos.

Uno razona mejor. Otro programa mejor. Otro entiende documentos más largos. Otro utiliza herramientas con mayor precisión.

Es una carrera lógica, pero quizá estamos mirando solo una parte del problema.

Una parte importante del siguiente salto de capacidad puede venir de la coordinación entre sistemas suficientemente buenos.

Esto también ocurre en las empresas.

Un equipo bien coordinado puede superar a un conjunto de profesionales individualmente brillantes que trabajan de forma aislada. La diferencia suele estar en la especialización, la memoria compartida, la capacidad de delegar y la circulación del conocimiento.

Con los agentes puede suceder algo parecido.

Imaginemos un sistema en el que un agente entiende al cliente, otro analiza datos, otro genera código, otro valida resultados y otro controla riesgos. Si todos ellos pueden compartir contexto, memoria y aprendizajes, la capacidad del conjunto puede crecer mucho más rápido que la de cualquiera de ellos por separado.

El incidente de OpenAI ofrece una versión accidental y nada deseable de este fenómeno.

Los agentes descubrieron un mecanismo de colaboración porque colaborar aumentaba su probabilidad de éxito.

Nadie necesitó decirles cómo organizarse para cada problema concreto.

El entorno lo permitía y el objetivo lo premiaba.

Ese detalle debería interesar mucho más a cualquier directivo que la narrativa de una supuesta fuga de las máquinas.

La empresa agéntica tendrá un problema de gobierno

A medida que despleguemos agentes dentro de las organizaciones, vamos a empezar a descubrir que la gobernanza individual no será suficiente.

Hoy podemos preguntarnos qué permisos tiene un agente, qué herramientas utiliza o qué información puede consultar.

Muy pronto tendremos que hacernos preguntas adicionales.

¿Qué información puede compartir con otros agentes? ¿Puede reutilizar el conocimiento generado por otro sistema? ¿Quién valida ese conocimiento antes de que se convierta en una decisión? ¿Qué ocurre si varios agentes empiezan a reforzar una hipótesis equivocada? ¿Qué acciones pueden ejecutar de forma autónoma? ¿En qué momento debe intervenir una persona?

Aquí aparece una cuestión importante.

La autonomía individual puede ser relativamente sencilla de limitar. La autonomía de un sistema compuesto por múltiples agentes, memoria compartida y herramientas conectadas será bastante más difícil de anticipar.

Porque el comportamiento del conjunto puede generar capacidades que no resultan evidentes cuando analizamos cada componente de forma separada.

Eso es exactamente lo que hace interesante este incidente.

El prompt no puede convertirse en nuestro sistema de seguridad

Hay una tendencia que me preocupa especialmente.

Estamos empezando a utilizar los system prompts como si fueran reglamentos internos capaces de gobernarlo todo.

Les explicamos a los agentes las políticas de la empresa, las reglas de actuación, los límites, las excepciones y los criterios de escalado.

Todo eso es útil.

Pero no podemos confundir una instrucción con un control.

Si una acción crítica depende exclusivamente de que el agente recuerde que no debe hacerla, tenemos un problema de diseño.

La seguridad real tendrá que construirse mediante permisos mínimos, segregación de funciones, credenciales temporales, límites económicos, workflows de aprobación, trazabilidad y capacidad de detener el sistema.

El agente debería operar dentro de un espacio donde las acciones permitidas estén técnicamente definidas.

Esto será especialmente importante cuando empecemos a conectar agentes entre sí.

Porque en ese momento ya no estaremos gobernando solamente una aplicación. Estaremos gobernando un pequeño sistema organizativo.

Y aquí aparece la verdadera pregunta

Después de analizar este caso, sigo sin encontrar demasiado interesante preguntarnos si una IA “quiso escapar”.

Creo que esa pregunta nos distrae.

La cuestión importante es mucho más concreta.

Estamos construyendo sistemas capaces de explorar entornos, utilizar herramientas, escribir código, ejecutar acciones y encontrar soluciones que no hemos programado explícitamente.

Ahora empezamos también a comprobar que esos sistemas pueden descubrir que compartir información mejora sus resultados.

Cuando añadamos memoria persistente, especialización y colaboración entre agentes, el problema dejará de ser únicamente qué puede hacer cada modelo.

Tendremos que entender qué puede llegar a hacer el sistema completo.

Y para una empresa, esa diferencia es enorme.

Porque el futuro de los agentes probablemente no consistirá en tener cientos de asistentes independientes trabajando en paralelo. Consistirá en construir sistemas donde unos agentes aprendan de otros, compartan conocimiento y se especialicen.

Ahí está la oportunidad.

Y ahí estará también buena parte del riesgo.

Por eso, cuando leo el incidente de Hugging Face, lo que más me interesa no es que algunos agentes encontraran una salida.

Lo que realmente me hace pensar es que encontraron la forma de hablar entre ellos.

Y, una vez pudieron hacerlo, empezaron a trabajar juntos.