5 patrones comunes que provocan fracasos en la IA
Descubre las causas más habituales de los fracasos en la adopción de la IA y cómo los líderes tecnológicos pueden mejorar los resultados a través de un mejor contexto, comunicación y toma de decisiones.
Adam Horner
Fundador de The CTO Playbook
Desafíos del CTO: Los CTOs enfrentan retos comunes en la integración de la IA, necesitando liderar profundas transformaciones organizacionales.
Impacto de la IA: La IA modifica el alcance del trabajo de ingeniería, mejorando la toma de decisiones más allá de la resolución técnica de problemas.
Ciclo de triaje de IA: La IA agiliza los ciclos de triaje y resolución, reduciendo las demoras en el soporte al cliente y mejorando el enfoque del equipo.
Riesgos de uso: El uso descontrolado de herramientas de IA puede aumentar los riesgos de datos; las organizaciones deben gestionar la política y supervisión de la IA.
Equipos pequeños: La IA transforma la dinámica de los equipos, permitiendo que equipos más pequeños trabajen de manera eficiente 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 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, construyendo y liderando equipos de ingeniería en fintech y software empresarial, incluyendo varios años en Palantir como uno de sus primeros contratados 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
El paso a la mentoría surgió de una observación simple: Convertirse en un directivo tecnológico eficaz es realmente difícil, y la mayoría lo recorre sin un mapa o alguien de su lado que haya pasado por ello. Eso es lo que hago ahora, ayudar a los CTOs a cruzar lo que llamo el abismo del CTO.
El enfoque de la IA, para mí, no es un tema separado. Atraviesa casi todas las conversaciones de mentoría que tengo, porque cada CTO con el que trabajo está enfrentando alguna versión del mismo desafío: ¿Cómo lideras una organización a través de una transformación de esta magnitud, en tu etapa específica, con tu propio equipo, y salir de ello siendo un negocio más fuerte?
El caótico punto medio de la curva de crecimiento
Mi propia organización es pequeña y deliberadamente ágil, un equipo fundador de cuatro personas construyendo totalmente con enfoque en IA, donde usamos esa experiencia para mantenernos cerca de la realidad del desarrollo de producto en etapas tempranas. También trabajo como CTO fraccional con una startup fintech en proceso de acreditación, gestionando 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 de exposición organizacional, son los CTOs a quienes oriento. Eso abarca desde equipos fundadores y startups iniciales autofinanciadas hasta empresas de rápido crecimiento con respaldo de VC y PE, pasando por negocios medianos que gestionan complejidad real y grandes empresas multidepartamentales que operan a escala.
El caótico punto medio de la curva de crecimiento es donde paso la mayor parte de mi tiempo, y es 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 o proceso, sino una expectativa. Como líder, cuando das al equipo permiso —y, más importante aún, la obligación— de reevaluar todo el ciclo de entrega desde cero, el alcance de esa revisión es fundamental. No solo cómo se escribe o despliega el código, sino todo lo que involucra el proceso de entrega: soporte al cliente, valor al usuario y la intención empresarial detrás de cada tarea.
Cuando el costo de escribir y mantener código era alto, tenía cierto sentido mantener a los ingenieros enfocados únicamente en el problema técnico. Pero ese costo ha colapsado. El factor limitante ya no es la velocidad de construcción, sino cuán claro tiene cada involucrado qué vale realmente la pena construir y por qué.
Ingenieros que entienden 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, sino la calidad de las preguntas que el equipo empezó a hacerse antes de escribir una sola línea.
Cómo los ciclos de triaje y solución pueden colapsarse con IA
Un ejemplo consistió en replantear cómo interactuaban soporte al cliente e ingeniería frente a errores confirmados. Anteriormente, los ciclos de triaje y solución se medían en días o semanas, con equipos de soporte gestionando clientes frustrados y los ingenieros absorbiendo el costo de distracción de los problemas en vivo junto a su trabajo habitual. Cuando el ciclo de entrega fue revisado considerando el desarrollo asistido por IA, los ciclos de solución se comprimieron drásticamente y gran parte del proceso se automatizó.
Esto supuso más trabajo inicial para el área de soporte, capturando y categorizando los incidentes con claridad, pero la recompensa fue la resolución en cuestión de horas y no días. Los ingenieros permanecieron enfocados. Los clientes obtuvieron respuestas más rápido. La interfaz entre dos funciones que siempre se había aceptado como lenta resultó ser totalmente renegociable.
Por Qué las Organizaciones No Deben Aplicar IA a Todo
En cuanto a qué debería ser una tarea humana frente a una tarea de IA, esto 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 el valor de tu organización y dónde se concentra el riesgo.
Las partes del proceso que son fundamentales para lo que hace el negocio —la lógica, la diferenciación, las áreas donde el fallo es visible o costoso— merecen generación y supervisión humana. Todo lo demás se encuentra en un espectro.
Una empresa de ciberseguridad dedicará una atención humana significativa a las propiedades de seguridad de su código, porque ese es su negocio. Una empresa de automatización de flujos de trabajo puede centrar ese mismo escrutinio en la lógica de toma de decisiones dentro de un flujo de trabajo crítico, mientras considera que las herramientas de seguridad pueden ser gestionadas adecuadamente por la IA.
Lo incorrecto es aplicar una política generalizada en cualquier dirección. La pregunta a hacer no es "¿Puede la IA hacer esto?" sino "¿Cuál es el coste si esto sale mal?"
Y hay otra cosa: una sorprendente cantidad de la complejidad que la gente quiere automatizar en realidad es deuda de procesos no resuelta. Resuelve eso primero. Así la adopción de IA será más fácil y barata después.
Por Qué los CTO Deben Comenzar Automatizando la Entrega, No el Código
Es realmente difícil comparar los resultados de la IA entre organizaciones porque la mayoría de los líderes, tanto en tecnología como en el negocio en general, todavía luchan por medir con claridad el impacto y el retorno de sus inversiones en IA. Sin eso, es difícil saber cómo se ve realmente el éxito, y más difícil aún justificar hacer más de ello.
Pero en general, la variedad de resultados de la IA es amplia. En un extremo, he trabajado con organizaciones que han eliminado efectivamente su backlog y ahora trabajan directamente en función del valor al cliente y la intención del negocio, lo que representa un cambio fundamental en cómo la ingeniería se relaciona con el resto del negocio.
Noté un patrón común en las organizaciones que lograron esto: ninguna comenzó por el extremo izquierdo del ciclo de vida del desarrollo de software. No empezaron con la generación de código. Comenzaron por la derecha: tuberías de CI/CD, confianza en el despliegue, revisión automática de código. Conseguir que el extremo de entrega del proceso fuera robusto y confiable fue lo que creó las condiciones para todo lo demás. A partir de ahí, el enfoque se desplazó a pruebas, restricciones y verificaciones previas a la generación, y a la estructura por encima de la velocidad.
Los equipos que más progresaron fueron los que operaban de forma más autónoma, no porque hubieran eliminado el juicio humano, sino porque habían codificado suficiente juicio humano en su proceso como para asumir trozos significativamente mayores de trabajo con confianza. El backlog no desapareció porque programaron más rápido. Desapareció porque toda la relación entre la intención y la entrega se volvió inequívoca.
En el otro extremo, he visto una verdadera pérdida de personal impulsada por la creciente brecha entre quienes avanzan rápidamente con IA y quienes no. Cuando comienza la adopción de 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 rápidos sigan adelante. Lo que eso genera, silenciosa y rápidamente, es fricción, desconfianza y sospecha entre equipos que erosionan los beneficios más rápido de lo que el progreso inicial puede acumularlos. El consejo que ahora doy al inicio de cada proyecto es el mismo: no dejes a nadie atrás. El ritmo de adopción debe establecerse de acuerdo a cuán rápido puedes llevar a toda la organización contigo, no al ritmo que pueden lograr tus ingenieros más entusiastas de manera individual.
Una organización a dos velocidades parece estar avanzando desde el frente. Desde atrás, se siente como quedarse rezagado, y esa sensación 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 lo hace, y el instinto natural es dejar que los que se mueven rápido sigan adelante. 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 rediseñarse para la IA
La diferencia más clara que he visto en las capacidades de la IA está 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 propios, ni sentido de consecuencia, ni responsabilidad sobre el resultado. Esperar que tome decisiones en tu nombre siempre dependerá de su capacidad de predecir, la cual es limitada en situaciones realmente inciertas o novedosas. Las organizaciones que más han quedado decepcionadas por la IA suelen ser las que han confiado en ella precisamente en esos momentos.
El otro ámbito donde el impacto no es el esperado, de forma más silenciosa pero igual de significativa, es cuando no se entienden bien las implicaciones de las ventanas de contexto. Si se le da una IA un contexto incompleto o mal estructurado, igual te dará una respuesta con seguridad. Distinguir entre una salida bien informada y una que solo suena plausible requiere un juicio humano que aún no han desarrollado suficientes equipos.
Por eso, la base de conocimientos de una organización es crítica. Con esto me refiero a todo el contexto que actualmente reside en la cabeza de las personas: la forma en que siempre se han hecho las cosas, los enfoques por defecto, las reglas no escritas de cómo realmente funciona la organización. La IA no puede trabajar con el conocimiento institucional que nunca se ha externalizado, y la mayoría de las organizaciones acumulan una enorme cantidad de ese conocimiento.
La buena noticia es que extraer ese conocimiento no requiere una estructura perfecta. La IA multimodal permite que un recorrido en video, un diagrama sencillo y un documento sin editar sean todas entradas significativas. La prioridad es externalizar primero, estructurar después.
Lo que encuentro de manera constante es que el hecho de sacar ese contexto de la mente de las personas y plasmarlo en cualquier forma de documentación ya es valioso en sí mismo, incluso antes de que la IA lo analice. Hace visibles las discrepancias, expone malas suposiciones y revela flujos de trabajo rotos que nadie había notado porque estaban demasiado inmersos en ellos.
Esa base luego multiplica todo lo que la IA puede hacer después. Es una de las inversiones de mayor impacto que un CTO puede hacer en este momento, y una de las más ignoradas, ¡a pesar de que los vendedores de Business Process Automation llevan años diciéndonoslo!
Cómo evitar que los desarrolladores escépticos ralenticen una organización
Un problema común que veo no es, en realidad, un fallo de la IA. Es un fallo de adopción, y suele seguir un patrón reconocible.
Un desarrollador escéptico — y sorprendentemente hay muchos — hace un intento a medias con un contexto mínimo, obtiene un mal resultado y presenta ese resultado como prueba de que la IA no es capaz. La conclusión se expone con confianza. La metodología raramente se examina. Lo que hace que esto sea algo más que una simple frustración individual es el efecto que tiene a lo largo de la organización.
La integración de la IA en un equipo o en el ciclo de vida del desarrollo es un trabajo de equipo, y unos pocos ingenieros motivados por demostrar que no funciona pueden ralentizar a toda la organización, no solo su propio trabajo.
La lección que extraigo de esto no tiene que ver con las limitaciones de la IA. Es que la adopción es un reto de liderazgo tanto como técnico. La calidad de lo que produce la IA es inseparable de la calidad del contexto y la intención que se le aporta, y crear ese entendimiento en un equipo requiere el mismo esfuerzo deliberado que cualquier otro cambio importante en la forma de trabajar. Así es como pasamos de la percepción de una "magia" imperfecta a una "tecnología avanzada" útil.
Por qué los equipos pequeños son una ventaja con IA
La suposición de que un equipo de ingeniería productivo y funcional necesitaba cierto número de personas para acumular suficiente contexto y avanzar a un ritmo significativo no ha sobrevivido al contacto con la forma en que realmente funciona 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 miembro del equipo opera múltiples agentes, y esos agentes transportan y aplican el contexto de maneras que cambian completamente la lógica anterior. La regla de las dos pizzas de Amazon era una heurística razonable para un mundo previo a la IA.
Aquí tienes un ejemplo.
Una organización con la que trabajo siempre había querido una interfaz de administración interna para su plataforma, pero nunca pudo justificar la inversión. Previamente, habían calculado que sería un esfuerzo de varios meses y todo el equipo. En cambio, asignaron a dos personas: 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.
El conocimiento empresarial de esas dos personas resultó ser tan importante como las herramientas de IA. Menos preguntas, menos sobrecarga, decisiones más ágiles. Pero el resultado más valioso no fue la propia herramienta. Fue lo que la organización aprendió sobre cómo trabajar de esta manera.
Los equipos que observo operar con mayor eficacia ahora están compuestos por dos o tres personas, cada una dirigiendo 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 crítica en los flujos de trabajo potenciados por IA
La colaboración puede volverse difícil con 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 el estado actual.
Parece demasiado agotador mantener el estado y la coherencia con un equipo grande y múltiples procesos de codificación agentes en paralelo por persona. Algunos equipos con los que trabajo han pasado a tener dos reuniones diarias para mantener la consistencia.
Por qué los CTO deben vigilar el uso no regulado de la IA
La "IA en la sombra" es el problema previamente observado de la TI en la sombra, pero con un nuevo presupuesto y un nuevo nombre.
El uso incontrolado y sin restricciones de herramientas de IA en la empresa puede aumentar fácilmente los riesgos de pérdida de datos y de propiedad intelectual —"exfiltración", como lo denomina el CISO—, a menudo de manera totalmente involuntaria por parte de los usuarios.
La mayoría de las organizaciones están saliendo rápidamente de la etapa 1 en el CMM (la fase de experimentación "salvaje") para implementar políticas y restricciones técnicas con el fin de reducir los riesgos.
Por qué los CTO deben enfocarse en su propio desarrollo
En la industria hay mucha ansiedad ahora mismo sobre lo que la IA significa para los equipos de ingeniería, para la dotación de personal, para el propio rol.
Si esa ansiedad está justificada o no es casi irrelevante. Lo importante es que estamos en un periodo de cambio significativo y rápido, y gestionarlo bien requiere líderes que estén desarrollando activamente sus propias capacidades, no solo gestionando los cambios a su alrededor.
Lo que aún me sorprende, con todo lo que sucede, es cuántos CTO y líderes tecnológicos senior actúan sin ninguna inversión dedicada en su propio crecimiento. Ni coach, ni desarrollo estructurado, ni compañero de reflexión. Yo cometí ese error una vez, y los errores que cometí y el tiempo que perdí no eran inevitables.
Los líderes que saldrán de este periodo siendo los más fuertes no son necesariamente quienes tengan las mejores herramientas o los equipos más grandes. Son quienes están desarrollando el criterio, la influencia y la claridad de pensamiento para liderar bien cuando nadie tiene un camino claro.
Sigue leyendo
Puedes seguir el trabajo de Adam Horner en LinkedIn. Para 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 etapas tempranas, dirígete a Early CTO Map.
¡Pronto más entrevistas con expertos en The CTO Club!
