El arnés importa más que el modelo: por qué la ingeniería de arneses define tus proyectos de IA

Cuando algo falla en un desarrollo con IA, el reflejo casi siempre es el mismo: “hay que cambiar de modelo”. Se prueba otro LLM, se sube de versión, se compara benchmark contra benchmark. Y muchas veces el problema no está ahí. Está en el arnés: la capa de herramientas, permisos, memoria, sandboxing y reglas que rodea al modelo y define qué puede hacer, cuándo y con qué límites.

Qué es un arnés (harness)

Un modelo de lenguaje, por sí solo, es una función que predice texto. No sabe leer un archivo, no sabe ejecutar un comando, no sabe qué repositorio está tocando ni qué credenciales tiene disponibles. Todo eso lo provee el harness: el código que decide qué herramientas se exponen al modelo, cómo se validan sus acciones, qué contexto recibe y qué pasa cuando se equivoca.

Claude Code, Cursor, los agentes de SOC que corren playbooks automatizados, cualquier sistema que conecta un LLM con acciones reales en el mundo, es en el fondo un arnés. El modelo razona; el arnés ejecuta, contiene y audita.

Por qué la ingeniería de arneses es el trabajo real

Elegir el modelo es la parte fácil. La ingeniería de arneses es donde se juega si el sistema es útil, seguro y confiable:

• Superficie de herramientas: qué puede hacer el agente (leer archivos, correr comandos, llamar APIs) y qué explícitamente no puede hacer.
• Permisos y confirmación humana: qué acciones requieren aprobación antes de ejecutarse, especialmente las irreversibles.
• Contexto y memoria: qué información recibe el modelo en cada turno, y qué se filtra o resume para no saturarlo ni filtrar datos sensibles.
• Manejo de errores: qué pasa cuando una herramienta falla, cuando el modelo alucina un parámetro, cuando intenta algo fuera de scope.
• Observabilidad: poder reconstruir después qué hizo el agente y por qué, con la misma seriedad con la que se audita cualquier proceso automatizado.

Cada uno de esos puntos es una decisión de diseño, no un detalle de implementación. Un arnés mal diseñado convierte un modelo excelente en un sistema frágil o peligroso. Un arnés bien diseñado hace que hasta un modelo mediocre produzca resultados confiables, porque lo que puede salir mal está acotado desde el principio.

La analogía con seguridad ofensiva

Para quien viene de pentesting o red team, esto es terreno conocido. Un exploit no vale nada sin un payload bien encapsulado, sin control de la superficie de ejecución, sin saber exactamente qué toca y qué no. Con los agentes de IA pasa lo mismo: el modelo es el exploit potencial, el arnés es lo que decide si esa capacidad se traduce en algo útil y controlado, o en un incidente.

De hecho, buena parte de los incidentes de seguridad con IA que se ven hoy (prompt injection que deriva en ejecución de comandos, agentes con permisos de escritura sobre sistemas que no deberían tocar, filtración de datos por contexto mal segmentado) no son fallas del modelo. Son fallas de arnés: faltó un límite, faltó una confirmación, faltó sandboxing.

Qué mirar al construir o evaluar un arnés

1. Principio de mínimo privilegio para herramientas. Si el agente no necesita borrar archivos, no le des esa herramienta.
2. Puntos de confirmación explícitos para toda acción irreversible o con impacto fuera del entorno local.
3. Trazabilidad completa de cada tool call, igual que loggeás cualquier acción con privilegios elevados.
4. Aislamiento del entorno de ejecución (containers, sandboxes, entornos efímeros) para que un error del agente tenga blast radius acotado.
5. Revisión periódica de la superficie expuesta, igual que se revisan permisos de IAM: las herramientas que el agente tenía sentido dar hace tres meses pueden ya no tenerlo.

La conclusión

El modelo va a seguir mejorando, eso es inevitable y no depende de vos. Lo que sí depende de vos es el arnés: los límites, los permisos, la memoria, la auditoría. Ahí es donde se define si un proyecto de IA es una herramienta confiable o un riesgo esperando a materializarse. Invertir en ingeniería de arneses no es un extra, es la parte del trabajo que realmente controlás.