El harness es lo que ya haces con un junior
Eres el ingeniero jefe. Tienes que entregar un estudio hidráulico. Se lo delegas a un ingeniero junior.
No le dices solo «hazme el estudio». Le dejas el marco:
- Qué herramientas puede usar (el software del estudio, el Excel del caudal, la capa de GIS; no el chat público).
- Qué debe hacer (armar el caso, correr el modelo, sacar caudales y advertencias).
- Qué debe comprobar antes de devolverte nada (unidades, tramo correcto, si el modelo abrió, si convergó).
- Qué no puede inventar si falta un dato.
- Qué te tiene que devolver (archivo, versión, números con unidades, y dónde se detuvo si falló).
- Qué no firma él: tú revisas y firmas.
Ese marco —herramientas, instrucciones, comprobaciones, límites y devolución— es exactamente un harness cuando rodea a un modelo de IA. El modelo razona y propone, como el junior. El harness es el marco con el que trabaja. Tú sigues siendo quien firma.
Un arnés no piensa por ti. Te sujeta. Te conecta. Evita que te salgas del espacio seguro. Tampoco convierte al chat en ingeniero automático.
Las nueve partes del marco que le das al junior
LÁMINA DE SISTEMA · HA-01
Anatomía de un harness de IA
Desliza horizontalmente para explorar la lámina completa.
En AEC, esas nueve partes se leen así. Entre paréntesis va el nombre en inglés, porque lo verás así en la documentación de agentes:
H-01 Instrucciones y políticas (system prompt / policies). Es el encargo escrito al junior: objetivo, alcance, unidades, normas, acciones prohibidas y cuándo preguntar al ingeniero jefe. «Haz el estudio» no basta. Eso es el system prompt.
H-02 Contexto (context). Es la carpeta del proyecto que recibe el junior: modelo y versión correctos, levantamiento, tormenta de diseño, red existente y criterios o especificaciones. Si falta o está mal el contexto, puede entregar una respuesta pulida para el proyecto equivocado. Incluye la ventana de contexto y su compactación.
H-03 Herramientas (tools). Son las herramientas que el junior está autorizado a usar: EPANET/SWMM, hoja de cálculo, GIS y repositorio documental. El junior o el modelo propone; la herramienta especializada calcula o consulta. No recibe llaves de todos los sistemas. En Revit, esa toma suele ser MCP.
H-04 Orquestación (orchestration). Es el orden acordado del trabajo: identificar entradas, hacer la revisión previa (preflight), construir el caso, ejecutar el motor de cálculo, inspeccionar advertencias y redactar el informe. Los pasos fijos permanecen fijos; solo se delega la interpretación cuando hace falta. Incluye despachar un agente a otro hilo con carpeta limpia.
H-05 Estado y memoria (state & memory). Es el cuaderno o registro de cálculo: archivo y versión usados, supuestos confirmados, pasos terminados y preguntas pendientes. La memoria útil está respaldada y se puede corregir; volcar toda la conversación no es buena memoria.
H-06 Validaciones y guardrails (validation & guardrails). Son comprobaciones y límites independientes: unidades, continuidad, rangos, balance de masa, convergencia y campos obligatorios. Los guardrails son controles, no una garantía de que el diseño sea correcto.
H-07 Aprobación humana (human approval). El junior puede inspeccionar y ejecutar borradores, pero el ingeniero jefe aprueba cambiar el modelo oficial, el presupuesto contractual, emitir el informe o firmar. Esos son puntos de parada exactos.
H-08 Observabilidad y evidencia (observability & evidence). Es el paquete de cálculo trazable: pedido, archivo y versión, herramienta o motor, parámetros, resultados, advertencias, tiempo o coste si importa y revisor. Otro ingeniero debe poder reconstruir lo ocurrido.
H-09 Manejo de fallos y entorno de ejecución (failure handling & runtime). Indica qué hace el junior si falta un archivo, el modelo no converge, falla la licencia o el sistema, o se alcanza el límite de tiempo o coste: parar, registrar, reintentar solo con reglas definidas, trabajar aislado sobre una copia y nunca rellenar huecos con números plausibles.
Las órdenes estandarizadas —unidades, formato, código o libro— no son un agente nuevo: son la ficha plastificada de la empresa que el harness puede cargar sin abrir otro contexto.
Por qué esas nueve partes son el harness
Juntas, esas nueve partes conforman el harness: no el junior, no el software hidráulico y no el chat, sino el marco que conecta el pedido con una ejecución controlada y una revisión profesional.
Los modelos de lenguaje (LLM) son probabilísticos: predicen el siguiente texto plausible. Por eso necesitan estar rodeados de un arnés (harness). El objetivo del harness no es «hacer que el chat suene más listo». Es entregar resultados anclados a procesos deterministas —motores, archivos, reglas y evidencia— en lugar de depender de la suerte del modelo.
El harness puede conectarse a aplicaciones (Revit, hojas, GIS), leer PDFs y planos, escribir código y usar código open source (OpenSees, OpenFOAM, CalculiX, EPANET/SWMM y otros) para que el número que llega a tu mesa salga de una herramienta verificable, no de la probabilidad del LLM.
Tu misión como ingeniero civil: verificar que el modelo, a través del harness, use las herramientas adecuadas, en el orden adecuado y con las restricciones adecuadas, para obtener resultados verificables y auditables. Si solo confías en lo que el chat «cree», no tienes ingeniería: tienes texto convincente.
Cada una de estas partes se explica con más detalle en los demás artículos de la serie. Este artículo es el mapa. Los siguientes abren cada pieza.
Qué no es (para no confundirte)
- Tener un chat con archivos no es tener un harness.
- Enchufar una herramienta (por ejemplo un conector a Revit o a un motor) no es el agente completo: es una mano. Faltan permisos, chequeos, parada y firma.
Señales de que solo tienes un chatbot
- Te devuelve texto, pero no deja evidencia de qué archivo o motor usó.
- No puedes señalar versión, parámetros o software.
- Cuando la herramienta falla, el modelo inventa el hueco.
- Ningún paso sensible te pide aprobación.
- No hay forma repetible de probar el mismo caso.
Si reconoces varias, no necesitas un modelo más grande. Necesitas marco.
Qué haces en quince minutos
Elige una tarea real (revisar un modelo, un caudal, un metrado, un avance). En una hoja, cuatro columnas:
| Conversar | Ejecutar | Verificar | Aprobar |
|---|---|---|---|
| Dónde solo interpreta o explica. | Qué archivo o motor hace la acción real. | Qué regla independiente comprueba el resultado. | Quién firma y con qué evidencia. |
Si solo existe la primera columna, tienes un chat. Si ejecuta, valida, deja evidencia y sabe detenerse, ya estás armando un harness.
Hoy: una tarea, esas cuatro columnas. Si algo falla, anota dónde se detuvo. Eso también es el oficio.
Serie: el mapa y las lecturas siguientes
Esta nota es el hub de la serie sobre el harness de IA para ingeniería civil. Cada pieza se desarrolla con analogías de obra y oficina:
- Lo primero que debes aprender para usar IA siendo ingeniero civil — este mapa (H-01…H-09).
- Haz que tu IA use Revit — H-03, MCP como el enchufe entre el chat y Revit.
- System prompt en ingeniería civil — H-01, políticas persistentes frente a reglas pegadas en cada correo.
- Prompt engineering para ingeniería civil — la orden de trabajo clara frente a la orden vaga.
- Mismo pedido, dos resultados: tu LLM no calcula, entendiendo el rol de un LLM en ingeniería civil — el ingeniero frente al taller.
- Entendiendo el papel del agente en un harness — enviar a alguien a otra oficina con carpeta limpia.
- Cómo estandarizar las órdenes que le das a un agente — la ficha plastificada de la empresa.
- Tu agente se olvida lo que le dijiste antes — cuando el cuaderno de obra ya no cabe en el escritorio.
Empieza por el system prompt y el rol del LLM si aún estás en el chat. Pasa a MCP, agente y compactación cuando el sistema empiece a ejecutar.
Conclusión
La conversación sobre IA en ingeniería civil no debería empezar y terminar con el nombre del modelo. La capacidad profesional aparece en el sistema completo: datos correctos, herramientas especializadas, permisos, validaciones, trazabilidad y revisión humana.
El modelo propone. El harness conecta, ejecuta, verifica y limita. El profesional decide y firma.
Fuentes
- OpenAI — A practical guide to building agents
- Model Context Protocol — Introducción
- OpenSees — sitio oficial
- Casys AI — mcp-calculix
- Sam Schillace — “What is a harness and why do I care?”
Evaluación y limitaciones
Trata las notas siguientes como contexto de evaluación, no como un cálculo o una revisión verificados.
Para trabajo profesional conviene evaluar el modelo y el harness como un sistema completo con casos representativos, criterios de aceptación, trazabilidad y revisión humana.