Una sola verdad para personas y máquinas

Un gerente le pregunta al nuevo asistente de IA de la empresa cuál fue el margen del trimestre. La respuesta llega en cuatro segundos, bien redactada y con una tabla. Está equivocada. El modelo escribió su propia consulta SQL, sumó ventas brutas en lugar de netas y usó una tabla de costos que finanzas dejó de actualizar hace meses. Nadie lo nota hasta la reunión de directorio.

La escena es una composición, y apunta a un problema que la temporada anterior dejó planteado: los modelos facilitan producir respuestas, pero una respuesta convincente puede propagar una definición equivocada a más decisiones. Una capa semántica ayuda a gobernar las métricas; todavía hay que validar las fuentes y la interpretación de cada pregunta.

Qué es una capa semántica

Entre los datos crudos, repartidos en el ERP, el CRM y el data warehouse, y las personas que hacen preguntas, hay una traducción que casi siempre se hace a mano. Qué tabla contiene las ventas. Qué columnas se suman. Qué filtros aplican. Qué se entiende por «cliente activo». Una capa semántica centraliza esa traducción en definiciones reutilizables de métricas y dimensiones. Según la herramienta, se configura en código o en un modelo administrado.

La idea no es nueva. LookML, de Looker, la popularizó hace más de una década, y herramientas como la capa semántica de dbt o Cube la llevaron al centro de la arquitectura de datos moderna. Lo que cambió es a quién sirve.

Por qué «headless»

En muchas implementaciones de BI, la lógica de una métrica acaba duplicada entre informes y planillas. Las copias divergen. Pero no es una limitación inevitable de la visualización: Power BI, por ejemplo, permite compartir modelos semánticos entre informes y consultarlos desde Excel. El problema aparece cuando los consumidores mantienen reglas independientes en vez de reutilizar una definición gobernada.

Una arquitectura con una capa semántica compartida separa la definición de las vistas que la consumen. Puede exponer métricas mediante una API u otras interfaces, según la plataforma. Un dashboard, una planilla, una aplicación interna y un agente pueden consultar la misma definición en lugar de mantener copias de la fórmula. Para que un cambio llegue a todos, hay que migrar los consumidores, versionar la métrica y comprobar que ninguno siga calculándola por su cuenta.

Una definición compartida reduce la deriva entre reportes; solo funciona si todos consultan la misma versión y las fuentes son confiables.

El efecto sobre las alucinaciones

Cuando un agente responde preguntas sobre datos escribiendo SQL libremente contra tablas crudas, tiene que adivinar: qué tabla usar, cómo se calcula cada cosa, qué casos excluir. Adivina con confianza y a veces se equivoca, y el error llega con una redacción impecable.

Cuando el mismo agente consulta una capa semántica, la situación cambia de naturaleza. Ya no escribe la fórmula del margen: pide la métrica «margen neto» filtrada por trimestre, y la capa ejecuta la definición oficial. El modelo aporta lo que hace bien, entender la pregunta en lenguaje natural, y deja lo que no debe improvisar, la regla de negocio, en manos de una definición gobernada. Además, puede mostrar la consulta que se ejecutó y la definición que usó, para que una persona la verifique.

No elimina todos los errores: una pregunta ambigua sigue siendo ambigua, una fuente desactualizada sigue estando desactualizada y el agente aún puede elegir la métrica equivocada. Por eso hay que validar fuentes, permisos y resultados además de gobernar las fórmulas. La capa reduce un riesgo concreto: que el modelo improvise por su cuenta cómo se calcula el negocio.

Por dónde empezar

No hace falta modelar toda la empresa. Se empieza por las diez métricas que más decisiones mueven, con las definiciones que acordó el negocio. Se conectan a las fuentes reales, se exponen por una interfaz y se apunta a ella todo lo que hoy recalcula esas cifras por su cuenta: primero los reportes más usados, después los agentes.

Las escenas de estos episodios son composiciones de situaciones frecuentes, no casos de clientes. Las cifras que aparecen en ellas son ilustrativas.