IA en Ingeniería Analítica: Lo Que los Ejecutivos Necesitan Saber (No el Hype)

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

Seamos honestos — los ingenieros rara vez escriben documentación voluntariamente. 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 varianza 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 run sin --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.

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ó, tienes 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.

Despliégala donde tiene apalancamiento. No la fuerces donde no lo tiene.

La conclusión para ejecutivos

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.

Invierte en el framework, no solo en la herramienta.

¿Estás evaluando IA para tu equipo de datos? Podemos ayudarte a separar lo que funciona de lo que es marketing. Hablemos.