Dar marcha atrás en la IA: historias reales de líderes
Lecciones sobre la IA: Muchos líderes pasan por alto las valiosas lecciones de los proyectos de IA fallidos o pausados, lo que pone de relieve ideas cruciales.
Pausar en lugar de avanzar: A menudo, las empresas se benefician de pausar las iniciativas de IA para establecer procesos fundamentales y garantizar la calidad de los datos.
Primero, hacerlo manualmente: La automatización solo debe llegar después de la ejecución manual, para garantizar que los procesos estén claramente definidos y comprendidos.
Medir el impacto: La clave del éxito consiste en evaluar los procesos actuales y el posible impacto de la IA antes de comenzar la implementación.
La importancia de la documentación: Una documentación eficaz debe registrar no solo los procesos, sino también el razonamiento detrás de las decisiones y las excepciones.
La mayoría de las historias sobre la adopción de la IA se cuentan desde el podio de los ganadores. Muchos menos líderes hablan del momento en que desconectaron el sistema: la automatización que se canceló, la implementación que se pausó, el piloto que tuvo que reconstruirse desde cero. Pero esas historias suelen ser donde se encuentran las verdaderas lecciones.
Preguntamos a tres expertos que han pasado por ello: ¿qué se deshizo, por qué y qué harían de otra manera? Sus respuestas convergen en un tema sorprendentemente coherente: el problema casi nunca es la IA en sí.
Cuándo lo más inteligente es pausar, no seguir adelante
Para la mayoría de las organizaciones, retirar por completo una inversión en IA no es realista una vez que se ha gastado el dinero. Tejinder, gerente sénior en Deloitte Consulting, afirma que eliminarla por completo no era una opción dadas las inversiones ya realizadas, pero sí lo era hacer una pausa deliberada. Cuando los resultados no estuvieron a la altura, su equipo dio un paso atrás y “analizó primero los aspectos básicos”, preguntándose si los procesos subyacentes estaban establecidos, si “la calidad de los datos” era “buena” y si los planificadores entendían el papel de los agentes frente al suyo propio. “Creo que una vez respondidas esas preguntas, tenía sentido reactivar el proyecto”, afirma.
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, responsable de perfeccionamiento profesional y propietaria de procesos de aprendizaje en la Universidad Estatal de Oregón, ha visto cómo el mismo patrón se repite una y otra vez. “He observado que varias organizaciones retrasan intencionadamente la ampliación de las iniciativas de IA después de reconocer que no estaban preparadas desde el punto de vista operativo”. En esos casos, la retirada no fue un fracaso, sino una reorientación. “En lugar de ampliar la IA de inmediato, el liderazgo cambió su enfoque hacia el fortalecimiento de la base organizativa”, explica Dave. Esto significó que “las organizaciones invirtieron en documentar los procesos empresariales, estandarizar los flujos de trabajo, mejorar la gobernanza de datos y desarrollar las capacidades de los empleados mediante el aprendizaje estructurado y la gestión del cambio”.
En lugar de ampliar la IA de inmediato, el liderazgo cambió su enfoque hacia el fortalecimiento de la base organizativa.
No automatices lo que no hayas hecho manualmente
A veces, retroceder significa cancelar un proyecto por completo y descubrir que esa era la decisión correcta desde el principio. Jaime Gil Martinez, fundador y consultor principal de Swift Ops Solutions, aprendió esta lección por las malas. “Una vez desarrollé una automatización para producir materiales de marketing para un cliente que nunca había realizado el proceso manualmente”, recuerda. “Como era algo nuevo para ellos, ambos pensamos que lo mejor era desarrollarlo de forma automatizada desde cero. Sobre el papel tenía sentido. En retrospectiva, fue un error de principiante”.
El sistema funcionaba técnicamente. “La automatización funcionaba”, afirma Gil Martinez. “El problema era que cada vez que se necesitaba un resultado, había que reconsiderar o ajustar algo (un público diferente, un formato diferente, un diseño diferente), así que no paraba de reconstruirla. Después de varias rondas de esto, el patrón era evidente: estaba automatizando un proceso que nadie había definido todavía”.
Después de varias rondas [de ajustes], era evidente que estaba automatizando un proceso que nadie había definido todavía.
La solución fue retroceder. “Así que cancelamos el proyecto por completo y volvimos a producir los materiales a mano”, afirma. “Ese resultó ser el objetivo: cada ronda manual nos proporcionó lo que nos había faltado, concretamente ejemplos de referencia y una visión clara de lo que variaba y lo que no. Más tarde reanudamos la automatización, y ese resultado manual se convirtió en la base de conocimientos que entregamos a la IA”. La experiencia dio lugar a una regla que ahora aplica en su propia empresa y con sus clientes: “no automatices nada hasta que lo hayas hecho manualmente al menos tres veces. Entonces puedes empezar a planteártelo”.
El paso que todos se saltan: mide antes de construir
Pregúntale a Gil Martinez qué les falta a la mayoría de los planes de adopción de la IA, y su respuesta es inmediata: «Medir antes de construir. A la mayoría de las empresas les faltan dos cifras cuando comienzan: qué tan bueno o malo es realmente su proceso actual y qué impacto podría tener la IA de forma realista. Sin ambas cifras, no puedes saber qué tan eficaz fue tu implementación ni si el costo estaba justificado».
Señala el caso de 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 llevaba, solo que era una tarea lenta y frustrante», explica. «Y si no sabes cuánto tiempo 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 referencia inicial: dos semanas de trabajo manual a tiempo completo. La automatización lo redujo a un día de trabajo asistido por IA, con un costo inferior a su gasto equivalente actual». Con esas cifras en la mano, «la decisión se tomó sola».
Dave ve una omisión diferente, pero igualmente crítica: la preparación no tiene que ver solo con 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 la IA», afirma. Y las brechas rara vez terminan estando relacionadas con la capacitación en herramientas. En varias evaluaciones de capacidades, «las evaluaciones revelaron sistemáticamente que las brechas de capacidades más importantes estaban relacionadas 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 es clara: «La preparación tecnológica y la preparación de la fuerza laboral son desafíos distintos. La adopción sostenible de la IA requiere ambas».
Cuando la IA llega a un proceso que no está preparado
¿Qué se rompe realmente cuando se incorpora la IA a un proceso inmaduro? Tejinder lo vio de primera mano cuando «la IA se integró en un proceso empresarial (procesamiento y asignación de pedidos) que no tenía la madurez suficiente»; el resultado fue una solución plagada de errores. Pero tiene claro dónde estaba el problema: «No creo que la IA fuera el problema aquí», afirma, señalando en cambio la madurez del proceso, los problemas con los datos maestros, las brechas de requisitos sin cerrar y las pruebas inadecuadas.
La IA se integró en un proceso empresarial (procesamiento y asignación de pedidos) que no tenía la madurez suficiente.
Dave describe la misma dinámica a partir de sus evaluaciones: distintos departamentos realizan el mismo trabajo de maneras diferentes, la documentación está incompleta y las excepciones solo existen en la mente de los empleados. «La preocupación era que la IA simplemente reprodujera prácticas incoherentes en toda la organización», explica. Es una consecuencia de un principio al que suele volver: «La IA no resuelve los problemas organizativos. Amplifica los sistemas existentes. Si los procesos son incoherentes o están mal documentados, la IA suele escalar esas incoherencias en lugar de mejorarlas». La conclusión, en sus palabras, fue: «La lección recurrente fue que las organizaciones deben mejorar los procesos antes de intentar automatizarlos».
Si los procesos son incoherentes o están mal documentados, la IA suele escalar esas incoherencias en lugar de mejorarlas.
Gil Martinez también ha aprendido de una experiencia difícil en este ámbito: una aplicación de generación de clientes potenciales que «falló estrepitosamente la primera vez». El desarrollo pasó de ser semimanual a estar completamente automatizado sin requisitos ni pruebas definidos. «Mi error fue suponer que la IA descubriría por sí sola parte de la lógica, porque la lógica parecía obvia y sencilla», admite. A partir de ahí, todo se complicó. «El código se volvió inmanejable y quedó completamente en manos de la IA, hasta el punto de que no podía volver a un hito seguro. Ese fue el momento en que supe que estaba estructuralmente roto, no solo lleno de errores».
La recuperación requirió empezar de cero. «La solución fue tan dolorosa como obvia: comenzar de nuevo», afirma. «Esta vez describí cada requisito y una prueba para cada uno, construí de forma incremental y di a la IA instrucciones claras para registrar los fallos y los éxitos junto con un control de versiones adecuado». El segundo intento, realizado con disciplina, «llevó aproximadamente la mitad del tiempo que había desperdiciado en el primero para alcanzar una solución funcional y apta para producción».
More Articles
- El problema de la gobernanza de datos de la IA que los líderes de operaciones no pueden ignorar
- El líder de entrega en Google comparte cómo los flujos de trabajo agenciales cambian los modelos de gestión de producto
- Privacidad desde el diseño: cómo crear una estrategia de IA que no comprometa la confianza
Cómo es realmente una buena documentación para la IA
Detrás de las tres historias se encuentra la misma solución: documentación que recoge cómo se realiza realmente el trabajo. Para Dave, eso significa ir más allá de las listas de tareas. «Una buena documentación de procesos explica no solo qué hace la gente, sino también por qué toma determinadas decisiones», afirma. Y el material más valioso suele ser precisamente el que nunca se documenta. «Uno de los errores más comunes que cometen las organizaciones es documentar únicamente el flujo de trabajo estándar. La mayor parte del conocimiento organizativo suele encontrarse en las excepciones, las decisiones basadas en el criterio y las decisiones contextuales que toman los empleados con experiencia».
Gil Martinez lo plantea desde una perspectiva que los directores de proyecto reconocerán cada vez más: «Una buena documentación de procesos refleja la ingeniería de instrucciones. Los mismos elementos que aprendimos a proporcionar a la IA en una instrucción (rol, contexto, tarea, instrucciones, restricciones) deberían aparecer a nivel de proyecto». Este cambio tiene implicaciones para la forma en que los profesionales emplean su tiempo. «El tiempo de ejecución de los seres humanos está desapareciendo, delegado en la IA, así que nuestro enfoque debe cambiar hacia una buena planificación y la validación de los resultados. Tenemos que 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 se arrepienten —o han visto arrepentirse a otros— es del orden de las operaciones. Tejinder lo resume así: «La adopción de la IA empresarial fracasa cuando el modelo se implementa antes que los fundamentos operativos. La secuencia correcta es madurez de los procesos, calidad de los datos y claridad de los roles primero. La 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 introdujo la IA». Resulta que dar marcha atrás no es el fracaso. Implementar antes de estar preparados sí lo es.
¿Quieres más información como esta? Regístrate para obtener una cuenta gratuita de DPM y escucha a más expertos como estos.