La ingeniería de «harnesses» es la práctica de construir la capa —incluido el código— que transforma un modelo de IA de un simple 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 hace posible, conectando el modelo con herramientas, contexto, sistemas externos y validación. En gran parte del trabajo práctico, y especialmente en el ámbito de la seguridad, el «harness» determina la calidad del resultado mucho más que la elección del modelo.
¿Qué es un «harness»?
Un «harness» es la capa de orquestación situada alrededor de un modelo, o de varios modelos a la vez. Es código, lógica de flujo de trabajo, diseño de «prompts» y validación trabajando en conjunto, con el modelo integrado como un componente más entre varios. El «harness» contiene la lógica que decide qué modelo se ejecuta en cada momento, qué contexto ve cada uno, cómo se verifican los hallazgos y cuándo se debe escalar a un modelo más potente.
En su forma más simple, un «harness» es un bucle corto de código:
- Llamar al modelo
- El modelo solicita una herramienta
- El «harness» ejecuta la herramienta y devuelve el resultado
- Repetir hasta obtener los resultados finales
A medida que los «harnesses» se vuelven más complejos, suelen utilizar algunos de los siguientes patrones:
- Encadenamiento de «prompts» («Prompt chaining»): Pasos secuenciales con comprobaciones intermedias para una tarea que se desglosa en un orden fijo.
- Enrutamiento («Routing»): Un clasificador envía cada entrada a un gestor especializado, derivando las consultas sencillas a un modelo más económico y reservando las difíciles para uno más potente.
- Paralelización («Parallelization»): Consiste en dividir una tarea en partes independientes o ejecutar la misma tarea varias veces y agregar los votos.
- Orquestador-trabajadores («Orchestrator-workers»): Un modelo central divide el trabajo sobre la marcha y lo delega, ideal para tareas donde no se pueden prever las subtareas de antemano.
- Evaluador-optimizador («Evaluator-optimizer»): Un modelo genera contenido mientras otro lo critica en un bucle hasta que el resultado supera la validación.
El «harness» también suele encargarse de la compactación, el proceso que condensa historiales de conversación largos o transcripciones resumiendo los mensajes más antiguos en un bloque denso de texto. Gestionar correctamente la ventana de contexto de un LLM tiene un impacto importante en la calidad y seguridad de las respuestas, lo que ha dado pie a un nuevo tema de gran interés: la ingeniería de contexto (que abordaremos en otra ocasión).
Por qué necesitas un «harness»
Si estás eligiendo entre varios modelos, solo estás ajustando una variable. Los modelos de vanguardia han convergido hasta el punto de que la diferencia entre los mejores en las pruebas de código estándar es relativamente pequeña. Sin embargo, si envuelves ese mismo modelo en un «harness» débil frente a uno fuerte, la diferencia en lo que realmente es capaz de encontrar es abismal. En muchos casos, el diseño del «harness» influirá más en la calidad del resultado que el propio modelo.
Depender menos de un modelo específico te permite adaptarte a los cambios. Los modelos de vanguardia se enfrentan últimamente a un mayor escrutinio y están perdiendo el favor de algunos. A raíz del incidente entre Hugging Face y OpenAI de julio de 2026, un modelo de vanguardia atacó a una empresa, pero no pudieron utilizar otro modelo de vanguardia para defenderse, ya que estos bloquean habitualmente las tareas relacionadas con la ciberseguridad. Hugging Face tuvo que recurrir a un modelo chino de pesos abiertos para su respuesta ante incidentes (afortunadamente, los modelos de pesos abiertos están rindiendo bastante bien hoy en día). Quedar a merced de las negativas de los modelos no es un plan 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 a través del mismo bucle de llamada, modelo, ejecución y herramienta que se describió antes. El bucle agéntico subyacente elige herramientas, acumula contexto y gestiona sesiones largas mediante compactación, estableciendo los límites de seguridad con modos de permisos y sandboxing. El modo de agente de Cursor aplica el mismo concepto dentro de un editor centrado en la IA construido sobre VS Code, donde el harness se encarga de editar varios archivos desde el propio entorno de desarrollo en lugar de la terminal.
El harness más conocido sea probablemente OpenClaw, aunque se podría decir que ha evolucionado más allá de ser un simple harness. En su interior, funciona como un servicio de Node.js de ejecución prolongada que conecta un LLM a tu Mac Mini y a aplicaciones de mensajería. Proporciona la pasarela, los canales, el ensamblaje de contexto, la memoria persistente, las habilidades y el bucle que los conecta. OpenClaw sirve también como un ejemplo aleccionador de lo débil que puede ser la seguridad cuando el harness no es estricto al respecto y el sandbox es prácticamente inexistente (volveremos sobre esto en un momento).
Para ver un ejemplo detallado del mundo real, Cloudflare publicó su harness de descubrimiento de vulnerabilidades paso a paso, diseñado mientras aplicaba modelos de seguridad a decenas de sus propios repositorios. Estas fases ofrecen una idea clara de todo lo que hace un harness maduro, especialmente en un contexto de seguridad. Nuestro propio harness en Aikido funciona de manera similar a alto nivel: explora una base de código en busca de posibles puntos de entrada, prioriza los flujos sospechosos que debe analizar, profundiza en cada uno de ellos y realiza el triaje de los resultados.
El papel del harness en la seguridad y protección de la IA
En el contexto de la seguridad, el harness también es parcialmente responsable de contener al modelo, manteniéndolo dentro de los límites establecidos cuando se desvía de su tarea o cuando algún elemento de su entrada lo hace desviarse. Se encarga de mantener los límites flexibles, y estos se sostienen siempre y cuando la orquestación se comporte tal como la diseñaste.
Los mecanismos de control, como el ámbito (scope) y el registro (logging), deben formar parte de la capa de herramientas que controla el código. Dado que los LLM no son deterministas y, por tanto, son impredecibles, incluso los intentos más heroicos de controlarlos únicamente mediante prompts no pueden garantizar la seguridad. La inyección de prompts es uno de los mayores problemas al intentar controlar los LLM mediante instrucciones, ya que cualquier entrada controlada por un atacante que logre colarse en el contexto puede envenenar al modelo con información lo suficientemente convincente.
Los controles de seguridad que cubre el harness incluyen:
- Control de ámbito (scope control): Reglas sobre lo que está permitido, como los dominios, hosts o repositorios a los que un agente puede acceder, bloqueando cualquier acción fuera de estos límites. En un harness, esto se traduce en una lista blanca que verifica la ejecución del código antes de que se active una herramienta, así como en instrucciones de ámbito en el propio prompt.
- Mediación de herramientas: El harness decide qué herramientas existen, qué argumentos están permitidos y si se permite ejecutar una llamada determinada. El modelo solo puede solicitar una herramienta, y el código del harness elige si debe ejecutarse o no.
- Gestión de contexto y entradas: Controles contra la inyección de prompts y contenido no confiable, como eliminar o poner en cuarentena datos externos, limitar lo que lee el modelo y evitar alimentarlo con contenido abierto de internet del que pueda extraer instrucciones.
- Validación y verificación: Comprobaciones independientes sobre lo que produce el modelo, como un segundo agente que intenta refutar un hallazgo, una comprobación de alcanzabilidad o la validación de esquemas en la salida. Esto permite filtrar el ruido y las alucinaciones.
- Lógica de escalado y enrutamiento: Reglas para determinar cuándo transferir una tarea a un modelo más potente, cuándo se requiere la intervención humana y cuándo detener el proceso. Los mecanismos de interrupción (circuit-breakers) y las condiciones de parada también se gestionan aquí.
- Registro y observabilidad: El registro de cada solicitud y acción para que una ejecución pueda supervisarse en directo, pausarse o auditarse. Este control permite intervenir cuando sea necesario.
- Gestión de recursos y límites de velocidad a nivel de aplicación: Limitación de velocidad (rate-limiting) y control de carga para evitar que los agentes saturen un objetivo o disparen los costes.
En algunos casos, los agentes operarán dentro de un sandbox, por lo general cuando interactúan con sistemas en producción o cuando se les permite ejecutar comandos de shell. El sandbox es el contenedor en el que se ejecuta todo el harness y el encargado de aplicar las restricciones de seguridad más estrictas, lo que incluye el aislamiento a nivel de sistema operativo, las restricciones de red, los límites de recursos y la separación de tu infraestructura interna. Como estos límites son impuestos por el entorno, el modelo no puede cruzarlos, sin importar lo que decida hacer.
Dato curioso: también puedes anidar sandboxes dentro del harness. Si el harness proporciona al modelo una herramienta que ejecuta comandos, dichos comandos pueden ejecutarse en su propio sandbox independiente, de modo que una capacidad de alto riesgo cuenta con su propio límite estricto sin comprometer la seguridad del resto del sistema.
La seguridad de los harnesses de IA en el mundo real
Dos casos recientes muestran lo que ocurre cuando estos límites fallan de diferentes maneras. OpenClaw ilustra lo que sucede cuando falta por completo el límite estricto. El incidente de Hugging Face y OpenAI demuestra lo que ocurre cuando este límite existe pero es vulnerado.
OpenClaw muestra cómo se manifiesta esto cuando las capas de seguridad se dejan en manos del usuario. Incorpora los controles del harness por defecto, pero trata el sandbox como una opción que se debe activar manualmente; por defecto, la sesión principal se ejecuta directamente en la máquina host con acceso total a sus credenciales y archivos. El sandboxing solo cubre las sesiones para las que se ha configurado y, aun así, algunas herramientas están marcadas para ejecutarse en el host de todos modos. Por lo tanto, la forma habitual de ejecutar OpenClaw es utilizar un harness potente con medidas de seguridad flexibles y sin un límite estricto por debajo, que es la configuración responsable de sus peores incidentes. Un harness sin un sandbox solo es tan seguro como lo permitan sus controles flexibles y, frente a un modelo no determinista, estos no siempre resisten.
El incidente entre Hugging Face y OpenAI que mencioné antes es un excelente (o alarmante) ejemplo de cómo la infraestructura que rodea a un modelo potente puede fallar a la hora de mantener la seguridad. OpenAI reveló que, durante una ejecución interna de un benchmark, sus propios modelos lograron escapar del sandbox de pruebas y accedieron a los sistemas de producción de Hugging Face para extraer las respuestas de la prueba.
El incidente ilustra lo que sucede cuando tanto el propio criterio del modelo como el sistema que lo rodea se ven comprometidos al mismo tiempo. El modelo de OpenAI había estado funcionando con las restricciones de ciberseguridad desactivadas, un estado en el que el modelo o los agentes se niegan a realizar una tarea solicitada basándose en su entrenamiento en lugar de en reglas externas. Esto tiene sentido para las pruebas que OpenAI intentaba realizar, pero también genera graves riesgos de seguridad. En este caso, el sistema circundante era el único responsable de contener a estos agentes en lugar de un prompt, es decir, el harness y el sandbox, y ambos fallaron.
Incluso OpenAI, que intentó implementar un sandbox seguro, se vio comprometido por un único sistema de registro de paquetes vulnerable y accesible. Este es, por supuesto, un ejemplo extremo, pero los modelos serán cada vez más inteligentes y tendrás que estar preparado para ello en tu sandbox.
La respuesta de diseño debe ser arquitectónica y multifactorial. Evalúa el riesgo de todo aquello a lo que el agente pueda acceder. Así es como construimos nuestro harness para nuestros agentes de pentesting de IA. El sistema separa la parte que planifica, razona y maneja datos sensibles (el plano de control) de un sandbox aislado que ejecuta herramientas, controla navegadores e interactúa con la red (el plano de ejecución) mediante políticas de red y software sólidos.
El componente de ejecución no tiene acceso a los secretos de orquestación ni a la infraestructura interna, bajo la premisa de que la ejecución puede fallar y el harness no puede contenerlo todo. Es aquí donde entra en juego el sandbox. El sistema estricto de control bloquea cualquier dominio que no esté incluido en la lista blanca a nivel de red, impidiendo que el agente pueda alcanzarlo, sin importar el curso de acción que decida tomar.
Los harnesses de IA, hoy y en el futuro
El modelo acapara la atención, pero el harness hace gran parte del trabajo. Es lo que convierte la capacidad en los mejores hallazgos y gestiona numerosos controles de seguridad. Las grandes organizaciones tecnológicas se están centrando en los harnesses, tanto para uso interno como en formato de servicio. Recientemente, Microsoft lanzó un framework de harness como producto. Mientras existan los LLMs, los mantendremos confinados en harnesses, por lo que esta disciplina no ha hecho más que empezar. Apenas hemos arañado la superficie en esta publicación, pero también puedes continuar tu aprendizaje sobre IA en esta fantástica página sobre ingeniería de harnesses.
Elige bien tu modelo, pero concentra tus mayores esfuerzos en el harness. Por eso desarrollamos nuestras propias herramientas, como AI code analysis y pentesting de IA de Aikido, diseñadas primero como harnesses.
Preguntas frecuentes
¿Qué es un «harness»?
Un harness es la capa de orquestación que rodea a uno o más modelos. Es el código, la lógica de flujo de trabajo, el diseño de prompts y la validación que transforman un modelo en un agente capaz de actuar, decidiendo qué agente se ejecuta en cada momento, qué contexto ve cada uno, cuándo escalar y cómo se verifica el resultado.
¿Cuál es la diferencia entre el harness y el modelo?
El modelo proporciona 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 se mantiene. Por eso, un buen harness te permite actualizar los modelos sin necesidad de reconstruir tu sistema.
¿Es la ingeniería de harnesses una disciplina real?
Se ha convertido en una. A medida que las capacidades de los modelos de vanguardia convergen, la orquestación que los rodea es 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 harnesses como un campo de estudio propio.
¿Cómo se aplica la ingeniería de harnesses a la seguridad?
En seguridad, el harness realiza dos funciones. Por un lado, eleva la calidad de los hallazgos mediante un ámbito reducido y una validación independiente a través de agentes en paralelo; por otro, confina al agente mediante aislamiento arquitectónico y control de ámbito a nivel de red, de modo que un agente no pueda adentrarse en producción ni filtrar datos.
¿Qué son los guardrails para agentes de IA?
Los guardrails son las restricciones que mantienen a un agente dentro de su ámbito previsto, como el sandboxing, los dominios permitidos, los límites de velocidad y una separación estricta entre la capa de planificación y la de ejecución. Los más fiables se implementan en el código y la infraestructura en lugar de solicitarse mediante un prompt, evitando así que el modelo pueda ignorarlos o ser manipulado para sortearlos.
