Se inicia un piloto. Un equipo, una herramienta, un periodo de algunas semanas o meses. Al final se hace una retroalimentación: se sintió bien, la gente estaba entusiasmada, algunas cosas fueron más rápido. Y entonces se toma una decisión basada en esa sensación, mientras que nadie fijó de antemano a qué pregunta debía responder realmente el piloto.
Esa es la trampa. No el piloto en sí, sino la ausencia de una pregunta que el piloto debía responder. Sin esa pregunta, cualquier resultado es un buen resultado, y ese es precisamente el problema. Un piloto sin acuerdo sobre qué debe demostrarse no puede fracasar, y por lo tanto tampoco puede demostrar nada.
Un piloto se siente como una manera segura de empezar. Empezar en pequeño, ver qué pasa, y luego escalar si funciona. Eso suena sensato, y en una situación estable lo es. Pero la IA no solo afecta al equipo que ejecuta el piloto. Afecta a la manera en que se registran los datos, a quién decide sobre qué, y a qué sistemas deben comunicarse entre sí. Un piloto que no mide nada de eso, tampoco mide nada sobre si el resto de la organización obtendría el mismo resultado.
La lógica de "probar primero en pequeño" asume que el éxito a pequeña escala se traduce en éxito a gran escala. Precisamente por eso escalar sin que la base esté establecida no aporta nada: lo que funcionó en un piloto a menudo lo hizo gracias a circunstancias que no están presentes en otros lugares. Un equipo motivado, un conjunto de datos limpio, un directivo que casualmente participó en la reflexión. Sin un acuerdo previo sobre qué debía comprobarse, sigue sin quedar claro si el resultado se debió a la tecnología o a las circunstancias excepcionales en las que se puso a prueba.
Hay algunas señales reconocibles.
La primera señal es que el piloto se cierra con una historia en lugar de con una respuesta. Se cuenta lo que ocurrió, pero nadie puede decir si la pregunta planteada de antemano —que en realidad nunca existió— ha sido respondida.
La segunda señal es que el piloto estaba desconectado del resto de la organización. Un equipo, un caso de uso, sin vínculo con los sistemas o departamentos que deberían sostener el resultado si funciona. Es la misma trampa que cuando un piloto solo funciona en su propio rincón: el éxito aislado dice poco sobre lo que ocurre cuando el resto de la organización tiene que integrarse.
La tercera señal es que nadie es dueño del piloto. Hay un líder de proyecto, quizás un proveedor, pero ningún responsable que se haga cargo de lo que debe ocurrir después del piloto. Esto se nota solo cuando el piloto ha terminado y la pregunta "¿y ahora qué?" queda sin respuesta, exactamente el patrón que se hace visible cuando una demo sin responsable no aporta nada.
La cuarta señal es que se puso a prueba la tecnología, pero no la estructura en la que debe funcionar. Roles, responsabilidades, líneas de toma de decisiones: permanecieron sin cambios durante el piloto, y precisamente por eso la tecnología sobre una estructura sin cambios no aporta nada. Un piloto que no afecta a la estructura solo comprueba si la tecnología funciona en un entorno que no necesita cambiar. Esa es una pregunta distinta a si la organización está lista para trabajar con ella.
El orden en que se construye la madurez en IA no es arbitrario. La organización, la infraestructura de TI y la gestión de datos forman la base sobre la que solo entonces pueden apoyarse las dimensiones dependientes, como la manera en que las personas colaboran con la IA o cómo se toman las decisiones. Un piloto que ignora este orden mide, en realidad, algo distinto de lo que dice medir. Mide la creatividad de un equipo en un momento determinado, no la preparación de la organización en su conjunto.
Ahí es también donde un CEO y un COO suelen mirar de manera distinta. Lo que observa un CEO respecto a la madurez en IA difiere de lo que evalúa un COO al respecto, y un piloto sin un punto de medición acordado de antemano deja a ambos sin puntos de referencia. La pregunta no es si el piloto fue agradable, sino si dice algo sobre las dimensiones que deben sostener el resto.
La medición de madurez de hybridresourcing.com está pensada para hacer posible ese acuerdo previo. Cinco niveles, de baseline a intelligence, en siete dimensiones, con una ronda de evaluación en la que varias personas puntúan de manera independiente para que se visualice la dispersión en lugar de asumir como verdad una única impresión. Así se hace visible dónde se encuentra realmente la organización, antes de iniciar otro piloto que deba demostrar a posteriori lo que nunca se fijó de antemano.
Esta medición trata sobre si la organización puede sostener la IA: si la base está establecida para que algo funcione de manera estructural. Una vez respondida esa pregunta, surge espacio para otra pregunta, concretamente qué parte del trabajo real puede asumir la IA. Esa pregunta la responde el escáner de trabajo de FTE TO AI, que calcula por tarea qué parte de esta puede transferirse a la IA. La herramienta para esta medición de madurez está en construcción; quien desee utilizar la medición en cuanto esté disponible, puede inscribirse en la lista de espera.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.