Sistema de monitoreo y ejecución delegada para once proyectos de IA

Contexto

Un grupo empresarial B2B lleva adelante once proyectos de IA en paralelo, cada uno con su repositorio, su estado y sus bloqueos propios. Para consolidar el seguimiento se construyó un sistema interno que corre en modo headless, escanea los repositorios y produce reportes de estado. Con el tiempo, ese sistema sumó una segunda capa: proponer y ejecutar trabajo bajo aprobación explícita.

Problema

La información de estado de los once proyectos ya existía, dispersa en cada repositorio, pero no estaba consolidada ni era confiable de leer a mano: el costo no era generar el reporte, era saber qué mirar cada día sin inventar un dato que faltaba. Un segundo problema apareció al pasar de lectura a ejecución: una vez que un agente puede leer once repositorios, la posibilidad de que también escriba en ellos exige control, porque esos repositorios incluyen código en producción, secretos y datos reales de clientes.

Solución

El diseño se apoyó en reglas determinísticas y no en el criterio del modelo, concentrando el control humano en un único punto: antes de que cualquier cambio llegue al código en producción.

• Regla de diseño no negociable: nunca inventar estado ni fechas; cuando un dato falta, se marca como desconocido, y cada porcentaje de avance se etiqueta según su origen (archivo de estado documentado o inferencia del sistema).
• Cada proyecto piloto tiene un contrato propio que declara zona permitida, zona prohibida y definición de hecho; sin contrato activo no hay ejecución.
• Un guardrail determinístico corre antes de cada acción del agente y bloquea la lectura de secretos, la escritura sobre el código en producción, borrados recursivos, migraciones y escritura fuera de las rutas permitidas.
• Antes de que el trabajo llegue a manos humanas, dos revisores automáticos en modo de solo lectura lo controlan: uno verifica que se haya hecho solo lo aprobado y otro revisa secretos y superficie de ataque; un rechazo es final.

Resultados

• El monitor sostiene la foto diaria y semanal de los once proyectos sin intervención manual: 31 entregables quedaron generados en un período de dos meses, junto con 34 archivos de resumen en disco.
• En una prueba del guardrail se bloquearon más de dieciocho intentos de acciones prohibidas —entre ellas un cambio no autorizado sobre el código en producción, lectura de archivos con secretos y borrados recursivos— antes de que se ejecutaran.
• El modo de ejecución delegada completó su ciclo de propuesta, aprobación y ejecución sobre dos pilotos activos, con la entrega del ejecutor registrada, aprobación del auditor automático y aprobación con observaciones del revisor de seguridad.

Arquitectura y decisiones

El monitor separa el estado de trabajo del entregable: los archivos de estado detallado quedan en disco como registro interno y nunca se envían por mail; solo un resumen final se publica hacia el canal de salida. El sistema no envía nada directamente por ningún canal externo: escribe archivos, y un flujo de automatización aparte vigila esa salida y hace el envío.

Sobre esa base se construyó el modo de ejecución delegada: cada corrida identifica trabajo posible y lo propone con un identificador único; sin una respuesta explícita de aprobación, nada se ejecuta. Los agentes trabajan en un espacio de trabajo aislado, separado en todo momento del código en producción, y solo pueden incorporar a su entrega los archivos que la tarea aprobada autoriza, sin tocar nada fuera de ese alcance. Esa evaluación de qué está autorizado se definió por zona del proyecto y no por el proyecto completo, para distinguir áreas donde el agente tiene permiso de escribir de aquellas que no. El pase de ese trabajo al código en producción quedó reservado como paso manual de la persona responsable del proyecto, fuera del alcance de la automatización: ningún cambio pasa a producción de forma automática.