El problema real: horas perdidas revisando reportes internos
Imagina que cada fin de mes, tu equipo de gestión tiene que revisar decenas de reportes escritos por distintos desarrolladores, con formatos diferentes, niveles de detalle dispares y entradas crípticas como "ajusté el header" o "fixed issue". Alguien tiene que leer todo eso, entender qué se hizo realmente, y armar una lista limpia de logros del mes. Es tedioso, propenso a errores y, si lo delegas a una IA en la nube, potencialmente un riesgo de seguridad.
Ese fue exactamente el punto de partida de un equipo de ingeniería que documentó su solución en Dev.to. La respuesta que encontraron no fue contratar más gente ni resignarse a usar ChatGPT con datos sensibles. Fue construir un agente local con LLM que automatiza todo el proceso dentro de sus propios servidores.
En este artículo analizamos su arquitectura, los resultados reales que obtuvieron, y por qué este enfoque es especialmente relevante para empresas en Perú y Latinoamérica que manejan información confidencial de proyectos.
Cómo funciona el agente: un pipeline de 6 pasos
El sistema está construido como una aplicación de consola que se ejecuta automáticamente al final de cada ciclo mensual. Usa Ollama para correr un modelo local de lenguaje (Gemma 4) y el modelo de embeddings nomic-embed-text para detección de duplicados semánticos. Todo corre sobre CPU, sin necesidad de GPU costosa.
El primer paso es la normalización. Un mismo proyecto puede recibir más de 80 reportes por mes, cada uno escrito de forma diferente. El agente convierte ese caos en un formato estructurado y consistente que el resto del pipeline puede procesar.
El segundo paso es el chunking. El modelo tiene un límite de 4,096 tokens por contexto. Para no superarlo, el sistema divide los reportes en bloques de aproximadamente 20 entradas cada uno. En una prueba real, 22 reportes crudos se expandieron a 94 ítems individuales después de separar entradas compuestas como "hice A, hice B, hice C".
El tercer paso es el enriquecimiento desde Jira. Cuando el agente detecta un ID de ticket en el reporte, consulta la API de Jira y trae la descripción completa. Así, una entrada como "AAA-123 – done" se convierte en un resumen profesional y comprensible para cualquier gerente.
El cuarto paso es el filtrado de ruido. Frases vagas como "trabajando en..." o "haciendo seguimiento" no representan trabajo terminado. El sistema las elimina. En la prueba documentada, este filtro descartó el 69.1% de las entradas. Solo 29 de 94 ítems sobrevivieron — los concretos y terminados.
El quinto paso es la selección de candidatos. Se elige un pool más amplio del necesario (por ejemplo, 80 ítems) para compensar lo que se descartará en el siguiente paso.
El sexto y más sofisticado paso es la detección de duplicados por vectores semánticos. Cada ítem se convierte en un vector numérico que representa su significado. Luego se compara contra el historial completo del proyecto almacenado en PostgreSQL. Si la similitud supera 0.85 (85%), el ítem se descarta como duplicado — incluso si está redactado de forma diferente. Esto evita que el mismo trabajo aparezca en dos reportes distintos del mes o de meses anteriores.
Por qué el enfoque on-premise importa más de lo que parece
El equipo que desarrolló esta solución empezó experimentando con ChatGPT. Funcionaba bien técnicamente, pero el problema era otro: estaban enviando un mes completo de actividad interna de proyectos a servidores externos. Para muchas empresas, eso es inaceptable.
Al correr el agente completamente en sus propios servidores, eliminaron ese riesgo. No hay datos que salgan de la organización. No hay dependencia de una API externa que puede cambiar precios o condiciones. Y el costo operativo es significativamente menor que pagar por tokens en un modelo cloud con uso intensivo mensual.
Uno de los argumentos más frecuentes contra los LLMs locales es que necesitan hardware caro con GPU. Este proyecto demuestra lo contrario: Gemma 4 corriendo en CPU con Ollama es suficiente para este tipo de tarea de procesamiento por lotes. No es tiempo real, pero para un proceso que se ejecuta una vez al mes, la velocidad no es el factor crítico. La privacidad y el control sí lo son.
¿Cómo aplica esto en empresas de Perú y Latinoamérica?
En la región, muchas empresas de servicios de TI, consultoras, estudios de abogados, clínicas y entidades financieras tienen el mismo problema: equipos que generan reportes periódicos en formatos inconsistentes, y alguien que tiene que leerlos todos para extraer lo relevante. Es trabajo manual, repetitivo y costoso en horas.
La buena noticia es que la arquitectura descrita no requiere infraestructura de nube ni presupuestos de empresa Fortune 500. Un servidor interno con recursos moderados es suficiente para implementar un pipeline similar. Y si ya tienen Jira u otro sistema de gestión de proyectos con API, la integración es directa.
Además, en sectores regulados como salud o finanzas, donde las normativas locales exigen que ciertos datos no salgan del país o de la organización, un agente on-premise no es solo una preferencia técnica — es un requisito de cumplimiento.
¿Cómo aplica esto en tu empresa?
Si tu equipo dedica tiempo mensual a consolidar reportes, extraer tareas o preparar resúmenes de avance de proyectos, este tipo de agente puede automatizar entre el 70% y el 80% de ese trabajo. Los pasos para evaluarlo son claros:
- Identifica el proceso repetitivo: ¿Qué tipo de reportes se consolidan manualmente cada mes? ¿Quién lo hace y cuántas horas toma?
- Evalúa la sensibilidad de los datos: Si la información no puede salir de la organización, un agente local como este es la única opción viable.
- Revisa tus integraciones actuales: Si ya usan Jira, Azure DevOps u otro sistema de tickets, el enriquecimiento automático de contexto es directo.
- Empieza pequeño: Un piloto con un solo proyecto y un mes de reportes es suficiente para validar el valor antes de escalar.
La tecnología para hacer esto ya existe, es open source en su mayor parte, y no requiere un equipo de data science. Requiere un equipo técnico que entienda cómo conectar las piezas correctamente.
Conclusión
Automatizar la generación de listas de trabajo desde reportes mensuales no es ciencia ficción ni un proyecto de investigación. Es un pipeline concreto, con herramientas disponibles hoy, que puede ahorrarle a tu equipo decenas de horas al mes — sin exponer datos internos a servicios externos.
En Consultoría-Ti ayudamos a empresas en Perú y Latinoamérica a diseñar e implementar este tipo de soluciones de automatización con IA, integradas con sus sistemas actuales de gestión de proyectos y ERP. Si quieres evaluar si un agente como este tiene sentido para tu operación, conversemos.
📩 Escríbenos y cuéntanos cuál es el proceso repetitivo que más tiempo le consume a tu equipo.
Fuentes y Referencias
✨ Contenido generado con ContentFlow — Consultoría-Ti