Se ha programado una demo. Un proveedor o un equipo interno muestra lo que puede hacer una aplicación de IA: un chatbot que responde preguntas de clientes, una herramienta que resume informes, un asistente que escribe código. La sala está entusiasmada. Se asiente, se hacen preguntas, alguien dice que esto es "realmente algo para nosotros". Una semana después, la energía ha desaparecido y ya no ocurre nada más.
La trampa no es la demo en sí. La trampa es que se celebra una demo sin que de antemano se haya establecido quién será responsable, una vez terminada, de lo que ocurra con el resultado. Hay una presentación, no un propietario de proceso. Hay una reacción, no una decisión. Hay atención, no una agenda.
Organizar una demo se siente como emprender una acción. Se muestra algo, se reacciona, hay movimiento visible. En una organización que está bajo presión para hacer algo con IA, ese movimiento ya tiene valor: demuestra que no se está de brazos cruzados. Una demo cuesta poco, se planifica rápidamente y genera de inmediato una historia que se puede compartir con una dirección o un consejo de administración.
Además, organizar una demo es más fácil que asignar una propiedad. Una demo requiere una franja horaria en una agenda. La propiedad requiere a alguien que reciba presupuesto, tiempo y mandato para rendir cuentas de un resultado, incluso cuando ese resultado decepciona. Esto último es una cuestión política, no operativa. Planificar una demo es más fácil que plantear esa pregunta, así que se planifica la demo y se omite la pregunta.
El resultado es que una demo se convierte en un sustituto de una decisión en lugar de un motivo para tomarla. Mientras nadie pregunte quién será el propietario después de esto, la demo sigue siendo una presentación sin continuación.
Hay algunas señales reconocibles. Después de la demo hay aplausos, pero no se menciona ningún nombre de quién retoma la iniciativa. Se habla de "vamos a seguir mirando esto" sin que quede establecido quién hace ese seguimiento y cuándo esa persona vuelve con un resultado. La demo se repite en pocas semanas para otro departamento, con la misma reacción y la misma falta de continuación.
Otra señal es que la discusión posterior a la demo gira en torno a la tecnología —lo impresionante que es la herramienta, todo lo que puede hacer— en lugar de en torno a la organización que debería usarla. Es una señal de que se está omitiendo la pregunta de si la estructura existente puede sostener la aplicación. Sobre lo que esto significa puede leer en por qué la tecnología sobre una estructura sin cambios no genera nada.
También reconocible: la demo es impulsada por dos personas que están personalmente entusiasmadas con la IA, mientras el resto de la organización sigue siendo espectador. En cuanto esas dos personas se ven ocupadas con otro trabajo, la iniciativa se detiene, porque nadie más se siente responsable. Esa dinámica está descrita en por qué dos entusiastas y nadie más no genera nada.
Una última señal: después de la demo se decide hacer un piloto, pero nadie ha acordado de antemano con qué se medirá ese piloto. Sin ese acuerdo, un piloto es una demo prolongada: muestra algo, pero no demuestra nada. Ese patrón está desarrollado en por qué un piloto sin acuerdo sobre lo que debe demostrarse no genera nada.
Una demo sin propietario no es un error en la demo, sino un error en su preparación. Antes de planificar una demo, se puede establecer quién asumirá el resultado una vez terminada, quién decide si habrá continuación y en qué plazo se toma esa decisión. No es una condición técnica sino organizativa, y esa condición precede a la pregunta de qué herramienta demuestra mejor.
Ese orden —primero la organización, después la tecnología— es precisamente donde se atascan la mayoría de las iniciativas de IA. Quien quiera saber si su propia organización ya tiene ese fundamento establecido, encontrará una visión detallada por función en en qué se fija un CEO en la madurez de IA y en qué se fija un COO en la madurez de IA.
Una demo muestra lo que puede hacer una tecnología, pero no dice nada sobre lo que eso significa para el trabajo en su propia organización. En cuanto queda claro quién es el propietario de una iniciativa de IA y la base está lista para ello, surge la pregunta de qué parte del trabajo real se puede asumir efectivamente. Esa pregunta no la responde una demo, sino un cálculo estructurado por tarea. El escáner de trabajo de FTE TO AI hace exactamente eso: calcula por tarea qué parte del trabajo puede ser asumida por la IA, de modo que un propietario pueda decidir con cifras en lugar de impresiones qué vale una continuación.
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.