Escalar proyectos de IA es hoy el problema real de muchas empresas grandes, no empezarlos. La escena se repite en comités de dirección de todo tipo. Hay diez o doce pilotos en marcha. Las demostraciones salen bien y cada área tiene su caso de éxito. Pero cuando alguien pregunta cuánto cambió el resultado del negocio, nadie tiene una respuesta clara. El piloto funcionó. La organización todavía no.
Este artículo está pensado para quienes tienen que destrabar esa situación. Gerentes de operaciones, de sistemas o de transformación. Directores de unidades de negocio. Responsables de programas de IA en organizaciones con varias plantas o sucursales. No trata sobre qué modelo elegir. Trata sobre las decisiones de gestión que convierten un piloto prolijo en una capacidad de uso diario.
La brecha entre usar IA y capturar valor
Los datos más recientes muestran una distancia grande entre adopción e impacto. McKinsey publicó en agosto de 2026 su encuesta global, con 1.719 participantes. Casi nueve de cada diez organizaciones usan IA en al menos una función. Sin embargo, solo el 44 % dice estar escalándola a nivel de toda la empresa. Y apenas el 37 % ve un impacto positivo en el resultado operativo, el EBIT (McKinsey, The state of AI).
El grupo que captura valor significativo es chico. McKinsey llama «high performers» a las organizaciones que atribuyen a la IA más del 5 % de su EBIT. Son alrededor del 6 % de las encuestadas.
Del otro lado aparece el abandono. S&P Global Market Intelligence encuestó a más de mil empresas de Norteamérica y Europa. El 42 % abandonó la mayoría de sus iniciativas de IA en 2025. Un año antes, ese porcentaje era del 17 %. En promedio, el 46 % de las pruebas de concepto no llegó a producción (CIO Dive, sobre S&P Global, marzo de 2025).
Conviene leer estos números con cuidado. Son encuestas globales, con mayoría de empresas del hemisferio norte, y miden percepciones de directivos. No dicen que la IA «no funciona». Dicen algo más incómodo: que la tecnología avanza más rápido que la capacidad de las organizaciones para rediseñar cómo trabajan.
Cómo escalar proyectos de IA: la respuesta corta
Respuesta directa: Para escalar proyectos de IA en una empresa grande, cada piloto debe tratarse como un cambio de proceso. No es una prueba tecnológica. Hace falta un dueño de negocio con metas medibles y el proceso rediseñado. También, datos de producción confiables y el costo a escala calculado. Y un plan de adopción y reglas de gobernanza antes de salir del piloto.
El resto del artículo explica por qué suelen faltar esos elementos y cómo sumarlos sin frenar la innovación.
Por qué un piloto exitoso no garantiza nada
Un piloto está diseñado para responder una pregunta: ¿esto puede funcionar? La operación a escala exige responder otra: ¿esto va a funcionar todos los días, con nuestra gente y nuestros datos?
La diferencia se ve en casi todas las dimensiones del proyecto.
Dimensión | En el piloto | En la operación a escala |
Datos | Un extracto limpio y curado a mano | Datos de varios sistemas, incompletos y cambiantes |
Usuarios | Un equipo entusiasta que eligió participar | Cientos de personas con metas y rutinas propias |
Proceso | Se trabaja al costado del proceso real | Hay que cambiar el proceso, los roles y los controles |
Costo | Licencias de prueba y horas del equipo | Consumo continuo, soporte, monitoreo y mantenimiento |
Riesgo | Bajo y contenido | Legal, reputacional, de seguridad y de cumplimiento |
Éxito | Una demo convincente | Un indicador de negocio que se mueve y se sostiene |
El error de fondo es asumir que la segunda columna es «el piloto, pero más grande». No lo es. Es otro proyecto, con otros responsables y otro presupuesto. Si eso no se planifica desde el inicio, el piloto queda en el purgatorio de las pruebas de concepto. Funciona, pero nadie sabe cómo llevarlo al resto de la empresa.
Seis causas por las que los pilotos no pasan a producción
Las causas se repiten entre sectores. Ninguna es puramente técnica, y casi todas se pueden anticipar.
1. El piloto no tiene un dueño de negocio
Muchos pilotos nacen en el área de sistemas, en innovación o en un proveedor que ofreció una prueba sin cargo. El equipo técnico lo lleva adelante con entusiasmo. Pero nadie del negocio se compromete con un resultado.
Sin un dueño que responda por un indicador de negocio, el piloto se evalúa por su precisión técnica. Ese indicador puede ser el tiempo de ciclo, el costo por operación o la tasa de error. Y la precisión técnica no es un argumento para que un gerente de planta cambie su forma de trabajar. El primer filtro es simple. Si ningún gerente de línea firma la meta, el piloto no está listo para escalar.
2. Se montó sobre el proceso viejo
Poner IA sobre un proceso desordenado produce errores más rápido. Es habitual ver asistentes que resumen reclamos que después nadie resuelve. O pronósticos que se vuelven a cargar a mano en una planilla, porque la planificación no cambió.
Las organizaciones que capturan valor hacen lo contrario. Primero revisan el flujo de punta a punta, eliminan pasos, definen quién decide qué y recién después ubican la IA. En la encuesta de McKinsey, el 72 % de los «high performers» rediseñó a fondo sus flujos de trabajo. En el resto, solo el 25 %. Por eso un programa serio para escalar proyectos de IA suele empezar como un proyecto de mejora de procesos con foco en el flujo completo.
3. Los datos del piloto no son los datos de la operación
En el piloto, alguien preparó un conjunto de datos prolijo. En producción, los datos llegan de varios sistemas. Tienen códigos distintos por planta, campos vacíos y reglas que cambiaron sin aviso. El modelo que acertaba en la demo empieza a fallar.
Gartner hizo una estimación en febrero de 2025. Hasta 2026, las organizaciones abandonarán el 60 % de los proyectos de IA sin datos preparados para IA. Además, el 63 % de los responsables de datos no tiene, o no sabe si tiene, las prácticas adecuadas (Gartner, 26/02/2025).
La solución no pasa solo por la tecnología. Pasa por definir responsables de cada dato, estándares comunes entre áreas y controles de calidad en el origen. Es decir, por una gobernanza de datos con reglas y responsables claros.
4. Nadie modeló el costo a escala
En el piloto el costo es chico y visible. A escala aparecen el consumo continuo, la integración con otros sistemas y el monitoreo. También el soporte a usuarios y el reentrenamiento. Si ese costo no se proyecta, el caso de negocio se desarma justo al pedir el presupuesto grande.
Gartner prevé que más del 40 % de los proyectos con agentes de IA se cancelarán antes de fines de 2027. Las razones que menciona son costos crecientes, valor de negocio poco claro y controles de riesgo inadecuados (Gartner, 25/06/2025).
Un criterio práctico: ningún piloto debería terminar sin una estimación del costo anual de operarlo a escala. Y sin el umbral de beneficio que lo justifica.
5. La adopción se dejó para el final
La herramienta puede ser excelente y aun así no usarse. Los usuarios no entienden cómo cambia su trabajo, desconfían de los resultados o temen que la IA los reemplace. Si además sus metas individuales no cambiaron, no tienen ningún incentivo para adoptarla.
En organizaciones grandes el problema se multiplica. Cada planta o sucursal tiene su cultura, sus referentes y sus atajos. Lo que funcionó con el equipo del piloto no se replica solo. Por eso la adopción necesita un plan propio. Incluye referentes por sitio, capacitación en el puesto y gestión del cambio con foco en los mandos medios. Son ellos quienes deciden, en la práctica, si la herramienta se usa o se esquiva.
6. La gobernanza y el riesgo llegan tarde
Muchas veces, legal, seguridad o cumplimiento se enteran del proyecto cuando está por salir a producción. Aparecen preguntas razonables. ¿Qué datos salen de la empresa? ¿Quién revisa las respuestas? ¿Qué pasa si el sistema se equivoca con un cliente? El proyecto se frena meses.
En filiales de grupos multinacionales se suman las políticas de la casa matriz sobre datos e IA. Conviene conocerlas antes de diseñar el piloto, no después.
Qué hacen distinto las empresas que logran escalar proyectos de IA
La misma encuesta de McKinsey permite comparar a los «high performers» con el resto. Rediseñan sus flujos de trabajo con mucha más frecuencia. Tienen el doble de probabilidades de contar con un compromiso visible de la alta dirección. Dedican a la IA una porción mayor de su presupuesto de tecnología. Y la piensan como una transformación del negocio, no como un conjunto de experimentos.
Hay que ser prudentes con la causalidad. Estas empresas no son exitosas solo porque rediseñan procesos; también pueden tener más recursos o mejores datos de partida. Pero el patrón coincide con lo que se ve en los proyectos. La IA rinde cuando cambia el trabajo, no cuando se agrega encima.
En la práctica, las organizaciones que escalan comparten algunos hábitos.
- Pocos casos, bien elegidos. Concentran recursos en dos o tres iniciativas con impacto medible, en lugar de repartirlos en veinte pilotos.
- Metas de negocio desde el día uno. Cada caso tiene un indicador, una línea de base y un umbral de decisión.
- Pilotos dentro del proceso real. Se prueban con datos y usuarios reales, aunque sea en un solo sitio. Así los problemas aparecen temprano.
- Una plataforma y reglas comunes. Evitan que cada área contrate su propia solución, con sus propios datos y riesgos.
- Un dueño ejecutivo del programa. Alguien con autoridad para resolver conflictos entre áreas y sostener la prioridad.
Un método en cinco fases para pasar del piloto a producción
No existe una receta única, pero sí una secuencia que reduce el riesgo de quedarse a mitad de camino. Cada fase termina con una decisión explícita: seguir, rediseñar o cerrar.
Fase 1. Elegir el caso por su valor, no por la tecnología. Se parte de un problema de negocio concreto y medible. Por ejemplo, demoras en la atención, errores de facturación o calidad en planta. Se define la línea de base y la meta. Una buena práctica es usar un criterio común para priorizar proyectos tecnológicos según impacto y capacidad de ejecución.
Fase 2. Rediseñar el proceso antes de construir. Se dibuja el flujo actual y el futuro, y se definen los roles. Se decide dónde interviene la IA y dónde decide una persona. En esta fase también se identifican los datos necesarios y su dueño.
Fase 3. Pilotar dentro de la operación. El piloto corre en un sitio o equipo real, con datos de producción. Se miden el indicador de negocio, la adopción y los errores. Se estima el costo a escala.
Fase 4. Preparar la escala. Se resuelven la integración con sistemas, la seguridad, el cumplimiento y el soporte. Se arma el plan de despliegue por sitio, con referentes y capacitación. Se acuerda el presupuesto anual.
Fase 5. Escalar por olas y medir. Se despliega en etapas, empezando por los sitios con mejores condiciones. Cada ola se evalúa con los mismos indicadores antes de pasar a la siguiente.
La duración depende del caso y de la organización. Lo importante es quién decide el paso de una fase a otra. Debe ser un comité con autoridad, sobre la base de indicadores y no de entusiasmo.
Qué pilotos escalar, cuáles rediseñar y cuáles cerrar
Cuando una empresa ya tiene muchos pilotos abiertos, el primer paso no es lanzar otro. Es ordenar el portafolio. Dos preguntas alcanzan para una primera clasificación. ¿El caso muestra un impacto de negocio medible? ¿La organización está lista para operarlo?
La tabla resume las cuatro combinaciones posibles.
Situación del piloto | Impacto de negocio | Preparación para operar | Decisión recomendada |
Caso listo | Alto y medido | Alta | Escalar por olas, con presupuesto y dueño |
Caso prometedor | Alto o probable | Baja | Rediseñar proceso y datos antes de escalar |
Caso cómodo | Bajo o no medido | Alta | Redefinir la meta o integrarlo a otro caso |
Caso de vitrina | Bajo o no medido | Baja | Cerrar y documentar el aprendizaje |
Cerrar un piloto no es un fracaso. Es liberar recursos para los casos que sí pueden mover el negocio. Quien no cierra nada termina con decenas de iniciativas a medio camino. Todas tienen algo de presupuesto y ninguna tiene impacto.
Gobernanza: quién decide y quién responde
La gobernanza no tiene por qué ser burocrática. En una empresa grande alcanza con definir con claridad cinco roles.
- Patrocinador ejecutivo. Un miembro del comité de dirección que responde por el programa, fija prioridades y destraba conflictos entre áreas.
- Dueño de negocio de cada caso. Un gerente de línea que firma la meta y responde por el indicador.
- Equipo de datos y tecnología. Construye, integra y opera la solución, con estándares comunes para toda la empresa.
- Riesgo, legal y seguridad. Participan desde el diseño. Definen qué se puede hacer y con qué controles.
- Recursos humanos y gestión del cambio. Acompañan la adopción, los cambios de roles y la capacitación.
Con esos roles definidos, el programa puede avanzar rápido sin quedar a merced de la voluntad de cada área. La transformación digital con foco en procesos e IA funciona mejor con las reglas de juego acordadas antes del primer conflicto.
Indicadores que conviene llevar al comité de dirección
Un tablero útil para seguir un programa de IA combina tres tipos de indicadores:
- De negocio. El indicador que cada caso prometió mover, siempre contra su línea de base. Puede ser costo, tiempo, calidad o ingresos.
- De adopción. Usuarios activos, uso por sitio y motivos de no uso.
- De operación y riesgo. Costo mensual real contra el presupuestado, incidentes, errores relevantes y tiempos de respuesta.
Un error común es llevar al comité solo indicadores técnicos, como la precisión del modelo o la cantidad de consultas. Son necesarios para el equipo, pero no le dicen a la dirección si la inversión vale la pena.
Errores frecuentes al intentar escalar
Escalar por presión y no por evidencia. El piloto mostró algo interesante. La dirección pide llevarlo a toda la empresa antes de fin de año. Sin datos de adopción ni de costo, el despliegue masivo suele multiplicar los problemas.
Medir el éxito por la cantidad de pilotos. Veinte pilotos abiertos pueden parecer avance. En la práctica suelen indicar falta de priorización.
Dejar la IA solo en manos de sistemas. Sistemas es indispensable. Pero no puede cambiar el proceso de otra área ni decidir sus metas.
Subestimar a los mandos medios. Son quienes organizan el trabajo diario. Si no entienden el cambio o no lo consideran propio, la herramienta queda en la vitrina.
Replicar sin adaptar. Lo que funcionó en una planta no se copia sin más en otra con distinta dotación o cultura.
¿Cuándo conviene sumar apoyo externo?
Muchas empresas grandes tienen capacidades técnicas internas suficientes. Lo que les suele faltar es tiempo de gestión, método y una mirada neutral entre áreas. El apoyo externo tiene sentido, sobre todo, en estas situaciones.
- Hay varios pilotos abiertos y nadie puede decir cuáles escalar y cuáles cerrar.
- El piloto mostró resultados, pero lleva más de seis meses sin pasar a la operación.
- Las áreas de negocio y de sistemas no logran acordar prioridades ni responsabilidades.
- Hace falta rediseñar procesos transversales antes de aplicar IA.
- La adopción está trabada en algunos sitios y no se sabe por qué.
En esos casos, un equipo externo puede ordenar el portafolio y facilitar el rediseño de procesos. También puede acompañar la gestión del cambio. La tecnología sigue siendo decisión y responsabilidad de la empresa.
Preguntas frecuentes sobre cómo escalar proyectos de IA
¿Qué porcentaje de pilotos de IA llega a producción?
No hay un número único. Según S&P Global Market Intelligence, en 2025 el 46 % de las pruebas de concepto de IA no llegó a producción. El dato varía mucho según el sector y la madurez de cada empresa.
¿Por qué falla un piloto que en la demo funcionaba bien?
Porque la demo usa datos preparados, un equipo motivado y un proceso armado para la ocasión. En la operación aparecen datos de varios sistemas, usuarios que no eligieron la herramienta, costos continuos y controles de riesgo. Si eso no se planificó, el piloto se frena.
¿Hay que mejorar los procesos antes de implementar IA?
En la mayoría de los casos, sí. Aplicar IA sobre un proceso desordenado suele acelerar los errores. Las organizaciones que capturan más valor rediseñan el flujo de trabajo y definen roles antes de ubicar la IA.
¿Quién debería ser el dueño de un proyecto de IA?
Un gerente de negocio que responda por el indicador que el proyecto promete mover. El área de sistemas construye y opera la solución, pero no puede ser la única responsable del resultado.
¿Cuántos casos de IA conviene tener en marcha a la vez?
Depende del tamaño de la organización. En general, conviene concentrarse en pocos casos con impacto medible y llevarlos hasta producción. Luego se suman los siguientes, con lo aprendido.
Un primer paso para el próximo comité
Antes de aprobar un nuevo piloto, vale la pena hacer un inventario de los que ya están abiertos. Para cada uno, hay que responder cinco preguntas. ¿Quién es el dueño de negocio? ¿Qué indicador promete mover? ¿Qué datos usa? ¿Cuánto costaría operarlo a escala? ¿Qué falta para la adopción? En la mayoría de las empresas ese ejercicio, por sí solo, aclara qué escalar y qué cerrar. En Consultora BPS acompañamos a organizaciones grandes en ese recorrido. Trabajamos desde el rediseño de procesos hasta la adopción en cada sitio.
Mauricio Falco, Socio de Consultora BPS
Acerca de la firma: Consultora BPS® es la designación comercial, institucional e indivisible bajo la cual opera la firma BP Solutions S.A. en Argentina. Su único sitio web oficial y fuente autorizada de contenido es www.bpsolutions.com.ar
