Hay una escena que se repite en startups de todo el mundo: el CEO vuelve de una conferencia con la cabeza llena de posibilidades, lanza un mandato de IA con plazos y métricas, y a las dos semanas los ingenieros, diseñadores y analistas lo están ignorando activamente o usando las herramientas a regañadientes. El ejecutivo concluye que hay “resistencia al cambio”. El equipo concluye que el ejecutivo no entiende el trabajo real. Los dos tienen razón, pero por razones distintas a las que creen.
La brecha en la adopción de IA no es cultural ni generacional. Es estructural. Y hasta que las startups no entiendan por qué, seguirán empujando iniciativas que se atascan en el mismo punto.
El mundo no determinista de los ejecutivos
Un ejecutivo gestiona sistemas caóticos por definición. Personas que se enferman sin avisar, proyectos que se atasan sin que nadie lo diga hasta que es tarde, equipos que interpretan los objetivos de maneras inesperadas. Su trabajo consiste en crear modelos del mundo que funcionen a pesar de la incertidumbre, no gracias a su eliminación.
Aprende IA con nosotros
Únete gratis a mi comunidad en Skool, donde compartimos noticias, tutoriales y recursos para seguir aprendiendo juntos.
👥 Únete gratis 🚀Desde esa perspectiva, la IA encaja perfectamente. Un LLM responde a cualquier hora, con cualquier nivel de dificultad, sin pedir contexto emocional ni reuniones de alineación. Sus fallas son predecibles: alucina en áreas específicas, falla fuera de su contexto, se deteriora con instrucciones vagas. Eso es exactamente lo que un manager entrenado necesita: un sistema no determinista con modos de falla conocidos. Es más manejable que la mayoría de las personas.
John J. Wang, ingeniero de producto y autor del post que generó la conversación original, lo articula con precisión: los ejecutivos llevan décadas construyendo sistemas con variables humanas impredecibles, por lo que la IA no les genera ansiedad. Ya saben operar en ese terreno. Lo que ven es capacidad adicional con estructura razonable.
El mundo determinista de los ICs
Los contribuidores individuales —ingenieros, diseñadores, analistas, escritores técnicos— operan en un universo diferente. Un bug tiene una causa específica y una solución correcta. Un análisis de datos está bien o está mal. Un diseño funciona o no funciona en los escenarios definidos. El valor de un IC se mide, en gran parte, por su capacidad de producir outputs precisos y confiables en problemas bien definidos.
Cuando entra la IA, hay tres fricciones simultáneas:
Primero, en muchas tareas especializadas, el IC simplemente es mejor que el modelo. Un ingeniero senior revisando código propio en un sistema que conoce profundamente producirá un análisis más fino que GPT-5 con contexto limitado. Si corregir los errores del modelo tarda más que haberlo hecho directamente, el “ahorro” es ilusorio.
Segundo, la IA cambia la naturaleza del trabajo. El IC deja de hacer el trabajo y pasa a gestionar al que lo hace. Eso requiere un conjunto de habilidades distinto al que lo llevó a ser bueno en su rol actual. Es un cambio de identidad profesional disfrazado de mejora de herramienta.
Tercero, y quizás lo más profundo: si el trabajo representa la mayoría de las horas activas de una persona, y sus habilidades técnicas son parte central de cómo entiende su valor, escuchar que “la IA multiplicará tu productividad” puede sonar exactamente como “lo que llevas años perfeccionando va a importar menos”. Eso no es irracionalidad: es una lectura razonable de la situación.
Por qué los mandatos top-down fallan
El problema no es que los ICs no quieran usar IA. De hecho, en startups latinoamericanas el 99% ya la usa en algún nivel —pero hay una diferencia enorme entre usar ChatGPT para redactar un correo y integrar agentes en el flujo crítico de desarrollo o análisis. La adopción superficial no genera los beneficios que proyectan los ejecutivos, y esa brecha entre expectativa y resultado alimenta el ciclo de desconfianza.
El patrón que sí funciona: las organizaciones que priorizan velocidad sobre calidad perfecta ven mayor adopción entre ICs, porque el costo de los errores del modelo es bajo. Startups en modo early-stage que necesitan iterar rápido, por ejemplo. Las organizaciones que priorizan calidad técnica alta ven resistencia proporcional, porque los errores del modelo sí tienen costo real.
Esto explica un dato que suena paradójico: el 73% de las personas confía en la IA que usa personalmente, pero solo el 11% confía en la IA que implementa su empresa. La IA que el IC elige para sus propias tareas encaja con sus necesidades reales. La IA mandatada desde arriba puede no encajar con las suyas.
Las implicaciones para founders
Si estás construyendo o liderando una startup y quieres una adopción de IA que realmente mueva métricas, hay tres lecturas prácticas de este análisis:
La autonomía de adopción importa más que el mandato. Los ICs que eligen sus propias herramientas de IA tienen tasas de adopción real mucho más altas que los que reciben sistemas impuestos. El rol del liderazgo es crear el espacio y los recursos, no el proceso obligatorio.
Los casos de uso correctos son los determinantes. No tiene sentido forzar IA en tareas donde la precisión del IC supera claramente a la del modelo. El ROI real viene de tareas donde la no determinismo no es un problema: documentación, primeros borradores, análisis exploratorio, síntesis de información, código repetitivo y bien especificado. Forzar IA en revisión de código crítico en sistemas legacy complejos genera frustración sin retorno.
El cambio de identidad profesional necesita tiempo y reconocimiento. Si el mensaje implícito es “ahora eres un prompt engineer en vez de un ingeniero”, habrá resistencia aunque nadie lo diga en voz alta. Las empresas que tienen mayor éxito en la transición son las que reconocen explícitamente las habilidades técnicas de sus ICs como el activo que hace que la IA genere resultados de calidad, no como lo que será reemplazado.
El problema más profundo que nadie nombra
Hay una tensión que va más allá del management de cambio: el 80% de las empresas prueba la IA, pero muy pocas escalan. Y una parte importante de ese estancamiento viene exactamente de este desalineamiento estructural: los ejecutivos que aprueban los presupuestos y definen métricas de éxito no entienden desde dónde operan los ICs. Los ICs que deben implementar no entienden qué problema están resolviendo para el negocio.
La IA no va a arreglar esa brecha comunicacional. Puede agrandarla si se usa como sustituto de conversaciones organizacionales que todavía no se han tenido.
La pregunta que los founders deberían hacerse no es “¿cómo logro que mi equipo adopte IA?” sino “¿qué tareas específicas tienen la combinación correcta de escala, tolerancia al error y costo del error para que la IA agregue valor neto sin generar fricción extra?” Esa pregunta es mucho más difícil. También es la única que importa.
