Seguimiento de proyectos con IA: menos avisos repetidos, sin perder cambios

Ilustración conceptual generada por IA; el contenido es un ejemplo hipotético.

Supón que le pides a la IA que vigile un proyecto con entrega el viernes. El lunes te recuerda que el cliente aún no ha confirmado los materiales; el martes envía un resumen casi idéntico. El miércoles, el cliente ya ha propuesto un aplazamiento por correo, pero el tablero del proyecto sigue indicando entrega el viernes. El asistente incluye ambas fechas en el informe y termina recomendándote que “sigas atento”.

Todavía tienes que abrir el correo, revisar el tablero y volver a preguntar al responsable.

El seguimiento continuo requiere conservar la última evaluación y explicar qué ha cambiado esta vez. Si en cada ejecución se resume todo el material desde cero, el asistente puede convertir mensajes antiguos en avances nuevos, o tomar una propuesta aún no decidida como un acuerdo ya vigente.

Qué hay que dejar tras un resumen

Ya existen bastantes intentos de organizar información entre aplicaciones. El caso del periódico familiar diario de Composio combina calendario, clima y contenido de entretenimiento en un pequeño diario del día; la presentación del AI teammate de Lindy analiza el contexto continuo y el seguimiento proactivo. Estos contenidos muestran qué puede organizarse con la información del día, pero no responden a una pregunta más concreta: entre dos comprobaciones consecutivas, qué juicios ya confirmados deben conservarse.

Un resumen del día te ayuda a entender los planes inmediatos; una tarea de seguimiento continuo también necesita explicar qué ha ocurrido respecto a la vez anterior.

Tomando como ejemplo la entrega de un proyecto, después de organizar el material por primera vez vale la pena conservar muy poco: la fecha de entrega confirmada actual, los materiales aún pendientes, la persona responsable del seguimiento y las fuentes que respaldan esos juicios. También hay que anotar hasta qué momento cubre esta comprobación y qué fuentes no se pudieron leer.

Este registro es el punto de partida de la siguiente comprobación. Puede guardarse en la base de datos de una aplicación, en un registro de tareas o en un documento controlado; la forma concreta la decide el sistema del asistente. Lo importante es que las ejecuciones posteriores puedan leerlo realmente y sepan qué parte está confirmada y qué parte es solo una suposición.

Si la vez anterior solo había una frase como “el proyecto avanza con normalidad”, la siguiente vez será difícil explicar qué ha cambiado exactamente.

Un mensaje nuevo no implica necesariamente que el asunto haya avanzado

El mismo material se reenvía al grupo, llega un “recibido, gracias” al correo y alguien modifica la descripción de una tarea en el tablero. Todos son registros nuevos, pero su impacto en la entrega es distinto.

La comparación puede girar en torno a los hechos que importan para la tarea. Para este proyecto, lo que realmente necesitas saber es: si los materiales están completos, si cambió la fecha de entrega, quién asumió la tarea pendiente y si apareció un nuevo bloqueo.

A continuación, un conjunto de situaciones hipotéticas:

Lo leído esta vez	Cómo debe interpretarse	Cómo conviene recordarlo
Un colega reenvía la solicitud de materiales del lunes	Es el mismo asunto; aún no hay nueva información de entrega	No repetir el mismo recordatorio; recordarlo igualmente al vencer
El cliente envía el archivo adjunto que faltaba	El material se ha recibido; aún hay que comprobar si cumple los requisitos	Explicar qué se recibió y qué falta
El cliente pregunta si puede cambiarse al lunes siguiente	Ha aparecido una solicitud de cambio de fecha	Marcarlo como pendiente de decisión y conservar la fecha confirmada actual
El responsable acepta explícitamente el cambio de fecha	Aparece un nuevo registro de confirmación	Explicar la fecha original, la nueva fecha y la fuente de la confirmación

Para identificar el mismo registro pueden usarse los identificadores que ofrece el sistema de origen; para determinar si registros distintos describen el mismo asunto hay que combinar proyecto, participantes y contenido. Que dos correos tengan el mismo asunto no basta para fusionarlos de forma fiable. Que el texto sea distinto tampoco debería llevar a pensar que el proyecto ha avanzado otro paso.

Los campos ya definidos pueden compararse directamente; los puntos que requieren comprensión semántica pueden dejarse al modelo. Por ejemplo, primero se localizan las tareas cuyo campo de fecha ha cambiado y luego se pide a la IA que lea los debates relacionados y explique si ese cambio ya se ha confirmado.

Cuando el correo y el tablero no coinciden, hay que dejar constancia de la discrepancia

El correo del miércoles propone entregar el lunes siguiente; el tablero sigue indicando viernes. ¿Cuál cuenta?

“Actualizado más tarde” solo indica cuándo se registró, no que quien habla tenga autoridad para cambiar el plan. El correo puede ser una solicitud, el tablero puede no haberse actualizado, o puede que solo esté citando la fecha de otra tarea.

El equipo puede acordar de antemano en qué basarse. Por ejemplo, que la fecha de entrega se rija por la confirmación del responsable designado y que el tablero sirva para registrar el plan ya confirmado. Así, cuando el asistente vea el correo de cambio de fecha, podrá clasificarlo como asunto pendiente de confirmación; y cuando vea que el responsable está de acuerdo, podrá señalar que el tablero aún debe sincronizarse.

Si no existe un acuerdo, el asistente debe presentar ambos registros juntos, explicar la discrepancia y dejar la decisión al responsable. A continuación, un ejemplo ficticio de recordatorio:

El cliente solicita hoy por correo cambiar la entrega al lunes siguiente; el tablero del proyecto sigue indicando este viernes. En los registros disponibles actualmente no se ha encontrado una confirmación del cambio de fecha por parte del responsable. Confirma si se acepta la solicitud.

Al citar fuentes deben darse enlaces reales y abribles; escribir solo “correo del cliente” o “tablero” impide que el responsable lo verifique.

Aquí hace falta una decisión humana, y la petición es muy clara. En comparación con “sigue atento a los riesgos del proyecto”, el responsable sabe qué debe responder y puede abrir directamente la evidencia.

Ausencia de cambios, fallo de comprobación y vencimiento deben tratarse por separado

Un asistente que funciona de forma continua debe permitir resultados silenciosos. Si las fuentes designadas se comprueban correctamente y nada ha cambiado, puede registrarse el resultado de la comprobación y, según lo acordado, no enviar otro resumen duplicado.

Pero cuando falla la lectura del correo, no puede llegarse a la misma conclusión. El asistente solo sabe que no pudo completar la comprobación; debe conservar la posición de la última lectura correcta e indicar las fuentes omitidas esta vez. Tras recuperar el acceso, hay que revisar los registros del periodo omitido; si la interfaz ofrece un cursor incremental, puede continuarse la lectura según su convención; de lo contrario, debe diseñarse una consulta que cubra el tiempo omitido. No basta con consultar solo el día de la recuperación y suponer que no hubo cambios intermedios.

El artículo de Viktor sobre automatizaciones que fallan en silencio describe lo difícil que resulta detectar que una tarea de larga duración ha dejado de funcionar. Con las tareas de seguimiento ocurre lo mismo: cuando no llega un recordatorio, deberías poder consultar si se ejecutó la última vez y qué fuentes revisó.

Hay otra situación que requiere un recordatorio aunque no haya mensajes nuevos: se ha alcanzado el plazo acordado. Si el cliente no ha respondido y llega el momento de seguimiento pactado entre ambas partes, este asunto merece volver a aparecer.

Por tanto, un recordatorio puede provenir de un cambio real o de una condición temporal acordada de antemano. Cuando la tarea termina, se cancela o pasa a manos del responsable, también deben detenerse los recordatorios correspondientes. De lo contrario, un trabajo ya completado seguiría exigiendo tu atención cada día.

OOMOL proporciona conexiones de aplicaciones para tareas de seguimiento

Para comparar cambios entre dos comprobaciones, el asistente necesita leer registros de sistemas reales. En OOMOL, el Connector SDK explica cómo elegir una cuenta de conexión ya autorizada y llamar a la operación correspondiente de la aplicación; la pasarela se encarga de custodiar las credenciales y realizar la solicitud real.

Por ejemplo, para el seguimiento de un proyecto se conectan el correo de trabajo y la herramienta de gestión de proyectos, y luego se comprueba si ofrecen la búsqueda, la lectura de detalles y los campos de hora de actualización necesarios. Los distintos servicios varían en alcance de consulta, historial y capacidades incrementales, por lo que hay que confirmarlo según cada interfaz concreta.

El último estado confirmado, la relación entre distintas fuentes, las condiciones de recordatorio y las condiciones de parada los conserva y ejecuta el asistente o el flujo de negocio. Una vez establecida la conexión, esas reglas de la tarea siguen siendo necesarias.

La primera versión puede limitarse a habilitar las operaciones de lectura necesarias y entregar el informe de cambios al responsable. Cuando haga falta sincronizar el tablero o responder al cliente, se configuran las operaciones correspondientes según la guía de control de acceso y se especifican el objetivo de ejecución y la forma de confirmación.

Si el equipo necesita gestionar por su cuenta el servicio de conexiones, puede usar el proyecto de código abierto de OOMOL OpenConnector y administrar credenciales, políticas de operación y registros de ejecución según la guía de autoalojamiento.

Comprobar dos veces seguidas con el mismo proyecto

Puedes conectar desde OOMOL Connections las aplicaciones que necesita la tarea y pedir a un asistente que admita llamadas a capacidades de conexión y pueda guardar el estado de la tarea que gestione una solicitud de alcance bien definido:

Ayúdame a hacer seguimiento de la fecha de entrega y los materiales pendientes de este proyecto. Primero lee la conversación de correo indicada y las tareas del proyecto, organiza el estado confirmado actual, los asuntos pendientes de confirmación y las fuentes, y guárdalo como base para comparaciones posteriores. Esta vez entrégame solo el resultado, sin modificar los sistemas de origen. En la próxima comprobación, explica qué ha cambiado respecto a esta vez; si no hay cambios, no repitas el resumen; si falla la lectura, indica qué falta. La hora del recordatorio y las condiciones de parada se configurarán después de que yo las confirme.

En la primera comprobación, verifica si eligió bien el proyecto, el correo y el responsable. En la segunda puedes añadir con material de prueba un reenvío duplicado, una solicitud de cambio de fecha y una confirmación formal, y observar si el asistente distingue las tres cosas. Luego deja temporalmente una fuente no disponible y comprueba si presenta el fallo de lectura como “sin avances”.

Cuando estos juicios se ajusten a lo esperado, programa la ejecución periódica. El siguiente recordatorio que recibas debería responder a una pregunta concreta: respecto al último estado confirmado, ¿qué hay ahora que requiera tu intervención?