La escena nueva en sala de reunión de 2026: el director pregunta sobre una métrica, el analista le pregunta al ChatGPT cómo buscarla, el ChatGPT entrega SQL, el analista lo corre en el warehouse, la diapositiva va a la reunión. Tiempo total de "pregunta" a "diapositiva": 15 minutos. En 2022 ese flujo llevaba 2 días. Ganancia enorme — y peligro igual.
Porque en al menos la mitad de los casos, el SQL generado por el LLM tiene error sutil: filtro equivocado, JOIN incompleto, métrica calculada con lógica que parece correcta y no lo es. El número sale con cara de oficial, se vuelve decisión, y nadie nota que está mal por semanas. Este texto va sobre cómo tratar al LLM en analytics como parte del pipeline — con la disciplina equivalente. Sin eso, la ganancia de velocidad se vuelve pasivo silencioso.
El problema del "ChatGPT que escribe SQL"
El LLM se volvió bueno generando SQL en 2025–2026. Bueno suficiente para parecer útil siempre. No bueno suficiente para parecer útil cada vez que parece útil. Tres modos de falla aparecen con regularidad:
Falla 1: error de schema sutil. El LLM cree que orders.total existe cuando en realidad es orders.amount_total. El SQL corre en otra tabla parecida, devuelve número que tiene sentido, pero mide cosa equivocada.
Falla 2: lógica de negocio embebida en el prompt. El analista pregunta "¿cuántos clientes activos?". El LLM genera SQL con su propia definición de "activo" (logueó en 30 días). La empresa define activo como "hizo transacción en 90 días". El número sale 3× mayor.
Falla 3: aggregation incorrecta con JOIN. El LLM genera SQL con JOIN entre hecho y dimensión, pero la dimensión tiene duplicidad. La agregación se infla. Nadie lo nota porque el número no es absurdo — solo está mal en ~15%.
Esos tres combinados producen lo que yo llamo "el número parece correcto, la decisión sale equivocada". Y como el LLM presenta el SQL con confianza, el analista valida menos de lo que validaría un SQL escrito por colega. La confianza sintética gana a la revisión crítica.
En analytics aumentado por LLM, la velocidad viene con riesgo escondido: el SQL parece correcto porque fue generado con confianza. Sin disciplina de validación, "voy a preguntarle al ChatGPT" se vuelve "voy a tomar decisión sobre número no verificado".
Las cinco prácticas que separan ganancia de teatro
La disciplina que empresa seria adopta cuando incorpora LLM en pipeline analítico. Sin esas cinco, la ganancia de velocidad se vuelve pasivo silencioso.
- Contexto schema-aware en el prompt. No tirás la pregunta cruda al LLM. Construís el prompt con schema del warehouse, descripción de las tablas-clave, definiciones de métricas oficiales. dbt docs como capa semántica alimenta eso bien. Sin contexto, el LLM inventa columnas.
- Definiciones de negocio inyectadas en el system prompt. "Cliente activo = transacción en 90 días. Ingreso = subtotal antes de impuesto y descuento. Churn = ausencia de transacción en 90 días". 5–10 definiciones core como parte del prompt fijo. Sin eso, el LLM usa definición genérica y el número diverge.
- Validación automática del output antes del uso. El SQL generado corre en sandbox, se valida contra eval set conocido. "¿La pregunta X devuelve un número Y entre 1000 y 1500?". Sin validación, el drift en el LLM degrada el output sin aviso. Mismo principio del eval set para evaluar agentes.
- Restricción a query read-only con gobernanza. El LLM no escribe en producción. La conexión usada es read-only, con permiso restringido a tablas analíticas. Sin eso, prompt malicioso o error puede causar daño real.
- Log de toda interacción prompt → SQL → resultado. Para auditoría, para entender drift, para debuguear incidente. Quién usó qué, cuándo, con qué respuesta. Sin log, la gobernanza de IA en analytics no existe.
Implementar los cinco transforma "ChatGPT para SQL" en pipeline de analytics aumentado. Sin ellos, es improvisación que se vuelve incidente en 3–6 meses.
Dónde el LLM en analytics realmente acelera
No confundir el argumento. Hay tres contextos donde LLM bien implementado ahorra tiempo enorme con riesgo controlado:
Traducción de pregunta de negocio en SQL. Quien no es analista puede formular pregunta en lenguaje natural, el LLM genera SQL, el sistema lo ejecuta, devuelve respuesta. Como argumenté sobre LLM como agente interno, ese caso es uno de los más consistentes en ROI. Funciona bien con schema-aware prompt + validación.
Generación de documentación de modelo. ¿Nuevo modelo dbt necesita description en 30 columnas? El LLM genera primer borrador basado en SQL y dato de ejemplo. El analista revisa. 80% del trabajo automatizado.
Análisis exploratorio rápido. Llegó dataset nuevo, el equipo necesita entender estructura, distribución, outliers. El LLM con Code Interpreter o equivalente hace EDA en minutos. No reemplaza análisis serio, pero acelera entender el terreno.
Esos tres casos comparten característica: el error es tolerable y detectable, el output es revisado por humano antes de volverse decisión. Donde el output se vuelve decisión sin revisión (como el caso de SQL a diapositiva directo), la disciplina de los cinco ítems se vuelve obligatoria.
La trampa del "él entiende mi negocio"
Error más frecuente en equipos que adoptan LLM en analytics: después de 2–3 preguntas que el LLM responde bien, el analista deja de validar. "Él entiende cómo medimos ingreso". Mentira. Él entiende cómo medimos ingreso en ese contexto específico, en esa formulación específica. Cambió el prompt, cambió la tabla, cambió el trimestre — puede estar equivocado de nuevo.
La confianza que se construye con LLM en analytics es distinta de la confianza que se construye con colega. El colega aprende del error. El LLM no aprende — performa bien en conjuntos parecidos al entrenamiento, mal en fronteras. Tratar con la misma confianza genera el peor escenario: velocidad alta + revisión baja.
Cómo medir si está rindiendo
Cuatro métricas dicen si el LLM en analytics está siendo bien aprovechado:
Tasa de SQL generado que necesita corrección manual. Por encima del 30%, el schema-aware prompt está débil o el eval set es insuficiente. Por debajo del 10%, el pipeline está maduro.
Tiempo medio de validación por query. Si pasa de 5 minutos, la herramienta perdió propósito. La validación automatizada necesita cubrir el 80% de los casos para valer la pena.
Incidentes de "número equivocado descubierto después". Contá los casos donde se tomó decisión sobre SQL generado y después se descubrió error. Por encima de 1/mes, la gobernanza está rota.
Adopción por persona. ¿El analista lo usa? ¿El director? ¿Quién usa cuál interfaz? Si solo el ingeniero de datos lo usa, la democratización no ocurrió — se volvió herramienta especializada.
La decisión para 2026
Si tu empresa tiene analistas usando ChatGPT/Claude para generar SQL sin gobernanza, tres movimientos:
Creá interfaz controlada. No "abrí el ChatGPT". Sino herramienta interna con schema-aware prompt + definiciones de negocio embebidas + ejecución en sandbox + log automático. Equivalente al "ChatGPT para analytics" de la empresa. Costos altos al inicio, ROI claro en 6 meses.
Capacitá al equipo para desconfiar. Sesión de 1 hora mostrando los tres modos de falla (schema, definición, JOIN). Cuando el equipo entiende cómo el LLM se equivoca, el uso se vuelve más cuidadoso.
Integrá con la capa semántica. dbt mart o semantic layer define métricas; el LLM consulta la capa, no el warehouse crudo. Reduce el error de definición en 80%.
LLM en analytics en 2026 es una de las oportunidades más claras de productividad — y una de las más peligrosas sin disciplina. La diferencia entre las dos posturas no está en qué modelo se elige. Está en el pipeline construido alrededor, con validación, contexto y log que tratan al LLM como herramienta crítica — no como asistente confiable por inercia.