Cuando alguien me pregunta qué modelo uso, la pregunta tiene sentido. Pero todavía está mirando el motor y llamándolo coche.

El motor importa. Un motor malo limita el viaje. Uno mejor puede volver ciertas tareas más rápidas, más baratas o simplemente posibles. Pero nadie cruza una carretera por poner un motor potente en el suelo del garaje.

Hacen falta chasis, dirección, frenos, tablero, mantenimiento, ruta y alguien responsable de decidir adónde va.

Con la IA ocurre lo mismo. Un modelo puede escribir, resumir, clasificar, extraer y razonar sobre lo que recibe. No sabe por iluminación divina qué archivo gobierna una decisión, qué datos puede consultar, qué no puede publicar, cuándo debe detenerse, cómo probar un cambio o cómo deshacerlo.

Para esa estructura alrededor del modelo uso la palabra harness.

TL;DR

Un harness de IA no es un cerebro consciente ni una ventana de conversación con accesorios. Es el sistema que transforma la capacidad general de un modelo en trabajo dirigido: reglas escritas, contexto, memoria y una base organizada de decisiones, herramientas y procedimientos reutilizables, partes especializadas, permisos, políticas, validación, seguimiento de la operación, seguridad, publicación y capacidad de volver a un estado anterior. El término no tiene una definición universal —cada plataforma traza sus límites de forma distinta—, pero la idea útil es simple: el modelo es un componente; la operación confiable depende del entorno que lo rodea. Eso no vuelve irrelevantes a los proveedores ni borra las diferencias entre modelos. Vuelve visibles dependencias, decisiones y límites para que cambiar una pieza no destruya el coche entero.

El modelo no es la operación

Un modelo de lenguaje recibe contexto y produce una salida. Puede ser excelente en eso y aun así insuficiente para un trabajo completo.

Para publicar un artículo, por ejemplo, no basta con generar párrafos. Hay que saber cuál es la tesis del autor, dónde están las fuentes, cómo comprobar una referencia, qué versiones del texto existen, qué imagen explica la idea, qué idioma falta, qué validaciones exige el sitio y en qué punto la publicación debe esperar una decisión humana.

Eso no es burocracia añadida después. Es el trabajo.

En la ingeniería de Codex, el agente de programación de OpenAI, la empresa llama harness a la capa que organiza el ciclo entre usuario, modelo y herramientas. Otro relato de OpenAI amplía el recorte a persistencia de conversaciones, configuración, autenticación, ejecución de herramientas y extensiones. Anthropic también describe sistemas agénticos como modelos ampliados por recuperación de información, herramientas y memoria.

Estas fuentes no crean una definición oficial y universal. Por eso no trato harness como nombre mágico de producto: es una palabra útil para la infraestructura de coordinación que hace útil a un modelo en un contexto real.

Cinco cosas que se suelen mezclar

Capa	Qué es	Qué no resuelve por sí sola
Modelo	El componente que interpreta entrada y produce salida	No conoce la operación sin contexto ni administra por sí solo el mundo fuera de la conversación
Chatbot	La interfaz con la que una persona conversa con un modelo	No define política, el registro autoritativo usado cuando la información entra en conflicto, ni responsabilidad
Automatización	Una secuencia definida: cuando pasa X, haga Y	No maneja ambigüedad solo porque recibió un nombre ambicioso
Agente	Un sistema que puede elegir próximos pasos y usar herramientas dentro de un objetivo y límites	No debe recibir autonomía ilimitada ni contexto genérico
Harness	La estructura que conecta las piezas, define contratos y hace verificable el comportamiento	No reemplaza juicio humano, datos buenos ni un proceso que la empresa nunca consiguió explicar

El acervo ya traía, en «La IA no es una sola cosa», un mapa de modelos, automatizaciones, agentes y harnesses. Aquí añado el chatbot a la conversación y profundizo el harness: no como la quinta casilla de una lista, sino como lo que impide que las otras piezas se conviertan en una pila de herramientas con demasiada autoestima.

Qué entra en el coche completo

La metáfora visual de este artículo no muestra un cerebro. Muestra un motor rodeado por el resto de la operación.

En el centro está el modelo. A su alrededor, pienso en al menos cuatro conjuntos de responsabilidades:

1. Contexto y memoria. Donde el sistema encuentra requisitos, decisiones vigentes, fuentes, preferencias confirmadas y la diferencia entre una conversación antigua y un contrato actual. Una conversación larga puede ayudar a pensar; no debería ser la única fuente de verdad. Esa fue la frontera que encontré cuando la IA olvidó una decisión que ya había tomado.
2. Herramientas, skills y agentes. Una herramienta es la capacidad de buscar, leer, editar, consultar o ejecutar algo. Una skill es un procedimiento reutilizable que explica cuándo usar esa capacidad, qué entradas necesita, qué límites respeta y cómo verificar la salida. Los subagentes dividen trabajo cuando hay una separación real de responsabilidad; no son una forma cara de convertir una tarea simple en una reunión de condominio.
3. Políticas y puntos de control (gates). Permisos, aprobaciones, límites de tiempo y costo, y criterios para preguntar, rechazar, escalar o parar. Son los puntos que permiten o bloquean la continuidad de una operación. Un agente que no sabe cuándo detenerse no es autónomo: solo es demasiado rápido para su propio bien.
4. Operación verificable. Validación, registros proporcionales de eventos (logs), pruebas, monitoreo, seguridad, publicar una versión en operación (deploy) y volver a un estado anterior conocido (rollback). Si la salida no se puede inspeccionar, corregir o deshacer, sigue siendo una apuesta, aunque venga con una tabla muy bien formateada.

Estas capas no necesitan la misma complejidad. Un buen harness no es el que acumula módulos. Es el que da a un problema las protecciones y capacidades que realmente necesita.

Cuando una estructura simple basta

Aquí es donde mucha gente saca la bazuca.

Si una tarea tiene entrada predecible, regla clara y salida conocida, quizá lo mejor sea código convencional, una automatización pequeña o eliminar un paso inútil. No hay medalla por llamar «agente» a un formulario que calcula flete siguiendo una tabla.

Una comprobación de datos puede empezar con una verificación regida por reglas que produce el mismo resultado para la misma entrada (validación determinista). Una notificación recurrente quizá solo necesite agenda y una regla. Un proceso confuso puede necesitar descubrimiento de requisitos antes de necesitar IA.

El modelo entra cuando lenguaje, documentos variados, ambigüedad controlada o comparación contextual aportan valor. El agente entra cuando además necesita elegir una secuencia de pasos dentro de límites. El harness crece cuando el costo del error, duración de la operación, cantidad de integraciones o necesidad de reconstruir y examinar lo ocurrido (auditabilidad) lo justifican.

Es la misma disciplina que defendí en «La IA en lo cotidiano no basta»: utilidad no es adornar una tarea simple con una arquitectura que nadie puede mantener.

Portabilidad no es independencia absoluta

No me interesa montar una operación que se derrumbe porque un proveedor cambió una pantalla, un precio o el comportamiento de un modelo.

Pero tampoco vendo la fantasía de independencia absoluta. Los modelos varían en capacidad, costo, contexto aceptado, herramientas, políticas y calidad de respuesta. Algunas integraciones siguen siendo externas. Migrar puede exigir adaptación, pruebas y una decisión económica real.

El objetivo más honesto es mantener portátil lo que es tuyo:

• contratos e instrucciones que explican cómo se trabaja;
• decisiones, fuentes y memoria con origen claro;
• pruebas y criterios de aceptación que comparan comportamiento;
• interfaces explícitas para herramientas y datos;
• artefactos generados que se puedan revisar fuera de la conversación;
• registros suficientes para entender qué cambió;
• un camino de rollback cuando un cambio no se sostiene.

Si cambiar de modelo exige calibrar algunas piezas, normal. Si exige reaprender todo el negocio porque el contexto estaba atrapado en una conversación o en una caja cerrada, el problema no es solo el modelo.

Es arquitectura.

Lo que aprendí construyendo el mío

Mi trabajo ha recorrido toda la cadena: conversar para entender el requisito, transformarlo en sistema, elegir arquitectura, implementar, publicar, monitorear, proteger y recuperar cuando hace falta.

Por eso desconfío de soluciones que empiezan por la herramienta. Una empresa puede tener una gran idea y aun así no haber definido quién aprueba, qué dato prevalece, dónde entra la excepción o qué ocurre cuando algo falla. La IA no arregla ese vacío por telepatía. Solo lo atraviesa más rápido.

Mi harness personal nació para evitar otro desperdicio: explicar toda mi forma de trabajar desde cero en cada conversación. Pero no convierte toda inferencia sobre mí en regla. Como conté en «ChatGPT ya sabe mucho sobre ti», el contexto acumulado se convierte en hipótesis; solo la confirmación se convierte en contrato.

Y un contrato no puede convertirse en dogma oculto. En «Una hipótesis no se vuelve un hecho porque la IA la repitió», explico por qué la wiki preserva origen, incertidumbre, consumidores afectados y condición de revisión. Así aprende el sistema sin reescribir el pasado a escondidas.

No necesito un agente que solo sepa estar de acuerdo

Un harness no mejora solo la ejecución. Puede mejorar la calidad de la conversación que viene antes.

Quiero un sistema que encuentre vacíos, muestre evidencia contraria, diga cuándo una fuente no sustenta toda la tesis y devuelva una decisión cuando sigue siendo mía. Eso es lo contrario de programar una voz para validarme con excelente dicción.

Ese principio aparece en «La mejor respuesta no es la que más me agrada». No basta que el agente sea fluido, amable o rápido. Necesita permiso y estructura para disentir, pedir más contexto y no ejecutar lo que todavía está mal definido.

También por eso desconfío de agentes genéricos vendidos como solución lista. Una base reutilizable es excelente. Fingir que ya conoce los nombres, las excepciones y la responsabilidad de una empresa es otro asunto.

La pregunta útil no es «¿qué IA compro?»

Antes de elegir una herramienta, yo empezaría por estas preguntas:

• ¿Qué decisión o trabajo necesita mejorar?
• ¿Dónde está la fuente de verdad?
• ¿Qué es repetitivo, qué es ambiguo y qué no debería automatizarse?
• ¿Qué dato puede consultar, cambiar o nunca ver el sistema?
• ¿Cuándo debe seguir, cuándo debe parar y quién recibe la excepción?
• ¿Cómo sabremos que funcionó y cómo volveremos atrás si no funcionó?

Cuando aparecen estas respuestas, modelo, chatbot, automatización y agente dejan de ser religión de herramienta. Se convierten en elecciones de arquitectura.

Ahí es donde trabaja i-9.ai: transformar contexto difuso y requisitos reales en sistemas que se puedan operar, verificar y evolucionar. A veces eso pide IA. A veces pide una automatización simple. A veces pide quitar un paso inútil antes de cualquiera de las dos.

El modelo puede ser excelente.

Pero todavía necesita un coche que sepa dónde están los frenos.

Sigue leyendo

• La IA no es una sola cosa: modelo, agente, automatización y harness: vocabulario básico antes de diseñar arquitectura.
• La IA en lo cotidiano no basta: construí una operación: cómo salir del uso aislado y pensar en capacidad operativa.
• La mejor respuesta no es la que más me agrada: el contrato de calidad que orienta mis agentes.
• ChatGPT ya sabe mucho sobre ti. Antes de confiar, haz que lo demuestre: cómo convertir contexto personal en una regla revisable.
• Una hipótesis no se vuelve un hecho porque la IA la repitió: el recibo necesario cuando una premisa gobierna una acción.
• Los agentes genéricos pueden ser tu peor primer contacto con la IA: por qué una demostración no sustituye el descubrimiento.

Referencias y límites de uso

Las referencias siguientes explican prácticas y terminología de plataformas específicas. No prueban que todo harness funcione igual ni que cualquier arquitectura elimine error, riesgo o responsabilidad humana.

• OpenAI, «Unrolling the Codex agent loop»: describe el ciclo usuario-modelo-herramientas que OpenAI llama Codex harness; es un relato de producto e ingeniería de la propia OpenAI.
• OpenAI, «Harness engineering: leveraging Codex in an agent-first world»: relata cómo se usaron documentación, estructura de repositorio, pruebas y ciclos de feedback en un proyecto interno; no es receta universal ni promesa de resultado para otra empresa.
• Anthropic, «Building Effective Agents»: distingue flujos de trabajo de agentes y describe modelos ampliados por recuperación, herramientas y memoria; refleja recomendaciones de ingeniería de la propia empresa.
• National Institute of Standards and Technology (NIST) de Estados Unidos — AI Risk Management Framework 1.0: marco voluntario para gobernar, mapear, medir y gestionar riesgos de IA; no certifica esta arquitectura ni reemplaza controles específicos del contexto.