Diseñar para HITL: el contrato entre la automatización y el juicio humano

La mayoría de los workflows no fallan en los pasos automatizados. Fallan en las costuras — el momento en que una regla no puede decidir, la evidencia es ambigua, el caso es raro o la política se escribió para un mundo que ya no existe. Los equipos instrumentan el camino feliz con cuidado y dejan el camino infeliz como una idea tardía: un ping de Slack, un correo a un buzón compartido, un ticket que nadie posee. La pregunta interesante no es si automatizar. La pregunta interesante es dónde el humano se gana su asiento en la ejecución, qué ve cuando se sienta y cómo el workflow sabe que terminó.

TL;DR

• La automatización pura se rompe en tres costuras predecibles: acciones de alto impacto, evidencia ambigua y situaciones nuevas. Diseña para esas costuras antes de diseñar el camino feliz.
• Una task en Sommatic es un contrato — asignación, cola, prioridad, SLA, evidencia, output validado — no es una notificación ni un ticket.
• Bien diseñado, HITL baja el costo por caso y sube la confianza al mismo tiempo, porque los humanos solo ven los casos que necesitan un humano.

Dónde se rompe la automatización pura

Todo equipo que construye workflows termina chocando con la misma pared. El primer noventa por ciento de los casos corre limpio. El último diez por ciento consume la mayor parte del presupuesto operacional, genera la mayor parte de las quejas de clientes y produce la mayor parte de los postmortems. Esos casos no son aleatorios. Se agrupan en tres clases de decisiones que nunca deberían auto-resolverse, y reconocer la clase es el primer paso para decidir dónde poner a un humano.

Primero, decisiones de alto impacto. Un reembolso de quince dólares y uno de quince mil dólares no son la misma operación, aunque el workflow se vea idéntico. El radio de impacto de equivocarse es lo que hace del segundo un problema distinto. Las decisiones de alto impacto son aquellas donde el costo de un falso positivo (auto-aprobar fraude) y de un falso negativo (negar un caso legítimo y perder al cliente) son ambos significativos, y donde la organización quiere una persona con nombre y apellido atada al resultado. La regla práctica es simple: si una respuesta equivocada exigiría un postmortem, el workflow debe pausar y preguntar.

Segundo, evidencia ambigua. Algunos casos son claros desde los inputs. Se transpuso un dígito; la dirección coincide; la huella del dispositivo es familiar. Otros casos quedan en el medio de la distribución — el documento es parcialmente legible, el agente extrajo tres de cuatro campos con alta confianza y uno con baja, la historia del cliente no coincide con el sistema de registro pero es internamente consistente. La evidencia ambigua no es una falla del modelo; es un modelo haciendo su trabajo y diciéndote que la respuesta es genuinamente incierta. Auto-resolver un caso incierto es como se quema la confianza.

Tercero, situaciones nuevas. Todo workflow se escribe contra una distribución conocida de casos. En el momento en que aparece un caso que la política no anticipó — un nuevo regulador, un nuevo patrón de fraude, una nueva línea de producto, un socio que rompió su contrato — el workflow no tiene nada que decir. Un buen sistema reconoce la novedad (un umbral de confianza no alcanzado, un camino no recorrido antes, una referencia de política no encontrada en el Knowledge Center) y enruta el caso a un humano que pueda decidir y, más importante, dejar rastro de que la política necesita actualizarse.

El trabajo de diseñar para HITL es el trabajo de catalogar estas costuras antes de que el workflow salga a producción, nombrar cada una y decidir qué pasa cuando el workflow llega a ella.

La task como contrato

Una task no es una notificación. Una notificación es algo que un sistema envía; una task es algo que un operador le debe al workflow. Una task tampoco es un ticket. Un ticket vive en una cola que puede o no trabajarse, con un estado que puede o no reflejarse en el sistema originador, y con resultados que pueden o no ser legibles por máquina. Una task es una compuerta contractual, no un ítem de bandeja de entrada.

En Sommatic, el contrato tiene seis cláusulas, y una task no existe sin todas ellas.

Asignación. La task sabe quién la posee. No un buzón grupal, no una rotación que nadie monitorea — un actor con nombre, con el rol, el alcance y el permiso de actuar. Si el operador asignado no puede actuar (fuera de oficina, fuera de alcance, conflicto de interés), la task sabe cómo reasignarse sin perder su historia.

Cola. La task vive en una cola con reglas de orden, capacidad y priorización. Las colas no son solo listas; son la unidad en la que se mide el trabajo en curso, se reporta el throughput y se detectan los cuellos de botella.

Prioridad y SLA. La task carga una prioridad y un plazo, ambos derivados del caso, no de la preferencia del operador. Un reembolso de alto valor y uno de bajo valor no son la misma task con la misma prioridad, aunque el workflow que las levantó sea el mismo.

Rastro de evidencia. La task llega con los artefactos que el operador necesita para decidir: el evento originador, la propuesta del agente, los pasajes de política relevantes del Knowledge Center, las decisiones previas sobre casos relacionados, el registro del cliente. El operador no sale a cazar; el caso llega a él.

Output validado. La task no se cierra con un comentario en texto libre. Se cierra con un resultado estructurado — aprobar, rechazar, escalar, pedir más información — que el workflow puede consumir. La validación es parte de la definición de la task, no un chequeo posterior.

Auditoría. Cada transición sobre la task — quién la tomó, qué vio, qué decidió, cuánto tardó, qué evidencia referenció — queda capturada y es reproducible. La Explainability no es solo una característica del workflow; también lo es de la task.

Una task a la que le falta alguna de estas cláusulas no es una task. Es una notificación con ambición.

De dónde vienen las tasks

Las tasks no aparecen de la nada. Las producen tres fuentes, y cada una tiene una postura de diseño distinta.

Los workflows pausan para ellas. La fuente más común es un Tasks node ubicado dentro de un workflow. El workflow corre, llega al nodo y cede el control. El estado de la instancia se persiste; el motor sabe que está esperando a un humano. Cuando la task cierra con un output validado, el workflow reanuda desde donde pausó, con la decisión del operador atada a la ejecución como evidencia. Este es el patrón más limpio: el autor del workflow toma la decisión de poner una compuerta en tiempo de diseño, y el operador nunca ve un caso que no le corresponde decidir.

Los agentes escalan a ellas. Un Agent trabajando un caso puede decidir, a media corrida, que el caso está fuera de su envoltura. El agente no improvisa; levanta una task con el contexto que reunió, la propuesta que estaba por hacer y la razón por la que se detuvo. Este es el patrón que mantiene a los agentes dentro de su carril. El trabajo del agente no es tener razón en todo; el trabajo del agente es tener razón en lo que sabe y escalar limpiamente sobre lo que no sabe.

Los operadores las despachan desde el Command Center. A veces el caso empieza con un humano. Un supervisor ve algo en Omnisearch, lo abre en el Command Center y decide que esto necesita ir a un operador específico con un plazo específico. El despacho produce una task con el mismo contrato que las otras dos fuentes — asignación, cola, prioridad, SLA, evidencia, output validado — y el operador que la recibe no puede notar, y no debería necesitar notar, que la task empezó con un humano y no con un workflow.

Tres fuentes, un contrato. Esa uniformidad es lo que hace que el trabajo sea medible.

Dónde los humanos las trabajan

Una task que llega a un buzón genérico es una task que perdió la mitad de su valor antes de que el operador la abriera. El operador ahora tiene que reunir el contexto, encontrar la política, buscar las decisiones previas y recordar las reglas de validación. El trabajo del workflow queda deshecho por el trabajo que el operador tiene que hacer para empezar a trabajar.

En Sommatic, las tasks se trabajan dentro de Operational Apps — superficies React construidas a propósito y producidas por el App Engine, cada una diseñada para un tipo específico de decisión. Una app de revisión de reembolsos no es una cola genérica con una caja de comentarios; es una pantalla que muestra la transacción, la historia del cliente, el pasaje de política que el workflow emparejó, la propuesta del agente y los controles estructurados aprobar/rechazar/escalar que producen el output validado. Una app de revisión de documentos muestra la imagen fuente al lado de los campos extraídos, permite al operador corregir lo que el modelo se equivocó y devuelve el payload corregido al workflow.

El Knowledge Center se carga dentro de la app, no se enlaza desde ella. El operador no sale a un wiki; los pasajes de política relevantes a este caso están presentes en el momento de la decisión. Las decisiones previas también se cargan — los últimos cinco reembolsos para este cliente, los últimos veinte para este comercio, los casos comparables que cerraron en el último trimestre. El operador trabaja con el caso, la política y el precedente en una sola superficie.

Aquí es donde las Operational Apps se diferencian de los sistemas de tickets. Un sistema de tickets es un contenedor genérico para cualquier tipo de trabajo. Una Operational App es un contenedor específico para un tipo específico de decisión, con el contrato de la task y el contexto del caso integrados en la pantalla. El resultado son tiempos de decisión más cortos, resultados más consistentes y rastros de auditoría que capturan no solo lo que el operador decidió sino lo que tenía enfrente cuando decidió.

Patrones de diseño

No hay una regla universal de dónde poner la compuerta. Hay una pequeña biblioteca de patrones que aparecen en operaciones de distintos rubros, y la mayoría de los workflows son un ensamble de unos pocos. Tres patrones aparecen con suficiente frecuencia para nombrarlos.

Compuerta de triage de reembolsos. El workflow recibe una solicitud de reembolso. Un chequeo de reglas clasifica el caso por monto y riesgo. Los reembolsos pequeños bajo un umbral, de clientes de bajo riesgo, con evidencia limpia, se auto-aprueban y escriben el resultado. Los reembolsos ambiguos — monto medio, evidencia parcial, sin historia reciente — van a una cola de tasks trabajada por operadores de primera línea dentro de una app de revisión de reembolsos. Los reembolsos grandes, los reembolsos para cuentas marcadas, o los reembolsos por encima de un umbral regulatorio, escalan a una task en una cola de supervisor con un SLA más ajustado y un requisito de segunda aprobación. Un workflow, tres caminos, una forma de resultado validado.

Cola de revisión de documentos. El workflow ingiere un documento — una factura, un anexo de contrato, un formulario enviado por el cliente. Un nodo de OCR extrae texto. Un Agent propone campos estructurados con un puntaje de confianza por campo. Los campos por encima del umbral pasan; los campos por debajo levantan una task en una app de revisión de documentos donde el operador ve la imagen fuente y los campos extraídos lado a lado. El operador confirma o corrige, y el workflow reanuda con el payload estructurado validado. El agente nunca publica extracciones inciertas, y el operador nunca re-tipea datos que ya se extrajeron correctamente.

Triage de excepciones. El workflow corre y algo se rompe — un sistema downstream devuelve un error, una validación de contrato falla, un paso hace timeout. En lugar de tirar la ejecución, el workflow levanta una task que carga el contexto completo de ejecución: qué nodo falló, qué devolvió el último paso exitoso, qué intentó el motor, qué dijo el error. La task aterriza en una cola de excepciones trabajada por operadores que entienden el workflow lo suficiente para decidir si reintentar, saltar, reparar el dato y reanudar, o cancelar. La excepción no es una línea de log en un dashboard de monitoreo; es una pieza de trabajo con un dueño y un plazo.

El hilo común entre los tres: el autor del workflow decide en tiempo de diseño dónde están las costuras, y el runtime hace que las costuras sean operables.

Cómo se ve esto: la compuerta de triage de reembolsos de punta a punta

Sigue un reembolso a través del sistema para ver cómo el contrato se sostiene.

Un cliente solicita un reembolso por un pedido que llegó dañado. La solicitud aterriza por el canal de soporte como un evento estructurado y dispara un workflow de reembolso. El primer nodo es un Agent que lee el mensaje del cliente, recupera la orden del sistema de registro, extrae la historia previa de reembolsos del cliente y propone una clasificación: reembolso elegible, monto $48, la evidencia respalda el reclamo (foto adjunta, orden entregada hace cinco días, sin marcas de fraude previas). La propuesta del agente se escribe al estado del workflow como un payload estructurado.

El siguiente nodo es un chequeo de reglas. La regla dice: montos bajo $25 de clientes con al menos tres transacciones limpias se auto-aprueban; montos entre $25 y $200 con evidencia de respaldo van a una task de primera línea; montos sobre $200 o cualquier caso con marcas de riesgo escalan a una task de supervisor. Este reembolso cae en la banda media. El workflow avanza a un Tasks node.

El Tasks node crea una task con el contrato intacto. Asignación: enrutada por reglas de cola a un operador de reembolsos de primera línea en turno, con el alcance correcto para la región del cliente. Cola: refund-triage-frontline. Prioridad: estándar. SLA: cuatro horas hábiles. Evidencia: el mensaje del cliente, el registro de la orden, la foto, la propuesta del agente, los pasajes de política relevantes del Knowledge Center sobre reembolsos por productos dañados, y las tres interacciones previas más recientes del cliente. Output validado: aprobar al monto propuesto, aprobar a un monto distinto con razón, rechazar con razón, escalar a supervisor con nota. El estado de la instancia del workflow se persiste; el motor cede.

El operador abre la app de revisión de reembolsos desde su cola. La pantalla muestra el mensaje del cliente a la izquierda, la foto y el detalle de la orden en el centro, la propuesta del agente y la referencia de política a la derecha. El operador lee el mensaje, mira la foto, confirma que la propuesta coincide con la política y aprueba al monto propuesto. El output validado escribe de vuelta a la task. La task cierra. El motor del workflow reanuda la instancia.

El siguiente nodo ejecuta el reembolso a través de la integración de pagos. Un nodo posterior envía la confirmación al cliente. Un nodo final escribe el caso cerrado de vuelta al canal de soporte. La ejecución se completa. Tiempo total de reloj: menos de cinco minutos. Tiempo total del operador: menos de treinta segundos. El rastro de auditoría captura la propuesta del agente, la decisión de la regla, la asignación de la task, la vista del operador sobre la evidencia, el resultado validado, la confirmación del pago y la notificación al cliente — todo atado a un identificador de ejecución y reproducible seis meses después.

Eso es lo que compra el contrato: una decisión del operador que cuesta treinta segundos y produce un registro que sobrevive a una auditoría.

La economía del HITL bien hecho

Una preocupación común sobre human-in-the-loop es el costo. Si una persona tiene que mirar cada caso, no automatizaste nada; construiste un sistema caro de notificaciones. Esa preocupación es correcta, y es también por qué el diseño importa. La economía del HITL cambia cuando los humanos solo ven los casos que necesitan un humano.

Cuando el workflow pone las compuertas correctas, tres números se mueven. Casos por hora-operador sube, porque el operador no anda persiguiendo contexto — el caso llega con la evidencia cargada. La calidad de la decisión sube, porque el operador ve la política y el precedente en el momento de decidir, no después. El costo por caso baja, porque la fracción de casos que necesita un humano se encoge hacia la fracción que genuinamente lo necesita.

Un cuarto número se mueve que es más difícil de poner en un dashboard: la confianza. Los operadores confían en workflows que escalan honestamente. Los clientes confían en resultados que vienen con un nombre adjunto. Los auditores confían en sistemas donde cada caso cerrado tiene un resultado estructurado y un camino trazable. La confianza es lo que le permite a la organización subir el umbral de auto-resolución el próximo trimestre, porque los casos que se ponen en compuerta lo hacen por la razón correcta.

La trampa es la inversa. Un sistema que auto-resuelve casos que debería haber puesto en compuerta quema confianza rápido, y la respuesta usual es retroceder la automatización — volver a poner humanos sobre casos que no los necesitaban. El sistema que puso compuertas con exceso se recupera; el sistema que auto-resolvió con exceso, muchas veces, no.

Diseñar para HITL no es diseñar al humano como un fallback. Es diseñar al humano como un participante de primera clase en la ejecución, con un contrato, una superficie y una contribución medible. Hecho así, la automatización y el juicio humano dejan de competir por los mismos casos y empiezan a operar como un solo sistema.

Sommatic entrega las piezas que hacen esto concreto: Workflows que pausan limpiamente, Tasks con el contrato intacto, Operational Apps que cargan el caso y el contexto juntos, un Knowledge Center del que las apps leen, Agents que saben cuándo escalar, un Command Center que permite a los supervisores despachar y observar, y Explainability que captura cada paso. El trabajo de decidir dónde poner la compuerta es tuyo. El trabajo de hacer que la compuerta sea operable es nuestro.

→ Cómo Sommatic maneja Tasks