Español

IA en el flujo de trabajo del BA: dónde ayuda y dónde falla

Son las 9:14 de un lunes. Un VP reenvía una captura de pantalla de Slack. El nuevo asistente de IA de la herramienta de CSM dice que los clientes activos crecieron un 38% el trimestre pasado. El ejecutivo quiere incluir ese número en una presentación para el directorio antes del mediodía.

Usted abre el almacén de datos. La cifra real ronda el 12%. El chatbot contó cada fila en customers sin importar el valor de status, ignoró el indicador is_test que el ingeniero de datos agregó en febrero y sumó silenciosamente una métrica que se reinicia mensualmente como si fuera acumulativa. Ahora tiene cuarenta minutos para explicar qué salió mal sin parecer alguien que teme quedar obsoleto.

Así es la vida del BA ahora. Cada herramienta de BI viene con una función de "pregunte en lenguaje natural". Cada IDE tiene autocompletado que escribe joins. La mayor parte del resultado es SQL confiado pero incorrecto: consultas que se ejecutan, devuelven números y cuentan mal de formas que no activan ninguna alerta. Alguien tiene que ser la última línea de defensa. Ese alguien sigue siendo usted, y las herramientas no han facilitado el trabajo tanto como han desplazado dónde viven las partes difíciles.

Esta es la perspectiva del BA en activo, escrita para quienes han entregado paneles de control reales y han cometido errores reales.

Dónde la IA realmente ayuda al BA

Aquí hay un apalancamiento real. Rechazarlo por principio tiene la misma energía que los analistas que insistían en escribir cada join a mano en 2014 porque los IDE eran "para juniors". El trabajo ha cambiado. Cinco áreas donde la IA vale la pena:

Borradores de SQL para refactorizar. Esqueletos de joins, sintaxis de funciones de ventana, regex para ese campo de log que nadie documentó. Usted le da a Claude los nombres de columnas y una descripción de una línea de lo que quiere, y devuelve una consulta correcta al 70% y 100% mejor que empezar desde un archivo en blanco. Luego usted la refactoriza. El modelo es más rápido que sus dedos; sus dedos nunca fueron el cuello de botella de todas formas.

Documentación del esquema del panel de control. Cuarenta y tres columnas en fact_orders, tres de ellas con nombres como flag_2 y legacy_amt_v3. Pegue el esquema y el historial de commits reciente en un modelo y pídale que redacte descripciones de columnas. Corregirá la mitad. También habrá creado documentación que antes no existía, lo cual supera la versión en que nunca se llega a escribir.

Preparación para entrevistas de levantamiento de requisitos. Antes de la reunión inicial con una parte interesada, pídale al modelo que genere las preguntas incómodas que tiende a olvidar, como "¿qué significa 'abandonado' aquí, mes calendario o 30 días móviles?" o "¿cómo tratamos las cuentas que bajan de plan y luego suben en el mismo periodo?" El modelo no conoce su negocio. Es bueno para recordarle las categorías de preguntas que de todas formas tiene que hacer.

Detección de anomalías en conjuntos de datos conocidos. Apunte un modelo a una serie temporal y pregúntele "¿dónde miraría primero una persona cuidadosa?" Marcará las cosas correctas: aumentos repentinos de nulos, picos en momentos concretos, días en que el conteo de filas cae a un número redondeado que sugiere una carga parcial. Usted aún tiene que investigar. El modelo simplemente comprime el escaneo.

Mantenimiento del diccionario de datos. Convertir tickets de Jira en entradas del glosario es un trabajo mecánico real. Pasar un ticket cerrado a un modelo y pedir una definición de un párrafo es el tipo de redacción mecánica que la IA hace adecuadamente y que usted de otro modo nunca llegaría a hacer.

Observe el patrón: la IA es útil cuando la entrada es acotada y usted permanece como editor. En el momento en que el modelo es el autor final, las cosas empiezan a fallar.

Dónde la IA falla silenciosamente

Esta es la sección que importa. Los fallos no son ruidosos. La consulta se ejecuta. El gráfico se renderiza. El número es incorrecto de una manera que lleva treinta minutos de arqueología en el almacén demostrar.

Semántica de datos. Su tabla orders tiene una columna status con valores como pending, processing, shipped, delivered, returned, void, chargeback y legacy_v2. ¿Cuál de esos significa "realmente una venta"? Su equipo de Finanzas tiene una opinión. Su equipo de Operaciones tiene una opinión diferente. El modelo no conoce ninguna de las dos y elegirá la opción que suene más plausible, normalmente delivered, que está mal en alrededor del 8% de los casos debido a devoluciones registradas en un lote separado.

Manejo de nulos. El modelo recurre por defecto a comprobaciones WHERE column IS NULL. Su almacén usa cadenas vacías, fechas centinela como 1900-01-01, la cadena literal "NULL" y una columna donde los valores faltantes se codifican como -999. El modelo no detectará ninguno de estos a menos que usted se lo indique. La mayoría de los BAs olvidan indicarlo porque han internalizado las peculiaridades y ya no las ven.

Lógica de negocio. "Cliente activo" tiene al menos seis definiciones en cualquier almacén de más de dos años. Conectado este mes. Tiene una suscripción de pago. Tiene una suscripción de pago y no está en dunning. Tiene una suscripción de pago, no está en dunning y no está marcado como cuenta de prueba. Ha usado el producto en los últimos 14 días. Estaba activo según el snapshot de Finanzas a fin de mes. El modelo elegirá una. No le dirá que eligió una. El CRO citará el número resultante en una reunión del directorio.

Gobernanza de datos. Pegar filas de clientes en una ventana de chat es un evento de exfiltración de datos. Pegar el esquema es limítrofe. Pegar planes de consulta que incluyen PII real es un incidente real. La mayoría de los BAs no piensan en "preguntarle a Claude" como un movimiento de datos, pero Legal sí lo hace, y también el próximo auditor.

He visto que cada uno de estos ha arruinado un análisis real en los últimos doce meses. Ninguno se anuncia solo. La consulta se ejecuta. Ese es el punto.

El ciclo Cursor + Claude para SQL

Así funciona en la práctica, para mí y los BAs en quienes confío:

Paso 1: Forzar suposiciones antes del código. El primer prompt nunca es "escribe la consulta". Es "antes de escribir SQL, lista cada suposición que tendrías que hacer para responder esta pregunta con este esquema". Pegue las definiciones de tabla relevantes. El modelo devuelve una lista. Usted la edita. Cerca de un tercio de las suposiciones serán incorrectas, y es preferible discutir una lista que una consulta terminada.

Un ejemplo real. La pregunta: "cuentas activas mensuales por nivel de plan para el Q1". Las suposiciones del modelo, ligeramente editadas:

  1. "Activo" significa last_activity_at dentro del mes calendario.
  2. El nivel de plan es accounts.plan_id unido a plans.tier_name.
  3. Las cuentas de prueba (is_test = true) están excluidas.
  4. Las cuentas en prueba gratuita cuentan como activas.
  5. Las cuentas con varios cambios de plan en un mes se atribuyen a su plan a fin de mes.
  6. La zona horaria es UTC.

Los puntos 4 y 5 son incorrectos para nuestro estándar de reporte. Las cuentas en prueba gratuita no cuentan, y atribuimos por el plan al inicio del mes porque así lo hace Finanzas. Detectar eso aquí le ahorra una consulta que reporta la forma correcta con los números incorrectos.

Paso 2: Borrador en Cursor. Con las suposiciones corregidas, solicite la consulta. El editor de Cursor permite ver el esquema en la barra lateral, lo que significa que el modelo tiene menos probabilidades de alucinar nombres de columnas. De todas formas alucinará uno o dos. Por eso usted la lee.

Paso 3: Refactorizar como un PR de dbt. Trate la consulta generada por IA como trataría el PR de un junior. Comentarios al inicio que indiquen el propósito, las suposiciones y "borrador asistido por IA, refactorizado y validado por [usted]". Notas en línea sobre cualquier join no obvio. Conteos de prueba al final (SELECT COUNT(*) FROM final contra una referencia conocida) antes de enviar el resultado a cualquier persona.

Paso 4: Ejecútela contra el almacén, dos veces. Una vez en un rango de fechas pequeño para verificar la forma. Una vez en el rango real para obtener la respuesta. Si ambos números parecen implausibles, lo son. El modelo tiene cero opinión sobre plausibilidad. Usted sí.

Este ciclo no es más lento que escribir SQL desde cero para la mayoría de las consultas no triviales. Es materialmente más rápido. También es materialmente más seguro que la versión en que acepta el primer borrador.

La trampa de "la IA generó esta consulta"

Hay una nueva excusa circulando. Alguien entrega un número incorrecto. Llega el análisis post-mortem. Aparece la frase: "la IA generó esta consulta".

La frase cumple dos funciones. La honesta: "estaba usando una herramienta, la herramienta estaba equivocada, no lo detecté". Bien, eso pasa, regístrelo y siga adelante. La deshonesta: "la responsabilidad de este número recae en el modelo, no en mí". Eso es el equivalente moderno de citar Wikipedia en una presentación judicial y encogerse de hombros cuando la cita resulta ser la edición de broma de alguien en 2009.

Si usted envió el número, usted es responsable del número. Si ejecutó la consulta, usted es responsable de la consulta. El modelo es una herramienta de escritura. Usted es el analista. Las partes interesadas no se preocupan por la cadena de custodia más allá de su nombre en el ticket, y no deberían tener que hacerlo.

La versión práctica de esta regla: nunca pegue el resultado de un modelo en un ticket de parte interesada sin antes ejecutarlo en el almacén. No "mirarlo". Ejecutarlo. Con un conteo de filas. Contra el esquema real, con los filtros reales, en el rango de fechas real. Si se encuentra a punto de saltarse ese paso porque el plazo es ajustado, el plazo siempre iba a ser ajustado, y saltárselo es cómo el número incorrecto termina citado en una presentación para el directorio.

Gobernanza y control de versiones

Trate el análisis asistido por IA como cualquier otro código, porque es código. Una lista de verificación funcional:

  • Revisión de PR. Cada consulta asistida por IA que llega a un panel de control o a un reporte recurrente pasa por la misma revisión que una escrita a mano. Sin excepciones para "es solo un número rápido".
  • Comentarios que indiquen la asistencia. Una línea de encabezado: -- Borrador asistido por IA (Claude, 2026-04-28); refactorizado y validado por [su nombre]. Esto es para el próximo analista, no para el modelo.
  • Sin PII en los prompts. El esquema está bien. Las primeras tres filas suelen estar bien si son datos de prueba. Filas reales de clientes, direcciones de correo electrónico, detalles de pago, registros de empleados: nunca. Use muestras sintéticas o descripciones de columnas solamente.
  • Registros de prompts para auditoría. Cursor y Claude tienen historial. No lo limpie. Cuando algo falle seis meses después, querrá encontrar el prompt original.
  • Lista de datasets con restricción de acceso. Algunas tablas nunca se envían a una API de terceros. Registros de HR, finanzas de clientes, cualquier cosa bajo una norma regional de residencia de datos. Escriba la lista. Fíjela en el canal de Slack del equipo de BA. Los nuevos empleados la leen antes de que se les dé acceso al almacén.

El trabajo de gobernanza de datos es poco glamoroso. También es la diferencia entre que la IA sea un multiplicador de productividad y que sea la causa nombrada en el informe de incidente de datos del próximo año.

Opcional: dónde se ubica esto en el ACE Framework

Para los equipos que usan el ACE Framework para mapear las capacidades de IA en la empresa, el trabajo de BA asistido por IA se ubica claramente en Analyze en el nivel de Capabilities (nivel 2 de 5). Está usando IA para interpretar datos existentes y producir decisiones, no para ingerir nuevas fuentes (Ingest), pronosticar (Predict), redactar documentos (Generate) o tomar acciones posteriores (Execute).

Este encuadre es útil porque le dice lo que la IA no está haciendo para el BA: no está construyendo pipelines de datos, no está ejecutando modelos sobre datos futuros, no está enviando correos automáticos a las partes interesadas. Esas funciones viven en otras filas del ACE Framework y tienen sus propios modos de fallo. Mantener los carriles claros mantiene las conversaciones claras.

El plan de 30 días

Si llegó hasta aquí y quiere una forma de empezar sin reescribir todo su flujo de trabajo, aquí está. Elija una tarea recurrente de SQL y ejecute el experimento.

Semana Enfoque Resultado
1 Elija una tarea recurrente de SQL. Ejecútela con asistencia de IA. Un registro de cada error que cometió el modelo, por categoría.
2 Documente las suposiciones que el modelo hace mal sobre su almacén. Un documento de una página sobre las peculiaridades del almacén que puede pegar en futuros prompts.
3 Construya una biblioteca personal de prompts. 5-10 plantillas de prompt reutilizables para las consultas que escribe con más frecuencia.
4 Trabaje en pareja con un ingeniero de datos. Agregue los 5 principales errores del modelo a los guardrails de prompts del equipo. Un prefijo de prompt compartido para el equipo y una lista de datasets con restricción de acceso.

El objetivo de los 30 días no es "adoptar la IA". Es aprender, en su almacén específico, dónde miente el modelo. Cada almacén miente de formas diferentes. Los consejos genéricos sobre IA ignoran esto; por eso la mayoría son inútiles.

Después de 30 días tendrá un sentido calibrado del apalancamiento. Sabrá qué tareas son 3 veces más rápidas con IA y cuáles son más lentas porque la verificación consume el ahorro. Habrá escrito las cosas que su equipo ha estado cargando en la cabeza, lo cual es un regalo aparte para su yo futuro.

Cierre

La IA en el flujo de trabajo del BA es un junior veloz en el primer día. Útil, entusiasta y confiadamente equivocado. El apalancamiento es real, y también lo es el modo de fallo. El trabajo no ha cambiado: entender la pregunta, entender el almacén, entregar el número correcto. Las herramientas han cambiado dónde viven las partes difíciles.

El BA que sabe dónde miente el modelo es más valioso, no menos. El BA que trata el modelo como el autor final es el que cuyo nombre aparece en el informe de incidentes del próximo año junto a "la IA generó esta consulta".

Elija la primera opción.

Aprenda más