Business IntelligenceFrontendBackend

Expert Group - BI

Escalar el BI del grupo a +30 usuarios, cada uno viendo solo lo suyo, era imposible por licencias. Construí la plataforma web que reemplazó Power BI: permisos granulares por usuario y costo fijo.

Áreas
Business Intelligence · Frontend · Backend
Tecnologías
  • Next.js
  • SQL Server
  • Claude APIs

01Cómo detecté la oportunidad

El dueño del grupo pidió algo simple de decir y caro de cumplir: que los más de 30 usuarios entraran al reporte, y que cada uno viera únicamente lo que le correspondía. Los datos ya estaban unificados — las bases venían dispersas y las consolidé con un proceso ETL propio. El cuello de botella era la capa de entrega. Estábamos sobre Power BI con licencia Premium por Usuario: cada persona nueva sumaba costo fijo mensual, y el modelo de permisos de la herramienta no bajaba al nivel que el negocio pedía, usuario por usuario, con su recorte exacto de información y sin puertas laterales al resto. Ahí dejó de ser un problema de reportes. No hacía falta otro tablero, hacía falta ser dueños de la plataforma: que el permiso fuera una decisión de diseño y no un límite de licencia.

02Cómo lo construí

Arranqué por lo menos vistoso: replicar en la app los mismos análisis que el grupo ya leía en Power BI. Si la plataforma nueva no mostraba exactamente lo mismo, nadie iba a migrar. Recién con los tableros en pie ataqué la parte que justificaba el proyecto — autenticación y permisos. Elegí Next.js para trabajar como monolito: UI y API en un solo proyecto, sin un backend aparte que sostener por mi cuenta. El acceso quedó en dos capas. La primera es un árbol de permisos nominales, cerca de ochenta llaves del estilo "bi.comercial.margen" o "pedidos.facturar", que define a qué vistas y a qué acciones entra cada usuario. La segunda son los scopes, que filtran filas y no pantallas: un usuario puede quedar acotado por unidad de negocio, negocio, agente, cliente o almacén, y ese filtro se inyecta en el SQL del servidor, nunca en el cliente. Sin scopes asignados ve todo lo que su permiso habilita; si la consulta de scopes falla, la petición muere — jamás devuelve datos sin filtrar. El asistente de IA fue la parte delicada. Preguntás en lenguaje natural, el modelo escribe la consulta, la ejecuta contra la base y devuelve el análisis en el chat, con gráfica o Excel si hace falta. El riesgo es obvio: un modelo con la mano dentro de la base de datos. Así que el SQL no se ejecuta como viene — solo SELECT, contra una whitelist de tablas derivada de los permisos de ese usuario en concreto, con sus scopes y exclusiones ya aplicados, tope de filas, timeout y rate limit propio. Las tablas de autenticación no están en la lista, así que para el modelo no existen. Lo que no anticipé fue el comportamiento del modelo. En lugar de ejecutar las herramientas, a veces narraba que iba a ejecutarlas — "ahora genero el reporte" — y ahí se quedaba. Y esa respuesta entraba al historial, así que aprendía a repetirse. Lo cerré por los dos lados: forzar el uso de herramientas en toda pregunta que implique datos, y filtrar del historial esas respuestas fallidas antes de devolvérselo al modelo.

03Qué problema resuelve

El grupo salió del ecosistema Power BI por completo: las dos licencias que había se cancelaron y no se compró ninguna otra. Hoy la plataforma tiene 39 usuarios activos, cada uno con su recorte propio — un agente entra y ve su venta, su cobranza y su cartera ya filtradas por su código, exporta a Excel y le pide a la IA un análisis profundo sin depender de nadie. Y una vez que la plataforma existía, dejó de ser solo BI: pedidos, CRM, prospección, pronóstico y flujo de efectivo se fueron sumando encima, cada módulo resolviendo un problema real del negocio y devolviendo, de paso, más datos que analizar.