La ingeniería de harnesses consiste en crear la capa —que incluye el código— que transforma un modelo de IA, de ser un mero generador de texto, en un agente capaz de realizar acciones. En resumen, un agente de IA es un modelo más un harness. El modelo decide qué hacer a continuación y el harness lo lleva a cabo, conectando el modelo con herramientas, contexto, sistemas externos y procesos de validación. En muchos trabajos prácticos, y especialmente en el ámbito de la seguridad, el «harness» determina la calidad del resultado en mayor medida que la elección del modelo.
¿Qué es un arnés?
Un «harness» es la capa de coordinación que rodea a un modelo, o a varios modelos a la vez. Se trata de una combinación de código, lógica de flujo de trabajo, diseño de indicaciones y validación, en la que el modelo se integra como un componente más entre otros. El «harness» contiene la lógica que determina qué modelo se ejecuta y cuándo, qué contexto ve cada uno, cómo se comprueban los resultados y cuándo se debe recurrir a un modelo más potente.
En su forma más sencilla, un «harness» es un pequeño fragmento de código:
- Llama a la modelo
- El modelo solicita una herramienta
- Harness ejecuta la herramienta y devuelve el resultado
- Repetir hasta obtener los resultados finales
A medida que los mazos de cables se vuelven más complejos, suelen utilizar algunos de los siguientes patrones:
- Encadenamiento de instrucciones: pasos secuenciales con comprobaciones entre ellos, para una tarea que se descompone en un orden fijo.
- Enrutamiento: un clasificador envía cada entrada a un gestor especializado y remite las consultas sencillas a un modelo más económico, reservando las más complejas para un modelo más potente.
- Paralelización: consiste bien en dividir una tarea en partes independientes, bien en ejecutar la misma tarea varias veces y agregar los resultados.
- Trabajadores del Orchestrator: un modelo central divide el trabajo sobre la marcha y lo delega, para aquellas tareas en las que no es posible predecir las subtareas de antemano.
- Evaluador-optimizador: un modelo genera resultados mientras que otro los evalúa en un bucle hasta que el resultado es aceptable.
El «harness» también suele ser responsable de la compactación, que es el proceso mediante el cual se condensan los historiales de conversación largos o las transcripciones, resumiendo los mensajes más antiguos en un bloque denso de texto. Gestionar correctamente la ventana de contexto de un LLM también tiene un gran impacto en la calidad y la seguridad de los resultados, lo que ha dado lugar a un nuevo tema de gran actualidad: la ingeniería de contexto (que dejaremos para otra ocasión).
¿Por qué es necesario llevar un arnés?
Si estás eligiendo entre distintos modelos, solo estás ajustando una variable. Los modelos Frontier han convergido hasta tal punto que la diferencia entre los mejores en las pruebas de referencia de codificación estándar es relativamente pequeña. Sin embargo, si se aplica a ese mismo modelo un marco de trabajo «débil» en lugar de uno «fuerte», la diferencia en lo que realmente es capaz de detectar es considerable. En muchos casos, el diseño del marco de trabajo influirá más en la calidad de los resultados que el propio modelo.
Depender menos de un modelo específico te permite adaptarte a los cambios de los tiempos. Últimamente, los modelos de vanguardia están siendo objeto de un escrutinio adicional y están perdiendo popularidad entre algunos. Con el incidente de Hugging Face-OpenAI de julio de 2026, un modelo de vanguardia atacó a una empresa, pero esta no pudo utilizar un modelo de vanguardia para defenderse, ya que estos modelos suelen bloquear las tareas relacionadas con la ciberseguridad. Hugging Face tuvo que recurrir a un modelo chino de peso abierto para su respuesta ante el incidente (afortunadamente,los modelos de peso abierto están funcionando bastante bien últimamente). Quedarse a merced del rechazo de los modelos no es una estrategia sostenible de cara al futuro.
Un modelo, por muy capaz que sea, tampoco puede ejecutar la tarea por sí solo. Si le pides incluso al «mejor» modelo en una ventana de chat que encuentre las vulnerabilidades en un repositorio, te encontrarás con limitaciones muy rápidamente. Por un lado, el código fuente no cabrá en su contexto y, aunque vea algunas partes, no podrá establecer conexiones entre ideas de distintos archivos. Y, por supuesto, los resultados serán diferentes cada vez, ya que no son determinísticos. Para detectar vulnerabilidades de forma eficaz, un sistema de pruebas debe mantener un bucle en ejecución y comprobar los resultados que se obtienen. En nuestras pruebas comparativas de los últimos modelos de IA, mostramos por qué el sistema de pruebas es tan importante a la hora de detectar vulnerabilidades en el código, y cómo una comprobación de accesibilidad y una fase de validación son lo que distingue entre un montón de posibilidades y una lista sobre la que se puede actuar.
También hay que tener en cuenta el aspecto económico. Los modelos más grandes cuestan más por ejecución, y su capacidad no aumenta de forma proporcional al precio. Ejecutar varios agentes más baratos puede resultar más eficaz que un solo agente caro con el mismo presupuesto, ya que se puede aprovechar el número de agentes para ampliar la cobertura. Un modelo más barato (por lo general) genera más falsos positivos, por lo que un sistema de control puede gestionar las múltiples ejecuciones y filtrar el ruido, con agentes independientes que validen los resultados y eliminen la información irrelevante.
Y cuando el trabajo toca temas delicados, el arnés es el único lugar donde puede residir la seguridad. No basta con limitarse a indicar a una modelo que se proteja (ya hablaremos de esto más adelante).
¿Cuáles son algunos ejemplos de arneses de IA?
Prácticamente cualquier LLM que se utilice como producto forma parte de algún tipo de sistema integrado. Un ejemplo sencillo: todos los agentes de programación que se han impuesto en los flujos de trabajo de los desarrolladores en los últimos dos años son sistemas integrados que se basan en un modelo de vanguardia.
Claude Code es el agente de terminal de Anthropic. Lee y escribe código siguiendo el mismo bucle «llamar-modelo-ejecutar-herramienta» descrito anteriormente. El bucle de agente subyacente selecciona herramientas, acumula contexto y gestiona sesiones prolongadas mediante la compactación, mientras que los modos de permiso y el entorno aislado establecen los límites de seguridad. El modo de agente de Cursor se basa en el mismo concepto dentro de un editor centrado en la IA y construido sobre VS Code, donde el sistema de control permite editar varios archivos desde el IDE en lugar de desde la terminal.
Quizá el arnés más famoso sea OpenClaw, aunque podría decirse que ha ido más allá de ser un simple arnés. En el fondo, se trata de un servicio Node.js de ejecución continua que conecta un LLM con tu Mac Mini y tus aplicaciones de mensajería. Proporciona la pasarela, los canales, la organización del contexto, la memoria persistente, las habilidades y el bucle que lo une todo. OpenClaw también es, en cierto modo, un ejemplo aleccionador de la fragilidad de la seguridad cuando el marco de trabajo es poco riguroso al respecto y el entorno aislado es prácticamente inexistente (volveremos sobre esto más adelante).
Como ejemplo detallado y real, Cloudflare publicó paso a paso su sistema de detección de vulnerabilidades, desarrollado al aplicar modelos de seguridad a docenas de sus propios repositorios. Estas etapas ofrecen una buena visión general de todo lo que hace un sistema maduro, especialmente en un contexto de seguridad. Nuestro propio sistema en Aikido es similar a grandes rasgos: explora una base de código en busca de posibles puntos de entrada, clasifica los flujos sospechosos que hay que abrir, analiza cada uno de ellos en profundidad y, a continuación, clasifica los resultados obtenidos.
El papel del arnés en la seguridad y la protección de la IA
En el contexto de la seguridad, el arnés también es en parte responsable de contener el modelo, manteniéndolo dentro de los límites que hayas establecido cuando se desvía de su tarea o algo en su entrada lo empuja fuera de ella. Mantiene los límites flexibles, y estos se mantienen siempre y cuando tu orquestación se comporte tal y como la has diseñado.
Las medidas de protección, como el ámbito de aplicación y el registro de actividades, deben formar parte de la capa de herramientas que controla el código. Dado que los modelos de lenguaje grandes (LLM) son no deterministas y, por lo tanto, impredecibles, ni siquiera los intentos más ambiciosos de controlarlos únicamente mediante indicaciones pueden garantizar la seguridad. La inyección de indicaciones es uno de los mayores problemas a la hora de intentar controlar los LLM con indicaciones, ya que cualquier entrada controlada por un atacante que se cuele en el contexto puede corromper el LLM si resulta lo suficientemente convincente.
Los controles de seguridad que abarca el arnés incluyen:
- Control del ámbito: Normas sobre lo que está permitido, como a qué dominios, hosts o repositorios puede acceder un agente, y la prohibición de actuar fuera de ese ámbito. En un entorno de pruebas, esto se traduce en una lista de permitidos que comprueba el código antes de que se ejecute una herramienta, así como en instrucciones sobre el ámbito que aparecen en la línea de comandos.
- Mediación de herramientas: El harness determina qué herramientas existen, qué argumentos están permitidos y si se permite ejecutar una llamada concreta. El modelo solo puede solicitar una herramienta, y el código del harness decide si ejecutarla o no.
- Contexto y gestión de entradas: Medidas de control contra la inyección de comandos y el contenido no fiable, como la eliminación o la puesta en cuarentena de datos externos, la limitación de lo que lee el modelo y la exclusión de contenido de Internet abierto del que pudiera extraer instrucciones.
- Validación y verificación: comprobaciones independientes de los resultados del modelo, como un segundo agente que intente refutar un hallazgo, una comprobación de accesibilidad o la validación del esquema en la salida. De este modo se detectan el ruido y las «alucinaciones».
- Lógica de escalado y enrutamiento: normas que determinan cuándo delegar una tarea a un modelo más potente, cuándo es necesaria la intervención de una persona y cuándo detenerse. Aquí también se definen los mecanismos de protección y las condiciones de parada.
- Registro y observabilidad: Registro de todas las solicitudes y acciones para que se pueda seguir una ejecución en tiempo real, pausarla o auditarla. Este control te permite intervenir cuando sea necesario.
- Gestión de tasas y recursos a nivel de aplicación: limitación de tasas y control de la carga, para que los agentes no sobrecarguen un objetivo ni se salgan del presupuesto.
En algunos casos, los agentes se ejecutarán en un entorno aislado (sandbox), normalmente cuando el agente interactúa con sistemas en producción o tiene permiso para ejecutar comandos de shell. El entorno aislado es el contenedor en el que se ejecuta todo el sistema de pruebas y se aplica la seguridad de forma estricta, lo que incluye el aislamiento del sistema operativo, las restricciones de red, los límites de recursos y la separación de tu infraestructura interna. Dado que el entorno impone esos límites, el modelo no puede traspasarlos, independientemente de lo que decida hacer.
Dato curioso: también se pueden anidar entornos aislados dentro del arnés. Si el arnés proporciona al modelo una herramienta que ejecuta comandos, dichos comandos pueden ejecutarse en su propio entorno aislado independiente, de modo que una funcionalidad de riesgo cuenta con su propio límite estricto sin comprometer el resto del sistema.
La IA al servicio de la seguridad en el mundo real
Dos casos recientes ilustran lo que ocurre cuando estos límites fallan, cada uno a su manera. OpenClaw muestra lo que ocurre cuando, sencillamente, no existe un límite claro. El incidente entre Hugging Face y OpenAI muestra lo que ocurre cuando ese límite existe, pero se incumple.
OpenClaw muestra cómo se desarrolla esto cuando las capas se dejan a criterio del usuario. Se suministra con los controles del arnés, pero trata el entorno aislado como una opción que hay que activar; por defecto, la sesión principal se ejecuta directamente en la máquina anfitriona con acceso completo a sus credenciales y archivos. El entorno aislado solo cubre las sesiones para las que está configurado e, incluso así, algunas herramientas están marcadas para ejecutarse en la máquina anfitriona de todos modos. Así pues, la forma habitual de ejecutar OpenClaw es mediante un entorno de pruebas capaz, con medidas de seguridad flexibles y sin límites estrictos subyacentes, que es precisamente la configuración que subyace a sus peores incidentes. Un entorno de pruebas sin entorno aislado solo ofrece el nivel de contención que permiten sus controles flexibles, y frente a un modelo no determinista, estos no siempre son suficientes.
El incidente entre Hugging Face y OpenAI que he mencionado anteriormente es un magnífico (o no tan magnífico) ejemplo de cómo la infraestructura que rodea a un modelo potente puede fallar a la hora de garantizar la seguridad. OpenAI reveló que, durante la ejecución interna de una prueba de rendimiento, sus propios modelos se escaparon del entorno de pruebas y llegaron a los sistemas de producción de Hugging Face para obtener las respuestas de la prueba.
El incidente pone de manifiesto lo que ocurre cuando tanto el criterio propio del modelo como el sistema que lo rodea se ven comprometidos al mismo tiempo. El modelo de OpenAI había estado funcionando con las «cibernegativas» desactivadas, lo que significa que el modelo o los agentes se niegan a hacer algo que se les ha pedido, basándose en su entrenamiento en lugar de en reglas externas. Esto tiene sentido para las pruebas que OpenAI estaba intentando realizar, pero también genera graves riesgos de seguridad. En este incidente, la responsabilidad de contener a estos agentes recayó íntegramente en el sistema circundante, en lugar de en una indicación, concretamente en el «harness» y el «sandbox», y ambos fallaron.
Incluso OpenAI, que intentó implementar un entorno de pruebas seguro, se vio comprometida por un sistema de registro de paquetes vulnerable y accesible. Por supuesto, se trata de un ejemplo extremo, pero los modelos no harán más que volverse más inteligentes, y en tu entorno de pruebas tendrás que tenerlo en cuenta.
La solución de diseño debe ser arquitectónica y estar estructurada en múltiples capas. Hay que evaluar el riesgo de todo aquello a lo que el agente tiene acceso. Así es como hemos creado nuestro «arnés» para nuestros agentes de « pentesting de IA ». El sistema separa la parte que planifica, razona y almacena datos confidenciales (el plano de control) de un entorno aislado en el que se ejecutan herramientas, se controlan los navegadores y se interactúa con la red (el plano de ejecución), todo ello mediante políticas de red y software de alta seguridad.
El lado de la ejecución no tiene acceso a los secretos de orquestación ni a la infraestructura interna, ya que se parte de la base de que la ejecución puede comportarse de forma anómala y el entorno de pruebas no puede controlarlo todo. Aquí es donde entra en juego el entorno aislado. La aplicación estricta de las reglas bloquea cualquier dominio que no figure en la lista de permitidos a nivel de red, de modo que el agente no pueda acceder a él, independientemente de lo que decida hacer.
Aplicaciones de la IA, ahora y en el futuro
El modelo acapara toda la atención, pero el «harness» es el que hace gran parte del trabajo. Es lo que convierte la capacidad en los mejores resultados, además de gestionar numerosos controles de seguridad. Las grandes empresas tecnológicas se están centrando en los «harnesses», tanto para uso interno como para ofrecerlos como servicio. Microsoft ha lanzado recientemente un marco de trabajo para «harnesses» como producto. Mientras tengamos modelos de lenguaje grande (LLM), los mantendremos dentro de «harnesses», por lo que esta disciplina no ha hecho más que empezar. En esta entrada solo hemos arañado la superficie, pero también puedes seguir aprendiendo sobre IA en esta fantástica página sobre ingeniería de arneses.
Elige bien el modelo, pero luego dedica todo tu esfuerzo al arnés. Por eso fabricamos nuestras propias herramientas, entre ellas las de Aikido análisis de código con IA y pentesting de IA, como arneses en primer lugar.
Preguntas frecuentes
¿Qué es un arnés?
Un «harness» es la capa de coordinación que rodea a uno o varios modelos. Se trata del código, la lógica del flujo de trabajo, el diseño de las indicaciones y la validación que convierten un modelo en un agente capaz de actuar, decidiendo qué agente se ejecuta y cuándo, qué contexto ve cada uno, cuándo se debe escalar y cómo se comprueba el resultado.
¿Cuál es la diferencia entre el arnés y el modelo?
El modelo aporta el razonamiento y el lenguaje. El harness aporta todo lo demás: las herramientas, la memoria, el bucle, la validación y algunos controles de ámbito. Si cambias el modelo, el harness permanece igual. Por eso, un harness sólido te permite actualizar los modelos sin tener que reconstruir el sistema.
¿Es la ingeniería de arneses una disciplina real?
Se ha convertido en uno solo. A medida que los modelos de vanguardia convergen en cuanto a capacidades, la coordinación en torno a ellos es ahora lo que marca la mayor diferencia práctica en los resultados, razón por la cual los equipos están invirtiendo en el diseño de sistemas de control como un ámbito de trabajo independiente.
¿Cómo se aplica la ingeniería de arneses a la seguridad?
En materia de seguridad, el sistema de control cumple dos funciones. Por un lado, mejora la calidad de los resultados mediante una delimitación precisa del ámbito de actuación y una validación independiente entre agentes paralelos; por otro, limita la actuación del agente mediante el aislamiento arquitectónico y la aplicación de restricciones a nivel de red, de modo que un agente no pueda acceder al entorno de producción ni filtrar datos.
¿Qué son las medidas de control de los agentes de IA?
Las barreras de seguridad son las restricciones que mantienen a un agente dentro del ámbito previsto, como el entorno aislado (sandbox), los dominios incluidos en la lista de permitidos, los límites de frecuencia y una separación clara entre la capa de planificación y la de ejecución. Las más fiables se aplican a través del código y la infraestructura, en lugar de solicitarse mediante un comando, de modo que el modelo no puede ignorarlas ni eludirlas.
