Propuesta
De QuickSight a tableros generados con IA, en 90 días
Primero entender y acordar las métricas; después construir la capa con evaluaciones; recién al final migrar, con QuickSight en paralelo. Nada se apaga hasta que el tablero nuevo dé los mismos números.
Fase 1Días 1–30
Entender y acordar
Antes de escribir código: saber qué tableros importan y qué significa cada número.
- Inventario de tableros de QuickSight y de los 5 que más usan los clientes.
- Glosario de métricas por estándar: qué es exactamente “hectárea verificada” para EUDR, ISCC, 45Z…
- Mapa campo de QuickSight → métrica semántica, marcando cálculos que hoy promedian ratios.
- Relevamiento de datos: qué vive en Mongo y qué en Postgres, frescura y huecos.
- Set dorado inicial con 50+ preguntas reales (de soporte, ventas y clientes) con su respuesta esperada.
- Primer workspace: cumplimiento EUDR (las obligaciones aplican desde el 30/12/2026).
Gate: Glosario firmado por BI y producto. Sin métricas acordadas no se construye.
Fase 2Días 31–60
Construir la capa con evaluaciones
La capa semántica, el compilador y las evaluaciones sobre los datos reales, sin tocar lo que ya funciona.
- Capa semántica versionada en el repo + linter en CI (referencias, joins no declarados, sinónimos).
- Marts anchos por proceso (lote-campaña, evaluación de cambio de uso, lotes de producto) sobre Postgres/PostGIS.
- Compilador determinístico y rol de solo lectura a nivel base.
- 8–12 consultas verificadas para las preguntas más frecuentes.
- Evaluaciones por etapa en CI; piloto interno con el equipo de BI.
Gate: ≥ 95 % de precisión en el set dorado, 100 % en rechazos e inyección, y cero diferencias contra QuickSight en los 5 tableros clave.
Fase 3Días 61–90
Migrar y pilotear con clientes
Los tableros nuevos conviven con QuickSight hasta que los números coinciden.
- Reconstruir los 5 tableros clave como specs (preguntas + planes), con QuickSight en paralelo.
- Piloto con 1–2 clientes en tableros de cumplimiento EUDR.
- Circuito de feedback: cada 👎 se revisa y puede pasar al set dorado.
- Monitoreo de costo, latencia y preguntas sin respuesta (que guían el próximo modelado).
Gate: OK del piloto y reporte de paridad. Recién entonces se apaga el tablero viejo correspondiente.
Cómo se mide el éxito a los 90 días
Tiempo para un tablero nuevodías → minutos
Precisión en el set dorado≥ 95 %
Preguntas respondidas con métricas gobernadas≥ 80 %
Diferencias contra QuickSight (top 5)0
Riesgos y cómo los manejo
| Riesgo | Mitigación |
|---|---|
| Definiciones distintas entre áreas | Se resuelve en la fase 1 con el glosario firmado, antes de escribir código. |
| Tentación de dejar que la IA escriba SQL libre para ir más rápido | Compilador determinístico; SQL libre solo como modo exploratorio etiquetado y apagado por defecto. |
| Joins de varios saltos (la causa principal de errores) | Se arreglan con modelado (marts anchos), no con prompts. Join no declarado = rechazo + registro de brecha. |
| Costo de LLM | Consultas verificadas sin LLM, caché, modelo barato para ruteo. Medido hoy: ~US$ 0,002 por pregunta en promedio. |
| Confianza del cliente en números generados | Nivel de confianza visible, linaje completo y advertencias de chequeos en cada respuesta. |
Qué entrego
- Glosario de métricas y mapa QuickSight → capa semántica
- Capa semántica + compilador + rol de solo lectura
- Set dorado y evaluaciones en CI con gates
- 5 tableros clave migrados, con reporte de paridad
- Panel de trazas, costo y preguntas sin respuesta
Qué necesito del equipo
- Acceso de lectura a Mongo, Postgres y a los datasets de QuickSight
- Un referente de producto/cumplimiento por estándar para el glosario
- Preguntas reales de clientes y de soporte para el set dorado
- 1–2 clientes dispuestos a pilotear
- Definir proveedor de LLM y restricciones de costo/privacidad