AI Harness: la peor y la mejor palabra de moda de la industria

Cada vez que leo "construimos un Enterprise AI Harness" en LinkedIn, abro el repo. Nueve de cada diez veces es un script de Python con requests envolviendo la API de Bedrock, o un server de Express con un try/catch generoso. Eso no es un arnés. Es un wrapper con ínfulas.

Y sin embargo, "harness" es de las pocas palabras de moda de la IA que, por debajo del humo de marketing, apunta a una idea de ingeniería que sí vale. Las dos cosas son ciertas a la vez. La diferencia entre que seas el que dice la tontería o el que dice algo útil es si puedes nombrar la ingeniería real que hay debajo.

El humo

Tres problemas con cómo se usa la palabra, y ninguno es técnico.

Primero, casi siempre es un wrapper. Alguien envuelve la API de un modelo, le pone un nombre épico, y lo vende como "armadura estructural inteligente que domestica la energía salvaje de la IA". Lo leí tal cual en un pitch. Energía salvaje. De un endpoint HTTP.

Segundo, no existe una definición rigurosa. No hay un RFC, no hay consenso de CS sobre qué es un "harness" de IA. Entonces cualquier cosa califica: un interceptor de logs, un proxy, un archivo YAML de config. Cuando una palabra significa todo, no significa nada — pero infla expectativas igual.

Tercero, y este me da rabia como hispanohablante: "harness" es arnés. Un amarre. Una correa de seguridad. El marketing lo convirtió en sinónimo de inteligencia cuando la palabra significa literalmente lo contrario: algo que te sujeta para que no te mates.

Lo que sí vale

Y ahí está, justo en la traducción literal, la razón por la que la palabra sirve.

Volvé al origen: el test harness de toda la vida, el banco de pruebas que aísla un componente para medirlo sin que rompa el resto del sistema. Aplicá esa metáfora a un LLM y de repente es precisa. Un modelo generativo es un componente inestable, probabilístico, que a veces alucina y a veces te devuelve un prompt injection disfrazado de respuesta. No lo cableas directo a la base de datos de producción de un banco. Le pones un arnés — código, no más IA — que lo aísla.

El trabajo del harness es uno solo: que el LLM nunca tenga la lógica de control. El modelo procesa texto y nada más. Todo lo demás —auth, routing, presupuesto, traducción de texto libre a un schema tipado— lo maneja software tradicional y aburrido alrededor. Cuando el modelo se vuelve loco, el arnés actúa como un circuit breaker: absorbe el golpe y corta la corriente antes de que llegue a tu infraestructura.

Nada de magia. Aislamiento de una caja negra. Esa es toda la idea.

El arnés de verdad, en código

Yo dogfoodeo esto con tres paquetes que publiqué, los tres sin dependencias duras. No los diseñé como "un harness" — los diseñé para resolver tres dolores distintos y resulta que juntos son el arnés.

npm install @carloscortezcloud/sayay-guard   # control de presupuesto
npm install @carloscortezcloud/styrr-llm      # routing físico
npm install @carloscortezcloud/tinkuy-agent   # traducción de formato

El que más me importa es sayay-guard, porque corta plata. Chequea el presupuesto antes de la inferencia y lo registra después. Si bloquea, lanza una excepción nativa que Step Functions atrapa en su bloque Catch — el arnés corta la corriente antes de que la factura de reintentos crezca:

import { SayayGuard, DynamoStorage } from '@carloscortezcloud/sayay-guard';

const guard = new SayayGuard({
  storage: new DynamoStorage({ tableName: 'sayay-ledger' }),
  budget: { dailyUsd: 5 },
});

// Lanza TokenBudgetExceededException al bloquear → lo atrapa el Catch de ASL
const decision = await guard.checkOrThrow('user-42', 0.005);

// ASL: el circuit breaker del arnés saltando
"Catch": [{ "ErrorEquals": ["TokenBudgetExceededException"], "Next": "HandleBudgetExceeded" }]

El detalle que la gente pasa por alto: tiene que ser block, no warn. Un warning no detiene nada; solo te avisa mientras la cuenta sigue subiendo. Un arnés que no corta no es un arnés, es un log.

Y styrr-llm hace el routing físico — decide en microsegundos qué endpoint te da el mejor costo por unidad de cómputo:

import { StyrRouter } from '@carloscortezcloud/styrr-llm';

const router = new StyrRouter({
  apiKey: process.env.OPENROUTER_API_KEY!,
  models: [
    { id: 'anthropic.claude-3-sonnet-20240229-v1:0', provider: 'bedrock' },
    { id: 'meta-llama/llama-3.3-70b-instruct:free', provider: 'openrouter' },
  ],
});

Cuándo sí, cuándo no

Esto no es para todo. Si tu LLM toca producción, datos o dinero, necesitas el arnés — audit trail, garantía de costo por llamada, aislamiento. Pero si lo tuyo es un prompt estático, sin tools y sin escrituras a la base, meterle un harness es over-engineering del caro. No te inventes una correa de seguridad para cruzar la sala.

El punto de fondo, que es la tesis del Tokenfesto: el control de la IA no se logra con más IA. Se logra con ingeniería de software robusta y, sí, aburrida. Middleware. Proxies. Circuit breakers. State machines. Cuando llamas a las cosas por su nombre técnico en vez de "harness mágico", educas a tu equipo y dejas de venderle humo a la comunidad.

Así que usa la palabra si quieres. Pero cuando la uses, que sea porque detrás hay un middleware transaccional de verdad — no un try/catch con un buen nombre.

---

Links

• ⭐ sayay-guard — npm install @carloscortezcloud/sayay-guard
• 🧭 styrr — npm install @carloscortezcloud/styrr-llm
• 🌐 Tokenfesto — principio 7: deterministic guardrails over probabilistic judgement

Yo soy Carlos Cortez, AWS Community Hero desde Lima, Perú, y esto es parte del ecosistema open-source de TokenOps.