El giro silencioso: de «preguntar al modelo» a «orquestar agentes sobre el dato»
Durante 2024 y buena parte de 2025, la conversación sobre modelos de lenguaje aplicados al análisis de datos giraba alrededor del chat: pegar un CSV, pedir un gráfico, obtener una tabla. Ese patrón se está agotando. Lo que domina las novedades recientes es otra cosa: modelos que no responden con texto, sino que ejecutan código, consultan catálogos, validan supuestos y devuelven resultados auditables.
La diferencia práctica es enorme. Un chat que «interpreta» un CSV alucina filas y promedios con una facilidad preocupante. Un agente que ejecuta SQL o Python contra un almacén real no puede inventarse una cifra sin que el motor de base de datos proteste. Ese es el eje del cambio: el modelo deja de ser el analista y pasa a ser el planificador que escribe consultas y verifica resultados.
Text-to-SQL maduro: dónde funciona y dónde sigue rompiéndose
La generación de consultas SQL a partir de lenguaje natural es la aplicación más extendida, y también la más sobrevalorada en demos. Según documentación oficial de los principales proveedores de bases de datos analíticas, los benchmarks públicos de text-to-SQL han mejorado de forma sostenida, pero esos números se obtienen sobre esquemas limpios, con nombres de columnas autoexplicativos y sin ambigüedad semántica.
En un almacén real, la cosa cambia. Un caso que se repite: la tabla se llama fact_ventas_v3, existe una fact_ventas_v2 que ya no se actualiza pero sigue viva, y hay una columna importe que en realidad está en céntimos en las filas anteriores a una migración concreta. Ningún modelo adivina eso. Lo resuelve un catálogo de datos con descripciones, linaje y reglas de negocio documentadas.
Lo que sí está funcionando
- Consultas de exploración sobre un dominio acotado (un departamento, un conjunto de tablas cerrado).
- Traducción de preguntas frecuentes a consultas parametrizadas previamente revisadas por un humano.
- Generación de borradores de SQL que un analista corrige en segundos en lugar de escribirlos desde cero.
Lo que no funciona (y conviene admitirlo)
- Preguntas que requieren conocer definiciones de negocio no escritas («clientes activos» puede significar cinco cosas distintas).
- Esquemas con cientos de tablas sin descripciones: la tasa de error se dispara.
- Cálculos donde un JOIN mal elegido duplica filas y nadie lo detecta hasta que el informe llega a dirección.
Agentes con ejecución de código: el patrón que se impone
El enfoque que más ha crecido consiste en dar al modelo un intérprete de código aislado. El modelo escribe pandas, DuckDB o R, lo ejecuta, lee la salida y, si hay un error, itera. Esto tiene una ventaja decisiva para el análisis: el resultado es reproducible. Puedes guardar el script, versionarlo y volver a ejecutarlo el mes siguiente.
Aquí hay un detalle que solo se aprende usando estas herramientas a diario: la mayoría de los fallos no vienen del razonamiento estadístico, sino de la gestión de tipos y valores nulos. Fechas en formatos mezclados, categorías con espacios finales, importes con coma decimal heredados de una exportación antigua. Un modelo potente escribe un groupby impecable y luego agrupa mal porque «Madrid» y «Madrid » son dos valores distintos. La solución no es un modelo mejor: es una capa de limpieza previa y validaciones explícitas.
Integración con el stack: MCP y catálogos semánticos
La novedad arquitectónica más relevante de los últimos meses es la estandarización de conectores. El protocolo abierto promovido para conectar asistentes con fuentes de datos (conocido como MCP) está permitiendo que un mismo modelo consulte un almacén, un CRM y una hoja de cálculo sin que cada integración sea un desarrollo a medida.
Esto tiene una consecuencia que las organizaciones están empezando a asumir: el valor ya no está en el modelo, está en la capa semántica. Definir métricas una sola vez (ingresos netos, churn, margen) y exponerlas como herramientas que el modelo puede invocar es lo que separa un piloto vistoso de un sistema que sobrevive al tercer mes.
Un patrón que aparece en equipos que ya han pasado la fase de prueba: menos prompts largos, más funciones registradas con nombre y descripción precisa. El modelo elige entre diez herramientas bien documentadas en lugar de improvisar SQL sobre cincuenta tablas.
Evaluación: el problema que casi nadie resuelve bien
Medir si un LLM analiza bien es más difícil que hacerlo funcionar. Los benchmarks públicos no reflejan tu dato. La práctica que se está consolidando entre equipos maduros es construir un conjunto de preguntas con respuesta verificada manualmente sobre el propio almacén, y ejecutarlo en cada cambio de modelo o de prompt.
Sin ese conjunto de evaluación, cualquier migración a un modelo nuevo es una apuesta a ciegas. Y aquí hay un matiz que conviene tener presente: mejorar en un benchmark genérico no garantiza mejorar en tu dominio. Hemos visto modelos que bajan el rendimiento en tareas de agregación con jerarquías de fechas porque cambian el estilo de razonamiento, no porque sean peores.
Coste y latencia: el factor que decide la arquitectura
Un análisis interactivo tolera dos segundos de espera; un informe programado que se ejecuta sobre miles de filas cada noche no tolera el coste de un modelo grande por cada consulta. De ahí la tendencia a arquitecturas híbridas:
- Modelos pequeños o reglas deterministas para las preguntas frecuentes y bien tipificadas.
- Modelos grandes solo para la exploración abierta y la depuración de errores.
- Caché de resultados para consultas repetidas, que en la práctica son la mayoría.
El gasto en tokens se convierte en una línea de coste operativo real cuando el sistema lo usan veinte personas a diario. Diseñar sin tener esto en cuenta es la vía rápida a que el proyecto se cancele.
Gobernanza y privacidad: la conversación que llega tarde pero llega
Enviar datos de clientes a un proveedor externo exige revisar contratos, retención y residencia del dato. Las opciones de despliegue privado y los modelos ejecutados en infraestructura propia han madurado lo suficiente como para ser viables en sectores regulados, aunque con un coste de mantenimiento que muchas empresas subestiman.
Un error habitual: asumir que «el proveedor no entrena con mis datos» resuelve el problema. No lo resuelve si el dato sale de tu perímetro. La decisión real es arquitectónica, no contractual.
Qué vigilar en los próximos meses
- Verificación de resultados: mecanismos que contrastan la salida del modelo con una fuente de verdad antes de mostrarla.
- Linaje automático: saber de qué tabla y qué transformación sale cada cifra que el sistema presenta.
- Interfaces híbridas: el chat no desaparece, pero convive con dashboards donde el LLM solo redacta la explicación del gráfico.
- Evaluación continua: suites propias que se ejecutan en cada actualización del modelo.
La conclusión honesta es que los LLM ya aportan valor claro en exploración, documentación de datos y generación asistida de consultas, y siguen siendo frágiles en cualquier tarea donde una cifra equivocada tenga consecuencias. Diseñar con esa asimetría en mente, poniendo el dato y la validación en el centro y el modelo en la periferia, es hoy la diferencia entre un experimento y un sistema en producción.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.