En prácticamente toda organización que experimenta con IA, surge en algún momento el mismo grupo: dos, quizás tres personas que lo entienden, que han empezado a probarlo por su cuenta, que hablan con entusiasmo sobre lo que es posible. Construyen un prototipo, prueban una herramienta, comparten resultados en un chat interno. El resto de la organización observa, asiente, y sigue trabajando como siempre lo ha hecho.
Tras unos meses hay una lista de experimentos interesantes y ningún cambio en cómo se realiza realmente el trabajo. Los dos entusiastas siguen entusiasmados. Todos los demás no se han movido con ellos.
El razonamiento detrás de este enfoque suena sensato: empiece en pequeño, con personas motivadas, y deje que el éxito se propague por sí solo. Eso funciona en algunos cambios. Una nueva forma de trabajar que ahorra tiempo de manera visible a veces se propaga de forma orgánica porque los colegas la adoptan.
Con la IA, ese mecanismo suele no funcionar, y la razón no está en las personas sino en la organización que las rodea. Los entusiastas suelen tener acceso a sistemas, tiempo y mandato que otros no tienen. Lo que para ellos es cuestión de probar una tarde, requiere para un colega sin ese acceso una solicitud, una aprobación, un ticket de TI. El entusiasmo no es el problema. La ausencia de un camino por el que otros puedan seguir, sí lo es.
El orden en el que se construye la madurez en IA no empieza con las personas que quieren. Empieza con la estructura que lo hace posible: cómo está organizada la organización, qué infraestructura de TI existe, cómo se gestionan los datos. Dos entusiastas pueden trabajar rodeando esa estructura, con su propio acceso, sus propios trucos, sus propios atajos. El resto de la organización no puede hacerlo, y tampoco debería querer hacerlo — los atajos no son una base para algo que debe seguir funcionando.
Eso explica por qué el patrón a menudo se repite junto a otras trampas conocidas. Quien lea sobre lo que debe quedar demostrado antes de que un piloto conduzca a algo, verá un mecanismo similar: la actividad sin un acuerdo sobre qué significa el éxito, sigue siendo solo actividad. Con dos entusiastas, tampoco existe ese acuerdo — ni sobre lo que debe quedar demostrado, ni sobre quién los sigue después.
Hay algunas señales reconocibles. La primera es que los mismos dos o tres nombres reaparecen siempre cuando se habla de IA, en cada reunión, en cada actualización. La segunda es que las preguntas de otros departamentos empiezan con "cómo lo hicieron ellos" en lugar de con una ruta propia. La tercera, y la más subestimada, es que nadie puede explicar qué debería ocurrir si una de esas dos personas se marchara mañana.
Una cuarta señal es más sutil: el experimento sigue funcionando en su propio rincón, desconectado del resto del proceso. Esto coincide con lo que ocurre cuando un piloto fuera del propio equipo no encuentra conexión — el entusiasmo sin conexión con el resto de la organización sigue siendo una isla, sin importar lo bien que funcione esa isla.
Una quinta señal, finalmente, es que se propone la ampliación como siguiente paso, mientras nadie ha comprobado si ya existe la base necesaria. Ese riesgo se describe en lo que ocurre cuando se intenta ampliar antes de que la base esté establecida: dos entusiastas que quieren multiplicar su propio éxito a diez equipos, se topan precisamente con la estructura que ellos mismos habían evitado.
Es tentador concluir que se necesitan más entusiastas, o mejor formación, o un programa de cultura. Eso pierde de vista el punto. La pregunta no es si hay suficientes personas motivadas — a menudo ya hay dos, y ese es precisamente el problema, porque dos no es una estructura. La pregunta es si la organización en su conjunto — en cómo está diseñada, cómo se comunican los sistemas entre sí, cómo están disponibles y son fiables los datos — puede sostener una situación en la que no dos, sino muchas más personas puedan trabajar con IA. Esa es una pregunta distinta de quién está entusiasmado, y es la pregunta que debe responderse primero.
Para quien se encuentre con este patrón desde un puesto directivo, resulta útil saber en qué se fijaría alguien en una posición comparable: en qué se fijaría un CEO al evaluar la madurez en IA describe algunos de esos puntos de atención, igual que la mirada de en qué se fijaría un COO respecto a la madurez en IA desde otra perspectiva sobre la misma organización.
Cuando dos entusiastas demuestran que algo es posible, queda sin responder cuánto del trabajo se puede realmente transferir, y a quién. Esa pregunta no corresponde a la preparación sino al trabajo mismo: qué tareas se prestan a ser asumidas por la IA y qué parte abarca eso. Precisamente para eso está pensado el escáner de trabajo de FTE TO AI — calcula por tarea qué parte del trabajo se puede transferir, independientemente de quién ya esté experimentando con entusiasmo con ello.
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.