AI en el flujo de trabajo del Data Analyst: dónde ayuda y dónde falla

Un VP de Sales le escribe en Slack a las 8:47 a.m. El mensaje es una sola línea: "El AI dice que los ingresos subieron un 14%; ¿puede verificarlo?"

Usted abre el copiloto del BI tool, pega el mismo prompt que usó el VP y obtiene de vuelta una consulta que se ejecuta en 1,2 segundos. El número que devuelve es 14%. La consulta también está mal. Une orders con customers usando email en lugar de customer_id, contando doble a cualquier persona que alguna vez haya actualizado su dirección de correo. Trata status = 'completed' como ingresos sin filtrar devoluciones. El 14% es aritmética real sobre un conjunto de datos equivocado.

El VP no lo sabe. El copiloto no lo sabe. Usted sí lo sabe, porque lleva nueve meses trabajando en este almacén y ya ha sufrido las consecuencias de ambas combinaciones de tablas antes.

Este es el trabajo real en 2026. No se trata de escribir SQL más rápido. Se trata de verificar SQL que ya fue escrito, de forma plausible, por algo que no entiende el negocio.

Por qué esto importa ahora

Cada proveedor de BI y cada IDE ha lanzado una función de "pregunta en términos sencillos". La dirección lo ha notado. El CFO leyó un artículo de McKinsey sobre productividad con AI y ahora espera que Analytics entregue más con el mismo equipo. Negarse a usar AI hace que uno parezca lento. Confiar en él ciegamente lo convierte en el sello humano de aprobación sobre números alucinados que llegan al deck del directorio.

La única posición sostenible es la tercera: usar AI como multiplicador de fuerza en las partes mecánicas del trabajo, y convertirse en la capa de gobernanza en las que no lo son. El analista que puede explicar con confianza por qué una consulta generada por AI está mal, corregirla en dos minutos y entregar la respuesta correcta es más valioso en 2026, no menos. El analista que pega el resultado del copiloto en un panel de control y se marcha es un junior con pasos adicionales.

Dónde el AI realmente ayuda

Sea específico. "El AI ayuda con la productividad" es exactamente el tipo de oración que me gustaría eliminar de este artículo. Aquí es donde realmente gana su lugar, por nombre.

Borradores de SQL para refactorizar

Cursor con Claude como modelo es el estándar seguro actual para analistas. Donde brilla es en el segundo borrador, no en el primero. Usted escribió una consulta de 200 líneas con cinco CTE para calcular la retención por cohorte MoM. Funciona. También es ilegible. Péguela en Cursor, pida una refactorización que consolide los CTE y añada comentarios, y en 30 segundos tendrá algo más limpio. Lo revisa, rechaza dos cambios que rompieron la lógica, acepta el resto, y ha ahorrado una tarde de limpieza.

Lo mismo aplica a funciones de ventana que se escriben dos veces al año, auto-combinaciones complicadas para datos jerárquicos y lógica de tablas dinámicas. Trate el resultado como un primer borrador de un junior inteligente que nunca ha visto su almacén. Útil, pero no terminado.

Documentación del esquema del panel de control

Aliméntele a Claude su archivo de modelo dbt, su LookML o el JSON del panel de control, y pídale que escriba la entrada del diccionario de datos. Producirá prosa revisable que es un 80% correcta. Usted edita el 20% donde adivinó. Tiempo total: 10 minutos por panel de control en lugar de dos horas, y el modo de fallo es "descripción incorrecta", no "número incorrecto". Mucho más fácil de detectar en revisión.

Este es el uso de AI con mayor apalancamiento que he encontrado. La documentación es lo que todo equipo de Analytics dice que hará "el próximo trimestre" y nunca hace. El AI elimina esa resistencia inicial.

Preparación para entrevistas de recopilación de requisitos

Antes de reunirse con una parte interesada sobre un nuevo panel de control, pegue el hilo de Slack, la cadena de correos y la solicitud aproximada en Claude. Indíquele: "¿Cuáles son las cinco preguntas que debería aclarar antes de escribir SQL para esta solicitud?" Recibirá una lista. La mitad de las preguntas serán obvias. Dos detectarán ambigüedades que usted pasó por alto. Una será inútil. Resultado positivo en 90 segundos.

El punto no es que el AI conozca su negocio. Es que el AI es un interlocutor competente que hace mejores preguntas de seguimiento que usted a las 9 a.m. de un martes.

Narrativa para detección de anomalías

Usted detectó el pico. La conversión bajó un 23% en la región sureste, semana a semana. Sabe que es la nueva prueba de precios. Ahora necesita escribir el mensaje de Slack con la voz de su equipo, con el lenguaje de cobertura adecuado, los próximos pasos correctos y una notificación a los afectados. El AI redacta ese mensaje en 15 segundos. Usted edita el tono, lo envía y continúa.

Note el orden. Usted hizo el análisis. El AI hizo la redacción. Invierta ese orden y volverá al "el AI dice que los ingresos subieron un 14%".

Mantenimiento del diccionario de datos

La mayoría de los equipos no tienen descripciones de columnas en su almacén. Cero. Cadenas vacías. Generar automáticamente descripciones a partir del nombre de columna, los valores de muestra y la tabla padre no es perfecto, pero "descripción imperfecta" supera a "sin descripción" en todos los casos. Ejecútelo como un proceso por lotes una vez al trimestre, edite manualmente las que estén claramente mal y publique.

Dónde el AI falla

Estos son los modos de fallo que envían números incorrectos a los ejecutivos. Memorícelos.

Semántica de los datos

orders.status = 'completed' no significa "ingresos" en su almacén. Puede excluir pedidos reembolsados, o no. Puede contar las renovaciones de suscripciones como pedidos separados, o agruparlas. Puede usar gross_amount, net_amount o amount_after_tax_and_discount. El AI no lo sabe. El AI adivinará. La suposición será plausible. Con frecuencia estará mal, y lo estará de una manera casi imposible de detectar solo a partir de la consulta. El SQL es sintácticamente perfecto, la combinación compila, el número se devuelve. Hay que conocer el almacén para detectarlo.

Manejo de NULL

COUNT(column) excluye los NULL. COUNT(*) no. SUM sobre una columna con NULL devuelve NULL si todos los valores son NULL, pero un número si alguno no lo es. LEFT JOIN en una relación de uno a muchos dispara el recuento de filas si se olvida de agregar. El AI se equivoca en esto aproximadamente la mitad de las veces con esquemas reales, porque la mitad de las veces los datos de entrenamiento públicos también tienen el error. Si su panel de control de repente muestra 4 veces más clientes que ayer, revise las combinaciones de tablas.

Lógica de negocio

"Cliente activo" significa algo diferente en cada empresa. En una empresa B2B SaaS puede ser "se conectó en los últimos 30 días". En un marketplace puede ser "completó una transacción en los últimos 90 días". En una fintech puede ser "saldo por encima de $0 y sin indicador de fraude". El AI adopta por defecto la definición más común en sus datos de entrenamiento, que casi con certeza no es la suya. Lo mismo ocurre con "MRR", "abandono de clientes", "engagement", "retención". Cada métrica tiene cinco definiciones plausibles. Su equipo usa una de ellas. El AI no sabe cuál.

Gobernanza y linaje de datos

El AI escribe felizmente una consulta contra customers_legacy_v2, una tabla obsoleta que no se ha actualizado desde noviembre. El AI no conoce su SLA de actualización de dbt. El AI no sabe que el equipo de Marketing bifurca la tabla de clientes los martes para una exportación de campaña y la bifurcación tiene una lógica ligeramente diferente. El AI no sabe que hace seis semanas migró el seguimiento de ingresos a una nueva tabla y la antigua es de solo lectura.

Este es el modo de fallo que escala peor. A medida que su almacén evoluciona, el modelo mental del AI sobre él se queda más atrás, y las consultas que genera se equivocan con mayor confianza con el tiempo.

La trampa de "esta consulta la generó el AI"

Esta es la línea clara. Nunca pegue una consulta generada por AI en un panel de control, un informe para partes interesadas o un deck ejecutivo sin realizar las cuatro verificaciones siguientes:

1. Ejecútela contra un resultado conocido. Elija un segmento que ya haya validado (el número del mes pasado que el CFO ya aprobó) y confirme que la consulta del AI lo reproduce.
2. Revise visualmente los recuentos de filas. Si espera aproximadamente 10.000 clientes y la consulta devuelve 47.000, tiene una multiplicación de filas. Si devuelve 12, tiene un filtro demasiado agresivo.
3. Compruebe las combinaciones de tablas en busca de multiplicación de filas. Revise cada JOIN. ¿El lado derecho tiene valores únicos garantizados en la clave de combinación? Si no es así, necesita DISTINCT o agregación.
4. Confirme que el filtro de fechas hace lo que dice. "El mes pasado" en el BI tool A puede significar "los últimos 30 días". En el tool B puede significar "el mes calendario anterior". En SQL escrito por AI, podría ser cualquiera de los dos, más un error de desfase de un día.

El patrón a interiorizar es: el AI lo escribió, yo lo verifiqué, yo lo asumo. No: el AI dijo que el número es X. Si no puede defender la consulta línea por línea ante el VP de Finanzas, no puede enviar la respuesta. Si la envía de todos modos y está mal, "el AI lo escribió" no es una defensa. Usted lo escribió, al aceptarlo.

Gobernanza y control de versiones

Trate el SQL asistido por AI como cualquier otro código. Confírmelo en su repositorio de dbt o en su GitHub de Analytics. Use la revisión de pull request, aunque el único revisor sea usted 24 horas después con la mente despejada. Etiquete el modelo y el prompt en el mensaje del commit si condicionó materialmente la lógica, para que usted en el futuro sepa de dónde vino esa extraña estructura de CTE.

Cree un pequeño archivo forbidden_patterns.md en el repositorio de su equipo. De diez a veinte entradas, cada una de ellas una trampa que haya encontrado personalmente:

• Combinaciones que parecen correctas pero no lo son (el ejemplo de email vs customer_id anterior)
• Columnas que han cambiado de significado (status antes incluía "enviado", ahora no)
• Tablas que no se deben consultar directamente (raw.events es firehose, use analytics.sessions)
• Definiciones de métricas que difieren del estándar público (su definición de "usuario activo")
• Tablas con SLA de actualización sensibles (esta tiene un retraso de 24 horas, esta otra es en tiempo real)

Alimente ese archivo en el contexto de Cursor para cada sesión de SQL. Es la herramienta de gobernanza más económica y de mayor apalancamiento que he encontrado. El AI tiene muchas menos probabilidades de caer en una trampa conocida si le ha dicho dónde están las trampas.

El plan de 30 días para integrar el AI sin perder el oficio

No intente aplicar el AI a todo su flujo de trabajo el primer día. Vaya paso a paso.

Semana 1, calibración. Elija una herramienta. Cursor más Claude es el estándar seguro; si su empresa tiene Copilot desplegado, úselo. Úselo únicamente para refactorizar SQL en consultas que ya comprende y ha validado. Compare cada resultado con lo que usted habría escrito. Desarrolle un sentido de dónde es confiable y dónde alucina. El objetivo es la calibración, no la productividad.

Semana 2, documentación. Añada las tareas de bajo riesgo y alto apalancamiento. Genere automáticamente entradas del diccionario de datos. Genere README de paneles de control. Escriba borradores de procedimientos de operación para las solicitudes recurrentes de su equipo. El modo de fallo aquí es una oración que hay que reescribir, no un número incorrecto en el escritorio del CFO.

Semana 3, preparación de requisitos. Antes de cada reunión con partes interesadas, ejecute el AI en el hilo primero. Pida las cinco preguntas de aclaración. Registre cuáles le ahorraron realmente una reescritura. Después de dos semanas, tendrá un patrón de lo que el AI detecta y lo que no.

Semana 4, codifique. Escriba el ai-usage.md de su equipo. Tres secciones: qué puede el AI redactar de forma autónoma, qué deben verificar los humanos antes de fusionar, y qué está fuera de los límites. Un punto de partida razonable:

• Permitido: borradores de documentación, sugerencias de refactorización, borradores narrativos de anomalías tras el análisis humano, preguntas de aclaración de requisitos.
• Verificar antes de fusionar: cualquier SQL que toque paneles de control de producción, cualquier cambio de definición de métrica, cualquier nuevo modelo de dbt.
• Fuera de los límites: ejecutar automáticamente SQL generado por AI contra producción sin un LIMIT 100 y una revisión humana; pegar cualquier columna con PII en un BI tool de terceros que no tenga un Acuerdo de Procesamiento de Datos firmado; usar AI para escribir SQL en dialectos que usted no lee con fluidez.

Este último punto es el que la mayoría de las personas omite. Si no puede leer la sintaxis de las funciones de ventana específicas de Snowflake, no puede revisar lo que Cursor escribió. Está confiando a ciegas. No lo haga.

Opcional: el ángulo del ACE Framework

Si su empresa está implementando un modelo operativo de AI basado en el ACE Framework, el flujo de trabajo del analista se ajusta perfectamente a él. El AI gestiona Generate (redactar SQL, redactar documentos, redactar actualizaciones en Slack) y asiste en Analyze (resúmenes de anomalías, sugerencias de refactorización). Los humanos son dueños de Ingest (semántica de los datos, lo que cada columna significa realmente en este negocio), Predict (interpretación causal de por qué se movió una métrica) y Execute (enviar la respuesta a una parte interesada con confianza y una lógica de razonamiento defendible).

Esa es la versión de un párrafo. El punto es que las partes del trabajo que requieren mayor confianza y contexto de negocio permanecerán con los humanos durante mucho tiempo. Las partes mecánicas van al AI. Su carrera se construye sobre la primera mitad.

Errores comunes

Algunas trampas en las que veo caer a los analistas, en orden aproximado de frecuencia:

• Dejar que las partes interesadas se sirvan a sí mismas con el copiloto de BI y tratar la revisión del analista como opcional. El copiloto envía números incorrectos; el analista es culpado de todos modos.
• Pegar el esquema de producción con PII en un BI tool de AI de terceros que no tiene un DPA. Esto es causal de despido en la mayoría de las empresas. Verifique antes de pegar.
• Usar AI para escribir SQL en dialectos que no se leen con fluidez. El ARRAY_AGG de BigQuery no es el de Postgres; el QUALIFY de Snowflake no es el de Redshift. No se puede revisar lo que no se puede leer.
• Omitir el paso de "comparar con un resultado conocido" porque la consulta "parece correcta". Así es como un crecimiento de ingresos del 14% llega a publicarse cuando el crecimiento real es del 3%.
• Tratar la confianza del copiloto de BI como evidencia de corrección. Dirá "los ingresos subieron un 14%" con el mismo tono tanto si la consulta es correcta como si es catastróficamente incorrecta.

Plantillas y herramientas

Tres artefactos para construir en sus primeros 30 días. Manténgalos en el repositorio de Analytics de su equipo.

1. forbidden_patterns.md: comience con diez entradas de su almacén. Combinaciones reales que le han causado problemas. Añada una por mes a medida que las encuentre.
2. Lista de verificación de revisión de SQL: ocho elementos para ejecutar en cualquier consulta generada por AI antes de fusionarla: verificación de resultado conocido, coherencia del recuento de filas, verificación de multiplicación de filas, verificación de filtro de fechas, verificación de manejo de NULL, verificación de lógica de negocio (¿"activo" significa lo que nosotros entendemos por activo?), verificación de gobernanza (¿esta tabla está actualizada?), verificación de legibilidad.
3. Prompt de preparación para entrevistas con partes interesadas: un prompt guardado en Claude en el que pega un hilo de Slack y obtiene cinco preguntas de aclaración. Refinélo mensualmente.
4. ai-usage.md: la política de su equipo. Documento en constante actualización. Revíselo trimestralmente.

Medición del éxito

Sabrá que esto está funcionando cuando tres cosas sean ciertas. Entrega más rápido en el lado de la documentación y la refactorización, y puede señalar entregables específicos que antes no existían. Las partes interesadas confían más en sus números, no menos, porque usted detecta rutinariamente los errores del copiloto de BI antes de que lleguen a Slack. Y puede articular, en una oración por consulta, por qué el primer borrador del AI estaba mal.

Esa última oración es la que lo hace más senior en 2026, no más reemplazable. "Hizo la combinación por email en lugar de customer_id." "Le faltó el filtro de devoluciones." "Usó la tabla de ingresos obsoleta." Cada oración es un fragmento de juicio específico del almacén que el AI no tiene y no puede tener sin usted. Ese es el foso defensivo. Constrúyalo.

El trabajo ya no consiste en escribir la consulta. El trabajo consiste en asumir la respuesta. El AI lo escribió, usted lo verificó, usted lo asume. Esa es la línea. Ese es todo el artículo.

Más información

• Un día en la vida de un Data Analyst
• Sus primeros 30/60/90 días como nuevo Data Analyst
• Plantilla de descripción de puesto: Data Analyst
• ACE Framework