El costo real de implementar IA sin arquitectura previa

El dato incómodo

En 2024, el MIT Sloan Management Review y BCG publicaron un dato que sigue sin ser digerido en la mayoría de los consejos: el 78% de las empresas que iniciaron pilotos de IA generativa no logró escalar ninguno hacia producción con impacto medible en 12 meses. Gartner llegó a una cifra similar por otra vía: para 2026, al menos el 60% de los proyectos de IA empresarial serán abandonados por falta de datos listos para consumo por modelos.

Estas cifras se han convertido en el nuevo estándar de conversación en foros directivos. La respuesta común, sin embargo, sigue siendo la equivocada: contratar más consultores de IA, comprar más licencias, arrancar más pilotos. Es tratar el síntoma. La enfermedad es otra.

El síntoma frente a la enfermedad

Un piloto de IA fracasa por síntomas visibles: el modelo no funcionó como se esperaba, los resultados no fueron útiles, el equipo no lo adoptó, el ROI no apareció. Estos son los diagnósticos que llegan al consejo. La causa real casi nunca aparece en el reporte, porque incomoda: la organización no tenía la arquitectura para sostener IA en producción.

Un piloto no exige mucho: unos cuantos casos de uso acotados, un dataset limpio construido a mano para la demo, un equipo pequeño y motivado, un tablero atractivo para la presentación al consejo. Producción es otra cosa. Producción exige:

• Datos ingresando de forma continua, limpios y con estructura consistente.
• Procesos operativos definidos que puedan consumir la salida del modelo sin interpretación heroica del operador.
• Un modelo de gobierno que decida quién puede cambiar el modelo, con qué frecuencia y bajo qué autoridad.
• Métricas de desempeño que permitan detectar drift antes del daño.
• Integración con los sistemas que ya usan los operadores en su día a día, no una segunda ventana.

La mayoría de las organizaciones no tiene esta base. El piloto se construye sobre un andamio artificial que no existe en el resto de la operación. Cuando llega la hora de escalar, el andamio se desarma y con él la promesa que se le presentó al consejo.

Los cuatro estratos que deben existir antes de la IA

La arquitectura organizacional que sostiene IA en producción se compone de cuatro estratos. Ningún modelo, por bueno que sea, compensa la ausencia de alguno.

Estrato 1: Datos limpios y continuos

Un modelo aprende de datos. Si los datos entran sucios, incompletos, con estructura variable o con lag de días, el modelo entrega salida inútil. Y no lo hace evidente: entrega salida verosímil pero desviada. El modelo no sabe que los datos están mal. Los usa.

El diagnóstico honesto: la mayoría de las empresas medianas mexicanas no tiene un data warehouse funcional. Tiene un ERP con datos transaccionales, un CRM aislado, sistemas de piso con exports manuales, hojas de cálculo con datos maestros duplicados y campos abiertos donde los operadores escriben lo que se les ocurre. Antes de hablar de IA, hay una obra de plomería que la organización postergó durante una década.

Este estrato exige tres componentes: ingesta continua desde los sistemas fuente, normalización a un modelo canónico y limpieza automatizada con reglas versionadas. Sin los tres, no hay base para nada.

Estrato 2: Procesos definidos y estables

La IA acelera procesos. No los crea. Si el proceso de aprobación de crédito depende de la interpretación personal del gerente de sucursal, ningún modelo va a aprender ese proceso. Solo va a codificar la inconsistencia y a escalarla.

Un proceso listo para IA cumple tres condiciones: está descrito con nivel de detalle operativo, es estable porque no cambia cada trimestre por decisión ad hoc, y produce trazas digitales de cada decisión. Sin las tres, el modelo entrena sobre ruido.

Este estrato exige una función de rediseño de procesos que la mayoría de las organizaciones no tiene formalizada. Suele estar dispersa entre operaciones, mejora continua y consultoría externa recurrente. El resultado: nadie es dueño y cada intento de estandarización se diluye.

Estrato 3: Gobierno de información y modelo

La pregunta que sigue: quién es dueño de qué. En organizaciones sin arquitectura, la respuesta es difusa. Compras cree que los datos maestros de proveedor son suyos, TI cree que son suyos, finanzas cree que son suyos, y en la práctica ninguno los mantiene con disciplina. Cuando el modelo empieza a producir decisiones basadas en esos datos, el conflicto sale a la superficie y suele resolverse desactivando el modelo.

El gobierno debe definir: propietario de cada dominio de datos, política de calidad, autoridad para cambiar el modelo en producción, cadencia de revisión periódica, y ciclo de retiro cuando el modelo deja de ser útil. Sin esto, cada modelo en producción es una bomba de tiempo regulatoria y operativa.

Estrato 4: Cultura de decisión basada en dato

Este es el estrato más difícil y el menos técnico. Una organización donde las decisiones importantes se toman por instinto ejecutivo, negociación política interna o costumbre no va a adoptar la salida de un modelo. La va a ignorar, la va a validar externamente hasta neutralizarla o la va a distorsionar hasta que confirme la decisión que ya estaba tomada.

Este estrato no se construye con capacitación ni con talleres. Se construye con incentivos y con demostración. Cuando el directivo ve que la métrica que decide su bono se mueve favorablemente con las decisiones que sigue el modelo, adopta. Antes, no.

La secuencia correcta

La secuencia que hemos observado como funcional en organizaciones que sí lograron capitalizar IA:

1. Diagnóstico honesto del estado de datos y procesos, sin proyecto de venta detrás (2 a 4 meses).
2. Arquitectura de información definida: qué se centraliza, qué se descentraliza, qué se retira (3 a 6 meses).
3. Rediseño de los tres a cinco procesos donde la IA va a operar, con propietario claro (3 a 6 meses).
4. Instalación del gobierno de datos y del modelo operativo de decisión humano-máquina (2 a 3 meses).
5. Primer caso de uso de IA en producción, escalable, medible (3 a 6 meses).

Total: 13 a 25 meses hasta el primer caso de uso productivo. La organización promedio quiere ir directo al paso 5 en 3 meses. Esa impaciencia es la razón principal del 78%.

Vale la pena aclarar algo que suele confundirse: la secuencia acumulativa no significa parálisis. Los estratos se pueden construir en paralelo cuando existe capacidad y gobierno para hacerlo, pero cada estrato debe estar estable antes de que el siguiente dependa de él. Saltarse el orden es lo que produce el fracaso.

Cuánto cuesta la ruta corta

El costo visible de la ruta corta, es decir el piloto que no escala, es la inversión del piloto. Suele estar entre 500 mil pesos y 5 millones de pesos por caso. Es el costo que aparece en el reporte al consejo.

El costo invisible es mayor:

• Fatiga organizacional: cada piloto fallido reduce el capital político para el siguiente intento y quema credibilidad del equipo interno.
• Deuda de arquitectura: el atajo del piloto acumula parches que se pagan después con intereses altos.
• Riesgo regulatorio: modelos en producción sin gobierno expuestos a auditorías fiscales, laborales o de protección de datos, con multas posibles bajo LFPDPPP.
• Costo de oportunidad: dos años de intentos fallidos son dos años que el competidor con arquitectura sí usa para consolidar ventaja.
• Sesgo del talento clave: los perfiles buenos en datos abandonan la organización que los pone a construir sobre arena movediza.

Un cálculo conservador: por cada millón de pesos invertido en pilotos que no escalan, la organización acumula entre 3 y 7 millones de deuda de arquitectura que debe pagar después con intereses.

Un patrón recurrente

En diagnósticos que hemos realizado con más de treinta empresas medianas mexicanas en los últimos tres años, el patrón se repite con precisión inquietante. Consejo aprueba estrategia de IA. Área de innovación arranca dos o tres pilotos con proveedores distintos. Los pilotos entregan demos exitosas. Al intentar escalar, aparecen los tres bloqueos: datos que no existen con la limpieza requerida, procesos que dependen de personas específicas y no de reglas, y falta de propietario claro para el modelo en producción.

La conversación al consejo, 18 meses después, tiende a girar hacia justificar el aprendizaje. Es una justificación honesta pero incompleta. Sí hubo aprendizaje. El costo, sin embargo, se pudo haber evitado con un diagnóstico previo del estado de arquitectura.

La lectura del consejo

La pregunta útil que el consejo debería hacer antes de aprobar el siguiente proyecto de IA no es cuál es el ROI proyectado. Es:

• ¿Existe el data warehouse donde este modelo va a leer y escribir de forma continua?
• ¿Los procesos que este modelo va a operar están descritos, estables y con dueño?
• ¿Tenemos definido quién gobierna este modelo en producción y con qué autoridad para modificarlo o retirarlo?
• ¿Cuál es nuestra métrica de éxito a 24 meses y quién es responsable de sostenerla?

Si tres o más respuestas son ambiguas, el proyecto no es un proyecto de IA. Es un proyecto de arquitectura organizacional disfrazado. Confundir esto es la razón principal por la que las organizaciones queman capital sin construir capacidad.

Conclusión

La IA no es la respuesta a problemas organizacionales. Los acelera. Una organización con arquitectura sólida usa IA para escalar ventaja. Una sin arquitectura la usa para escalar caos. El costo real de implementar IA sin arquitectura previa no se mide en el piloto que fracasó. Se mide en los 18 meses que la organización perdió creyendo que el problema era técnico cuando era estructural, y en el capital político consumido que después falta cuando la verdadera transformación arquitectónica ya no puede posponerse más.

El consejo que entiende esto invierte primero en la base y después en el modelo. El consejo que se salta la base termina, tres años después, contratando a otra consultora para diagnosticar por qué su transformación de IA no funcionó. La respuesta, casi siempre, es la misma. La pregunta útil es por qué nadie la formuló al principio.