Si tus empleados votan sobre los proyectos de IA, la dirección no está haciendo su trabajo

Soy propietaria de un estudio de IA y, a través de él, trabajo en proyectos de IA para empresas de todo el mundo. En esta serie escribo sobre algunos de los mayores errores que he visto en proyectos de implementación de IA y software, para que puedas evitar cometerlos.

Cuando empecé a trabajar con uno de mis clientes, un fabricante de alimentos para mascotas¹ que vende a través de tiendas de animales y supermercados, ya habían pasado muchas cosas antes de mi llegada. Como muchas empresas ahora mismo, sabían que querían empezar a utilizar datos e IA, pero no por dónde empezar. Así que habían contratado a una consultora para que les ayudara a averiguar dónde podía la IA marcar realmente la diferencia en el negocio.

Los consultores entrevistaron a personas de toda la empresa y revisaron sus sistemas y datos en busca de ámbitos en los que la IA pudiera ahorrar tiempo o dinero, o ayudar a la empresa a vender más. Al terminar, presentaron una lista de treinta proyectos. Cada proyecto incluía una breve descripción y una explicación de por qué sería bueno para el negocio. Uno predeciría qué productos se iban a vender, para que la fábrica dejara de producir más de lo que necesitaban las tiendas. Otro ofrecería al equipo comercial una visión en tiempo real de lo que estaba pidiendo cada tienda. Un tercero quitaría de las mesas parte del papeleo repetitivo. Casi todo lo que figuraba en la lista tenía sentido por separado. Lo que no tenía la lista era un orden de prioridad.

Casi todas las empresas se están haciendo ahora mismo las mismas preguntas sobre la IA. Primero, ¿qué proyectos podríamos hacer? Y, una vez que tenemos una lista, ¿cómo elegimos entre ellos sin dejar atrás a nuestra gente, sobre todo a quienes mejor conocen el trabajo diario y pueden ver algo que la dirección no ve? La respuesta de mi cliente fue una votación. La dirección envió la lista de treinta proyectos a los empleados y les pidió que eligieran los que querían. Sobre el papel, parece un ejemplo de manual de buen liderazgo, porque todo el mundo puede opinar.

Llegaron los votos y se hizo el recuento para determinar los ganadores. Después, la lista acabó en manos de quienes realmente tenían que pagarla. El CEO y las personas que asignaban el presupuesto examinaron lo que habían elegido los empleados y vieron que no eran proyectos en los que estuvieran dispuestos a gastar dinero. Así que, antes de que se desarrollara nada, el CEO cambió la selección.

Llevo 12 años trabajando en tecnología y nunca he sometido, ni sometería, una cuestión técnica a una votación de toda la empresa. La inclusión no es una opción que se activa para todo, y los responsables deben tener muchísimo cuidado al decidir en qué cuestiones dan participación. Pedir a toda la empresa que vote sobre los proyectos de IA se parece a la inclusión que te enseñan en la escuela, pero en la práctica es casi una broma. Se pide a las personas que tomen una decisión que no tienen forma de tomar y después ven cómo se anula. Eso no es solo una falta de respeto. Es desmotivador. Quienes dedicaron tiempo a pensar qué proyectos les ayudarían más descubren que su respuesta nunca contó, y lo tienen presente la próxima vez que la dirección les pide algo.

Para mí, este intento de inclusión es casi un ejemplo de manual de una concepción equivocada de la inclusión. Por buenas que fueran las intenciones, el método nunca podría haber dado un buen resultado. Así que en este artículo no quiero limitarme a mostrarte qué salió mal. Quiero mostrarte cómo lo habría hecho yo.

Nadie hizo la parte más difícil del trabajo: elegir

Sería fácil culpar al CEO por anular el resultado de la votación, pero creo que eso pasa por alto dónde estuvo realmente el error. Para empezar, la votación nunca debería haberse propuesto. No sé si la idea fue de los consultores o del CEO, pero, en cualquier caso, el CEO debería haberla frenado. Una empresa no pone en marcha un programa de IA sin tener alguna idea de cuánto está dispuesta a gastar y, en un encargo normal, cada proyecto incluye al menos una estimación aproximada de su coste. En cuanto comparas esas dos cifras, ya sabes que la mayoría de los treinta proyectos nunca se llevarán a cabo. Someterlos todos a votación significaba prometer a las personas una posibilidad de elegir que no existía.

Tampoco creo que los consultores terminaran su trabajo. Encontrar oportunidades es solo la mitad de aquello por lo que paga una empresa cuando contrata ayuda con la IA. La otra mitad es que le digan cuáles debe abordar primero, y así es como se suele entregar este tipo de trabajo. La propia guía de Microsoft para adoptar la IA indica a las empresas que puntúen cada posible caso de uso según su impacto en el negocio, su complejidad técnica, los recursos necesarios y su encaje con los objetivos, y que después «seleccionen los casos de uso de máxima prioridad» y los conviertan en una hoja de ruta. Gartner, la firma de investigación, ha descrito casos de clientes que parten de más de 600 posibles casos de uso de IA y les aconseja ordenarlos según su valor para el negocio y su viabilidad técnica antes de comprometer cantidades importantes de dinero. Un asesor que presenta treinta proyectos y después se aparta para que decida el cliente ha entregado un menú, no asesoramiento.

Elegir es el trabajo, y aquí tanto los consultores como la dirección se lo saltaron. Las empresas a las que mejor les va con la IA parecen saberlo. En una encuesta de 2024 a 1.000 directivos, Boston Consulting Group descubrió que las empresas líderes en IA persiguen aproximadamente la mitad de oportunidades que las demás y esperan obtener más del doble de retorno. Si la dirección no va a elegir entre treinta proyectos, ¿para qué está?

Los empleados votaron sin saber cuánto costaría cada proyecto ni qué retorno generaría

Esto no es una crítica a los empleados. Una persona de contabilidad sabe exactamente en qué se le va la semana. Sabe qué facturas tiene que introducir dos veces y qué informe mensual vuelve a elaborar a mano cada vez porque dos sistemas nunca muestran las mismas cifras. Una persona de recursos humanos sabe qué formularios nadie rellena correctamente. Siempre quiero contar con ese conocimiento, y la mayoría de las empresas lo aprovechan demasiado poco.

Pero priorizar proyectos de IA requiere un conocimiento completamente distinto. Hay que saber cuánto costará desarrollar cada proyecto y mantenerlo en funcionamiento, cuánto aportará y cuánto tardará en hacerlo. Hay que saber si los datos de los que depende existen y son fiables, que es a lo que se refiere la gente cuando habla de madurez de los datos. Y hay que saber qué debe hacerse primero, porque un modelo de previsión no sirve de nada si los datos de ventas en los que se basa son un desastre. Nada de eso se ve desde el departamento de contabilidad, así que las personas votan por el problema que sufren cada día o por lo que les parece más atractivo.

Recuadro informativo: qué significa la madurez de los datos

La madurez de los datos describe hasta qué punto están preparados los datos de una empresa para utilizarlos en algo más ambicioso que un informe mensual. En el nivel más bajo, la información está dispersa entre hojas de cálculo, sistemas que no se comunican entre sí y bandejas de entrada, y dos departamentos pueden dar dos respuestas diferentes a la misma pregunta. En el nivel intermedio, los datos están en un solo lugar, se han depurado y todo el mundo los define de la misma manera, por lo que las personas confían en ellos. En el nivel más alto, los datos fluyen casi en tiempo real y tienen la calidad suficiente para alimentar previsiones, automatizaciones e IA.

Esto importa a la hora de priorizar porque la mayoría de los proyectos de IA dan por supuesto, sin decirlo, que se parte del nivel más alto. Una previsión de demanda, un asistente comercial o un informe automatizado solo pueden ser tan buenos como los datos en los que se basan. Una empresa que está en el nivel más bajo y financia primero el proyecto atractivo suele acabar pagando de todos modos por el aburrido, solo que más tarde y a un precio mayor.

Una votación te dice cuántas personas sufren un problema. No te dice nada sobre el valor de resolverlo. Todos los departamentos tienen la misma voz, así que los proyectos que ganan suelen ser los que afectan al trabajo diario de más personas, no los que supondrían la mayor diferencia para el negocio. BCG descubrió que el 62 por ciento del valor que las empresas obtienen de la IA procede de funciones centrales como operaciones, ventas y desarrollo de productos, y no de funciones de apoyo como contabilidad y recursos humanos.

Elegir los proyectos equivocados le cuesta a una empresa más que el dinero que reserva para ellos. La mayoría de las empresas tienen un único equipo pequeño de datos y TI, y todos los proyectos de la lista compiten por esas mismas pocas personas, a menudo durante meses. Un proyecto desarrollado sobre datos en los que nadie confía produce paneles que nadie utiliza. Y mientras el equipo está ocupado con lo que haya ganado la votación, el trabajo que realmente marcaría la diferencia tiene que esperar. Muy a menudo se trata de la tarea poco vistosa de depurar primero los datos.

El CEO anuló el resultado de la votación antes de que se desarrollara nada

Si la dirección se hubiera limitado a elegir tres proyectos al principio, algunas personas habrían refunfuñado y todo el mundo habría seguido adelante. Anular el resultado de una votación es otra cosa. Cuando pides su opinión a las personas, prometes escucharlas. Cuando les pides que voten, prometes que su respuesta decidirá. Los investigadores que estudian la justicia han encontrado lo mismo: las personas valoran que se las escuche aunque no se haga lo que quieren, pero tener una voz que consideran sin influencia real puede hacer más daño que no tener voz en absoluto. Así que nunca sometas a votación una decisión que no estés dispuesto a dejar en manos de tus empleados.

La votación no solo fracasó a la hora de elegir los proyectos adecuados. También consumió la buena disposición que la empresa iba a necesitar más adelante, porque los proyectos de IA salen adelante o fracasan según si las personas realmente los utilizan. Los empleados que ven cómo se anula su voto aprenden que la verdadera decisión se tomó en otro lugar, con información que nadie les mostró, y lo recuerdan la próxima vez que se les pide que prueben algo nuevo.

Lo que yo habría hecho: dejar que las personas identifiquen los problemas y después priorizar cada idea según los datos, el coste y el beneficio

En mis propias empresas nunca dejamos que todo el mundo vote. Cuando priorizábamos nuevas funcionalidades o nuevos proyectos en CanopyLAB, no contábamos cuántas personas querían algo, porque lo que más se pide rara vez es lo más valioso. Analizábamos si los datos tenían la madurez suficiente para trabajar con ellos. Analizábamos la magnitud de la inversión, en dinero y en tiempo, y la dificultad del trabajo. Y analizábamos qué podíamos ganar si funcionaba. Así es como habría abordado esta lista de treinta proyectos.

1. Pide a los empleados que identifiquen problemas, no proyectos. Aquí es donde tiene sentido la inclusión. Pregunta a las personas en qué se les va el tiempo, qué hacen a mano que debería hacer un sistema y en qué casos las cifras que reciben no coinciden con la realidad. La persona de contabilidad es quien mejor puede decirte en toda la empresa que las cifras de ventas que recibe cada mes son incorrectas. No es quien debe averiguar por qué los datos están mal ni qué sistema debería corregirlos. Ese es el trabajo de la dirección.
2. Comprueba los datos antes que nada. Para cada idea, pregunta si los datos que necesita existen, si están depurados y si alguien es responsable de ellos. Si la respuesta es no, el proyecto espera o corregir los datos se convierte en el proyecto.
3. Calcula el coste total. Examina la magnitud total de la inversión. Eso significa el dinero, pero también cuánto tiempo llevará el proyecto y lo difícil que será desarrollarlo y mantenerlo en funcionamiento. Una idea que parece barata pero consume un año del tiempo del equipo de TI no es barata.
4. Calcula el beneficio. Pregunta qué obtiene realmente la empresa si el proyecto funciona. Puede ser dinero ganado o ahorrado, horas que las personas recuperan o menos errores. Cuantifícalo siempre que puedas y sé honesto sobre tu grado de certeza.
5. Decide y di que no abiertamente. Ordena las ideas según los datos, el coste y el beneficio, elige las pocas que encabecen la lista y explica a las personas qué ideas han quedado fuera y por qué. Un no acompañado de una razón mantiene la confianza de las personas. Una votación cuyo resultado se anula, no.
6. Vuelve a contar con los usuarios para hacer pruebas. Antes de poner nada en marcha, las personas que vayan a utilizarlo cada día deberían probarlo durante una jornada laboral normal. Detectarán lo que falla más rápido que cualquier consultor.

Aplica esos pasos a los treinta proyectos de mi cliente y la lista se ordenará rápidamente. Las ideas que no se apoyan en datos fiables caen al final o se convierten en un proyecto para depurar primero los datos. Las ideas caras que solo aportarían un pequeño beneficio quedan descartadas. Lo que queda es una lista corta que la dirección puede defender, porque cada no tiene una razón.

Cuando llegó la lista, parecía un mapa del futuro de la empresa. Para cuando el CEO cambió la selección, se había convertido en el registro de una decisión que la empresa intentó ceder y después tuvo que recuperar. Las papeletas, el recuento y la anulación del resultado fueron trabajo que la empresa hizo para evitar decir una frase al principio de todo: estos tres, y no los otros veintisiete.

¹ Todas las historias de esta serie son reales. Para proteger a mis clientes, cambio los detalles que podrían identificarlos, como el sector, los productos, el tamaño y la ubicación de la empresa, y los nombres de personas y proveedores. Lo que ocurrió, las decisiones que se tomaron y los motivos por los que salieron mal se mantienen tal como fueron.

Fuentes

• Boston Consulting Group, "Where's the Value in AI?", octubre de 2024.
• E. Allan Lind, Ruth Kanfer y P. Christopher Earley, "Voice, Control, and Procedural Justice", Journal of Personality and Social Psychology 59(5), 1990.
• Stacy G. Ulbig, "Voice Is Not Enough: The Importance of Influence in Political Trust and Policy Assessments", Public Opinion Quarterly 72(3), 2008.
• Microsoft, "Plan for AI adoption", Cloud Adoption Framework.
• Heather Wright, "The AI prioritisation problem", iStart, 2 de julio de 2026.