El modelo no es la parte cara. En la mayoría de los programas de IA empresarial, la integración con la infraestructura heredada representa entre el 40 % y el 60 % del coste total de entrega, y casi ningún caso de negocio lo contabiliza.
This article was translated from the English original. Translations are machine-assisted and reviewed on a rolling basis.
Todo proveedor de IA empresarial demuestra su producto en un entorno limpio. Los datos están estructurados, las API están bien documentadas y el sistema se ha construido para aceptar exactamente el tipo de entrada que produce su modelo. No hay engaño alguno; un entorno limpio es la única manera racional de demostrar un producto. También es profundamente poco representativo del entorno en el que el producto operará de verdad.
Ese entorno se construyó a lo largo de décadas, por equipos distintos, sobre pilas tecnológicas distintas, y nunca se diseñó para conectarse a nada que no existiera en el momento en que se construyó. Conseguir que la IA funcione de forma fiable en ese entorno es un programa de ingeniería, no una tarea de configuración, y es de forma sistemática la partida de coste más grande que los casos de negocio de IA empresarial no incluyen.
El modelo es la parte más barata
La estructura de precios de los proveedores de IA genera una distorsión sistemática en la forma en que las organizaciones estiman el coste de un programa. Los costes de inferencia del modelo son visibles, predecibles y decrecientes. Aparecen con claridad en las propuestas de los proveedores y son fáciles de proyectar. El trabajo de ingeniería necesario para conectar un modelo a los sistemas de los que depende no aparece en absoluto en el precio del proveedor.
El análisis de Gartner sobre las estructuras de coste de los programas de IA en grandes despliegues empresariales indica que la integración y la ingeniería de datos representan entre el 40 % y el 60 % del coste total del programa una vez que el despliegue alcanza escala de producción. Es el mayor componente de coste individual en la mayoría de los programas y, en la mayoría de los casos de negocio, es la categoría con más probabilidades de estar representada por una estimación de relleno en lugar de una fundamentada.
La encuesta Office of the CFO 2025 de L.E.K. Consulting encontró que el fallo de integración era el bloqueo citado con más frecuencia para materializar el valor de la IA, por delante del rendimiento del modelo, la adopción por parte de la plantilla y las restricciones presupuestarias. La tecnología funcionaba. La infraestructura que la rodeaba no la sostenía.
Por qué se subestiman sistemáticamente los sistemas heredados
Los ingenieros que construyeron la mayoría de los sistemas centrales de las empresas ya no trabajan en las compañías que los operan. La documentación de esos sistemas está incompleta, es inconsistente o describe una versión del sistema que quedó superada en 2017. Las API, cuando existen, se construyeron para las integraciones que existían entonces, no para el acceso a datos estructurados, en tiempo real y de alto volumen que la IA exige.
Esto produce una secuencia predecible de descubrimientos durante el trabajo de integración de IA. El primero es que los datos que la IA necesita existen, pero no en la forma en que los necesita. El segundo es que ponerlos a disposición en la forma correcta obliga a tocar sistemas que cargan un riesgo organizativo desproporcionado (ERP central, libros contables, registros de clientes) donde los plazos de gestión del cambio se miden en trimestres, no en sprints. El tercer descubrimiento es que la calidad de los datos en esos sistemas, al nivel de campo del que depende la IA, es más baja de lo que sugería cualquier auditoría previa al proyecto.
Nada de esto es raro. Es el estado normal de la infraestructura de datos empresarial en organizaciones que llevan operando más de diez años. Lo raro es tratarlo como un coste conocido de antemano y no como uno descubierto sobre la marcha.
Los cuatro costes de integración que los casos de negocio pasan por alto
Hay un patrón constante en los costes de integración que aparecen en los post mortem pero no en los casos de negocio.
Preparación y limpieza de datos. Los modelos de IA producen resultados proporcionales a la calidad de sus entradas. En la mayoría de los despliegues empresariales, preparar los datos hasta el nivel de calidad que el modelo exige es un programa en sí mismo: auditorías de los sistemas de origen, deduplicación, normalización y mantenimiento continuo de las canalizaciones. Este trabajo rara vez está terminado antes de que se financie un piloto de IA y casi siempre se subestima cuando lo está.
Autenticación y control de acceso. Los sistemas empresariales no comparten datos libremente. Tienen estructuras de permisos, requisitos de auditoría y controles de acceso que no se diseñaron pensando en cuentas de servicio de IA. Conectar la IA a esos sistemas exige trabajo de arquitectura de seguridad que lleva tiempo y, en sectores regulados, implica revisión de cumplimiento. No aparece en la hoja de precios de ningún proveedor de modelos.
Gestión del cambio en los sistemas de origen. Cuando la integración de IA obliga a modificar cómo funciona un sistema de origen (cambiar una API, añadir un disparador de eventos, alterar una estructura de datos), ese cambio entra en la cola de gestión del cambio de ese sistema. En organizaciones grandes esas colas son largas, y los sistemas que van primero rara vez son los que el programa de IA necesita. Las estimaciones de tiempo construidas sobre la suposición de que los cambios en los sistemas de origen ocurren al ritmo del programa se equivocan siempre.
Supervisión continua y gestión de la deriva. Una vez que un modelo está en producción, la integración no pasa a ser gratuita. Los datos de los sistemas de origen cambian. Las API upstream se versionan. Los resultados del modelo derivan a medida que cambian las distribuciones de entrada. Supervisar y mantener la capa de integración es un coste de ingeniería continuo que la mayoría de los casos de negocio dan por insignificante después de la puesta en marcha.
Cómo es un caso de negocio bien fundamentado
Las organizaciones que valoran la integración con precisión antes de arrancar un programa lo consiguen empezando por la arquitectura de sistemas, no por el precio del proveedor.
Antes de presentar un caso de negocio, las preguntas correctas son: ¿a qué sistemas de origen necesita acceder esta IA, en qué forma, con qué latencia, y cuál es el estado actual de la calidad de datos y de la superficie de API de esos sistemas? Ese análisis produce un alcance de integración real y una estimación de coste real. También saca a la luz, pronto, las restricciones de los sistemas de origen que determinarán el calendario del programa más que cualquier decisión sobre qué modelo elegir.
No es un proceso largo. Una revisión de arquitectura de sistemas de dos días, realizada antes de seleccionar proveedor, basta para convertir un caso de negocio sin restricciones en uno con una estructura de coste defendible. Las organizaciones que se saltan este paso no evitan el coste. Lo descubren más tarde, cuando el programa ya está comprometido y las opciones para gestionarlo se han estrechado considerablemente.
Lo que implica para las compras
El impuesto de integración tiene una implicación directa en cómo se compra la IA empresarial. Seleccionar un proveedor por el rendimiento del modelo y el coste de licencia, sin tener en cuenta la complejidad de integración, produce una estructura de coste que no sorprenderá a nadie salvo a las personas que aprobaron el presupuesto.
Los procesos de compra que evalúan las plataformas de IA por el riesgo de implantación, en concreto por con qué limpieza y rapidez se conectan a los sistemas de origen que la organización realmente opera, dan mejores resultados que los procesos que evalúan solo por pruebas comparativas del modelo. Las capacidades de modelo de las grandes plataformas están convergiendo. La superficie de integración que ofrecen, y el ecosistema de servicios profesionales que la sostiene, divergen bastante.
Las organizaciones que más valor extraen de la IA empresarial son las que entraron en sus programas con una idea precisa de lo que conectar esos modelos a su negocio iba a exigir de verdad, y que incorporaron ese requisito al programa desde el principio. El rendimiento del modelo en sí rara vez es lo que decide.
El impuesto de integración no es un coste oculto en el sentido de que sea difícil de encontrar. Es un coste oculto en el sentido de que nadie dentro del proceso de compra tiene incentivos para sacarlo a la luz pronto. Los proveedores cotizan costes de modelo. Los integradores de sistemas cotizan costes de implantación contra un alcance que aún no se ha definido. Los equipos internos estiman contra el escenario optimista porque es lo que consigue que el programa se financie.
El resultado son programas estructuralmente infrafinanciados para producción y estructuralmente sobrecomprometidos en plazos. Acertar con el caso de negocio no exige herramientas nuevas ni una metodología nueva. Exige hacer las preguntas de infraestructura antes que las preguntas al proveedor, y tratar las respuestas como restricciones y no como notas al pie.
Frequently asked questions
Why is AI integration into legacy systems so expensive?+
Legacy enterprise systems were not designed to expose the data AI requires in the form it requires it. Connecting them requires translation layers, data cleaning pipelines, authentication bridging, and often significant engineering work on systems that were never meant to be touched again. This work does not appear in model vendor pricing.
What portion of enterprise AI cost is integration?+
Estimates vary, but L.E.K. Consulting's 2025 Office of the CFO survey found integration failure cited as the single largest operational blocker to AI value realisation. Gartner's analysis of AI programme cost structures suggests integration accounts for 40–60% of total programme cost in mature enterprise deployments.
How should enterprise leaders account for integration cost in AI business cases?+
Integration costs should be estimated at the systems architecture level before a business case is submitted — not after a vendor is selected. The questions to answer: which source systems does this AI require access to, in what form, at what latency, and what is the current state of those systems' data quality and API surface?