Cómo verificar que una automatización de IA terminó bien

Una automatización termina bien cuando el resultado previsto puede comprobarse en la fuente o el conjunto de fuentes que conservan el estado final. Que el orquestador —el sistema que coordina los pasos— muestre todos los pasos en verde demuestra que ejecutó un recorrido sin registrar un error. No demuestra que el proceso externo completara el trabajo.

La diferencia importa más cuando interviene un agente de IA. El agente puede describir con mucha seguridad lo que cree haber hecho. Sin embargo, puede haber recibido una confirmación parcial, interpretado mal una respuesta o actuado sobre el objeto equivocado. La verificación tiene que apoyarse en una postcondición observable: un hecho que debe ser verdadero al terminar. No puede depender del relato que produce el mismo componente que ejecutó la acción.

Qué respalda este enfoque y qué sigue abierto

Las tres fuentes revisadas no ofrecen un estándar único para cerrar una automatización de IA. Coinciden en una idea que después hay que convertir en diseño: delegar una acción y verificar su resultado son problemas distintos.

El contrato que propongo más abajo es una síntesis operativa de esas piezas y de los fallos conocidos de los procesos asíncronos. No se trata de un estándar publicado ni de un resultado experimental propio. Su valor depende de que permita definir una postcondición, demostrarla y recuperar una excepción sin repetir la acción a ciegas.

Un paso verde solo acredita que ese paso terminó

Pensemos en un caso hipotético. Una automatización recibe la baja de una persona externa y debe retirar su acceso. Para ello, el flujo localiza la cuenta, pide al proveedor de identidad que la desactive y recibe una respuesta aceptada. Con esa respuesta, marca el ticket como resuelto.

Todos los pasos pueden aparecer en verde y, aun así, la cuenta seguir activa. Puede ocurrir que el proveedor procese la baja de forma asíncrona y la rechace más tarde. También puede suceder que la petición haya apuntado a otra cuenta con un identificador parecido. Una integración secundaria podría conservar una sesión; si se pierde la confirmación, además, el proceso puede quedar en un estado que nadie revisa.

Aunque el flujo terminó y la acción fue aceptada, el acceso no quedó retirado. Los tres hechos deben distinguirse.

El error de diseño está en usar la ausencia de excepciones como condición de éxito. Una llamada técnica solo puede afirmar lo que su contrato garantiza. Según RFC 9110, secciones 15.3.1 y 15.3.3, 200 OK indica que la petición ha tenido éxito según la semántica de la operación y, tras un POST, puede representar el estado o el resultado de la acción. No demuestra por sí solo que un proceso asíncrono posterior haya terminado. Un 202 Accepted afirma que la petición se ha recibido para su procesamiento. Si el efecto ocurre después, el proceso necesita observarlo.

Ejecución, aceptación y resultado son estados distintos

Separaría la finalización en tres niveles:

El cierre exige una postcondición observable en la fuente que conserva el efecto.

Los tres niveles no siempre necesitan esperas distintas. Una operación síncrona puede aceptar y completar dentro de la misma respuesta. Aun así, conviene conservar la distinción: obliga a comprobar qué promete realmente el contrato y evita convertir cualquier código HTTP de éxito en una prueba de negocio.

En procesos asíncronos la separación debe aparecer en el modelo de estados. Una acción aceptada pasa a «pendiente de comprobar». Desde ahí puede llegar a «resultado verificado», «resultado rechazado», «plazo agotado» o «requiere intervención». Si solo existen éxito y error, cualquier estado intermedio acabará escondido dentro de un registro o de una cola.

El resultado se define antes de automatizar

La herramienta no debería ser la primera decisión. Antes escribiría un contrato de resultado con la información mínima que permite saber cuándo ha terminado el trabajo, sin convertirlo en un documento jurídico ni en una especificación extensa.

El estado previo impide automatizar una acción que todavía no está autorizada, mientras que definir el efecto evita expresiones como «gestionar la baja», que no dicen qué cambia. Al identificar la fuente de prueba también aparece el propietario del estado; el plazo convierte una espera indefinida en una excepción, y el responsable evita que acabe en una bandeja sin dueño.

Una automatización queda terminada cuando una evidencia independiente y consultable demuestra el resultado dentro de las garantías y tolerancias acordadas. Si nadie puede leer esa prueba, el proceso puede estar automatizado, pero no puede considerarse verificado ni cerrarse de forma defendible.

El relato del agente no demuestra el resultado

Un agente puede devolver «cuenta desactivada» porque llamó a la herramienta correcta y recibió una respuesta que interpretó como éxito. Sin embargo, esa frase solo es una salida narrativa. La evidencia procede de una lectura posterior del estado de la cuenta o de un evento final emitido por el sistema que la gestiona.

La verificación debería usar un canal distinto siempre que el riesgo lo justifique. La acción puede ejecutarse mediante una orden y comprobarse con una consulta de estado. La independencia tiene varias capas: fuente autoritativa, ruta de código, credenciales y momento de la lectura. Si acción y consulta pasan por el mismo adaptador, comparten algunos modos de fallo y esa limitación debe quedar explícita.

Para reconstruir lo ocurrido conservaría solo la evidencia necesaria, no la respuesta completa sin filtrar: puede contener datos personales, tokens o secretos. La evidencia se depura o enmascara, se cifra, se limita por permisos y se elimina según una política de retención. El identificador de correlación enlaza registros; la clave de idempotencia evita duplicados solo si el receptor o nuestra propia tabla de operaciones la hacen cumplir.

Tampoco basta con pedir al agente que «revise su trabajo» usando el mismo texto que acaba de generar. Esa segunda respuesta puede repetir el supuesto inicial. La comprobación gana fuerza cuando cambia la evidencia: leer el sistema de registro, ejecutar una prueba, validar una regla o pedir a una persona que resuelva una discrepancia concreta.

El coste de la comprobación debe ajustarse al daño posible, sin desconfiar por defecto de toda salida. Para ordenar notas internas puede bastar una revisión por muestreo. Para retirar accesos, emitir un pago o publicar una calificación, la postcondición debe quedar demostrada antes de cerrar el proceso.

El éxito técnico puede ocultar fallos posteriores

Cuando la ejecución y el resultado se mezclan, los fallos posteriores se descubren por una queja o una auditoría. El contrato permite anticiparlos:

La recuperación depende de la naturaleza de la acción. Una acción reversible puede deshacerse tras verificar el estado; una compensable exige otra operación que deje evidencia; una que solo admite recuperación hacia delante debe completarse; una irreversible se detiene antes y requiere una autoridad mayor. «Compensar» no sirve como respuesta genérica para pagos, publicaciones, correos o decisiones legales.

Reintentar sin conocer el estado final es especialmente peligroso. Si la primera acción tuvo efecto y solo se perdió la respuesta, el segundo intento puede duplicarlo. Antes de repetir, consultaría la postcondición o reconciliaría mediante una clave estable de la operación de negocio.

Una clave basada en el número de intento no sirve para deduplicar. Cada reintento produciría una clave distinta. La identidad debe pertenecer al trabajo que se quiere completar, no a la ejecución técnica que intenta completarlo.

El reintento tampoco sale directamente de «plazo agotado». Primero pasa por reconciliación; solo vuelve a emitir la misma operación lógica cuando no existe evidencia del efecto y el receptor admite idempotencia. Así se evita que una lectura obsoleta convierta un éxito tardío en una segunda acción destructiva.

La revisión humana necesita autoridad y contexto

Añadir un paso de aprobación humana no resuelve por sí solo la verificación. La persona necesita saber qué se pidió, qué respondió cada sistema, qué postcondición falta y cuánto tiempo queda. También necesita autoridad para aceptar, rechazar, corregir o escalar.

Una bandeja que solo muestra «el agente no está seguro» traslada la investigación entera a operaciones. Una excepción útil llega con el objeto afectado, la regla incumplida, la evidencia disponible, el historial de intentos y las acciones permitidas. El trabajo humano se concentra entonces en la decisión que no puede automatizarse.

La intervención responde a tres motivos: una discrepancia, cuando el sistema devuelve un estado distinto del esperado; la falta de prueba dentro del plazo, o un riesgo que exige autorización aunque la acción sea técnicamente posible. Mezclarlos en una sola cola impide priorizar y medir.

La cola necesita límites operativos (prioridad por daño y antigüedad, responsable suplente, capacidad máxima y escalado antes de saturarse) y métricas sobre la edad de los pendientes, las discrepancias, los duplicados, los reintentos agotados, el tiempo hasta el resultado y la carga de revisión humana.

La autoridad también importa. Si quien revisa no puede corregir el dato ni detener el proceso, su aprobación es decorativa. La automatización necesita un propietario de la excepción con acceso al sistema y una política clara de escalado.

La productividad se calcula después de verificar

La estimación habitual compara minutos manuales con segundos de ejecución. Deja fuera el diseño del flujo, la vigilancia, las revisiones, las excepciones y la recuperación. Con ese cálculo casi cualquier automatización parece rentable.

Usaría una medida de tiempo neto liberado, no un ROI completo:

tiempo evitado de trabajo manual
    − diseño y mantenimiento prorrateados
    − supervisión y comprobación
    − tratamiento de excepciones
    − retrabajo y recuperación
    = tiempo neto liberado

La medida se apoya en resultados verificados. Si el flujo procesa cien bajas y diez quedan pendientes sin que nadie lo sepa, no ha completado cien casos. Si las diez excepciones requieren veinte minutos de investigación, ese coste forma parte del proceso.

También mediría el tiempo hasta el resultado, no solo el tiempo de ejecución. Una automatización que responde en segundos y tarda dos días en resolver sus excepciones puede ser peor que un proceso más lento con un estado final fiable. La pieza sobre productividad del desarrollo con IA aplica la misma idea al cambio de software validado y estable.

Una automatización termina cuando la evidencia demuestra el resultado

El contrato de resultado cambia el orden del trabajo. Primero se define qué debe cambiar, quién conserva ese estado, cómo se demostrará, cuánto puede tardar y quién resuelve la excepción. Después se elige el orquestador, el agente o la integración.

Esta secuencia evita usar el panel técnico como evidencia de un proceso externo que no observa. El orquestador acredita la ejecución, el sistema receptor acredita la aceptación y la fuente de registro acredita el resultado. Cuando esas tres pruebas coinciden, el flujo puede cerrarse con una razón que una persona y otra máquina pueden comprobar.

Ese es el umbral que utilizaré para el resto del clúster de automatización. La siguiente pregunta será qué procesos merecen automatizarse según su variabilidad, reversibilidad, coste del error y prueba disponible. Sin una postcondición verificable, la respuesta será sencilla: todavía no.

Última revisión: 27 de julio de 2026.

Alberto Lara Hernández trabaja en dirección técnica, arquitectura de software, inteligencia artificial aplicada y plataformas de aprendizaje.