Retrocediendo con la IA: Historias reales de líderes
Lecciones de IA: Muchos líderes pasan por alto las valiosas lecciones de proyectos de IA fallidos o pausados, destacando conocimientos cruciales.
Pausar en vez de insistir: Las empresas a menudo se benefician al pausar iniciativas de IA para establecer procesos básicos y garantizar calidad de datos.
Primero manual: La automatización debe implementarse solo tras ejecutar el proceso manualmente, asegurando que estén claros y comprendidos.
Medir el impacto: La clave del éxito es evaluar los procesos actuales y el posible impacto de la IA antes de iniciar la implementación.
Importancia de la documentación: La documentación efectiva debe captar no solo los procesos, sino también el razonamiento detrás de las decisiones y las excepciones.
La mayoría de las historias de adopción de IA se cuentan desde el podio de los ganadores. Muy pocos líderes hablan del momento en el que tiraron del cable: la automatización que se canceló, la implementación que se pausó, el piloto que hubo que rehacer desde cero. Pero esas historias suelen ser donde realmente están las lecciones.
Le preguntamos a tres expertos que ya han pasado por ello: ¿qué fue lo que deshicieron, por qué, y qué harían diferente? Sus respuestas confluyen en un tema sorprendentemente consistente: casi nunca el problema es la propia IA.
Cuando la decisión inteligente es pausar, no seguir avanzando
Para la mayoría de las organizaciones, eliminar por completo una inversión en IA no es realista una vez que ya se ha invertido el dinero. Tejinder, Gerente Senior en Deloitte Consulting, dice que desecharlo totalmente no era una opción dada la inversión realizada, pero sí lo era una pausa deliberada. Cuando los resultados no estuvieron a la altura, su equipo dio un paso atrás y “miraron primero lo básico”, preguntándose si los procesos subyacentes estaban establecidos, si “la calidad de los datos” era “buena” y si los planificadores comprendían el rol de los agentes frente al suyo propio. “Creo que una vez respondidas esas preguntas la reactivación tenía sentido”, dice.
Desbloquea Gratis
Crea una cuenta gratuita para terminar de leer este contenido y unirte a una comunidad de líderes visionarios que están desbloqueando herramientas, manuales y conocimientos para prosperar en la era de la IA.
Have an account? Log In
Priyanka Dave, PhD, líder de Upskilling y responsable de procesos de aprendizaje en la Universidad Estatal de Oregón, ha visto el mismo patrón repetirse una y otra vez. “He observado que varias organizaciones retrasan intencionalmente la expansión de iniciativas de IA tras reconocer que no estaban preparadas operativamente”. En esos casos, la retirada no fue un fracaso, sino una redirección. “En vez de expandir la IA de inmediato, la dirección desvió su atención a fortalecer la base organizacional”, explica Dave. Esto significó que “las organizaciones invirtieron en documentar procesos de negocio, estandarizar flujos de trabajo, mejorar la gobernanza de datos y desarrollar competencias de los empleados mediante aprendizaje estructurado y gestión del cambio”.
En vez de expandir la IA de inmediato, la dirección desvió su atención a fortalecer la base organizacional.
No automatices lo que no has hecho manualmente
A veces, retroceder significa cancelar un proyecto por completo y descubrir que, en realidad, era la decisión correcta desde el principio. Jaime Gil Martínez, fundador y consultor principal en Swift Ops Solutions, lo aprendió por las malas. “En una ocasión creé una automatización para producir materiales de marketing para un cliente que nunca había realizado el proceso de forma manual”, recuerda. “Como era nuevo para ellos, ambos pensamos que sería mejor crearlo automatizado desde cero. Sobre el papel tenía sentido. Viéndolo en retrospectiva, fue un error de principiante.”
Técnicamente el sistema funcionaba. “La automatización funcionaba”, dice Gil Martínez. “El problema era que cada vez que se necesitaba un resultado, había que reconsiderar o ajustar algo (un público diferente, un formato distinto, otro diseño), así que constantemente tenía que rehacerla. Tras varias iteraciones el patrón era evidente: estaba automatizando un proceso que nadie había definido aún.”
Tras varias iteraciones [de ajustes] era evidente que estaba automatizando un proceso que nadie había definido aún.
La solución fue volver atrás. “Así que cancelamos el proyecto directamente y volvimos a producir los materiales de forma manual”, comenta. “Eso resultó ser el punto clave: cada ronda manual nos daba lo que nos faltaba, es decir, ejemplos de referencia y una visión clara de qué variaba y qué no. Reanudamos la automatización más adelante, y ese resultado manual se convirtió en la base de conocimiento que proporcionamos a la IA.” La experiencia le dejó una regla que aplica tanto en su propia empresa como en las de sus clientes: “no automatices nada hasta haberlo hecho manualmente al menos tres veces. Recién entonces puedes empezar a considerarlo.”
El paso que todos se saltan: mide antes de construir
Pregunta a Gil Martinez qué les falta a la mayoría de los planes de adopción de IA, y su respuesta es inmediata: “Medir antes de construir. La mayoría de las empresas no tienen dos números al comenzar: qué tan bueno o malo es realmente su proceso actual y qué impacto realista podría tener la IA en él. Sin ambos, no puedes determinar qué tan efectiva fue tu implementación ni si el costo estuvo justificado.”
Él señala una clínica de salud que quería automatizar la programación de citas para más de 100 pacientes. “No sabían cuánto tiempo les tomaba, solo que era algo que consumía mucho tiempo y resultaba frustrante”, dice. “Y si no sabes cuánto tiempo te lleva, no sabes cuánto te cuesta.” Así que, antes de construir nada, su primer paso fue calcular las horas que consumía la programación y el valor financiero de esas horas. “Eso nos dio la base: dos semanas completas de trabajo manual. La automatización lo redujo a un solo día de trabajo asistido por IA, con un costo menor al equivalente actual.” Con esos números en la mano, “la decisión se tomó sola.”
Dave percibe una omisión diferente pero igual de crítica: la preparación no se trata solo de la tecnología. “El paso que veo que las organizaciones pasan por alto con mayor frecuencia es evaluar la capacidad de la fuerza laboral antes de implementar IA”, comenta. Y las carencias rara vez son sobre capacitación en herramientas. En varias evaluaciones de capacidades, “las evaluaciones revelaron consistentemente que las mayores brechas tenían que ver con el pensamiento analítico, el pensamiento crítico, la alfabetización de datos, la comunicación consultiva y la resolución de problemas.” Su conclusión: “La preparación tecnológica y la preparación de la fuerza laboral son desafíos diferentes. Una adopción sostenible de IA requiere ambas.”
Cuando la IA Llega a un Proceso que No Está Listo
¿Qué es lo que realmente falla cuando la IA se aplica a un proceso inmaduro? Tejinder lo vivió de primera mano cuando “se integró IA en un proceso empresarial (procesamiento y asignación de pedidos) que no era lo suficientemente maduro”, lo que resultó en una solución llena de errores. Pero deja claro dónde estaba la falla: “Creo que la IA no fue el problema aquí”, afirma, señalando en cambio la madurez del proceso, problemas con los datos maestros, brechas no resueltas en los requisitos y pruebas insuficientes.
Se integró IA en un proceso empresarial (procesamiento y asignación de pedidos) que no era lo suficientemente maduro.
Dave describe la misma dinámica a partir de sus evaluaciones: diferentes departamentos realizando el mismo trabajo de maneras distintas, documentación incompleta y excepciones que solo existen en la mente de los empleados. “La preocupación era que la IA simplemente reprodujera prácticas inconsistentes en toda la organización”, señala. Es consecuencia de un principio al que recurre a menudo: “La IA no resuelve los problemas organizacionales. Amplifica los sistemas existentes. Si los procesos son inconsistentes o están mal documentados, la IA a menudo escalará esas inconsistencias en lugar de mejorarlas”. La conclusión, en sus palabras: “La lección recurrente fue que las organizaciones deberían mejorar los procesos antes de intentar automatizarlos.”
Si los procesos son inconsistentes o están mal documentados, la IA a menudo escalará esas inconsistencias en lugar de mejorarlas.
Gil Martinez tiene su propio aprendizaje duro aquí: una aplicación de generación de leads que “fracasó de manera dramática la primera vez”. Se pasó de un sistema semi-manual a uno totalmente automatizado sin requisitos ni pruebas definidos. “Mi error fue asumir que la IA deduciría parte de la lógica por sí sola, porque la lógica parecía obvia y simple”, admite. Desde ahí todo se complicó. “El código se volvió inmanejable y completamente dominado por la IA, hasta el punto de que no podía volver a un punto seguro. Fue entonces cuando supe que estaba estructuralmente roto, no solo era cuestión de errores.”
La recuperación requirió un reinicio total. “La solución fue tan dolorosa como obvia: empezar de nuevo”, comenta. “Esta vez delineé cada requisito y una prueba para cada uno, construí de forma incremental y di instrucciones claras a la IA para registrar fallos y éxitos junto a un control de versiones adecuado.” El segundo intento, más disciplinado, “me llevó aproximadamente la mitad del tiempo que desperdicié en el primer intento para llegar a una solución viable y lista para producción.”
Cómo Es Realmente una Buena Documentación para la IA
Debajo de las tres historias se encuentra la misma solución: documentación que capture cómo realmente se realiza el trabajo. Para Dave, esto implica ir más allá de listas de tareas. “Una buena documentación de procesos explica no solo lo que hacen las personas sino también por qué toman determinadas decisiones”, explica. Y el material más valioso suele ser aquello que nunca se plasma por escrito. “Uno de los errores más comunes que cometen las organizaciones es documentar solo el flujo de trabajo estándar. El mayor conocimiento organizacional suele encontrarse en las excepciones, los juicios de valor y las decisiones contextuales que toman los empleados experimentados.”
Gil Martínez lo plantea desde una perspectiva que los PM reconocerán cada vez más: “Una buena documentación de procesos es un reflejo de la ingeniería de prompts. Los mismos elementos que aprendimos a proporcionar a la IA en un prompt (rol, contexto, tarea, instrucciones, restricciones) deben aparecer a nivel de proyecto”. Ese cambio tiene implicaciones en la forma en que los profesionales invierten su tiempo. “El tiempo de ejecución para los humanos está desapareciendo, delegado a la IA, por lo que nuestro enfoque debe cambiar hacia planificar bien y validar los resultados. Debemos comportarnos como gestores de IA”.
Conclusión: La secuencia es la estrategia
Ninguno de estos líderes se arrepiente de haber invertido en IA. De lo que sí se arrepienten —o han visto a otros arrepentirse— es del orden de las operaciones. Tejinder lo resume así: “La adopción de IA en las empresas fracasa cuando el modelo se implementa antes que los fundamentos operativos. La secuencia correcta es primero madurez de procesos, calidad de los datos y claridad de roles. IA, después. Cuando las organizaciones invierten ese orden, culpan a la IA, pero el problema subyacente casi siempre es el entorno en el que se inserta la IA”. Retroceder, resulta, no es el fracaso. Implementar antes de estar preparados sí lo es.
¿Quieres más perspectivas como estas? Regístrate gratis en DPM para escuchar a más expertos como estos.
