Cuando las organizaciones adoptan nuevas tecnologías sin clarificar primero el propósito, caen en "el pensamiento inverso": partir de la solución en lugar del problema. Es un enfoque que puede generar implementaciones superficiales que rara vez producen valor sostenible.

La IA no es diferente. De hecho, puede ser peor. A diferencia de otras herramientas empresariales, la IA tiene características que amplifican los riesgos de una adopción no reflexiva: aprende de nuestros datos (incluidos nuestros sesgos), puede automatizar decisiones sin supervisión humana clara, y genera outputs que parecen convincentes incluso cuando son incorrectos o dañinos.

Sin embargo, la presión por "no quedarse atrás" lleva a muchas organizaciones a saltar directamente a pilotos de IA sin haber discutido primero aspectos fundamentales: ¿qué trabajo queremos que la IA haga? ¿Qué trabajo queremos que sigan haciendo los humanos? ¿Cómo sabremos si la IA está funcionando bien? ¿Qué pasa cuando comete errores?

Estas no son preguntas técnicas. Son conversaciones sobre valores, sobre cómo entendemos el trabajo del conocimiento, y sobre qué tipo de organización queremos ser.

Conversación 1: ¿Para qué queremos IA?

La primera conversación que necesitamos tener es brutalmente honesta: ¿por qué estamos considerando IA? Las respuestas habituales ("porque todos lo están haciendo", "porque la competencia ya la usa", "porque puede hacernos más eficientes") son señales de alarma, no razones válidas. Si un equipo usa IA para escribir código más rápido pero ese código no resuelve los problemas correctos, ¿hemos ganado algo? Si automatizamos la generación de documentación que nadie lee, ¿estamos siendo más eficientes o simplemente produciendo más ruido?

Muchas organizaciones pueden confundir actividad con progreso. Adoptar IA sin clarificar el outcome deseado es otra forma de caer en esta trampa. Antes de hablar de herramientas, necesitamos responder:

• ¿Qué problema específico estamos intentando resolver? No "mejorar la productividad" (demasiado vago), sino algo concreto: "reducir el tiempo que los desarrolladores pierden escribiendo tests repetitivos", "ayudar a product managers a identificar patrones en feedback de usuarios", "acelerar la generación de prototipos visuales en discovery".
• ¿Por qué ese problema es importante ahora? ¿Está limitando genuinamente nuestra capacidad de entregar valor, o es una optimización prematura de algo que funciona suficientemente bien?
• ¿Qué alternativas no tecnológicas hemos considerado? A veces, el problema real no es que necesitemos automatización, sino que tenemos procesos innecesariamente complejos, falta de claridad en roles, o déficits de habilidades que se resolverían mejor con formación o cambios organizacionales.

Si la respuesta a "¿para qué queremos IA?" no es clara y específica, el resto de las conversaciones carecen de sentido. Y si la respuesta real es "porque tenemos presión de arriba" o "porque hay presupuesto disponible", entonces la conversación que necesitamos tener es con quienes están presionando o asignando ese presupuesto, no con la tecnología.

Conversación 2: ¿Quién decide qué automatizar y qué no?

Una vez que hemos clarificado el propósito, surge la pregunta del control: ¿quién tiene voz en las decisiones sobre qué tareas se automatizan con IA y cuáles siguen siendo responsabilidad humana? Esta no es una pregunta técnica ni jerárquica, sino profundamente relacionada con cómo entendemos el trabajo ágil.

Las decisiones sobre cambios tecnológicos que afectan directamente al trabajo de los equipos, pero se toman sin su participación, pueden erosionar la confianza y el compromiso. Cuando la IA se introduce de arriba hacia abajo sin consultar a quienes realmente hacen el trabajo, el mensaje implícito es: "no confiamos en que toméis decisiones inteligentes sobre vuestras propias herramientas".

Pero involucrar a los equipos no significa simplemente "comunicar mejor" las decisiones ya tomadas. Significa genuinamente co-crear los criterios para decidir qué automatizar. Algunas preguntas útiles para esta conversación:

• ¿Qué tareas consumen tiempo sin aportar aprendizaje? Los tests de regresión manuales repetitivos pueden ser buenos candidatos para automatización. La exploración de APIs desconocidas, probablemente no, porque el proceso de exploración es donde aprendemos.
• ¿Dónde está el juicio humano crítico? Automatizar la generación de código puede acelerar la implementación, pero automatizar decisiones de priorización sin supervisión humana puede llevarnos a construir las cosas equivocadas más rápido.
• ¿Qué tareas disfrutamos y nos hacen mejores profesionales? No todo lo que puede automatizarse debería automatizarse. Si los desarrolladores disfrutan y aprenden escribiendo ciertos tipos de código, automatizarlo completamente puede reducir su desarrollo profesional y satisfacción laboral.

Los equipos empoderados necesitan autonomía para decidir cómo trabajan. La introducción de IA no debería ser una excepción a este principio. Si creemos en equipos autoorganizados, entonces necesitamos confiar en que pueden tomar decisiones inteligentes sobre cuándo y cómo usar IA en su trabajo.

Esto no significa que cada equipo haga lo que quiera sin coordinación. Significa que las políticas organizacionales sobre IA deberían construirse con los equipos, no para los equipos. Y que los criterios para decidir qué automatizar deberían ser explícitos, discutibles y revisables.

Conversación 3: ¿Cómo mediremos el éxito (y el fracaso)?

Si no sabemos cómo mediremos si la IA está funcionando, entonces estamos adoptando tecnología basándonos en fe, no en evidencia. Y en contextos ágiles, donde iteramos basándonos en feedback, necesitamos claridad sobre qué feedback estamos buscando. Las métricas mal diseñadas pueden generar comportamientos perversos. Si medimos el "éxito" de la IA solo por velocidad (líneas de código generadas, tickets cerrados, tiempo ahorrado), podemos incentivar la producción de outputs de baja calidad que crean más problemas de los que resuelven. Las métricas útiles para evaluar la adopción de IA en equipos ágiles deberían capturar múltiples dimensiones:

• Métricas de outcome, no solo de output. No cuánto código genera la IA, sino si ese código reduce bugs, mejora la mantenibilidad, o acelera la entrega de valor a usuarios. No cuántos resúmenes de meetings produce, sino si las decisiones se toman más rápido o con mejor información.
• Métricas de calidad y confianza. ¿Cuántas veces los equipos necesitan revisar o descartar outputs de IA? ¿Están confiando ciegamente en las sugerencias o las están validando críticamente? Un equipo que revisa todo el código generado por IA está usando la herramienta de forma diferente (y potencialmente más segura) que uno que lo acepta sin revisión.
• Métricas de experiencia del equipo. ¿Los equipos sienten que la IA les está ayudando o añadiendo carga cognitiva? ¿Están aprendiendo todavía, o la IA está sustituyendo oportunidades de desarrollo profesional? La satisfacción del equipo no es un "nice to have", es un leading indicator de sostenibilidad.
• Métricas de riesgo y fallos. ¿Cuántos errores introducidos por IA hemos detectado? ¿Cuántos no hemos detectado? ¿Qué sesgos están apareciendo en los outputs? Un sistema sin métricas de fallo está diseñado para ocultar problemas, no para aprender de ellos.

Además de definir qué medir, necesitamos acordar cuándo revisar estas métricas y qué haremos si no vemos los resultados esperados. ¿Estamos dispuestos a retirar o reducir el uso de IA si las métricas muestran que no está funcionando? ¿O hemos invertido tanto política y económicamente que daremos marcha atrás será imposible?

Esta conversación sobre métricas no debería esperar a la implementación. Debería ser parte del diseño del piloto. Porque si empezamos sin saber qué estamos buscando, nunca sabremos si lo hemos encontrado.

Conversación 4: ¿Qué pasa cuando la IA comete errores?

Todas las herramientas fallan. La IA no es diferente. Pero hay una diferencia crítica entre un error de una hoja de cálculo (que generalmente podemos detectar) y un error de un modelo de lenguaje que genera código o documentación que parece plausible pero es incorrecto. Los expertos humanos desarrollan intuición para detectar cuándo algo "no huele bien". Con IA, esa intuición tarda más en desarrollarse, porque los outputs a menudo son lo suficientemente buenos como para no activar nuestras alarmas.

Los sistemas seguros no son aquellos que intentan eliminar todos los errores (imposible), sino aquellos que son buenos detectando y respondiendo a errores cuando ocurren. Aplicado a IA en contextos ágiles, esto significa que necesitamos conversaciones explícitas sobre:

• ¿Quién es responsable cuando la IA comete un error? Si un modelo genera código con vulnerabilidades de seguridad que pasan a producción, ¿es responsabilidad del desarrollador que no lo detectó, del equipo que eligió usar esa herramienta, o de la organización que presionó para aumentar velocidad sin ajustar estándares de calidad?
• ¿Cómo creamos espacios seguros para reportar problemas? Si los equipos sienten presión por "adoptar IA exitosamente", pueden ser reacios a reportar problemas o errores. Necesitamos cultivar una cultura donde hablar sobre lo que no funciona sea valorado, no penalizado.
• ¿Qué procesos de revisión y validación son no negociables? Algunas organizaciones están estableciendo que ciertos tipos de código generado por IA (por ejemplo, código relacionado con seguridad, privacidad o cálculos financieros críticos) requieren siempre revisión humana experta. ¿Cuáles son nuestras líneas rojas?
• ¿Cómo aprendemos de los errores sin culpar? Un error de IA debería tratarse como un error de sistema, no como un fallo individual. Necesitamos retrospectivas que investiguen no solo qué falló técnicamente, sino qué presiones o incentivos llevaron a depender de la IA de formas que resultaron problemáticas.

Esta conversación es incómoda porque nos obliga a reconocer que introducir IA introduce nuevos tipos de riesgos. Pero pretender que esos riesgos no existen no los hace desaparecer, solo hace que seamos peores detectándolos y respondiendo a ellos.

Conversación 5: ¿Qué habilidades necesitamos desarrollar ahora?

La llegada de IA no significa que ciertas habilidades se vuelven obsoletas, pero sí que el mix de habilidades valiosas cambia. Y los equipos necesitan tiempo y recursos para desarrollar esas nuevas capacidades. Esta conversación es especialmente relevante en organizaciones ágiles que valoran el aprendizaje continuo.

Las organizaciones ágiles necesitan invertir constantemente en el desarrollo de capacidades de sus equipos, no solo en la entrega de features. La adopción de IA no es diferente. Algunas habilidades que se vuelven más críticas:

• Prompting efectivo. No es simplemente "saber usar ChatGPT". Es entender cómo estructurar problemas de formas que los modelos de lenguaje puedan procesar útilmente, cómo iterar sobre prompts, y cómo detectar cuándo un output es plausible pero incorrecto.
• Pensamiento crítico sobre outputs de IA. La habilidad de evaluar rápidamente si un output de IA es correcto, útil, o presenta sesgos. Esto requiere experiencia de dominio sólida, no la erosiona.
• Diseño de procesos que combinan humano + IA. No se trata de "IA o humanos", sino de diseñar workflows donde cada uno hace lo que mejor sabe hacer. Esto requiere pensamiento sistémico y experimentación.
• Ética y responsabilidad en IA. Entender implicaciones de privacidad, sesgos, y uso responsable de datos. En equipos de producto, esto es parte de product thinking, no una responsabilidad exclusiva de un equipo de ética centralizado.

La pregunta entonces es: ¿estamos dando a los equipos tiempo y recursos para desarrollar estas habilidades? ¿O estamos asumiendo que "aprenderán sobre la marcha" mientras también se les presiona por mantener el mismo ritmo de entrega?

Conversación 6: ¿Qué no vamos a hacer con IA?

Esta puede ser la conversación más importante y la que menos organizaciones están teniendo: ¿qué usos de IA consideramos inaceptables, independientemente de su eficiencia potencial? Establecer límites claros no es una señal de tecnofobia, sino de madurez organizacional. Algunas organizaciones están estableciendo políticas explícitas, por ejemplo:

• No usar IA para decisiones de evaluación de desempeño. Aunque teóricamente un modelo podría analizar datos de rendimiento, el juicio sobre el desempeño de una persona debe seguir siendo humano y contextual.
• No usar IA para generar comunicación personalizada con clientes sin revisión humana. El riesgo reputacional de un error o un tono inapropiado es demasiado alto. * No usar IA para tomar decisiones de priorización sin validación humana experta. Un modelo puede sugerir, pero no puede entender el contexto estratégico completo o las implicaciones políticas de ciertas decisiones.
• No entrenar modelos con datos sensibles de clientes sin consentimiento explícito. Esto parece obvio, pero la línea entre "mejorar el producto" y "violar privacidad" a veces es más difusa de lo que nos gustaría admitir.

Estas líneas rojas no son universales. Cada organización necesita definir las suyas basándose en sus valores, su contexto regulatorio, y los riesgos específicos de su dominio. Pero lo que no es aceptable es no tener ninguna línea roja, o tenerlas implícitas y no discutidas. La IA presenta riesgos reales: sesgos, errores, mal uso, erosión de habilidades críticas, impactos en empleo. Necesitamos conversaciones honestas sobre estos riesgos, no narrativas optimistas que los minimizan.

Lo que estas conversaciones revelan

Si has llegado hasta aquí y estás pensando "esto suena a mucho trabajo antes siquiera de empezar con IA", entonces este artículo ha cumplido su propósito. Porque sí, es mucho trabajo. Y ese es precisamente el punto: la adopción reflexiva de cualquier tecnología que impacta cómo trabajamos requiere conversaciones que van más allá de "¿qué herramienta compramos?"

Estas conversaciones no son obstáculos burocráticos que retrasan la "verdadera" adopción. Son la adopción. Son donde clarificamos valores, alineamos expectativas, construimos confianza, y diseñamos sistemas que realmente funcionan para las personas que los usan.

Las organizaciones que están adoptando IA de forma más madura no son necesariamente las que la están usando más rápido, sino las que están haciéndose estas preguntas incómodas primero. Y las que están dispuestas a responder "quizás no deberíamos usar IA para esto" cuando las respuestas no son satisfactorias.

En contextos ágiles, donde valoramos la colaboración sobre los contratos, individuos e interacciones sobre procesos, y responder al cambio sobre seguir un plan, estas conversaciones son coherentes con nuestros valores. No estamos siendo "anti-tecnología" al insistir en tenerlas. Estamos siendo ágiles: empezando con el problema, no con la solución, e iterando basándonos en feedback real.

¿Qué conversación crees que es más urgente en tu contexto?

Bibliografía

• Cagan, M. (2020). Empowered: Ordinary People, Extraordinary Products. Wiley.
• Cutler, J. (2023). "The Messy Middle of Product Development". The beautiful mess. Disponible en: https://cutlefish.substack.com
• Dekker, S. (2014). Safety Differently: Human Factors for a New Era. CRC Press.
• Edmondson, A. C. (2018). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley.
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
• Gothelf, J., & Seiden, J. (2017). "Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously". Harvard Business Review Press.
• Heffernan, M. (2011). Willful Blindness: Why We Ignore the Obvious at Our Peril. Walker & Company.
• Klein, G. (1998). Sources of Power: How People Make Decisions. MIT Press.
• Martin, R. (2009). "The Design of Business: Why Design Thinking is the Next Competitive Advantage". Harvard Business Press.
• Perri, M. (2018). Escaping the Build Trap: How Effective Product Management Creates Real Value. O'Reilly Media.
• Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.