IA en Ingeniería Analítica: Lo Que Realmente Funcionó (Guía Ejecutiva)
- SaaS y Tecnología
Resumen
La IA (Claude Code) redujo el tiempo de ingeniería analítica en una migración de 5 meses con datos financieros reales, pero solo dentro de límites estrictos: aceleró trabajo repetitivo (12 modelos de staging generados en minutos), mantuvo consistencia en 161 modelos vía un archivo CLAUDE.md, y detectó edge cases de precisión financiera — pero nunca tomó decisiones de pricing, no descubrió reglas de negocio no documentadas, y no resolvió fricción organizacional de permisos y SSO. El equipo de 4 personas entregó 161 modelos usando barreras explícitas (~2 días de inversión) que hicieron la IA confiable sobre datos financieros, no solo rápida.
Conclusión clave — Lo que la IA realmente hizo — y no hizo — en una migración analítica de 5 meses con datos financieros reales.
Olvídate del hype. Esto es lo que realmente pasó.
Usamos IA (Claude Code) como herramienta de desarrollo en un proyecto de migración analítica de 5 meses. No como demo. No como prueba de concepto. En producción, con cálculos financieros, con datos reales de ingresos.
Esto es lo que funcionó, lo que no, y lo que los ejecutivos realmente deberían considerar.
Lo que la IA hizo bien
1. Aceleró trabajo repetitivo de patrones
El proyecto requería 12 modelos de staging — uno por región de nube — todos siguiendo el mismo patrón con variaciones menores (tablas fuente distintas, identificadores de región distintos). La IA los generó en minutos en vez de horas.
De manera similar, crear documentación de schema (archivos YAML con descripciones de columnas y tests) para 80+ modelos es trabajo tedioso que la IA maneja eficientemente.
2. Mantuvo consistencia en 161 modelos
Con un archivo CLAUDE.md definiendo convenciones de nombres, patrones de arquitectura y estándares de código, la IA produjo código estilísticamente consistente en todo el proyecto. Sin el drift de “diferente desarrollador, diferente estilo.”
3. Detectó edge cases en lógica financiera
Durante la implementación de pricing, la IA detectó problemas potenciales de precisión (tipos FLOAT vs NUMBER) y sugirió casts explícitos. También identificó riesgos de fan-out en joins que podrían inflar cálculos de ingresos.
4. Hizo que la documentación existiera
Los ingenieros rara vez escriben documentación voluntariamente — eso no es un secreto para nadie que haya trabajado en un proyecto de datos. Con asistencia de IA, cada modelo obtuvo descripciones, cada columna quedó documentada, y las guías de autoservicio para Finanzas se redactaron y refinaron iterativamente.
Lo que la IA NO hizo
1. Tomar decisiones financieras
La IA nunca decidió cuánto debería ser una tarifa de pricing, cómo debería aplicarse un descuento, o si una variación era aceptable. Cada cálculo financiero fue propuesto por la IA, revisado por un humano y aprobado por stakeholders de Finanzas.
Esto fue por diseño — el archivo CLAUDE.md del proyecto prohíbe explícitamente que la IA cambie macros financieros sin aprobación humana.
2. Reemplazar experiencia de dominio
La IA no tenía idea de que el pricing de una categoría de producto había cambiado significativamente a mitad del año porque la tarifa existía en una base de datos, no en código ni documentación. Un humano tuvo que hacer ingeniería inversa del multiplicador comparando outputs del sistema viejo y el nuevo.
La IA acelera trabajo dentro de un dominio conocido. No descubre reglas de negocio no documentadas.
3. Navegar complejidad organizacional
Permisos de Snowflake, configuraciones de SSO con Okta, aprobaciones de tokens de GitHub, jerarquías de roles — nada de esto era solucionable con IA. La “danza de permisos” (intentar → fallar → solicitar acceso → esperar → reintentar) consumió tiempo real de proyecto que ninguna IA podía acortar.
4. Funcionar sin barreras
Al inicio del proyecto, sin restricciones adecuadas, la IA ocasionalmente sugería ejecutar comandos amplios de dbt que podían afectar producción. La solución fueron barreras explícitas:
- Nunca ejecutar
dbt runsin--select(limita el alcance) - Nunca usar FLOAT para valores monetarios
- Nunca modificar código de referencia legacy
- Siempre validar antes de declarar que algo es correcto
Sin estas reglas, la asistencia de IA habría sido neta negativa en un sistema financiero.
El framework: cómo usar IA en analytics de verdad
El patrón CLAUDE.md
La decisión de mayor impacto fue crear un archivo de instrucciones a nivel proyecto (CLAUDE.md) que define:
Reglas de arquitectura — dónde pertenece cada tipo de código (staging, intermediate, marts), convenciones de nombres, patrones de materialización.
Límites duros — operaciones que requieren aprobación humana (cambios de lógica financiera, deploys a producción, comandos destructivos).
Contexto de dominio — qué hace el proyecto, qué representan los datos, qué estándares de precisión aplican.
Patrones de workflow — cómo abordar tareas comunes (migración, validación, testing).
Este archivo cumple doble función: restringe a la IA durante el desarrollo Y documenta conocimiento institucional para miembros humanos del equipo. Cuando el consultor se fue, el equipo tenía todo lo necesario para continuar — con o sin asistencia de IA.
La inversión en barreras
Tiempo invertido en escribir barreras: ~2 días a lo largo del proyecto. Tiempo ahorrado por la IA en 5 meses: significativo (difícil de cuantificar con precisión, pero los 285 commits del desarrollador principal sugieren alta velocidad).
El ROI de las barreras no es solo seguridad — es calidad. La IA con restricciones produce mejor código que la IA sin restricciones porque sigue patrones en vez de adivinar.
Lo que los ejecutivos deberían preguntar a sus equipos
1. “¿Qué barreras tenemos implementadas?”
Si la respuesta es “estamos usando la herramienta de IA tal cual,” eso es un riesgo. Especialmente en sistemas financieros. Cada proyecto debería tener restricciones documentadas — no porque la IA sea maliciosa, sino porque sin contexto específico del dominio, sugiere cosas razonables en abstracto que son peligrosas en su sistema concreto.
2. “¿Quién aprueba la lógica financiera generada por IA?”
Debería haber un humano en el loop para cualquier cálculo que afecte ingresos, facturación o reportes de compliance. “La IA lo escribió y pasó los tests” no es aprobación suficiente.
3. “¿La IA nos está haciendo más rápidos, o solo más ocupados?”
La IA puede generar código rápidamente. Pero si ese código necesita review extenso, debugging y retrabajo, la ganancia neta de velocidad puede ser menor de lo que parece. Mide cycle time, no solo volumen de output.
4. “¿Qué pasa cuando apagamos la IA?”
Si el codebase solo tiene sentido para la IA que lo escribió, tiene un problema de dependencia. Código bien estructurado con asistencia de IA debería ser legible y mantenible por humanos. Documentación, convenciones de nombres y arquitectura clara importan más con IA, no menos.
5. “¿Estamos usando IA donde tiene apalancamiento?”
La IA destaca en: patrones repetitivos, documentación, consistencia de código, generación de tests. La IA falla en: reglas de negocio no documentadas, navegación organizacional, decisiones financieras de precisión crítica.
Deploying donde tiene apalancamiento. No la fuerces donde no lo tiene.
La IA en ingeniería analítica es real y valiosa — pero es un multiplicador de productividad, no un reemplazo de la experiencia de dominio ni del juicio humano.
El proyecto entregó 161 modelos en 5 meses con un equipo de 4. Esa velocidad no habría sido posible sin asistencia de IA. Pero tampoco habría sido posible sin:
- Patrones claros de arquitectura
- Barreras explícitas en lógica financiera
- Revisión humana de cada cálculo de pricing
- Navegación organizacional que ninguna IA puede automatizar
Las empresas que van a obtener más valor de la IA en analytics no son las que tienen las mejores herramientas de IA. Son las que tienen las mejores barreras, la documentación más clara y la experiencia de dominio más fuerte para guiar a la IA. El framework primero. La herramienta después.
¿Está evaluando IA para su equipo de datos? Podemos ayudarle a separar lo que funciona de lo que es marketing. Hablemos.
Preguntas frecuentes
¿La IA puede reemplazar a un analytics engineer en proyectos financieros?
No. En esta migración de 5 meses, la IA (Claude Code) aceleró trabajo repetitivo — como generar 12 modelos de staging en minutos — y mantuvo consistencia de estilo en 161 modelos, pero nunca tomó decisiones financieras: cada cálculo de pricing fue propuesto por la IA, revisado por un humano y aprobado por Finanzas. Tampoco descubrió reglas de negocio no documentadas ni resolvió la danza de permisos de Snowflake, Okta y GitHub. Es un multiplicador de productividad para un equipo con experiencia de dominio, no un reemplazo del juicio humano.
¿Qué es un archivo CLAUDE.md y para qué sirve?
Es un archivo de instrucciones a nivel de proyecto que define reglas de arquitectura, límites duros (qué requiere aprobación humana), contexto de dominio y patrones de workflow para que la IA los lea al inicio de cada sesión. En este proyecto fue la decisión de mayor impacto: mantuvo 161 modelos estilísticamente consistentes y, al mismo tiempo, documentó conocimiento institucional para el equipo humano — de modo que cuando el consultor se fue, el equipo pudo continuar con o sin asistencia de IA.
¿Qué tareas hace bien la IA en ingeniería analítica y cuáles no?
La IA destaca en patrones repetitivos (modelos de staging similares), documentación de schema para 80+ modelos, consistencia de código y detección de edge cases técnicos como riesgos de fan-out en joins o tipos FLOAT vs NUMBER. Falla en reglas de negocio no documentadas — no detectó un cambio de pricing a mitad de año porque la tarifa vivía solo en una base de datos —, en navegar complejidad organizacional (permisos de Snowflake, SSO de Okta, aprobaciones de GitHub) y en decisiones financieras de precisión crítica, que siempre requirieron aprobación humana.
¿Cuánto cuesta poner barreras de IA en un proyecto financiero?
En este proyecto, escribir las barreras (reglas explícitas como nunca ejecutar dbt run sin --select, nunca usar FLOAT para valores monetarios, siempre validar antes de declarar algo correcto) tomó aproximadamente 2 días a lo largo de una migración de 5 meses. El retorno no fue solo seguridad: la IA con restricciones produjo mejor código que la IA sin restricciones, porque siguió patrones en vez de adivinar. Sin esas reglas, la asistencia de IA habría sido neta negativa en un sistema financiero.
¿Qué preguntas debe hacer un ejecutivo antes de aprobar IA en su equipo de datos?
Cinco preguntas clave: ¿qué barreras tenemos implementadas, más allá de usar la herramienta tal cual?; ¿quién aprueba la lógica financiera generada por IA, dado que debe haber un humano en el loop para cualquier cálculo que afecte ingresos o compliance?; ¿la IA nos hace más rápidos o solo más ocupados, midiendo cycle time y no solo volumen de output?; ¿qué pasa cuando apagamos la IA, es decir, el código sigue siendo mantenible por humanos?; y ¿estamos usando la IA donde realmente tiene apalancamiento?