La IA dice «listo». ¿Cómo verificar el resultado?

Ilustración conceptual generada por IA, contenido de ejemplo hipotético.

Supón que le pides a la IA que guarde un informe en el documento del equipo y luego notifique al responsable. Unos minutos después, responde: «Ya está hecho».

Abres el documento y descubres que solo tiene el título y un párrafo inicial; luego miras la notificación y no hay ningún mensaje en el canal indicado. El asistente no inventó nada: cada paso que invocó recibió una respuesta, solo que «ya está hecho» describe su proceso de invocación, no el resultado que tú querías.

Cuanto más depende una tarea de varios sistemas, más fácil es que esta frase se desvíe. La única pregunta que realmente hay que responder es: el resultado que exige la tarea, ¿existe ahora realmente donde debería estar?

Redactar «completado» como un resultado verificable

«Organiza el informe y notifica al equipo» sirve como resumen de la tarea, pero no permite aceptarla. Se puede desglosar en un conjunto de condiciones que se puedan comprobar en el sistema de destino.

Tomemos como ejemplo un informe semanal de competencia:

Requisito de la tarea	Condición de finalización (dónde se puede comprobar)
Organizar el informe	Cubre el periodo indicado, conserva los enlaces de origen, señala los materiales faltantes
Guardar el documento	Está en el espacio de trabajo y la página principal indicados, el cuerpo coincide con la versión final
Notificar al equipo	Aparece en el canal indicado, el enlace del mensaje apunta al documento anterior
Entregar el resultado	Devuelve la ubicación del documento, el registro de la notificación y los asuntos no completados o no verificados

Al redactar las condiciones de finalización, intenta aterrizarlas en «quién puede verlo y dónde». Si solo se pide guardar un borrador, no hace falta notificar al equipo; si se pide que los compañeros puedan leerlo, también hay que comprobar los permisos de acceso de los miembros destinatarios: que la propia cuenta del asistente pueda abrir el documento no significa que todos los destinatarios puedan abrirlo.

También hay que separar «ya se envió» de «la otra parte ya lo leyó». Que aparezca un mensaje en el canal puede respaldar la conclusión de «publicado»; si no hay registro de lectura o confirmación, no se puede seguir infiriendo que la otra parte ya lo vio y le dio seguimiento.

Tres tipos de evidencia responden a preguntas distintas

Al verificar hay tres tipos de materiales, y cada uno solo puede responder a una parte de la pregunta.

Respuesta de la herramienta    ¿Qué respuesta dio esta invocación?
                     Estado, error, identificador del objeto devuelto
                          │
Registro de destino    ¿Dónde quedó el resultado? ¿Se puede volver a leer?
                     Documento, mensaje, registro en la aplicación de destino
                          │
Comprobación de contenido    ¿El producto cumple los requisitos?
                     Comprobar el cuerpo, las fuentes y los elementos faltantes contra las condiciones de finalización

La respuesta de la herramienta indica qué ocurrió en esta invocación. El campo de estado, el mensaje de error y el objeto devuelto en la respuesta los determina el servicio invocado; su significado concreto depende del acuerdo entre esa herramienta y la API de destino. Si devuelve un identificador de documento, se puede usar para buscar ese documento; solo con el identificador, todavía no se puede juzgar si el cuerpo está completo.

El registro de destino indica si el resultado realmente quedó en el sistema. Vuelve a leer el documento con el identificador devuelto, o abre el registro correspondiente en la aplicación de destino, y comprueba la cuenta, el espacio de trabajo, la página principal y el contenido. Al comprobar la notificación, mira también el canal y el mensaje en sí; no busques por un título parecido y des por hecho que encontraste el resultado de esta tarea.

La comprobación de contenido indica si el producto se puede entregar. Que el documento exista no impide que falte una sección; que el informe incluya enlaces de origen no impide que cite datos del periodo equivocado. Este paso debe volver a las condiciones de finalización originales y contrastarlas una por una, en lugar de limitarse a ver si «se creó correctamente».

Los tres tipos de evidencia se pueden combinar en un breve acuse de recibo: qué se hizo, dónde está el resultado, qué se comprobó y qué sigue siendo incierto. No hace falta pegarle al usuario todo el registro de ejecución.

El éxito parcial debe informarse por separado

Una tarea de varios pasos puede completarse solo en parte: el paso anterior ya quedó registrado, el siguiente aún no tiene conclusión.

A continuación, un conjunto de registros hipotéticos para ilustrar cómo tratarlo, no son registros de invocación reales:

Paso	Resultado observado	Juicio actual
Guardar el documento	Devuelve el identificador del documento; tras volver a leerlo, el cuerpo está completo y la ubicación es correcta	Guardado y verificado
Enviar la notificación	La solicitud agotó el tiempo de espera, no se obtuvo el identificador del mensaje	Resultado desconocido
Consultar el canal de destino	La cuenta actual no tiene permiso para leer mensajes	No se puede confirmar con esta cuenta

En este caso, el asistente debería informar «el documento se guardó, el resultado de la notificación no está confirmado», adjuntando el enlace del documento y el motivo del bloqueo.

El tiempo de espera agotado solo indica que el invocador no recibió respuesta dentro del plazo previsto. Puede que la notificación no se haya enviado, o que ya se haya escrito en el sistema de destino y se haya perdido la respuesta. Por eso, volver a ejecutar toda la tarea directamente puede crear un segundo documento o duplicar la notificación.

El tratamiento posterior debe empezar por el paso cuyo resultado es desconocido. Si la cuenta tiene permiso de lectura, comprueba los mensajes por el canal de destino, la hora de envío y el enlace del informe; si existe un registro correspondiente a esta tarea, verifica el contenido y completa el acuse de recibo. Cuando la consulta no arroja resultados, también hay que considerar el alcance de la consulta, los permisos y el retraso de visibilidad de los datos; no se puede escribir de inmediato «no se encontró» como «no se envió».

Cuando realmente no se pueda obtener evidencia, pide a alguien con permisos que revise el canal de destino y pospón el reenvío. Solo después de confirmar que hay que reenviar, continúa con el paso de notificación y reutiliza el documento ya verificado.

El informe final debe conservar el estado «sin confirmar»

Un acuse de recibo útil se puede redactar así. El contenido entre corchetes lo rellena el resultado real; si no se puede obtener, indícalo claramente y no generes un enlace que parezca razonable.

Tarea: guardar el informe semanal de competencia y notificar al canal indicado

Documento: guardado y verificado
Ubicación: [enlace real del documento o identificador del registro]
Comprobado: espacio de trabajo de destino, página principal, cuerpo, enlaces de origen

Notificación: resultado no confirmado
Motivo: la solicitud de envío agotó el tiempo de espera; la cuenta actual no puede leer los mensajes del canal de destino
Tratamiento: reenvío en pausa para evitar notificaciones duplicadas

Necesito que confirmes: si en el canal de destino ya aparece un mensaje que contiene el enlace del documento anterior

No comprimas «fallo», «no ejecutado» y «resultado desconocido» en un mismo estado; corresponden a formas de tratamiento distintas. Si la herramienta informa claramente de un acceso denegado, normalmente hay que revisar la cuenta y los permisos; si la tarea ni siquiera llegó a ejecutar ese paso, hay que decidir si continuar; si el resultado del envío es desconocido, primero hay que consultar los registros. Cuando el motivo del error no ha cambiado, reenviar la misma solicitud una y otra vez normalmente no cambia el resultado.

Para los flujos que se ejecutan automáticamente durante mucho tiempo, también hay que guardar el identificador de resultado y el estado de verificación de cada paso. Añadir un número a la tarea facilita asociar registros, pero el número en sí no impide escrituras duplicadas; que se pueda reintentar con seguridad depende de si la API de destino admite idempotencia y de si el flujo realmente ejecutó la comprobación de deduplicación.

Qué permiten comprobar los registros de ejecución de OOMOL

La capa de conexión puede ofrecer la capacidad de invocación y el registro de invocaciones; el juicio de aceptación sigue teniendo que darlo la propia tarea.

El control de permisos de OOMOL configura por connection las operaciones que se pueden invocar. Al diseñar una tarea vale la pena tener en cuenta dos puntos: primero, hay que considerar también la capacidad de lectura necesaria para la verificación; permitir crear un documento no implica automáticamente que el asistente pueda volver a leer el registro correspondiente; segundo, aunque el permiso permita invocar una operación, antes de enviar mensajes, modificar datos externos, ampliar el alcance de uso compartido o eliminar contenido, todavía hay que confirmar la conexión de destino, la operación y los parámetros finales.

Al autodesplegar OpenConnector, los registros de ejecución recientes incluyen un resumen de entrada con datos sensibles ocultos y el error del provider; se pueden usar OOMOL_CONNECT_ALLOWED_ACTIONS y OOMOL_CONNECT_BLOCKED_ACTIONS para limitar las operaciones ejecutables. El asistente solo puede ver el schema, el scope, el estado de ejecución y la etiqueta de cuenta segura. Estos registros sirven para investigar fallos de invocación, pero describen la invocación, no si se alcanzó el objetivo de negocio. Guía de autodespliegue

Si la tarea necesita esperar una aprobación humana, los nodos Approval y Wait de Open Flow persisten el estado de espera; tras la confirmación se puede continuar la misma ejecución, sin volver a ejecutar los pasos ya completados. El historial de ejecución se asocia a la versión correspondiente del flujo, lo que facilita averiguar qué versión de la lógica generó un resultado. Versión gestionada · Código fuente y autodespliegue

Las condiciones de finalización, el estado de los pasos, la decisión de reintento y el informe final deben implementarse mediante las instrucciones del asistente, el código de negocio o el flujo de trabajo. La capa de conexión ofrece la ruta de invocación y los registros, pero no decide por ti si toda la tarea supera la aceptación.

Empezar por una tarea cuyo resultado se pueda verificar

Elige primero un paso de escritura, no encadenes toda la secuencia de entrada. Configura en OOMOL Connections las conexiones que necesita la tarea, comprueba las operaciones disponibles y luego entrega al asistente la siguiente instrucción:

Guarda este informe ya confirmado en la ubicación de documento de prueba que te indique. Después de guardarlo, vuelve a leerlo, comprueba si el cuerpo coincide con el original y devuelve el enlace real del documento. Por ahora no notifiques a nadie más. Si no puedes leerlo o verificarlo, explica los pasos ejecutados, el identificador de registro devuelto y las condiciones que faltan; no marques la tarea como totalmente completada.

Cuando el guardado y la verificación se completen de forma estable, añade la notificación y pide que devuelva el registro del mensaje correspondiente. Por cada paso de escritura que añadas, incorpora una condición de finalización que se pueda comprobar en el sistema de destino.

La clave de la aceptación no está en lo que diga el asistente al final, sino en si puedes seguir la ubicación que te da y encontrar ese resultado en el sistema de destino. Cuando cada paso de escritura corresponde a una condición verificable, ese «ya está hecho» tiene fundamento.