A los builders nos encanta tratar el human-in-the-loop como una vergüenza temporal: lo que quitas cuando el modelo, el script o el RPA ya es "suficientemente bueno." En trabajo pesado de ops, ese framing va al revés. El paso de juicio no es muleta. Es el producto.

El fallo no es "un humano lo tocó"

El fallo es un sistema que produce un output confiado mientras la decisión real — seguir o parar, confiar o escalar — sigue siendo de una persona que ya no ve la evidencia. Si tu automatización mueve tecleo pero entierra las razones, no liberaste juicio. Lo escondiste. Así es como los errores silenciosos se vuelven retrasos, riesgo y operadores que dejan de creer en el botón. Escribí sobre condiciones de apagado en Automatización falsificable. Esta es la gemela: define dónde el humano debe seguir visible antes de celebrar el camino autónomo.

El juicio es el contrato

En superficies como ECORPA, el cliente no compra un spinner que termina. Compra un camino confiable hacia una decisión con portales ajenos y datos incompletos. El humano en el loop es cómo esa promesa se mantiene honesta cuando el happy path miente. Las tools personales en tools.danieldiaz.dev pueden ser más estrictas y silenciosas — a menudo el único operador soy yo. El producto de empresa no puede fingir lo mismo. Mismo oficio de sistemas. Distinto contrato con el usuario. Por eso tools y empresa se mantienen aparte.

Tres diseños que dejan el HITL de verdad

1. Evidencia antes de la acción — la pantalla que pide juicio debe mostrar los inputs que usó el modelo o el script, no solo la recomendación.
2. Desacuerdo ruidoso — cuando automatización y operador divergen, el sistema lo registra. La divergencia es señal, no vergüenza.
3. Autonomía acotada — automatiza preparación y routing; deja el commit irreversible detrás de un paso humano explícito hasta que un falsificador diga lo contrario.

Si no puedes nombrar cuál paso es irreversible, no estás listo para quitar al humano. Estás listo para quitar la accountability.

Lo que me niego a shippear como "listo"

• Un flujo que termina en "éxito" mientras quien decide sigue abriendo tres pestañas para verificar.
• Un bot que se salta la pantalla de juicio porque el demo se veía limpio.
• Una métrica que cuenta corridas completadas sin contar overturns tras revisión humana.

Eso es theater con mejor CI. Falla la misma barra que las historias del cajón en El 99% que se queda en el cajón: contacto con la realidad, no highlight reel.

Checklist: ¿HITL es el producto o la disculpa?

1. ¿Puede el operador ver por qué el sistema sugiere X?
2. ¿El paso irreversible tiene dueño humano explícito hasta prueba en contrario?
3. ¿Medimos overturns y tiempo-hasta-juicio, no solo throughput?
4. Cuando un portal ajeno se mueve, ¿el humano sigue teniendo un camino seguro — o solo un auto path roto? (ver Cuando el portal se mueve)
5. ¿Apagaría la rama "autónoma" si los overturns suben dos semanas?

Si la respuesta a (5) es "nunca la apagaríamos," no estás shippeando un producto. Estás shippeando una historia en la que los operadores ya no confían. El human-in-the-loop no es el plan B de una automatización débil. En esta clase de trabajo, es la superficie del producto. La automatización gana el derecho a preparar la decisión — no a borrarla.