Por qué los agentes de análisis de IA necesitan una capa semántica en lugar de SQL en bruto
Text-to-SQL en tablas sin procesar inventa métricas e ignora las reglas de acceso. Una capa semántica como Cube, ofrecida a través de MCP, proporciona a los agentes de IA un significado empresarial estructurado.
Fuentes: The Semantic Layer for AI Agents: How to Stop LLMs From Inventing Metrics
Permitir que un agente de análisis basado en IA escriba SQL es la forma más rápida de obtener una demostración que impresione a las personas. También es la forma más rápida de generar problemas, si ese SQL se ejecuta contra tablas brutas del almacén sin contexto empresarial. El problema no está en la sintaxis, sino en el significado.
Tomemos la palabra “ingresos” y preguntémonos qué abarca:
- Brutos o netos?
- ¿Se restan los reembolsos?
- ¿Qué columna de fecha determina el trimestre?
- ¿“Cliente activo” significa activo en el momento en que se realizó el pedido o activo hoy?
- ¿Qué mapeo de regiones se aplica?
- ¿Qué regla de conversión de moneda se utiliza?
- ¿Está permitido incluso a este usuario ver los datos de ese cliente?
La conversión directa de texto a SQL falla precisamente en estos puntos. El modelo puede generar SQL válido, la base de datos puede ejecutarlo sin problemas, y aun así el resultado puede ser incorrecto. Por esa razón, un agente de análisis necesita una capa semántica entre él y los datos empresariales. Cube es un ejemplo bien elaborado de dicha capa, y sirve como caso de estudio en el siguiente apartado.
Los esquemas no tienen significado
La conversión de texto a SQL es una buena idea. Permite a los desarrolladores, analistas y usuarios empresariales trabajar más rápidamente. Pero un esquema de almacén rara vez contiene el significado que una persona espera de él.
Una tabla cuenta con columnas como amount, status, created_at, customer_type, region_id y currency, pero nadie en la empresa formula las preguntas de esa manera. Nadie pide sum(amount) grouped by region_id where status = 'paid'; en su lugar, preguntan cómo creció los ingresos empresariales en el sur de la India el último trimestre.
Esa única oración oculta una serie de decisiones. ¿Qué es la facturación y qué hace que una empresa sea cliente? ¿Qué fecha marca el trimestre y cómo se representa el sur de la India? ¿Se eliminan los reembolsos y los pedidos cancelados? ¿Qué regla monetaria se aplica y qué puede ver quien hace la consulta? Un modelo puede hacer conjeturas sobre cada uno de estos aspectos. Sin embargo, las conjeturas no equivalen a una gestión adecuada. Si la respuesta del agente difiere de la que muestra el panel de control, la gente deja de confiar en él. Si se utiliza la tabla incorrecta, la cifra parece creíble pero está errónea. Si se ignoran las reglas de acceso, la respuesta se convierte en una fuga de datos.
La verdadera pregunta, entonces, no es si el modelo puede escribir SQL, sino si en realidad debería inventar lógica de negocio.
Qué hace una capa semántica
Una capa semántica se sitúa entre los datos brutos y quienes los consumen, convirtiendo las estructuras técnicas de la base de datos en conceptos empresariales estructurados. Define métricas, mediciones, dimensiones, uniones, segmentos, jerarquías, reglas de acceso, reglas de caché, preagregaciones y las API utilizadas para consultarlas, en lugar de exponer tablas y columnas.
En concreto, orders.amount, customers.type, orders.created_at y refunds.amount se convierten en Ingresos, Cliente Empresarial, Fecha del Pedido e Ingresos Ajustados por Reembolsos. Los agentes necesitan ese vocabulario. Sin una capa semántica, un agente debe analizar el esquema para deducir las informaciones; con ella, trabaja a partir de definiciones aprobadas. El agente sigue sin ser perfecto, pero una de las principales causas de errores en los análisis desaparece, ya que la definición de las métricas ya no tiene que reconstruirse a partir de tablas brutas.
Se trata de una categoría y no de un producto en sí. Cube, la capa semántica de dbt (construida sobre MetricFlow) y LookML de Looker abordan cada uno el mismo problema dentro de sus propios ecosistemas. Cube recibe atención aquí porque su enfoque para los agentes es excepcionalmente completo, aunque la arquitectura es más importante que la marca.
Por qué Cube es un buen ejemplo
Cube no es solo una capa para paneles de control. Un único modelo gestionado alimenta herramientas de BI, análisis integrados, APIs y agentes de IA, todos construidos a partir de cubos, mediciones, dimensiones, uniones, segmentos, jerarquías, preagregaciones y políticas de acceso. Estos elementos constituyen prácticamente los componentes exactos que necesita un agente de análisis.
Su propia descripción del diseño refleja bien la idea central: los agentes no consultan directamente el almacén de datos, sino que consultan la capa semántica, y el entorno de ejecución actúa como una barrera de protección entre el agente y el almacén.
Compare lo que cada uno proporciona al modelo. Al recibir una tabla en bruto, solo ve los nombres de las columnas y nada más. Al contar con una capa semántica, también recibe los conceptos aprobados, el cálculo detrás de cada uno, cómo se relacionan, qué puede acceder el usuario actual y una forma segura de realizar consultas. Redescubrir la lógica empresarial para cada pregunta es un desperdicio, por lo que el agente debería consultar una capa que ya la contenga.
Conexión más significado: dónde encaja MCP
MCP es la forma habitual de conectar asistentes de IA con herramientas y datos externos, pero la conexión no es lo mismo que la comprensión. Si se le da a un agente acceso directo a tablas de almacén en bruto a través de MCP, aún debe adivinar su significado, lo cual representa el problema original en el nuevo enfoque.
Un patrón más sólido dirige al agente a través de la capa semántica:
AI agent
→ MCP client
→ semantic-layer MCP server (e.g. Cube's)
→ semantic layer (governed metrics, dimensions, joins, policies)
→ data warehouse
MCP se encarga del acceso y la capa semántica se ocupa del significado. El agente no debería preguntarle a la base de datos qué tablas unir para calcular los ingresos; en su lugar, debe solicitar a la capa semántica la métrica de ingresos aprobada y las dimensiones que puede utilizar.
Existen dos consideraciones importantes que mantienen la realidad, ya que este campo evoluciona rápidamente y es fácil exagerar al respecto. El servidor oficial de Cube MCP, que forma parte de Cube Cloud y al que se accede mediante HTTPS con OAuth, es diferente de los servidores MCP comunitarios para Cube, como aquellos distribuidos a través de Smithery. Su nivel de confianza, soporte y mantenimiento difieren, y el uso en entornos de producción requiere recurrir a la vía oficial y regulada. Además, el soporte nativo para MCP es algo reciente en este ámbito, añadido sobre las API REST, SQL y GraphQL que estos productos han ofrecido durante años. Funciona, pero se trata de una funcionalidad propia de 2025 a 2026, por lo que conviene verificarla en función de la versión que realmente se esté utilizando.
Una arquitectura más segura de extremo a extremo
Una vez completamente montado, el flujo se ve así:
user question
→ AI analytics agent
→ MCP / tool call
→ semantic layer (approved metrics, dimensions, joins, segments, policies)
→ data warehouse
→ governed result
→ agent explanation
El agente no tiene libertad total sobre los datos brutos. Recibe una interfaz regulada, de modo que el equipo controla qué métricas existen, qué dimensiones son válidas, cómo funcionan las uniones, qué filtros están permitidos, quién ve qué filas, si las respuestas provienen del caché o de datos preagregados, y cómo se exponen las consultas a través de APIs. Eso es mejor que decirle a un modelo que escriba SQL con la esperanza de que la lógica empresarial salga correcta.
Ejemplo práctico: crecimiento de los ingresos
Pida el crecimiento de los ingresos empresariales del último trimestre. Sin una capa semántica, el agente infiere qué tabla contiene los ingresos, si se refiere a brutos, netos, registrados o reconocidos, si se excluyen los reembolsos, cómo se identifican las cuentas empresariales, qué columna de tiempo define el último trimestre, si es necesario convertir monedas y si este usuario puede ver cada segmento. El SQL puede ejecutarse, pero ejecutarse no es lo mismo que estar correcto.
Con una capa semántica, esas respuestas ya existen. Los ingresos son una métrica aprobada, el cliente empresarial es un segmento aprobado, la fecha del pedido es una dimensión de tiempo aprobada; la lógica de reembolso se define una sola vez y la política de acceso se aplica según quien lo solicita. El agente no inventa una métrica, sino que solicita una ya aprobada. Eso separa la generación de SQL en lenguaje natural de los análisis agentes regulados.
¿Qué puede salir mal con el acceso directo al almacén?
El acceso directo deja al agente demasiada libertad para adivinar, y los fallos son predecibles:
- Inventación de métricas: los ingresos se calculan de manera diferente a la del panel financiero.
- Uniones incorrectas: la consulta se ejecuta, pero una unión duplica filas o elimina registros.
- Filtros faltantes: los pedidos cancelados, las cuentas de prueba, los registros eliminados o los usuarios internos permanecen en los resultados.
Los agentes que responden a preguntas de negocio necesitan medidas de seguridad más estrictas que las que ofrece la generación de SQL. Necesitan restricciones semánticas.
Mantener SQL sin exponer tablas en bruto
Renunciar a la flexibilidad no es el precio de la gobernanza. Una capa semántica madura puede mantener abierta la posibilidad de usar SQL, orientándola hacia objetos gestionados en lugar de tablas físicas. En la API SQL de Cube, cada cubo o vista se comporta como una tabla, y sus mediciones, dimensiones y segmentos se asemejan a columnas. Dado que utiliza el protocolo y dialecto Postgres, casi cualquier cliente compatible con Postgres puede conectarse.
Las herramientas y los agentes mantienen las consultas al estilo SQL, pero el modelo determina qué se puede consultar. El agente no navega por tablas en bruto; trabaja con métricas y dimensiones aprobadas, lo cual representa un punto intermedio práctico mucho más cercano a la forma en que deberían funcionar las analíticas en producción.
Las reglas de acceso son tan importantes como las métricas
En el caso de los agentes conversacionales, el control de acceso se vuelve crucial, ya que el cuadro de diálogo invita a hacer preguntas abiertas. Alguien escribe “muéstrame los ingresos por cliente”, y el sistema debe saber qué clientes puede ver esa persona, qué región o inquilino aplica, y si se permite el detalle a nivel de cliente o solo deben devolverse datos agregados.
Cube aplica políticas de acceso y seguridad a nivel de fila dentro de la capa semántica. Esa ubicación es intencionada: nadie debería depender de un agente para que recuerde todas las reglas sin que se le solicite. Escribir “nunca revele datos no autorizados” en una instrucción es una solicitud; que la capa restrinja a un usuario determinado a ciertas filas, dimensiones y mediciones constituye la aplicación de esas reglas. La aplicación de reglas es mucho más estricta y tiene lugar en la capa de datos en lugar de en la instrucción.
El aspecto de rendimiento: caché y preagregaciones
El análisis conversacional es iterativo. Una persona solicita los ingresos por región, luego los divide por producto, luego los compara con el último trimestre y finalmente los limita a clientes empresariales. Si cada paso se convierte en una nueva consulta compleja al almacén de datos, la latencia y el costo aumentan rápidamente.
Las preagregaciones y el caché de Cube, gestionadas por su motor CubeStore, aceleran las consultas analíticas más comunes. Un resultado reportado fue una reducción aproximada a la mitad de los costos de almacén tras trasladar los resúmenes estadísticos al almacenamiento de Cube. Así, para preguntas repetidas, la capa semántica funciona como capa de rendimiento además de una capa de gobernanza.
Dónde rinde frutos este enfoque
Los agentes que responden preguntas sobre ingresos, segmentos de clientes, uso de productos, análisis orientados al cliente, paneles operativos, KPIs o explicaciones de métricas se benefician al máximo, al igual que cualquier escenario de BI de autoservicio.
El beneficio es mayor cuando ya existen definiciones recurrentes. Defina una sola vez conceptos como ARR, MRR, ingresos, tasa de abandono, retención, usuarios activos, tasa de conversión, margen bruto, tiempo de resolución de tickets y adopción de funciones, y cada agente las reutilizará en lugar de volver a calcularlas cada vez que cambie la consulta.
Donde los equipos deben tener cuidado
Nada de esto es magia, y la gobernanza debe ser real y no solo un título. Un modelo incompleto hace que el agente tenga dificultades. Definiciones erróneas de métricas generan números correctos pero erróneos. Las políticas de acceso demasiado amplias siguen exponiendo en exceso los datos. Un modelo repleto de métricas casi idénticas y confusas permite que el agente elija la incorrecta. Y si la actualidad de los datos no es visible, una respuesta puede parecer actual cuando en realidad se basa en información obsoleta.
Por lo tanto, la pregunta útil no es si existe una capa semántica, sino si esa capa es lo suficientemente buena como para que un agente la utilice con seguridad. El modelo debe estar documentado, versionado, probado, tener control de acceso y ser comprensible, alinearse con los paneles de control en los que la gente ya confía, conectarse a las verificaciones de calidad de datos y ser claro respecto a su actualidad y limitaciones. Una capa débil genera respuestas débiles por parte del agente.
De SQL en bruto a análisis gobernados
Lo que diferencia los enfoques es lo que ve el agente y qué puede fallar:
- Texto bruto a SQL: el agente ve las tablas y columnas del almacén, y el principal riesgo es la lógica de negocio inventada.
- SQL más documentación del esquema: una mejora, pero las uniones y las métricas siguen siendo fácilmente mal utilizadas.
- Solo una capa semántica: el agente trabaja con métricas, dimensiones, relaciones y políticas definidas. Es más seguro, ya que la calidad está limitada por el modelo que lo sustenta.
- Capa semántica más MCP: análisis regulados expuestos como herramientas para el agente, actualmente la opción más adecuada para análisis de IA controlados.
El texto a SQL sigue siendo útil, pero para el análisis empresarial debería basarse en semántica regulada en lugar de con suposiciones sobre un esquema bruto.
Una lista de verificación antes de que un agente acceda a datos empresariales
- Primero, coloque las métricas clave en una capa semántica.
- Especificar cuáles dimensiones y uniones son válidas.
- Aplicar políticas de acceso y reglas a nivel de fila en la capa.
- Ofrecer APIs reguladas en lugar de las tablas en bruto anteriores.
- Acceder a la capa a través de MCP únicamente mediante herramientas oficiales aprobadas.
- Mantener un registro de cada consulta del agente junto con el SQL que generó.
- Entregar cada respuesta junto con la definición de la métrica subyacente.
- Indicar en cada respuesta cuán actualizados están los datos.
- Reproducir preguntas comerciales habituales y comparar los resultados con paneles de control confiables.
- Prohibir el acceso directo a tablas sensibles del almacén.
- Decidir qué ocurre cuando una métrica solicitada no tiene definición.
- Enseñar al agente a responder “no definido” en lugar de improvisar.
- Versionar las definiciones de métricas como si fueran código.
- Probar las reglas de acceso con roles de usuario reales.
- Esté atento a las consultas que generan errores o resultados ambiguos.
La regla más importante: cuando una métrica no está definida, el agente no debe inventar una. Debe solicitar aclaraciones o indicar que la métrica no está disponible.
Preguntas para los equipos de producto
Antes de proporcionar a un nuevo agente analítico todo el esquema del almacén, deténgase y resuelva primero algunos aspectos. Decida qué preguntas empresariales debe responder, qué métricas están aprobadas, qué dimensiones son válidas y qué uniones son seguras. Defina quién puede ver qué, qué tan actualizados deben estar los datos, qué respuestas necesitan una definición o referencia adjunta, y qué consultas deben ser rechazadas. Solo entonces exponga esa información reducida al agente.
El cubo es una forma de construir la superficie de datos, mientras que la capa semántica de dbt, LookML y MetricFlow abordan el mismo problema desde otros ángulos. La lección clave no tiene nada que ver con un producto en particular: los agentes necesitan semántica empresarial regulada antes de poder trabajar con los datos empresariales.
El punto central
Tratar el análisis con IA únicamente como una tarea de texto a SQL ignora el verdadero objetivo, ya que la gobernanza del significado es la parte más difícil. Un agente que trabaje con tablas brutas del almacén puede escribir SQL perfectamente válido y, aun así, ofrecer respuestas empresariales incorrectas, gracias a métricas inventadas, uniones defectuosas, reglas de acceso omitidas o cifras que contradicen los indicadores del panel de control. Una capa semántica cambia la interfaz: métricas, dimensiones, uniones, políticas y APIs aprobadas reemplazan a un esquema bruto que debe ser interpretado. MCP proporciona la conexión, la capa semántica aporta el significado, y el análisis gobernado necesita ambos elementos.
Leer más
- Construye un agente de calificación de clientes potenciales con IA en Python usando FastAPI y Pydantic — Convierte clientes potenciales sin procesar en clientes calificados: extracción estructurada con LLM, validación con Pydantic, puntuación basada en reglas, almacenamiento en PostgreSQL, colas de trabajo y un proceso de revisión humana.
- Comparación de agentes gestionados: Anthropic, LangGraph y Google ADK — ¿Quién controla el entorno de pruebas, las credenciales y los registros? Una comparación de los agentes gestionados de Anthropic, LangGraph y Google ADK con información sobre precios, modos de fallo y una guía rápida para tomar decisiones.