GenBI: el fin del cuello de botella del analista de datos

¿Y si cualquiera pudiera “hablar” con la base de datos sin saber SQL? Bienvenido a la revolución que llevas años esperando (y temiendo).

---

Si eres analista de datos en una empresa, conoces esta escena: llega el director de marketing a las 17:30 del viernes con “una preguntita rápida”. Necesita saber las ventas del Q3 filtradas por región, producto y tipo de cliente. Para ayer.

Tú sabes que esa “preguntita” implica tres JOINs, un GROUP BY con HAVING, y probablemente descubrir que los datos de región están mal cargados desde octubre. Dos horas mínimo. Y el viernes se fue al carajo.

GenBI promete que esto se acabe. La pregunta es: ¿es real o es humo?

Qué es GenBI (y qué no es)

GenBI significa Generative Business Intelligence. La idea es simple: en lugar de escribir consultas SQL o navegar por dashboards prediseñados, el usuario hace preguntas en lenguaje natural y obtiene respuestas.

“¿Cuáles fueron las ventas del Q3 por región?” → El sistema genera la consulta, la ejecuta, y devuelve el resultado. Quizás con un gráfico. Quizás con un resumen en texto.

Suena a ChatGPT conectado a una base de datos. Y en su forma más básica, eso es exactamente lo que es. El problema es que esa forma básica es peligrosa.

Por qué “ChatGPT + SQL” no funciona

Si conectas un LLM directamente a tu base de datos y le dices “genera consultas SQL a partir de preguntas”, vas a tener problemas. Muchos problemas.

Alucinaciones semánticas. El modelo no entiende tu negocio. No sabe que “ventas” en tu empresa significa la tabla fact_sales excluyendo devoluciones, que “región” viene de dim_geography y que hay que filtrar por is_active = 1. Va a inventar joins que no existen o interpretar campos de forma incorrecta. He documentado los tipos de fallos que cometen los LLMs y este es uno de los más comunes.

Inconsistencia. Pregunta lo mismo de dos formas distintas, obtén dos respuestas distintas. “Ventas del Q3” y “revenue en julio-agosto-septiembre” deberían dar el mismo número. Sin contexto de negocio, no lo harán.

Seguridad. ¿De verdad quieres que un LLM genere SQL arbitrario contra tu base de datos de producción? Un DELETE mal generado y tienes un problema gordo.

Rendimiento. Los LLMs no optimizan queries. Pueden generar consultas que funcionen pero que tarden 40 minutos en ejecutar porque no usan índices o hacen full table scans innecesarios.

La capa semántica: el ingrediente que faltaba

La diferencia entre “GenBI que funciona” y “ChatGPT conectado a SQL” es la capa semántica.

Una capa semántica es una abstracción que define, en términos de negocio, qué significan tus datos. Define que “ventas” es SUM(fact_sales.amount) WHERE is_returned = 0. Define que “cliente activo” es aquel con last_purchase_date > DATEADD(month, -6, GETDATE()). Define las relaciones entre tablas y las reglas de agregación.

Cuando el LLM recibe una pregunta, no genera SQL directamente. Primero la traduce a conceptos de la capa semántica, y luego la capa semántica genera el SQL correcto y optimizado.

Es la diferencia entre:

• “Genera SQL para ventas por región” → SQL potencialmente incorrecto
• “El usuario quiere la métrica ‘ventas’ agrupada por la dimensión ‘región’” → SQL garantizado correcto

Herramientas como Cube, dbt Semantic Layer, o AtScale implementan esto. No es nuevo, pero la combinación con LLMs lo hace accesible de una forma que antes no era posible.

Si trabajas con Power BI, esto te sonará: el modelo tabular con DAX es esencialmente una capa semántica. Las medidas definen métricas de negocio, las relaciones definen cómo se conectan las tablas. GenBI aplica el mismo concepto pero con interfaz de lenguaje natural.

Qué significa esto para ti (analista de datos)

Aquí viene la parte incómoda. Si tu trabajo consiste principalmente en traducir preguntas de negocio a SQL y devolver tablas de Excel, GenBI es una amenaza existencial.

No mañana. No el mes que viene. Pero en 2-3 años, la mayoría de consultas ad-hoc las hará el propio usuario hablando con el sistema.

La buena noticia: alguien tiene que construir y mantener esa capa semántica. Alguien tiene que definir las métricas de negocio, validar que los datos son correctos, y asegurar que el sistema no devuelve basura.

Ese alguien eres tú. Pero el trabajo cambia.

De: “Recibo peticiones → Escribo SQL → Devuelvo Excel” A: “Diseño el modelo semántico → Valido la calidad de datos → Gobierno el acceso”

Es un trabajo más estratégico, más cercano al negocio, y francamente más interesante. Pero requiere habilidades diferentes. Si estás pensando en dar el salto, escribí sobre la transición de analista a data engineer.

Cómo prepararte

Aprende sobre capas semánticas. dbt Semantic Layer, Cube, LookML de Looker. Entiende cómo se modelan métricas y dimensiones de forma declarativa.

Mejora tu conocimiento del negocio. La capa semántica solo es tan buena como las definiciones que contiene. Si no entiendes qué significa “cliente churneado” para tu empresa, no puedes modelarlo.

Familiarízate con data governance. Quién puede preguntar qué, qué datos son sensibles, cómo se auditan las consultas. GenBI sin governance es un desastre esperando a ocurrir.

Experimenta con las herramientas. Monta un prototipo con tus datos. Conecta un LLM a una capa semántica básica. Entiende las limitaciones antes de que tu jefe te pida implementarlo en producción.

El elefante en la habitación

GenBI no va a funcionar para todo. Las preguntas complejas que requieren contexto implícito, las exploraciones abiertas donde ni el usuario sabe qué busca, los análisis que requieren creatividad humana… eso sigue siendo tu territorio.

Y seamos honestos: la mayoría de empresas no tienen sus datos lo suficientemente limpios y documentados para que GenBI funcione bien. Antes de hablar con los datos en lenguaje natural, necesitas que los datos tengan sentido. Y eso es un problema que llevamos décadas sin resolver.

Pero para las consultas repetitivas, las “preguntitas rápidas” del viernes, los informes mensuales que siempre son iguales… sí, eso lo va a hacer una máquina.

La pregunta no es si va a pasar. Es si vas a ser quien lo implemente o quien sea reemplazado por ello.

---

¿Tu empresa está explorando GenBI? ¿Has probado conectar LLMs a tus datos? Cuéntame tu experiencia.