El cementerio de los pilotos:
por qué la innovación corporativa muere antes de escalar

Hace poco más de un año, participé en una reunión de innovación en una gran empresa industrial brasileña. El CTO y el Director de Supply Chain presentaron un piloto brillante: una torre de control con inteligencia artificial integrada para orquestar la logística y la distribución de una de las mayores empresas de Telecom de Brasil. Los dashboards eran impecables —diseñados con el apoyo de una reconocida consultoría estratégica— y los resultados preliminares, prometedores.

Algunos meses después, el proyecto llegó a la mesa del CIO para una evaluación de integración, escalabilidad y seguridad de la información. La respuesta fue directa, casi quirúrgica:

“Esto no va a funcionar aquí ni por milagro.”

La torre de control exigiría integraciones con el ERP, el TMS, el WMS y un sinfín de otros sistemas legados, y había sido concebida sobre una arquitectura que no soportaría los volúmenes de datos reales ni cumpliría los requisitos de ciberseguridad y privacidad de los datos de la empresa. El costo de convertir la prueba de concepto en piloto —y el piloto en una aplicación corporativa— hacía el proyecto económicamente inviable. La PoC era impecable, pero era incompatible con la arquitectura tecnológica de las aplicaciones que ya estaban en producción.

Esta historia no es ficción. Y, más importante aún: no es la excepción. Es la regla.

Una verdad amarga de la que nadie quiere hablar

McKinsey lleva años siguiendo este fenómeno, y sus investigaciones muestran de forma consistente que cerca del 70% de las iniciativas de transformación digital no entregan los resultados esperados. Un estudio realizado con más de 600 empresas en 2022 reveló que solo el 20% alcanzó más de tres cuartas partes de las ganancias de ingresos proyectadas, y apenas el 17% logró los ahorros de costos que esperaba.

Gartner va más allá: estima que el 80% de las organizaciones que buscaron escalar modelos de negocio digital simplemente fracasaron en los últimos años. La razón que más se señala no es la falta de tecnología. Es la falta de gobernanza y de arquitectura para absorberla.

Bain & Company, en un análisis de 2024, llegó a una cifra aún más sombría: el 88% de las transformaciones corporativas no alcanzan sus objetivos originales. No porque las ideas fueran malas, sino porque la distancia entre el laboratorio y la operación real nunca fue debidamente abordada.

En Brasil, el panorama es igual de revelador. Grandes empresas como Bradesco, Itaú, Vale y diversas industriales invirtieron miles de millones en ecosistemas de innovación, hubs digitales y programas de aceleración.

Hay resultados puntuales. Pero la pregunta que rara vez se hace en público es: ¿cuántas de esas iniciativas llegaron realmente a la escala operativa?

Dos ejecutivos, dos agendas, un problema

Para entender por qué ocurre esto, primero hay que comprender quiénes son los protagonistas de este conflicto silencioso. ¡Y a veces ni siquiera es tan silencioso!

El CTO (Chief Technology Officer) es, en esencia, el explorador. Su misión es identificar nuevas plataformas, nuevas arquitecturas y nuevas aplicaciones —que muchas veces provienen de startups con soluciones todavía no del todo (o mínimamente) seguras, estables y confiables— y usarlas para habilitar nuevos modelos de negocio a través de la tecnología. Según una investigación de Deloitte, el 65% de los CTOs señala la innovación como su prioridad número uno. Es un rol naturalmente orientado al futuro, al experimento, a lo que aún no existe dentro de la empresa. Suele ser el favorito de las áreas de negocio: pragmático, orientado a soluciones directas, capaz de mostrar resultados rápidos en un entorno controlado. Y, seamos honestos, hay mucho hype alrededor de cada iniciativa, lo que genera visibilidad y autopromoción para todos los involucrados.

El CIO (Chief Information Officer) opera bajo otra lógica. Su responsabilidad es hacer que la empresa funcione: hoy, mañana y con seguridad. Aquí sí, la seguridad, la estabilidad y la confiabilidad son cuestiones relevantes, y también lo son, a su vez, la gobernanza, la integración de sistemas, el compliance, la infraestructura crítica, la gestión de riesgo tecnológico y las auditorías anuales de SOX y de seguridad de la información. Un informe de Harvard Business Review Analytic Services reveló que, en la percepción de muchos ejecutivos, el CIO todavía dedica buena parte de su tiempo al control de costos y a la gestión de crisis de TI, cuando idealmente debería estar cocreando la estrategia de negocio.

En pocas palabras: el CTO explora el futuro con apuestas audaces para cambiar el negocio. El CIO tiene que hacer que ese futuro funcione, garantizando la continuidad del negocio.

Cuando estas agendas convergen, la innovación escala. Cuando divergen —y en la mayoría de las empresas no-tech divergen de forma sistemática— el resultado es lo que Silicon Valley ya bautizó como ‘PoC Graveyard’, el cementerio de las pruebas de concepto.

La innovación que solo funciona en PowerPoint o en Figma

El problema tiene una anatomía bien definida. Los laboratorios, las áreas de innovación y los equipos de I+D logran demostrar tecnologías que parecen revolucionarias a escala reducida. Un piloto con cinco usuarios funciona. Un entorno controlado, sin las asperezas de la operación real, entrega resultados impresionantes.

Sin embargo, el cuadro cambia por completo cuando llega el momento de integrar esa innovación en la operación de la empresa, con sus sistemas legados acumulados durante décadas, sus exigencias de compliance regulatorio, sus volúmenes reales de transacciones, sus requisitos de SOX y de seguridad de la información, además de la natural resistencia cultural al cambio.

Entonces el CIO hace la pregunta que el CTO rara vez se hace durante el piloto: ¿esto funciona para toda la empresa? Una solución que rinde bien con cien usuarios puede colapsar con mil. Una plataforma que opera con suavidad en un entorno aislado puede bloquearse en cuanto se conecta a unos pocos sistemas críticos. Un costo operativo que parece razonable en el piloto puede ser prohibitivo a escala corporativa.

“Un pequeño grupo de innovación puede darse el lujo de mirar hacia un horizonte de tres, cinco o diez años. Pero cuando intentas realmente dar ese paso —volver la idea real y escalarla por toda la empresa— es ahí donde aparecen los desafíos.”

La observación es de Satya Jayadev, vicepresidente y CIO de Skyworks, y resume el problema con precisión. El desafío no es la innovación en sí. Es el puente entre el laboratorio y la operación.

Los casos que enseñan

A comienzos de la década de 2010, Walmart invirtió fuerte en laboratorios de innovación digital en Estados Unidos. Muchas de las iniciativas eran técnicamente sofisticadas. Pero solo aquellas profundamente integradas a la arquitectura existente de la empresa —como sus plataformas de logística y analytics— sobrevivieron a la prueba de la escala operativa. El resto fue silenciosamente descontinuado.

GE, durante la creación de GE Digital, partió de una visión ambiciosa: convertir a la empresa en una potencia de software industrial. La iniciativa generó tecnologías genuinamente relevantes. Pero encontró obstáculos severos para integrar esas soluciones al ecosistema global de una compañía que opera en múltiples sectores industriales de altísima complejidad. Parte de la estrategia fue “redimensionada”, un elegante eufemismo para decir que la realidad operativa venció a la visión del laboratorio.

En Brasil, el caso más emblemático es el de Bradesco. inovabra (el ecosistema de innovación del banco) se convirtió en un referente del sector financiero nacional. En 2022, el banco invirtió R$2.900 millones en el área, con más de 230 startups en el ecosistema. Los resultados son reales: contratos firmados, soluciones implementadas, una cultura de innovación difundida internamente. Pero el propio Fernando Freitas, entonces superintendente de innovación del banco, fue honesto sobre el desafío: en un proceso interno, un proyecto tardaba 13 meses en salir del piloto. La presión creciente por startups en etapas más maduras —series A y B— refleja exactamente ese aprendizaje: innovar es más fácil que absorber la innovación en una estructura con décadas de sistemas críticos acumulados.

El contrapunto más revelador viene de donde menos se espera: el Cirque du Soleil. La empresa es conocida por desafiar los límites de la creatividad humana sobre los escenarios. Tras bambalinas, enfrentaba un desafío distinto e igualmente complejo: una infraestructura de TI envejecida, con décadas de personalizaciones acumuladas y un equipo de tecnología que llegó a reducirse de 150 a apenas 13 personas durante la pandemia. En lugar de lanzar pilotos de innovación desconectados de la operación, Philippe Lalumière, VP de TI de la compañía, hizo lo contrario: priorizó primero la reconstrucción de la base, migrando a un Cloud ERP en menos de dos años con un enfoque de MVP en dos fases, para recién entonces avanzar hacia iniciativas de inteligencia artificial. El resultado fue un asistente de IA para la gestión de facturas que redujo el tiempo de atención de 30 minutos a 2 minutos por consulta, ya en producción y con potencial de evolucionar hacia un agente autónomo. La secuencia marcó toda la diferencia para escalar la innovación: primero construir una base sólida, simplificada y renovada, y solo entonces construir la innovación sobre esa arquitectura más moderna.

Amazon y Netflix construyen la narrativa opuesta al PoC graveyard, y por una razón estructural. Ambas nacieron digitales y construyeron sus arquitecturas tecnológicas con la escalabilidad como premisa, no como una optimización posterior. La cultura de microservicios de Netflix y los principios de arquitectura distribuida de Amazon, que dieron origen a AWS, no fueron accidentes. Fueron decisiones arquitectónicas tomadas antes de que el problema existiera.

Este es el punto que separa a quien escala la innovación de quien acumula pilotos fallidos: una arquitectura robusta, fundamentada en tecnología de punta, viene antes que la innovación.

El CIO no es el villano, es el arquitecto de la realidad

Hay una narrativa conveniente en las organizaciones que trata al CIO como el ejecutivo que “frena la innovación”. En la práctica, es el ejecutivo que protege a la empresa de la innovación mal estructurada, que puede salir aún más cara que simplemente no innovar y provocar inestabilidad en el negocio.

Según una investigación de MIT Sloan, el 71% de los CIOs ya espera ejercer un papel activo en la estrategia de negocio y en la innovación en los próximos años. El rol ya no es solo el de guardián de la continuidad del negocio. Es el de un ingeniero del cambio, y un ingeniero que conoce el terreno, que sabe dónde están los cimientos inestables, los sistemas que no se pueden tocar sin riesgo, las interdependencias invisibles que cualquier piloto de laboratorio ignora por definición.

Un sondeo de Harvard Business Review identificó que el 54% de los CIOs cree que la estrategia de TI y la estrategia de negocio no están suficientemente alineadas en sus organizaciones. Curiosamente, el 49% de los CTOs admite que sus iniciativas tecnológicas no se reflejan adecuadamente en los objetivos estratégicos de la empresa. Ambos lados reconocen el problema. Pero rara vez construyen el puente juntos, y antes de que empiece el piloto.

El diagnóstico real: la innovación sin arquitectura no escala

La raíz del problema no es tecnológica. Es estructural y cultural.

McKinsey identificó que las empresas que invierten en el cambio cultural tienen 5,3 veces más probabilidades de éxito en sus transformaciones que aquellas que se enfocan solo en la tecnología. La cultura, más que la herramienta, determina si la innovación se vuelve producto o se vuelve descarte.

En el contexto específico del conflicto CTO-CIO, esto significa que la innovación debe diseñarse para la empresa real, no para el laboratorio ideal. Tres cambios concretos marcan la diferencia:

• El CIO debe entrar en el proceso de innovación antes, no después. No como revisor de lo que construyó el CTO, sino como ingeniero de las restricciones y posibilidades del mundo real. La arquitectura y la escalabilidad operativa no son etapas de validación, son variables de diseño. Cuando esa premisa no se incorpora desde el inicio del piloto, termina inevitablemente convirtiéndose en el obstáculo que aborta el proyecto.
• Las métricas de innovación deben incluir la viabilidad operativa desde la línea de salida. ¿Cuántas de las pruebas de concepto aprobadas llegan a producción? Ese índice de conversión —del piloto a la operación— es el dato que separa a los programas de innovación que realmente transforman empresas de los que acumulan trofeos de hackathon.
• Y quizás el punto más desatendido de todos: la innovación necesita un dueño en el negocio, no solo en la tecnología. Las iniciativas que quedan confinadas a laboratorios o equipos de TI tienden a estancarse por falta de tracción organizacional. Cuando los líderes de negocio definen el valor esperado, los KPIs y el modelo de adopción operativa desde el principio, la probabilidad de que el piloto se convierta en una solución real aumenta de manera sustancial. Innovación sin patrocinio del negocio es un proyecto de TI. Innovación con patrocinio del negocio es transformación.

Michael Porter ya decía que la eficiencia operativa no es estrategia. Del mismo modo, un laboratorio de innovación no es transformación. La innovación que no encuentra camino hacia la operación real es apenas un costo sofisticado.

El eslabón perdido: el bridger

Incluso cuando las tres condiciones anteriores están presentes —el CIO involucrado desde el inicio, las métricas de conversión establecidas y el patrocinio del negocio garantizado— sigue existiendo una brecha con frecuencia invisible: ¿quién, en la práctica, construye y mantiene los puentes entre estos mundos en el día a día del proyecto?

La edición de marzo/abril de 2026 de Harvard Business Review trae una respuesta directa. En el artículo “Por qué las grandes innovaciones fracasan al escalar”, Linda Hill (profesora de Harvard Business School y una de las mayores autoridades en liderazgo de innovación) y sus coautores identifican el principal factor diferenciador entre las organizaciones que escalan la innovación y las que acumulan pilotos. No es la tecnología. No es el presupuesto. Es un tipo específico de liderazgo que ellos llaman bridging: la capacidad de colaborar de manera efectiva a través de las fronteras organizacionales.

“Ningún equipo o empresa por sí solo tiene todas las capacidades, herramientas o autoridad necesarias para mover las ideas del prototipo a la escala.”

Los bridgers, como los define Hill, son líderes con suficiente inteligencia emocional y contextual para construir confianza mutua, traducir entre mundos con lógicas distintas e integrar los esfuerzos de socios con agendas a menudo en conflicto. No lo hacen mediante la autoridad jerárquica. Lo hacen mediante la relación, la credibilidad y una rara capacidad de hacer que cada parte sienta que sus intereses están siendo considerados.

En el contexto del conflicto CTO-CIO, el bridger es el ejecutivo que logra sentarse a la vez con el equipo de innovación y con el equipo de arquitectura, y ser tomado en serio por ambos. Habla la lengua de lo posible con el CTO y la lengua de lo sostenible con el CIO. No minimiza las restricciones operativas como burocracia ni descarta las ambiciones innovadoras como ingenuidad. Transforma la tensión entre esas perspectivas en diseño.

El caso de Delta Air Lines ilustra bien lo que está en juego. Nicole Jones, que construyó y lideró The Hangar, el primer laboratorio global de innovación de Delta, enfrentó exactamente el problema de la integración entre innovación y operación. Cuando su equipo desarrolló una tecnología de embarque biométrico que exigía la coordinación de startups, equipos internos de TI y agencias federales como la TSA, las tensiones eran inevitables: el equipo de TI de Delta tenía una profunda aversión al riesgo tras una costosa caída del sistema el año anterior. Jones no lo resolvió con autoridad formal. Lo resolvió recordándoles constantemente a todos cuál era la ambición compartida —mejorar la experiencia de millones de pasajeros— y haciendo explícito para cada parte cómo eso se conectaba con sus propias prioridades. Aquel año, Delta fue la primera gran aerolínea en debutar en el Consumer Electronics Show.

Lo que vuelve al concepto de bridger especialmente relevante para el contexto de las empresas no-tech es que no exige la creación de un nuevo cargo en el organigrama. Es una competencia, y una que puede cultivarse de forma deliberada. Hill y sus coautores identifican que las organizaciones que colocan bridgers en posiciones clave de innovación no solo escalan más rápido: crean un entorno donde la confianza entre los equipos que necesitan colaborar se convierte en un activo permanente, y no en una conquista frágil que hay que reconstruir en cada nuevo proyecto.

En resumen: la arquitectura resuelve el problema técnico de la escalabilidad. El patrocinio del negocio resuelve el problema de la relevancia estratégica. Y el bridger resuelve el problema humano: lograr que personas con agendas, incentivos y lenguajes diferentes trabajen juntas hacia un objetivo que todavía no existe.

El equilibrio que marca la diferencia

El futuro de las empresas que compiten en un entorno de intensa transformación tecnológica no depende solo de quién lidera la tecnología. Depende de cómo estos roles trabajan juntos y, sobre todo, de cuándo y cómo inician esa conversación.

El CTO debe explorar lo que es posible. El CIO debe garantizar que lo posible sea sostenible. El negocio debe garantizar que lo sostenible sea también deseado, con metas claras, KPIs definidos y un compromiso real con la adopción. Y el bridger debe garantizar que estas tres perspectivas se encuentren en el momento adecuado, antes de que los silos organizacionales conviertan la divergencia natural en un conflicto paralizante.

Cuando este cuadrilátero funciona, la innovación deja de ser un laboratorio caro y se convierte en una ventaja competitiva real. Cuando no funciona —cuando el CTO construye en el vacío, el CIO rechaza al final, el negocio no asume la responsabilidad y no hay nadie construyendo el puente— lo que debería ser transformación se convierte en apenas una línea más de costo en el balance.

Enterrada en el cementerio silencioso de las buenas ideas que nadie logró escalar.

---

Nota del autor

No podía dejar de citar el artículo de Linda A. Hill en esta edición de Harvard Business Review. Linda fue mi profesora en el Harvard Program for Leadership Development (HPLP) —una de las experiencias más transformadoras de mi trayectoria— y cruzarme con esta edición en el aeropuerto camino al SXSW 2026, mientras escribía este mismo artículo, retomó precisamente su tema central. Fue una de las coincidencias más felices que este proyecto me ha dado. El concepto de bridging que ella y sus coautores desarrollan en “Why Great Innovations Fail to Scale” es, a mi juicio, una de las contribuciones más urgentes al debate sobre liderazgo de innovación de los últimos años.

Fuentes

• HILL, Linda A.; TEDARDS, Emily; WILD, Jason. Why Great Innovations Fail to Scale. Harvard Business Review, Boston, mar./abr. 2026, pp. 74–85. [Adaptado del libro Genius at Scale. Harvard Business Review Press, mar. 2026.]
• McKINSEY & COMPANY. Losing from day one: Why even successful transformations fall short. McKinsey Quarterly, dic. 2021.
• McKINSEY & COMPANY. The state of achieving digital value at scale. McKinsey Digital, 2022.
• GARTNER. Digital business scaling survey. Gartner Research, 2021.
• BAIN & COMPANY. Making transformation work: Lessons from 1,000+ programs. Bain Insights, 2024.
• DELOITTE. 2023 Global Technology Leadership Study. Deloitte Insights, 2023.
• MIT SLOAN MANAGEMENT REVIEW. The evolving role of the CIO. MIT Sloan Management Review, Cambridge, 2022.
• HARVARD BUSINESS REVIEW ANALYTIC SERVICES. Closing the IT-business strategy gap. Harvard Business Review, Boston, 2022.
• JAYADEV, Satya. Declaraciones sobre el desafío de escalar la innovación. En: CIO Executive Council Forums, 2022.
• SAP SE; OXFORD ECONOMICS. The Value of AI with SAP. Oxford Economics, oct. 2025. Disponible en: sap.com/documents. Acceso: mar. 2026.
• SAP NEWS CENTER. Cirque du Soleil Entertainment Group implements AI-enabled invoice assistant. SAP SE, Walldorf, oct. 2025. Disponible en: news.sap.com. Acceso: mar. 2026.
• SAP APPHAUS NETWORK. Cirque du Soleil’s Leap into the Future through RISE with SAP. SAP AppHaus, 2025. Disponible en: apphaus.sap.com. Acceso: mar. 2026.
• FREITAS, Fernando. Declaraciones sobre el proceso de innovación en Bradesco/inovabra. En: Foro Brasileño de Innovación Corporativa, São Paulo, 2022.
• PORTER, Michael E. What is strategy? Harvard Business Review, Boston, nov./dic. 1996.