Aunque suene contraintuitivo, muchas de las iniciativas creadas explícitamente para “innovar” terminan profundizando los problemas que buscan resolver. La innovación no suele fallar, sino lo que falla es que estas iniciativas suelen intervenir en el lugar equivocado de la organización.
En los últimos años, numerosas empresas intentaron acelerar su transformación digital mediante la creación de unidades especializadas: laboratorios de innovación, hubs de inteligencia artificial (IA) o equipos de transformación. Muy probablemente algo similar ocurrió en tu organización. Frente a un entorno cada vez más incierto y competitivo, la dirección decidió responder creando un área dedicada exclusivamente a “innovar”.
La lógica parecía sólida: aislar a ese equipo de la inercia operativa, darle libertad para pensar distinto y moverse más rápido que el resto de la empresa. Sin embargo, este intento por acelerar el cambio rara vez produjo el impacto estructural esperado.
Durante meses, estos equipos generan propuestas, desarrollan prototipos y lanzan pilotos. Y algunos funcionan, al menos en condiciones controladas: mejoran un proceso, automatizan una tarea, abren una posibilidad nueva.
El problema aparece cuando llega el momento de escalar.
El piloto exitoso se presenta al negocio principal y, de forma predecible, algo falla. Surgen problemas de integración, los procesos existentes no encajan, las personas clave no adoptan la solución y el costo de escalar resulta mayor de lo previsto. Al final, el proyecto se archiva o se implementa de forma tan limitada que su impacto es marginal.
Tiempo después, la organización concluye que “la iniciativa no era viable” o que “el equipo no entendió el negocio real”. Pero rara vez se formula la pregunta que realmente importa: ¿y si el problema no es el piloto, sino la forma en que estamos intentando cambiar?
Los números que evidencian el problema sistémico
Este patrón no es una anécdota aislada. Los datos de 2025 muestran que le pasa a muchas empresas que intentan innovar. En el área de inteligencia artificial (IA), por ejemplo, el 46% de las pruebas de concepto se abandonan antes de llegar a producción, según la encuesta Voice of the Enterprise de S&P Global Market Intelligence, que analizó organizaciones en Norteamérica y Europa.
Este porcentaje representa un aumento dramático: en 2024, solo el 17% de las empresas abandonaban la mayoría de sus iniciativas de IA, mientras que en 2025, esa cifra saltó al 42%.
El informe del MIT Media Lab, The GenAI Divide: State of AI in Business 2025, va más allá. Después de analizar 300 implementaciones públicas, realizar 52 entrevistas estructuradas con líderes organizacionales y encuestar a 153 ejecutivos senior, la conclusión es que el 95% de los pilotos de IA generativa no logran impactar la rentabilidad del negocio. A pesar de que las empresas invirtieron entre 30 y 40 mil millones de dólares en esta tecnología, el 95% de las organizaciones no reporta ningún retorno medible.
¿Qué está pasando? que el funcionamiento de estos pilotos no opera con una lógica que el sistema principal de la organización no comparte. Y cuando intentan escalar, se encuentran con un sistema perfectamente diseñado para rechazarlos.
Por qué los departamentos aislados intervienen en el lugar equivocado
Para entender por qué este patrón se repite con tanta frecuencia, vale la pena recurrir al trabajo de Donella Meadows, una científica de sistemas que dedicó décadas a estudiar cómo funcionan los sistemas complejos, desde ecosistemas y economías hasta organizaciones.
En su ensayo Leverage Points: Places to Intervene in a System, Meadows explica que en cualquier sistema existen distintos puntos donde es posible intervenir, pero no todos tienen el mismo impacto. A estos lugares los llamó leverage points, que podríamos traducir como palancas de cambio, los cuales son puntos donde una intervención pequeña puede generar efectos desproporcionadamente grandes en el comportamiento del sistema.
Los puntos de menor impacto —los que están al final de su lista— son los parámetros: presupuestos, metas numéricas, estructuras formales, número de personas asignadas. Son visibles, fáciles de modificar y políticamente “seguros”. Por eso concentramos ahí casi toda nuestra atención.
El problema es que, como advertía Meadows, “probablemente el 99% de nuestra atención va a los parámetros, pero ahí casi no hay capacidad real de cambio”. Es, decir, que ajustar números rara vez cambia el comportamiento del sistema, y si este está diseñado para resistirse a cierto tipo de cambios, aumentar el presupuesto o crear un nuevo equipo no va a alterar esa lógica de fondo.
En contraparte, los puntos que producen un mayor cambio están mucho más arriba en la lista y son menos evidentes: las reglas bajo las cuales se toman decisiones, los incentivos que guían el comportamiento cotidiano, los criterios reales de éxito, la distribución del poder y, sobre todo, las creencias profundas sobre qué es valioso, qué riesgos son aceptables y qué tipo de resultados importan.
Aquí aparece el problema estructural de los departamentos de innovación aislados, que casi siempre intervienen en el nivel más bajo del sistema. Se les asigna un presupuesto propio, se les definen métricas distintas y se les concede permiso para experimentar y fallar, y el resultado es que los pilotos que producen generan un choque entre dos lógicas incompatibles: una orientada al aprendizaje y la exploración –la de estos departamentos–, y otra optimizada para estabilidad, control y eficiencia de corto plazo, que es la del sistema.
Por qué separar la innovación del negocio no resuelve la tensión de fondo
La razón por la que los departamentos de innovación aislados fallan de forma tan consistente fue descrita hace más de tres décadas por James March, uno de los teóricos clave del aprendizaje organizacional. En su artículo de 1991, Exploration and Exploitation in Organizational Learning, March explicó que toda organización vive una tensión permanente entre dos tipos de actividades que compiten por los mismos recursos y la misma atención.
Por un lado, la exploración, la cual lleva a experimentar, aprender bajo incertidumbre y asumir el riesgo de equivocarse. Por el otro, la explotación, la cual busca perfeccionar lo que ya funciona, estandarizar procesos y operar con eficiencia. Ambas son necesarias, pero operan con lógicas distintas, y por diseño, las organizaciones tienden a optimizar la explotación, porque es la que garantiza estabilidad, resultados predecibles en el corto plazo y sobre todo, dinero de la forma más inmediata.
El problema aparece cuando la exploración se intenta resolver creando un espacio separado, como un departamento de innovación. Con ello, la organización no elimina la tensión entre explorar y explotar, simplemente la desplaza. Dentro del departamento, la exploración es posible. Fuera de él, el sistema principal sigue operando con las mismas reglas, incentivos y criterios de éxito.
Cuando los resultados de esa exploración intentan integrarse al negocio, el conflicto se vuelve inevitable. Los pilotos requieren flexibilidad, iteración y decisiones basadas en aprendizaje, pero el sistema principal exige planes cerrados, estabilidad operativa y retorno inmediato. Y como ambos responden a objetivos distintos, los pilotos no escalan y terminan muriendo.
Dónde se manifiesta esto en decisiones reales de gestión
Esta tensión entre exploración y explotación se vuelve visible en decisiones muy concretas: cómo se gasta el dinero, cómo se asignan recursos y bajo qué criterios se decide si algo “funcionó” o no. Uno de sus primeros efectos es la duplicación de inversiones sin un retorno claro, porque la exploración se financia en espacios aislados –como lo son los laboratorios de innovación– sin que el negocio modifique las condiciones necesarias para absorber sus resultados.
En inteligencia artificial este patrón es claro. sin integración al sistema operativo del negocio, incluso proyectos técnicamente viables se quedan en fase experimental.
El mismo patrón aparece al intentar escalar. Un piloto puede funcionar con diez usuarios y colapsar al extenderse a mil, porque escalar no es replicar, sino que implica modificar el sistema que lo recibe. Infraestructura, procesos, incentivos y criterios de evaluación deben cambiar para absorber la nueva solución. Cuando eso no ocurre, el piloto encuentra resistencia estructural en cada punto de contacto con la organización.
A esto se suma una desconexión profunda entre cómo se evalúa al departamento de innovación y cómo se evalúa al negocio. Mientras los equipos de innovación reportan ideas, pilotos o visibilidad externa, el negocio se mide por rentabilidad, eficiencia y crecimiento. Así, es posible que la innovación “tenga éxito” en sus métricas sin que el negocio perciba impacto real. Y cuando llega el momento de asignar más recursos, la justificación financiera simplemente no existe.
Así que mientras la exploración siga confinada a espacios separados y la explotación gobierne todas las decisiones relevantes del negocio, los pilotos seguirán muriendo al intentar escalar.
La pregunta clave, entonces, no es cómo hacer departamentos de innovación más sofisticados ni cómo lanzar más pilotos, sino qué tendría que cambiar en las reglas, los incentivos y los criterios de éxito del negocio para que innovar deje de ser una excepción tolerada y se convierta en una capacidad organizacional real.
