5 patrones comunes que provocan fracasos en la IA
Descubre las causas habituales de los fracasos en la adopción de la IA y cómo los líderes tecnológicos pueden mejorar los resultados mediante un mejor contexto, comunicación y toma de decisiones.
Adam Horner
Fundador de The CTO Playbook
Desafíos del CTO: Los CTO se enfrentan a desafíos comunes en la integración de la IA, lo que requiere liderar transformaciones organizacionales significativas.
Impacto de la IA: La IA cambia el alcance del trabajo de ingeniería, potenciando la toma de decisiones más allá de la simple resolución técnica de problemas.
Ciclo de triaje de IA: La IA optimiza los ciclos de triaje y solución de problemas, reduciendo retrasos en el soporte al cliente y mejorando el enfoque del equipo.
Riesgos de Uso: El uso incontrolado de herramientas de IA puede aumentar los riesgos de datos; las organizaciones deben gestionar la política y supervisión de IA.
Equipos Pequeños: La IA transforma la dinámica del equipo, permitiendo que equipos más pequeños trabajen eficientemente con desarrollo asistido por IA.
Adam Horner ha formado equipos de ingeniería en fintech y software empresarial. Ahora es fundador de The CTO Playbook, donde educa y trabaja como CTO fraccional.
Nos sentamos con él para conocer los patrones que observa detrás de los éxitos y fracasos en la integración de la IA. Esto es lo que nos contó.
Alguna versión del mismo desafío
Soy Adam Horner, coach de CTOs y CTO fraccional en The CTO Playbook. Pasé la primera parte de mi carrera como ingeniero y CTO cofundador, formando y liderando equipos de ingeniería en fintech y software empresarial, incluyendo varios años en Palantir como uno de sus primeros empleados en el Reino Unido.
¿Quieres más de The CTO Club?
Crea una cuenta gratuita para terminar de leer este contenido y unirte a una comunidad de CTOs y líderes de ingeniería que comparten marcos, herramientas y conocimientos reales para diseñar, desplegar y escalar tecnología impulsada por IA.
Have an account? Log In
Mi paso a la mentoría surgió de una observación simple: Convertirse en un ejecutivo tecnológico efectivo es realmente complicado, y la mayoría lo enfrenta sin una hoja de ruta ni alguien en su esquina que haya pasado por ello. Ese es mi trabajo ahora, ayudar a CTOs a cruzar lo que llamo el "abismo del CTO".
El enfoque de la IA, para mí, no es un hilo separado. Atraviesa casi todas las conversaciones de mentoría que tengo, porque cada CTO con el que trabajo está navegando alguna versión del mismo desafío: ¿Cómo liderar una organización a través de una transformación de esta magnitud, en tu etapa específica, con tu equipo concreto, y salir fortalecido como negocio?
La compleja mitad de la curva de crecimiento
Mi organización es pequeña y deliberadamente ágil, un equipo fundador de cuatro que construye priorizando la IA desde el inicio, donde utilizamos esa experiencia para mantenernos cerca de las realidades del desarrollo de producto en etapas tempranas. También trabajo como CTO fraccional en una startup fintech previa a la acreditación, enfrentando las presiones particulares de llevar un producto regulado al mercado con un equipo externo de desarrollo.
Pero la visión más amplia, y de donde proviene la verdadera profundidad en la exposición organizacional, está en los CTOs a los que asesoro. Ese espectro va desde equipos fundadores y startups autofinanciadas tempranas, pasando por scaleups en rápido crecimiento con respaldo de capital de riesgo o capital privado, hasta empresas de tamaño medio manejando complejidad organizativa real, y grandes compañías con varios departamentos operando a escala.
La mitad compleja de la curva de crecimiento es donde paso la mayor parte de mi tiempo, y también donde los desafíos de liderazgo suelen ser más agudos.
Cómo la IA permite a los ingenieros ver el panorama general
Para mí, el cambio más significativo no ha sido una herramienta ni un proceso; ha sido una expectativa. Como líder, cuando das permiso al equipo —y más importante aún, la obligación— de replantearse todo el ciclo de entrega desde cero, el alcance de esa revisión importa. No solo cómo se escribe o se despliega el código, sino todo lo que toca el proceso de entrega: atención al cliente, valor para el usuario y la intención del negocio detrás de cada tarea.
Cuando el costo de escribir y mantener código era alto, mantener a los ingenieros concentrados únicamente en el problema técnico tenía cierto sentido. Pero ese costo se ha desplomado. El factor limitante ya no es la velocidad de desarrollo, sino qué tan claramente todos los involucrados entienden qué vale realmente la pena construir y por qué.
Los ingenieros que comprenden el producto, el cliente y los objetivos empresariales detrás de un cambio pueden tomar decisiones y avanzar de formas que antes simplemente no eran posibles. Lo que mejoró no fue una métrica. Fue la calidad de las preguntas que el equipo comenzó a plantear antes de escribir una sola línea.
Cómo los ciclos de triage y resolución pueden comprimirse con IA
Un ejemplo fue replantear cómo interactuaban soporte al cliente e ingeniería en torno a los bugs confirmados. Previamente, los ciclos de triage y resolución se medían en días o semanas, con los equipos de soporte gestionando clientes frustrados y los ingenieros asumiendo el coste de la distracción de incidencias en vivo además de su trabajo habitual. Cuando el ciclo de entrega se revaluó con el desarrollo asistido por IA en juego, los ciclos de resolución se comprimieron drásticamente y buena parte del proceso se automatizó.
Esto trasladó más trabajo a la función de soporte al inicio, obligando a capturar y categorizar los problemas de manera clara, pero la recompensa fue una resolución en horas en lugar de días. Los ingenieros permanecieron concentrados. Los clientes recibieron respuestas más rápido. La interfaz entre dos funciones que siempre se consideró lenta, resultó ser completamente renegociable.
Por qué las organizaciones no deben aplicar la IA a todo
En cuanto a qué tareas deberían ser humanas y cuáles para la IA, varía en cada organización. El punto de partida correcto no es una lista de actividades, sino una comprensión clara de dónde reside tu valor y dónde se concentra tu riesgo.
Las partes del proceso que son el núcleo de lo que hace el negocio —la lógica, la diferenciación, las áreas donde el fracaso es visible o costoso— merecen generación y supervisión humana. Todo lo demás se sitúa en un espectro.
Una empresa de ciberseguridad pondrá una atención humana significativa en las propiedades de seguridad de su código, porque esa es la esencia del negocio. Una empresa de automatización de flujos de trabajo puede centrar ese mismo nivel de análisis en la lógica de toma de decisiones dentro de un flujo crítico, mientras que considera que las herramientas de seguridad son algo que la IA puede gestionar adecuadamente.
Lo que está mal es aplicar una política general en cualquier dirección. La pregunta que hay que hacerse no es “¿Puede la IA hacer esto?”, sino “¿Cuál es el coste si esto sale mal?”
Y otra cosa: una sorprendente cantidad de la complejidad que las personas quieren automatizar es en realidad deuda de proceso no resuelta. Ordena eso primero. Esto hará que adoptar la IA sea más sencillo y barato más adelante.
Por qué los CTO deben empezar automatizando la entrega, no el código
Es realmente difícil comparar los resultados de IA entre organizaciones porque la mayoría de los líderes, tanto en tecnología como en el negocio en general, aún están luchando por medir el impacto y el ROI de sus inversiones en IA con claridad. Sin eso, es difícil saber cómo se ve el éxito realmente, y aún más difícil justificar hacer más en ese sentido.
Pero en general, el rango de resultados con IA es amplio. En un extremo, he trabajado con organizaciones que han eliminado efectivamente su backlog y ahora trabajan directamente orientadas al valor para el cliente y la intención del negocio, lo que representa un cambio fundamental en cómo la ingeniería se relaciona con el resto de la empresa.
Noté un patrón común en las organizaciones que lograron esto: ninguna comenzó por el extremo izquierdo del ciclo de desarrollo de software. No empezaron con la generación de código. Comenzaron por la derecha: pipelines CI/CD, confianza en los despliegues, revisión automática de código. Lograr que el extremo de entrega del proceso fuera robusto y confiable primero fue lo que creó las condiciones para todo lo demás. Desde ahí, la atención se desplazó a las pruebas, restricciones y comprobaciones previas a la generación, y a la estructura por encima de la velocidad.
Los equipos que más avanzaron fueron los que operaban de manera más autónoma, no porque hubieran eliminado el juicio humano, sino porque habían codificado lo suficiente en el proceso como para abordar grandes bloques de trabajo con confianza. El backlog no desapareció porque escribieran código más rápido. Desapareció porque toda la relación entre intención y entrega se volvió inequívoca.
En el otro extremo, he visto una verdadera pérdida de talento impulsada por la creciente brecha entre quienes avanzan rápido con IA y quienes no. Cuando empieza la adopción de IA, casi siempre hay un grupo pequeño que avanza rápido y otro más grande que no, y el instinto natural es dejar correr a los rápidos. Pero eso crea, de forma silenciosa y rápida, fricción, desconfianza y sospecha entre equipos, erosionando los logros antes de que los avances iniciales puedan acumularse. El consejo que doy ahora al inicio de cada proyecto es el mismo: no dejes a nadie atrás. El ritmo de adopción debe marcarlo la rapidez con la que puedes llevar a toda la organización contigo, no la velocidad individual de tus ingenieros más entusiastas.
Una organización a dos velocidades parece un avance desde el frente. Desde atrás, se siente como quedarse rezagado, y ese sentimiento tiene consecuencias.
Cuando comienza la adopción de la IA, casi siempre hay un pequeño grupo que avanza rápido y un grupo más grande que no, y el instinto natural es dejar que los que se mueven rápido continúen. Lo que eso genera, silenciosa y rápidamente, es fricción, desconfianza y sospecha entre los equipos, lo que erosiona los avances más rápido de lo que el progreso inicial puede acumularlos.
Por qué la base de conocimientos de una organización debe ser rediseñada para la IA
La brecha más clara que he visto en las capacidades de la IA es en la toma de decisiones bajo incertidumbre.
La IA es fundamentalmente un motor de predicción, y predecir no es lo mismo que juzgar. No tiene intereses personales, ni sentido de las consecuencias, ni responsabilidad sobre los resultados. Esperar que tome decisiones en tu nombre solo será tan efectivo como su capacidad de predecir, que en situaciones genuinamente inciertas o novedosas es limitada. Las organizaciones que más se han decepcionado con la IA suelen ser aquellas que han dependido de ella precisamente en esos momentos.
El otro ámbito donde el impacto se queda corto, de forma más silenciosa pero igual de significativa, es cuando no se comprenden adecuadamente las implicaciones de las ventanas de contexto. Si le das a una IA un contexto incompleto o mal estructurado, igualmente te dará una respuesta segura. Saber distinguir entre una respuesta bien fundamentada y una que solo suena plausible requiere de juicio humano, algo que muchos equipos aún no han desarrollado.
Por eso, la base de conocimientos de una organización es fundamental. Con esto me refiero a todo ese contexto que actualmente vive en la cabeza de las personas: la forma en que siempre se han hecho las cosas, los enfoques por defecto, las reglas no escritas sobre cómo realmente funciona la organización. La IA no puede trabajar con conocimiento institucional que nunca se ha externalizado, y la mayoría de las organizaciones acumulan una gran cantidad de este conocimiento.
La buena noticia es que sacarlo a la luz no requiere que esté perfectamente estructurado. Gracias a la IA multimodal, una grabación en video, un diagrama preliminar y un documento sin editar son insumos valiosos. La prioridad es primero externalizar, luego estructurar.
Lo que encuentro de manera constante es que el acto de sacar este contexto de la cabeza de las personas y plasmarlo en cualquier tipo de documentación ya es valioso en sí mismo, incluso antes de que la IA lo procese. Saca a la superficie discrepancias, expone suposiciones erróneas y revela flujos de trabajo rotos que nadie había notado porque estaban demasiado inmersos en ellos.
Esa base, entonces, multiplica todo lo que la IA pueda hacer después. Es una de las acciones con mayor impacto en las que un CTO puede invertir tiempo ahora mismo, y una de las más sistemáticamente ignoradas, ¡a pesar de que los vendedores de Automatización de Procesos de Negocio llevan diciéndonos esto durante años!
Cómo evitar que los desarrolladores escépticos ralenticen a una organización
Un problema común que observo no es realmente un fallo de la IA. Es un fallo de adopción, y generalmente sigue un patrón reconocible.
Un desarrollador escéptico —y hay sorprendentemente muchos— hace un intento a medias con poco contexto, obtiene un mal resultado y presenta ese resultado como evidencia de que la IA no puede hacer el trabajo. La conclusión se expone con seguridad. Rara vez se examina la metodología. Lo que hace que esto sea más que una simple frustración individual es el efecto en cadena.
La integración de la IA en un equipo o en el ciclo de vida del desarrollo es un trabajo en equipo, y unos pocos ingenieros motivados para demostrar que no funciona pueden ralentizar a toda la organización, no solo a su propia producción.
La lección que extraigo de esto no trata sobre las limitaciones de la IA. Es que la adopción es tanto un reto de liderazgo como uno técnico. La calidad de lo que produce la IA es inseparable de la calidad del contexto y de la intención que le aportas, y construir ese entendimiento en todo el equipo requiere el mismo esfuerzo deliberado que cualquier otro cambio significativo en la forma de trabajar. Así es como pasamos de percibir la "magia defectuosa" a utilizar una "tecnología avanzada" funcional.
Por qué los equipos pequeños son una ventaja con la IA
La suposición de que un equipo de ingeniería funcional y productivo necesitaba un cierto número de integrantes para acumular suficiente contexto y avanzar a un ritmo significativo no ha sobrevivido al contacto con la forma en que funciona realmente el desarrollo asistido por IA.
El factor limitante en cualquier equipo siempre ha sido cognitivo: cuánta información puede retener cada persona, cuán claramente puede comunicarla a quienes la rodean y cuánta energía consume esa comunicación. Lo que ha cambiado es que la unidad que realiza el trabajo ya no es solo una persona. Cada integrante del equipo ejecuta varios agentes, y esos agentes transportan y aplican contexto de formas que cambian completamente la ecuación. La regla de las dos pizzas de Amazon era una heurística razonable para un mundo anterior a la IA.
He aquí un ejemplo.
En una organización con la que trabajo, siempre habían querido una interfaz interna de administración para su plataforma, pero nunca lograron justificar la inversión. Anteriormente la habían calculado como un esfuerzo de varios meses para todo el equipo. En su lugar, pusieron a dos personas a cargo: ambas con profundo conocimiento del negocio y de la plataforma existente, alta autonomía y un conjunto claro de restricciones dentro de las cuales trabajar. Seis semanas después, tenían una primera versión funcional.
La familiaridad que tenían esas dos personas con el negocio resultó ser tan importante como las herramientas de IA. Menos preguntas, menos sobrecarga, decisiones más rápidas. Pero el resultado más valioso no fue la herramienta en sí. Fue lo que la organización aprendió sobre cómo trabajar de esta manera.
Los equipos que veo operar con mayor eficacia ahora tienen entre dos y tres personas, cada una ejecutando múltiples agentes, y eso no es una limitación. Para el tipo de trabajo adecuado, es una ventaja.
Por qué la comunicación frecuente es crucial en los flujos de trabajo potenciados por IA
La colaboración puede volverse difícil con la IA.
Se necesita una comunicación mucho más frecuente porque todo avanza más rápido. Es una de las razones por las que los equipos pequeños funcionan mejor en este momento.
Parece que es demasiado agotador mantener el estado y la consistencia en un equipo grande y con varios procesos de codificación agentica paralelos por persona. Algunos equipos con los que trabajo han cambiado a realizar dos reuniones rápidas al día para mantener la coherencia.
Por qué los CTO deben estar atentos a la IA en la sombra
La IA en la sombra es el problema anteriormente observado de las tecnologías en la sombra, pero con un nuevo presupuesto y un nuevo nombre.
El uso incontrolado y sin restricciones de herramientas de IA en toda la empresa puede incrementar fácilmente los riesgos de pérdida de datos e información confidencial — "exfiltración", como la llama el CISO —, muchas veces de manera totalmente involuntaria por parte de los usuarios.
La mayoría de las organizaciones están saliendo rápidamente de la etapa 1 del CMM (la fase de experimentación tipo "lejano oeste") para implementar políticas y restricciones técnicas que reduzcan los riesgos.
Por qué los CTO deben enfocarse en su propio desarrollo
Hay mucha ansiedad en la industria actualmente sobre lo que la IA significa para los equipos de ingeniería, para el tamaño de las plantillas y para la función en sí misma.
Si esa ansiedad está justificada es casi lo de menos. Lo relevante es que estamos en un periodo de cambio significativo y rápido, y navegarlo con éxito requiere líderes que estén desarrollando activamente sus propias capacidades, no solo gestionando el cambio a su alrededor.
Lo que aún me sorprende, a la luz de todo lo que está ocurriendo, es cuántos CTO y altos líderes tecnológicos siguen operando sin ninguna inversión dedicada a su propio crecimiento. Sin coach, sin formación estructurada, sin un socio de pensamiento. Yo cometí ese error una vez, y los errores y el tiempo perdido que resultaron no eran inevitables.
Los líderes que saldrán más fortalecidos de este periodo no serán necesariamente los que tengan las mejores herramientas ni los equipos más grandes. Serán aquellos que estén construyendo el criterio, la influencia y la claridad de pensamiento para liderar bien incluso cuando nadie tenga un mapa claro.
Sigue de cerca
Puedes seguir el trabajo de Adam Horner en LinkedIn. Para sesiones de coaching 1:1, cursos en cohortes y el pódcast, visita The CTO Playbook. Y para un curso gratuito por correo electrónico de 5 días para CTOs en etapa inicial, dirígete a Early CTO Map.
¡Pronto habrá más entrevistas con expertos en The CTO Club!
