01 — CONTEXT
El contexto
Una empresa de eventos nacional registra su actividad en un gestor de imputaciones propio sobre MySQL: horas, proyectos, fases, gastos, desplazamientos y cambios. Siete años de datos operativos. El objetivo: que dirección tenga cada día una lectura fiable de lo que está pasando, sin tocar el gestor.
02 — PROBLEM
El problema
Tener datos no es lo mismo que poder decidir con ellos. Estos había que leerlos con cuidado: horas que se registran con retraso, gastos que pueden solaparse entre tipos, un calendario de festivos que no existe desde 2022. Un dashboard ingenuo habría enseñado cifras equivocadas con total seguridad.
03 — CONSTRAINTS
Las restricciones
- 01No modificar el gestor existente ni migrar sus datos.
- 02Solo lectura, impuesta en cada conexión a la base de datos.
- 03Nombres de personas ocultos salvo que se activen expresamente.
- 04No calcular lo que la base no contiene: presupuestos, ingresos, avance o margen.
04 — SYSTEM
Qué decidí construir
Una capa de inteligencia de solo lectura sobre la base del gestor: informe diario y semanal, plan de acción priorizado, alertas con su evidencia y un asistente para preguntar sobre el informe.
05 — ARCHITECTURE
Arquitectura del sistema
SOFTWARE
Software
- Portada con resumen «En tres líneas», acciones priorizadas (máximo 15, sin relleno) y alertas.
- Panel de alertas con detalle, acción recomendada y evidencia paginada.
- Acceso autenticado con sesión cifrada.
DATA
Datos
- Contrato de datos: qué contiene cada tabla, con qué significado verificado y con qué cautelas.
- Comparaciones al mismo retraso de registro, para no comparar un día a medio registrar con otro completo.
- Periodos en horario de Madrid, probados con los días de 23 y 25 horas.
- Conciliación independiente con SQL escrito a mano: horas, costes y hallazgos coinciden.
- Cobertura explícita: el coste de horas indica siempre qué parte tiene tarifa.
AI / AUTOMATION
IA y automatización
- Asistente «Preguntar sobre este informe» con un catálogo cerrado de herramientas.
- El modelo elige la operación; el servidor valida los parámetros y ejecuta SQL fija y parametrizada.
- El modelo no escribe SQL, no ve credenciales ni tablas fuera del catálogo.
- Al proveedor solo viajan la pregunta, el historial en texto y resultados agregados; no guarda las conversaciones.
- Evaluación del asistente contra la base y el modelo reales.
06 — DECISIONS
Decisiones importantes, y por qué
Leer, no migrar
El gestor funciona y el equipo lo usa. La inteligencia se construye encima, con un usuario de solo lectura que el propio servidor de base de datos hace cumplir.
Reglas deterministas antes que IA
Los hallazgos salen de siete reglas explícitas y documentadas, cada una con su evidencia. La IA responde preguntas; no decide qué es una alerta.
Excluir lo que no se puede afirmar
Presupuesto, margen, rentabilidad y previsiones quedan fuera por diseño, porque la base no contiene los datos para calcularlos.
Comparar con justicia
Cada día se compara con el anterior del mismo tipo y al mismo retraso de registro. Sin eso, el sistema anunciaría caídas que no existen.
07 — RESULT
Resultado
- Informe diario y semanal sobre los datos reales del gestor.
- Hallazgos conciliados de forma independiente con SQL escrito a mano.
- Asistente operativo sobre el mismo catálogo de datos que el informe.
Sin cifras de negocio inventadas: lo que se muestra es lo que existe y está documentado.
08 — STACK
Stack técnico
- Nuxt 4
- Vue 3
- MySQL (solo lectura)
- ApexCharts
- Tailwind CSS
- OpenAI
09 — SIMILAR PROBLEMS
Qué problema parecido puedo resolver
- →Tu empresa tiene años de datos en un ERP o gestor propio que nadie explota.
- →Dirección necesita una lectura diaria fiable sin montar informes a mano.
- →Quieres alertas sobre lo que requiere atención, con la evidencia detrás.
- →Quieres preguntar a tus datos sin exponerlos ni poner en riesgo el sistema original.
Este proyecto es un ejemplo de datos e inteligencia, ia y automatización y software a medida.