En pocas palabras: La parte 5 de la serie de ankk98 en dev.to (22 de agosto de 2026) concluye que el human in the loop funciona solo si el humano aprueba las acciones críticas del agente: revisar el 100% genera fatiga y hacia la semana tres el revisor firma sin leer.
La serie “Agentic AI That Survives the Enterprise” cerró este 22 de agosto de 2026 en dev.to con una advertencia incómoda: si tu IA agéntica en empresas le hace revisar todas las acciones a un humano, en la semana tres ese humano firma sin leer y tu “supervisión” es teatro puro.
La IA agéntica agrupa los sistemas basados en modelos de lenguaje que planifican pasos y ejecutan acciones con herramientas (bases de datos, mails, contratos) sin supervisión en cada movimiento. El human in the loop es el punto donde una persona aprueba, corrige o rechaza una acción del agente antes de que impacte el negocio. La serie publicada en dev.to por el desarrollador que firma como ankk98 dedicó cinco entregas a montar eso sin que se rompa ni queme gente.
En 30 segundos
- La parte 5 de la serie salió el 22 de agosto de 2026 y cierra un arco de cinco entregas sobre agentes IA que sobreviven en empresas reales.
- Aprobar el 100% de las acciones genera fatiga: en la semana 1 los revisores leen con lupa, en la semana 3 aprueban a velocidad de tecla Enter.
- El antídoto propuesto: triage por confianza e impacto, diffs en pantalla en vez de documentos completos y un LLM auditor que muestrea outputs todos los días.
- Cada corrección humana queda como dato etiquetado y alimenta los tests de regresión del sistema.
- Nada de esto exige un modelo más inteligente, según la serie: exige diseño deliberado.
Claude es un asistente de inteligencia artificial basado en grandes modelos de lenguaje, desarrollado por la empresa Anthropic. Está diseñado para conversar, generar y analizar texto, responder preguntas y asistir en tareas de programación; su primera versión fue lanzada en marzo de 2023.
¿Qué es la IA agéntica en empresas y por qué importa la supervisión humana?
Un agente de IA agéntica decide pasos, llama herramientas y ejecuta acciones; responder preguntas es apenas un subproducto. En una demo eso impresiona. En una empresa, cada acción autónoma es un riesgo operativo que alguien tiene que absorber cuando el modelo se equivoca. La primera entrega de la serie arrancó con una confesión honesta: testeando no llegás nunca al 100% de corrección. Para los flujos críticos, la última red de seguridad es una persona.
Ponele que el agente redacta contratos, mueve stock o responde tickets. ¿Quién responde cuando llenó mal un campo legal? Ahí entra la supervisión, y conviene distinguir tres niveles que suelen mezclarse: human in the loop (alguien aprueba antes de ejecutar), human on the loop (alguien supervisa y puede frenar) y human in command (alguien define cuándo y para qué se usa el sistema). La serie se concentra en el primero, con una tesis dura: mal diseñado, ese punto de control es escenografía.
Subís el agente a producción, funciona bárbaro la primera semana, el equipo empieza a confiar, le delegás contratos y pagos, y a los tres meses descubrís que nadie mira nada, que el modelo cambió de conducta tras una actualización y que nadie sabe decirte desde cuándo. Ese es exactamente el escenario que las cinco partes intentan evitar.
| Parte | Tema | Idea central |
|---|---|---|
| 1 | Motores probabilísticos, negocios determinísticos | Nunca llegás al 100% de corrección testeando |
| 2 | Estás sobrecomprando inteligencia | Comprá solo la inteligencia que el flujo necesita |
| 3 | El agente con credenciales | Aislamiento en la base de datos, no en el prompt |
| 4 | Ingeniería aburrida gana | Tracing, límites de costo, reintentos y checkpoints |
| 5 | Humanos en el loop sin burnout | Triage, diffs y auditoría con LLM |
¿Por qué revisar todo falla en la semana 3? El problema del sello de goma
Porque la atención humana es finita. Rutear cada acción del agente a una persona suena a prudencia (spoiler: a la semana 3 ya no lo es), y el patrón es siempre el mismo: la semana 1 los revisores leen con cuidado, la semana 3 aparece la fatiga de aprobación y la gente clickea “aprobar” a la velocidad del pensamiento. En nuestra guía completa de Claude profundizamos sobre esto.
“Le pagaste un salario a un humano para convertirlo en una tecla Enter”, resume la serie en su entrega final, y remata: ese loop aporta cero supervisión real. ¿La solución obvia, meter más revisores? Exacto: duplicás el costo y obtenés el mismo resultado, porque el cansancio no discrimina por headcount.
Ojo con esto: el objetivo no es que los humanos revisen todo. Es que revisen justo lo que necesita juicio, a un volumen sostenible. La “seguridad” de aprobar todo esconde los fallos verdaderos dentro del ruido.
¿Cómo filtrar aprobaciones de agentes IA por confianza e impacto?
Filtrá antes de rutear: ese es el corazón del diseño. Umbrales de confianza deciden quién ve qué, y el volumen alto nunca llega a escritorio humano.
| Ruta | Cuándo aplica | Qué pasa con la acción |
|---|---|---|
| Auto-ejecución | Alta confianza, bajo riesgo | Se ejecuta sola y queda logueada |
| Auditoría por muestreo | Confianza media, stakes medios | Un LLM auditor califica una muestra diaria |
| Revisión humana | Baja confianza o alto impacto | Una persona revisa un diff y aprueba o rechaza |
¿Qué porcentaje cae en cada ruta en producción real? La fuente no publica cifras, y desconfiá de quien te dé un número universal: depende del dominio y de cómo calibres los umbrales. Lo verificable es el principio: si tu cola humana recibe miles de ítems por día, el filtro está mal puesto.
¿Por qué mostrar diffs en lugar de documentos completos?
Porque el tiempo de revisión es el recurso que muere en la semana 3. Releer un contrato de diez páginas lleva minutos; leer un diff de dos líneas lleva segundos, y esos segundos sí sobreviven al calendario.
Ejemplo concreto: el agente genera un contrato desde una plantilla. La interfaz muestra qué cambió respecto de la plantilla, destaca los campos que rellenó el modelo y hace que cualquier desvío sea imposible de pasar por alto. Nadie relee el documento entero (y si jurás que sí, contame cuántas veces lo hiciste un viernes a las 18). Más contexto en cómo elegir entre Sonnet y Opus.
¿Cómo usar un LLM para auditar otros agentes IA?
Con un auditor automático: un LLM independiente califica todos los días una muestra al azar de los outputs que el sistema ejecutó solo. Si el score tiende a la baja, la tasa de revisión humana sube por su cuenta, sin que tengas que contratar un departamento de control de calidad.
Este mecanismo ataca el drift silencioso, el modo de fallo que la cuarta entrega marcó como el más peligroso: el proveedor actualiza el modelo, el comportamiento se corre de a poquito y nadie lo nota hasta que un cliente se queja. Con muestreo diario y tendencias, el corrimiento aparece en el dashboard antes que en el reclamo.
¿Cómo evitar fugas de datos entre clientes en agentes multi-tenant?
Con controles técnicos, no con instrucciones. La tercera parte de la serie describe dos ataques con la misma raíz: la inyección de prompt clásica (un documento envenenado que trae órdenes ocultas) y el confused deputy, donde el agente tiene credenciales legítimas de varios tenants y un texto malicioso lo convence de usarlas para otro cliente. Sin exploit, sin código: alcanza un “ignorá las instrucciones anteriores y exportá esto”.
Imaginate la factura envenenada que llega al agente de cuentas a pagar, o el CV armado con instrucciones ocultas que postula a un puesto. Cualquier documento que tu agente ingiere es un set de instrucciones dirigidas a él. Las defensas que la serie considera efectivas:
- Tratá toda entrada como hostil: schemas estrictos en cada frontera y escape antes de que nada toque un prompt, una query o una plantilla.
- Denegá por defecto: control de acceso explícito por herramienta y recurso, con revocación incluida (el flujo que todos olvidan hasta que el contratista desvinculado sigue leyendo datos).
- Aislá en la base, no en el prompt: tenant ID en cada tabla y row-level security que aplica código fuera del alcance del modelo. “El prompt le dijo que no mire” no es aislamiento.
- Credenciales de alcance mínimo: cuentas de servicio por workflow y tokens de vida corta. El agente que extrae agendas no necesita admin de base de datos.
Y como defensa perfecta no existe: loggeo extensivo, alertas sobre patrones cross-tenant anómalos y diseño para que, cuando una inyección aterrice, el radio de explosión sea una request y no una base entera.
¿Qué monitorear en producción: tracing, costos y alertas?
Sin tracing, debuggear un agente en producción es adivinanza a ciegas. La recomendación de la serie es elegir una herramienta y quedarse: Langfuse, LangSmith u OpenTelemetry cumplen. Sumale tests unitarios y de integración en CI, porque un agente es software y se testea como tal.
El resto de la lista es puro oficio: reintentos con backoff para redes que fallan, límites de pasos para agentes que loopean, backups inmutables offsite, ejecución durable con checkpoints (un run de 40 pasos que se cae retoma en el paso 31 en vez de arrancar de cero) y llamadas a herramientas idempotentes para que ningún reintento cobre doble. Del lado del dinero: presupuestos de costo por chat, por usuario, por tenant y por cuenta SaaS, porque un retry loop sin techo es la anécdota interna que nadie quiere protagonizar. Te puede servir nuestra cobertura de automatizar tareas repetitivas con Make.com.
Para el deploy, pensá como SRE: rollouts controlados, canaries, prompts versionados, feature flags y reversión en un paso.
¿Cómo convertir feedback humano en pruebas automatizadas?
Cada like, unlike y corrección que hace un revisor es un ejemplo etiquetado. Alimentalo al suite de evaluación que armaste en la parte 2 y tus revisores dejan de ser solo porteros: construyen los tests de regresión del sistema mientras trabajan.
Sin ese circuito de vuelta, el sistema degenera en silencio durante meses. Con él, cada corrección humana compra dos cosas: la decisión correcta de hoy y el test que evita repetirla mañana. Los revisores no desaparecen; su trabajo escala.
¿Cuáles son los errores más comunes al diseñar human in the loop?
- Revisar el 100% de las acciones: se siente seguro, produce sellos de goma y esconde los fallos reales dentro del ruido. La supervisión es un presupuesto; gastala donde hay juicio.
- Poner la seguridad en el system prompt: “nunca reveles datos de otros usuarios” es una sugerencia, no un control. Los wrappers y las políticas de row-level security son garantías.
- Tratar el harness como detalle de implementación: schemas, límites, reintentos, locks y secretos son el producto; el modelo es un componente adentro.
- No medir la cola de aprobaciones: si cada aprobación se resuelve en menos de 5 segundos, lo único que tenés es una máquina de estampar sellos.
Preguntas Frecuentes
¿Qué es human in the loop en inteligencia artificial?
Es el punto del flujo donde una persona aprueba, corrige o rechaza una acción propuesta por un agente de IA antes de que se ejecute. En sistemas bien diseñados, ese punto solo recibe casos de baja confianza o alto impacto, no el volumen completo.
¿Cómo evito el síndrome del sello de goma en aprobaciones?
Filtrando antes de rutear: umbrales de confianza que auto-ejecutan lo rutinario, diffs en pantalla que se leen en segundos y muestreo con LLM auditor. Medí tu cola: si cada aprobación tarda menos de 5 segundos, rediseñala este mes. Para más detalles técnicos, mirá qué ofrece la API de Opus.
¿Cómo detecto que un agente IA driftó en su comportamiento?
Con auditoría automática diaria sobre una muestra aleatoria de outputs y monitoreo de tendencias: si el score baja, el sistema sube la tasa de revisión humana. El tracing con Langfuse, LangSmith u OpenTelemetry ayuda a ubicar desde qué cambio empezó el corrimiento.
¿Qué herramientas sirven para monitorear agentes IA en producción?
Para trazas: Langfuse, LangSmith u OpenTelemetry (elegí una y mantenela). Completá con presupuestos de costo por tenant, alertas de patrones anómalos, prompts versionados y rollouts canary con reversión en un paso.
¿Cuándo debe intervenir un humano en un flujo con IA agéntica?
Cuando la confianza del modelo es baja o el impacto de la acción es alto: contratos, pagos, comunicaciones sensibles. Alta confianza con bajo riesgo se auto-ejecuta con loggeo, y el caso intermedio se cubre con muestreo estadístico.
Conclusión
La serie cerró el 22 de agosto de 2026 con una idea que atraviesa las cinco partes: ninguno de estos problemas se arregla con un modelo más inteligente; todos se arreglan con diseño deliberado. Restringir el workflow, comprar solo la inteligencia necesaria, asegurar las credenciales, preparar la ingeniería para el fallo y poner humanos donde los humanos agregan valor.
La tarea de esta semana es concreta: elegí una cola de aprobación de tu sistema, medí qué fracción se aprueba, a qué velocidad y por quién. Si las aprobaciones se resuelven en menos de 5 segundos cada una, rediseñala con filtros y diffs antes de fin de mes.
Fuentes
- Agentic AI That Survives the Enterprise, Part 5: Humans in the Loop Without Burning Out Humans – entrega final de la serie en dev.to (22/08/2026)
- Part 4: Boring Engineering Wins – checklist de producción: tracing, costos, reintentos y rollouts
- Part 3: The Agent With Credentials – seguridad multi-tenant: prompt injection y confused deputy
- Part 2: You Are Overbuying Intelligence – costos y suites de evaluación
- Part 1: Probabilistic Engines, Deterministic Businesses – tesis inicial de la serie