El modelo no es el sistema: por qué la IA poderosa todavía necesita un harness

Cada nueva generación de modelos invita a la misma fantasía: ahora la tecnología se ha vuelto tan capaz que el resto de la ingeniería se ha convertido en detalle. La demostración comprende la intención, escribe código, utiliza herramientas y parece completar una tarea de un extremo a otro. La pregunta cambia rápidamente de "¿funciona?" a "¿cuánto podemos automatizar?"

Es en este intervalo cuando los proyectos prometedores se convierten en sistemas frágiles.

El modelo produce posibilidades. El sistema necesita transformar una posibilidad en un resultado aceptado, en el entorno adecuado, bajo permisos explícitos, con costos, verificación y responsabilidad conocidos. Un modelo mejor puede elevar el techo. No define por sí solo lo que se debe hacer, a qué datos puede acceder, cuándo debe detenerse o qué se considera hecho.

Esta capa alrededor del modelo es la harness de ingeniería.

El error de categoría

Comparar modelos le ayuda a elegir una capacidad: razonamiento, código, visión, contexto, latencia o costo. Pero una empresa no compra capacidad abstracta. Necesita que se realice un cambio, que un análisis sea confiable, que se resuelva un servicio o que se tome una decisión dentro de unos límites.

Entre la solicitud y el resultado hay preguntas que un modelo de referencia no responde:

• quién definió la intención y los criterios de aceptación;
• qué fuentes, repositorios, herramientas y entornos se pueden utilizar;
• qué acciones son reversibles y cuáles requieren confirmación;
• cómo se recupera el contexto a largo plazo después de un fracaso;
• quién controla el comportamiento, la seguridad y el impacto;
• qué evidencia vincula el resultado con la versión, el control y el aprobador;
• cómo un fracaso se convierte en aprendizaje, y no sólo en un nuevo intento.

Cuando estas preguntas están implícitas, el prompt se convierte en política, el modelo se convierte en un límite de seguridad y una respuesta convincente se convierte en sinónimo de entrega. Hay tres responsabilidades que el modelo no debe acumular.

El Harness es el sistema de trabajo del agente

En FORGE, el harness está organizado en seis planos. No es necesario que sean seis servicios o seis productos; Es necesario que haya seis responsabilidades visibles.

1. Intención

Transforma el deseo en objetivo, alcance, restricciones y definición de término. "Mejorar el pago" no es una especificación. Es una oportunidad para que el sistema descubra el problema equivocado muy rápidamente.

2. Política

Define autoridad: lo que se puede leer, escribir, ejecutar, publicar o enviar; qué datos están prohibidos; cuándo debe detenerse la tarea; y qué decisión sigue siendo humana. La política no es una recomendación en el prompt. Es una regla que el entorno y las herramientas pueden imponer.

3. Ejecución

Proporciona herramientas, zona de pruebas, identidad de sesión, memoria duradera y mecanismo de reanudación. El trabajo debe sobrevivir a una caída del proceso y seguir siendo asignable. Anthropic la investigación de ingeniería sobre agentes administrados describe la separación entre harness, zona de pruebas y registro de sesiones; Las fuentes analizadas por FORGE sostienen que la historia, la política de orquestación y el aislamiento deben ser límites explícitos, y que el modelo o canal no puede convertirse en el límite de seguridad. [HARNESS31-C2]

4. Verificación

Pruebe diferentes propiedades con diferentes controles. Las pruebas unitarias, el contrato API, la evaluación de comportamiento, el escáner secreto, la revisión arquitectónica y la navegación real no son votos repetidos de la misma cosa. Cada control necesita declarar lo que observa y lo que no prueba.

5. Evidencia

Vincula el resultado a su origen: commit, versión del contrato, informe, hash, fuente, ejecutor, verificador, validez y residual. “Aprobado” sin subject y sin artefacto es sólo una frase.

6. Comentarios

Convierte la corrección, el incidente y la excepción en una mejora duradera. El bucle sólo se cierra cuando el fallo produce una prueba, una medida de seguridad, una decisión, una actualización del contexto o un límite explícito.

Un ejemplo sencillo: cambiar un flujo de autenticación

Imagínese preguntarle a un agente: "agregar inicio de sesión social". Un modelo capaz puede localizar archivos, generar la integración y producir una pantalla. Aún así, el resultado puede fallar por motivos ajenos a la generación de código:

• el proveedor elegido no cumple con el marco de identidad del producto;
• un secreto acabó en el paquete del navegador;
• la devolución de llamada acepta un origen inadecuado;
• no existe una prueba de aislamiento de tenant;
• la experiencia móvil no cubre errores ni recuperación;
• la documentación indica que la función está lista antes de la implementación;
• Nadie aprobó el cambio de superficie de ataque.

El harness cambia el trabajo. La intención requiere escenarios y criterios. La política restringe el secreto y el permiso. La ejecución se produce en una rama y un entorno aislados. La verificación combina contrato, pruebas, seguridad y flujo real. La evidencia vincula todo con el mismo commit. La aprobación humana ocurre cuando el riesgo se vuelve externo o difícil de revertir.

El modelo sigue siendo esencial. Simplemente dejó de confundirse con todo el producto.

Más capas no significan un mejor sistema

También existe el error opuesto: responder a cada falla con más agentes, más revisores y más bucles. La complejidad puede mejorar un resultado y al mismo tiempo empeorar el costo, la latencia y el diagnóstico.

En un experimento de desarrollo de aplicaciones a largo plazo, Anthropic informó mejores resultados con el planificador, el generador y el evaluador, pero con un costo y una duración materialmente mayores. Este resultado pertenece a la tarea, modelo y diseño probado. Apoya la necesidad de evaluaciones y ablación caso por caso; No es una regla que indique que cada tarea necesite un equipo de múltiples agentes. [HARNESS31-C3]

Un componente debe permanecer en el harness porque demuestra un valor mensurable o controla el riesgo real. Ante cada salto en la capacidad del modelo, cabe preguntarse:

• este paso aún evita una clase de fracaso;
• el mismo control puede simplificarse;
• la ganancia compensa el costo y la latencia;
• el verificador es en realidad independiente del ejecutor;
• la eliminación empeora los resultados en evaluaciones realistas.

El harness es la arquitectura adaptativa. No se trata de un cobro permanente de compensaciones por limitaciones de una versión antigua del modelo.

La herramienta no es autoridad.

Un agente puede operar en el endpoint, en el navegador, en Slack, en una API o en un portal. Estos canales son superficies de integración. No deben otorgar, por conveniencia, autoridad sobre toda la organización.

Las fuentes examinadas por FORGE apuntan a capacidades compartidas administradas y con alcance, manteniendo la web, el chat y las interfaces futuras como canales reemplazables. No definen un modelo de autorización universal; La denegación por defecto, la revocación y las pruebas siguen siendo obligatorias en cada producto. [HARNESS31-C4]

Esta distinción ayuda a cambiar de modelo sin reconstruir la seguridad. La lista puede cambiar según la tarea, el costo y el riesgo. La identidad que ejecuta, los recursos a los que accede y los gates de publicación permanecen estables.

Lo que los empresarios deben exigir

Una decisión de IA se vuelve más madura cuando va más allá de "¿cuál es el mejor modelo?" y responde:

1. ¿Qué resultado será aceptado y por quién?
2. ¿Qué línea de base existe hoy en cuanto a tiempo, calidad, costo y riesgo?
3. ¿Dónde sugiere, ejecuta, verifica o debe detenerse la IA?
4. ¿Qué datos y acciones están fuera de alcance?
5. ¿Qué evidencia acompaña cada entrega?
6. ¿Cómo corregimos, eliminamos o revertimos el resultado?
7. ¿Qué sucede cuando cambia el modelo, herramienta o entorno?

Estas preguntas le permiten comparar sistemas, no demostraciones.

Lo que los equipos técnicos deben dejar explícito

Para ingeniería, el mínimo útil es un contrato de explotación:

• entrada y salida con esquema;
• identidad y capacidades por tarea;
• contexto versionado y recuperable;
• sandboxing y secretos fuera del alcance de códigos que no son de confianza;
• límites de intento, costo y duración;
• evaluaciones y pruebas vinculadas al perfil de riesgo;
• provenance del artefacto y verificadores;
• gate humano para una acción irreversible o externa;
• telemetría suficiente para explicar fallas y consumos;
• reversión y retiro público cuando corresponda.

Esto no requiere comenzar con una plataforma enorme. Requiere que la primera versión no oculte los límites que deberán existir cuando el experimento se convierta en una operación.

Una prueba de siete preguntas

Antes de llamar a una solución “agente en producción”, intente responder sin recurrir al nombre del modelo:

1. ¿Qué está autorizado a hacer?
2. ¿Cómo sabemos que hicimos lo correcto?
3. ¿Quién puede detener o revocar la ejecución?
4. ¿Qué sobrevive si el proceso falla?
5. ¿Qué evidencia vincula el resultado con la versión ejecutada?
6. ¿Quién responde cuando el resultado afecta a otra persona?
7. ¿Cómo aprende el sistema sin reescribir silenciosamente el pasado?

Si las respuestas no existen, quizás haya una capacidad impresionante. Todavía no existe un sistema confiable.

Conclusión

Los mejores modelos importan. Amplian el espacio de lo que se puede delegar y permiten simplificar partes del andamio. Pero cuanto más capaces se vuelven, mayor puede ser el efecto de un permiso erróneo, un objetivo ambiguo o un control circular.

El harness no compite con el modelo. Convierte la capacidad en trabajo gobernable: intención, política, ejecución, verificación, evidencia y retroalimentación.

El modelo genera posibilidades. El sistema es lo que hace que uno de ellos sea aceptable, asignable y corregible.

Próxima lectura: Humano responsable, ejecutando IA, el contrato operativo que organiza la autoridad y la ejecución dentro del escuadrón.