“¿Cuánto vendimos el trimestre pasado?” parece una pregunta sencilla. Puede tener cinco respuestas correctas: pedidos, facturación, ingreso reconocido, moneda constante o ventas netas después de devoluciones.
Un agente de datos no falla solo cuando genera SQL inválido. Falla cuando ejecuta una consulta impecable sobre una definición equivocada y presenta el resultado con seguridad.
La base no es NL2SQL, sino significado compartido
Natural Language to SQL (NL2SQL) traduce lenguaje natural a una consulta. El salto difícil está antes: entender qué significa “cliente activo”, qué tabla contiene devoluciones y qué calendario usa Finanzas.
Una capa semántica ofrece nombres de negocio, medidas, dimensiones, relaciones y reglas. Puede definir que margen es ingreso neto menos coste reconocido, que el año fiscal empieza en abril o que “EMEA” excluye una filial. Sin esa capa, el modelo infiere a partir de columnas y ejemplos. A veces acertará por casualidad.
Las plataformas actuales convergen en este punto. Snowflake recomienda vistas semánticas para nuevas implantaciones de Cortex Analyst (Snowflake), y Microsoft describe agentes de datos que generan DAX o SQL sobre modelos y fuentes preparados para IA (Microsoft Fabric).
Una arquitectura que separa interpretación y ejecución
El agente recibe un catálogo acotado, no todas las tablas. Selecciona fuente, formula un plan y genera la consulta contra nombres lógicos. Un validador analiza operaciones permitidas, tablas, filtros, límites de filas y coste estimado. Solo después se ejecuta bajo la identidad del usuario.
La respuesta incluye valor, periodo, moneda, filtros y definición empleada. Para análisis que no caben en una cifra puede aportar tabla o gráfico, pero nunca ocultar qué agrupación realizó.
Seguridad: leer tampoco es inocuo
Una consulta de solo lectura puede exfiltrar datos, consumir recursos o revelar información por agregaciones pequeñas. Los permisos del usuario, Row-Level Security y Column-Level Security deben seguir aplicándose. Microsoft indica que los agentes de Fabric ejecutan bajo la identidad y permisos de datos del usuario y mantienen controles de fila y columna (Microsoft Fabric).
No se entrega una credencial compartida con acceso amplio. El agente utiliza vistas autorizadas, listas de operaciones y límites de tiempo y coste. Las consultas con uniones cartesianas, acceso a campos sensibles o exportaciones masivas se bloquean antes de ejecutar.
El historial conversacional también requiere cuidado. “Compáralo con el año anterior” depende del conjunto y filtro anteriores. Si esa respuesta estaba truncada o procedía de otra fuente, continuar puede producir una comparación falsa. El estado debe conservar consulta y metadatos, no solo el texto mostrado.
Preguntar mejor al usuario es parte del rigor
Cuando “ventas” tiene varias definiciones, el agente no debería elegir en silencio. Puede usar la definición institucional por defecto y hacerla visible, o preguntar si la diferencia cambia materialmente la respuesta.
Un buen agente distingue tres situaciones:
Existe una métrica aprobada y el agente responde con sus filtros.
Dos interpretaciones cambian el resultado; solicita una aclaración.
Explica qué falta y evita fabricar una aproximación.
Deriva a BI, análisis estadístico o un proceso autorizado.
Esto contradice la idea de que la mejor experiencia siempre entrega una cifra inmediata. En datos, una aclaración breve puede ser la respuesta más eficiente.
Consultas verificadas y evaluación real
Los ejemplos aprobados enseñan cómo se formula una pregunta y qué consulta la responde. Snowflake dispone de un repositorio de consultas verificadas y evalúa SQL generado ejecutándolo y comparando resultados contra esas referencias; separa además las consultas usadas como ground truth de las que guían al sistema durante la prueba (Snowflake).
El conjunto de evaluación debería cubrir:
- métricas frecuentes, periodos fiscales y sinónimos internos;
- uniones entre fuentes y dimensiones lentamente cambiantes;
- preguntas ambiguas y preguntas sin respuesta disponible;
- permisos por rol, fila y columna;
- consultas caras, inyecciones y solicitudes de escritura;
- conversaciones donde un filtro cambia entre turnos.
Medimos exactitud del resultado, no coincidencia textual del SQL. Dos consultas distintas pueden devolver lo mismo. También latencia, coste, claridad de la explicación y tasa de aclaración correcta.
Ejemplo ilustrativo: “clientes que hemos perdido”
Un director pregunta cuántos clientes se han perdido este año. La capa semántica ofrece “baja contractual” y “cliente sin compra durante 180 días”. Son conceptos distintos. El agente muestra ambas definiciones y pregunta cuál necesita.
Al elegir inactividad, genera una consulta sobre última compra, excluye cuentas de prueba y aplica la región del usuario. Antes de ejecutar estima el volumen; después entrega número, evolución mensual y consulta. Señala que los clientes recientes aún no pueden cumplir 180 días.
El valor no está en escribir SQL más deprisa. Está en convertir una pregunta ambigua en un resultado que Finanzas y Ventas pueden interpretar igual.
Cuándo no conviene conversación
No recomendamos un agente para informes regulatorios cerrados, cuadros de mando con definiciones estables o exportaciones completas. Un informe certificado o una consulta parametrizada es más reproducible. Tampoco para análisis causal: una correlación obtenida mediante conversación no demuestra una causa.
Los agentes de datos son útiles en exploración y autoservicio acotado. El paso a una decisión sensible puede requerir que un analista revise supuestos, calidad y método. El agente debe hacer fácil esa revisión mostrando el camino.
Preguntas frecuentes
¿Un agente de datos sustituye al equipo de BI?
No. Reduce preguntas repetitivas y acelera exploración, pero necesita modelos semánticos, calidad, gobierno y consultas verificadas que el equipo de datos ayuda a mantener.
¿Debe mostrar siempre el SQL?
Debe estar disponible para usuarios autorizados y auditoría. Para lectores de negocio puede ser más útil mostrar métricas, filtros, fuente y definición, con acceso al detalle.
¿Puede consultar varias bases?
Sí, si existen relaciones gobernadas y permisos coherentes. Conviene preparar vistas o modelos en lugar de confiar en que el agente descubra uniones complejas en cada pregunta.
¿Cómo evitamos consultas demasiado caras?
Con límites de bytes, tiempo y filas, estimación previa, vistas agregadas y bloqueos de patrones peligrosos. Google recomienda límites de gasto a nivel de proyecto, usuario y consulta para agentes de BigQuery (Google Cloud).
¿Qué pasa si los datos están desactualizados?
La respuesta debe mostrar la última actualización de cada fuente y abstenerse cuando no cumple la frescura necesaria. El modelo no puede corregir una carga fallida.
Conversar no elimina la necesidad de definir
La interfaz puede aceptar lenguaje natural. La organización sigue necesitando acordar qué significan sus números. Un agente fiable no oculta esa disciplina: la convierte en parte visible de cada respuesta.
Evaluar si tus datos están preparados para un agente conversacional
Fuentes y lecturas recomendadas
- Cortex Analyst — Snowflake
- Cortex Analyst evaluations — Snowflake
- Semantic model best practices — Microsoft Fabric
- Conversational Analytics — BigQuery
Fuentes y vigencia técnica revisadas el 18 de agosto de 2026.