Qué es un modelo semántico (Power BI y Fabric)

El informe donde el margen no cuadra

Reunión de dirección. El director comercial dice que el margen del trimestre fue del 32%. El financiero, mirando su propia hoja, dice que fue del 27%. Los dos tienen razón — cada uno en su Excel. El comercial calcula margen sobre precio de venta y sin descontar portes; el financiero lo hace sobre coste completo e incluye devoluciones. Nadie ha mentido. Simplemente "margen" significa dos cosas distintas en dos sitios distintos, y no hay ningún lugar donde esté escrito cuál es la buena.

Ese es el problema que resuelve un modelo semántico. No es un gráfico más bonito ni un dashboard más rápido: es el sitio donde tu empresa decide, una sola vez, qué es cada número. Y resulta que es, además, la pieza sin la cual no funciona nada de lo que viene después — empezando por la IA.

Qué es un modelo semántico

Un modelo semántico es la capa que está entre tus datos en bruto y los informes que consulta la gente. Según la propia definición de Microsoft, un modelo semántico de Power BI "representa una fuente de datos lista para informes y visualización" (Microsoft Learn — Semantic models in the Power BI service). Es el mismo concepto que durante años se llamó dataset en Power BI; Microsoft lo renombró a semantic model precisamente porque la palabra "dataset" se quedaba corta: no es un conjunto de datos, es un modelo de negocio construido sobre esos datos.

Técnicamente, un modelo semántico de Power BI es un modelo tabular de Analysis Services — la misma tecnología de modelado madura que Microsoft lleva más de una década puliendo. En la práctica, contiene tres cosas:

• Los datos, organizados en tablas.
• Las relaciones entre esas tablas.
• Las medidas: los cálculos de negocio (ventas, margen, rotación) escritos una vez y reutilizables en cualquier informe.

La diferencia con un Excel no es de tamaño. Es que en el modelo semántico la definición vive en un único sitio. "Margen" se calcula en una medida, y esa medida es la que usan todos los informes, todos los usuarios y —esto es lo importante— cualquier IA que pregunte a tus datos. Si cambias la definición, cambia en todas partes a la vez.

Las tres piezas: hechos, dimensiones y relaciones

Un buen modelo semántico casi nunca es una tabla gigante. Es un esquema en estrella: una tabla de hechos en el centro y varias tablas de dimensiones alrededor, conectadas por relaciones.

Las tablas de hechos guardan lo que pasa: cada línea de factura, cada pedido, cada movimiento. Son largas (millones de filas) y estrechas (pocas columnas: fecha, cliente, producto, importe, coste, unidades).

Las tablas de dimensiones guardan el contexto: quién es cada cliente, qué características tiene cada producto, a qué mes y trimestre pertenece cada fecha. Son cortas y anchas.

Las relaciones unen ambas: cada venta apunta a un cliente, a un producto y a una fecha. Cuando un usuario filtra "trimestre 3, zona Norte", el modelo sabe propagar ese filtro desde las dimensiones hasta los hechos y devolver exactamente las ventas que tocan.

Esta estructura no es un capricho académico. Es lo que separa un modelo que se mantiene de uno que hay que rehacer cada seis meses. Lo desarrollamos como base de todo proyecto en arquitectura Medallion para PYMEs: el modelo semántico se construye sobre el nivel Gold, los datos ya limpios y agregados.

Las medidas: el diccionario de cálculo

Si las tablas son el sustantivo, las medidas son el verbo. Una medida es un cálculo escrito en DAX (el lenguaje de cálculo de Power BI) que se evalúa según el contexto en el que se mira: Margen % = DIVIDE([Ventas] - [Coste], [Ventas]) devuelve el margen del total, de una zona o de un cliente concreto según lo que el usuario haya filtrado.

Aquí está la clave del problema de la reunión: si "margen" es una medida única en el modelo, deja de existir la versión del comercial y la del financiero. Hay una, la acordada, y todos —personas e IA— beben de ella.

No vamos a re-explicar DAX aquí: el concepto de contexto de fila frente a contexto de filtro, que es donde se cae el 80% de los proyectos, lo tienes desarrollado en qué es Power BI: licencias, DAX y errores frecuentes. Lo que importa para este artículo es la idea: el cálculo se define una vez, en el modelo, y se reutiliza siempre.

Dónde vive el modelo: Import, DirectQuery y Direct Lake

Un modelo semántico puede guardar los datos de tres maneras (Microsoft las llama modos de almacenamiento):

• Import — los datos se cargan en memoria dentro del modelo. Es rapidísimo para consultar, pero necesita un refresco que copia los datos cada vez.
• DirectQuery — el modelo no guarda datos; cada consulta se traduce y se lanza contra la fuente original. Datos siempre frescos, pero a costa de rendimiento.
• Direct Lake — el modo nativo de Microsoft Fabric, y el cambio más interesante de los últimos años.

Direct Lake es, en palabras de Microsoft, "una opción de modo de almacenamiento de tablas de un modelo semántico de Power BI disponible en Microsoft Fabric... optimizada para cargar grandes volúmenes de datos rápidamente en memoria desde tablas Delta en OneLake, el almacén único de todos los datos analíticos" (Microsoft Learn — Direct Lake overview). La gracia: une el rendimiento de Import con la frescura de DirectQuery, porque lee directamente los ficheros de OneLake sin copiar. Su "refresco" no duplica datos, solo actualiza metadatos (lo que Microsoft llama framing) y tarda segundos.

Microsoft lo dice explícitamente: Direct Lake "es la opción ideal para el nivel Gold de la arquitectura Medallion". Es decir, el modelo semántico moderno se apoya directamente sobre la capa de datos limpios y agregados que ya estás construyendo. Eso sí, Direct Lake requiere capacidad de Fabric (F2 o superior).

Para una PYME la decisión rara vez es dramática: si ya trabajas en Fabric, Direct Lake es el camino por defecto; si sigues en Power BI Pro con pocas fuentes, Import te resuelve perfectamente. Lo que no cambia en ninguno de los tres modos es el principio: encima vive el mismo modelo de negocio, las mismas medidas, las mismas relaciones.

Por qué el modelo semántico es la base de la IA

Aquí es donde casi todo el mundo se salta un paso. La demo de IA que has visto —escribir una pregunta en lenguaje natural y obtener el gráfico— no funciona por arte de magia. Funciona porque hay un modelo semántico debajo que le dice a la IA qué significa cada cosa.

Lo confirma la documentación de Copilot en Power BI: "cuando una pregunta está relacionada con datos del modelo semántico, Copilot usa el modelo semántico para responder; en caso contrario, responde con el conocimiento general del modelo de lenguaje" (Microsoft Learn — Copilot for Power BI overview). Traducido: sin un buen modelo semántico, Copilot no responde sobre tu negocio — responde de cultura general. Por eso Microsoft recomienda explícitamente que los responsables del modelo "preparen sus modelos semánticos para la IA" antes de activar Copilot.

La razón es sencilla. Un LLM es excelente entendiendo la pregunta en español ("¿qué cliente creció más este trimestre?") y pésimo adivinando que en tu empresa "crecer" se mide sobre facturación neta y que "cliente" excluye los intercompañía. Esa parte —el contexto de negocio— no la pone la IA. La pone el modelo semántico. Mejor modelo, mejor pregunta posible, mejor respuesta.

Esto vale para Copilot y vale para cualquier otra IA, incluida la tuya propia. De hecho, cómo consumir el modelo semántico con IA —Copilot, Claude y el protocolo MCP— es el tema del siguiente artículo de esta serie: Hablar con tus datos: cómo consultar tu modelo semántico con IA. Pero el orden no se puede invertir: primero el modelo, después la conversación.

Errores de diseño que vemos una y otra vez

Un modelo semántico mal diseñado no falla con un error rojo. Falla en silencio: da números, pero los da mal. Los más frecuentes, más allá de los cinco clásicos de Power BI que cubrimos en el artículo de Power BI:

• Modelo plano en vez de estrella. Importar el export del ERP con sus 40 columnas como una sola tabla funciona en la demo y se rompe al añadir datos. Sin hechos y dimensiones separados, no hay modelo que escale.
• Métricas sin medida. Calcular el margen "a mano" en cada gráfico en lugar de en una medida central es reproducir el problema de la reunión dentro del propio Power BI. Si el cálculo no está en una medida, no hay una sola verdad.
• Sin tabla de calendario marcada. Las funciones de inteligencia de tiempo (comparar con el año anterior, acumulados) necesitan una tabla de fechas explícita y marcada como tal. Si no la marcas, no fallan: devuelven resultados sutilmente incorrectos.
• Definiciones ambiguas sin documentar. "Cliente activo", "venta", "pedido cerrado": si no están descritos en el modelo, cada informe (y cada IA) los interpretará a su manera.

El patrón común es el mismo: el modelo semántico es donde se concentran las decisiones de negocio. Escatimar ahí se paga en todos los informes a la vez.

Cómo saber si tu modelo está listo

Una lista corta para autodiagnóstico. Tu modelo semántico está sano si:

1. Cada métrica importante ("ventas", "margen", "ticket medio") es una medida única, no un cálculo repetido por ahí.
2. Hay hechos y dimensiones separados, con relaciones uno-a-varios bien definidas.
3. Existe una tabla de calendario marcada como tal.
4. Las definiciones de negocio están escritas (descripciones en las medidas, glosario), no solo en la cabeza de una persona.
5. Un compañero que no construyó el modelo puede abrir un informe y entender de dónde sale cada número.

Si fallas en varias, no es un drama — es el punto de partida de casi todo el mundo. Pero es el trabajo que hay que hacer antes de pensar en IA, no después. La IA amplifica lo que hay debajo: amplifica un buen modelo en respuestas fiables, y un mal modelo en errores convincentes.

---

¿Tienes Power BI funcionando pero no sabes si tu modelo semántico aguantaría una capa de IA encima? Nuestro Data Discovery diagnostica el estado de tus datos y tu modelo en 2 semanas — y te dice exactamente qué falta antes de dar el siguiente paso. Cuéntanos tu caso.