IA en la Gestión de Proyectos: ¿un caballo de Troya? [general]

Autor: Beñat Descalzo Alcuaz (equipo Ada Byron)

Pocas tecnologías han sido tan disruptivas en los últimos años como la IA generativa. Está afectando, ya sea bienvenida o por la fuerza, a todo trabajo que pueda realizarse en un ordenador (desde la generación de código hasta la -polémica- generación de ilustraciones). Por supuesto, la barbarie burocrática asociada a la gestión de un proyecto no iba a ser menos.

El director afronta la tarea de armonizar documentos sueltos, densos y potencialmente contradictorios: especificaciones formales del cliente, comunicaciones con el mismo, especificaciones internas de la organización, regulaciones pertinentes, y un largo etcétera. A la hora de planificar un proyecto es fácil mezclar mentalmente requisitos (especialmente cuando el tiempo para revisar la planificación es limitado), olvidar alguno de los puntos relevantes, o pasar por alto contradicciones sin resolver entre la organización y el cliente. Por supuesto, una de las primeras líneas de fuego debería ser siempre la revisión de calidad sobre la propia planificación, pero la idea se mantiene: en muchos casos, es altamente propensa a errores.

¿Puede ayudar la IA con este problema? Creemos que sí, pero hay que tener cuidado. En base a nuestra experiencia usándola para gestionar los proyectos P2.2 y P2.3 de la organización, estas son algunas de las lecciones que hemos aprendido:

- En tareas ajenas al ámbito técnico, y con muchos documentos, los modelos de lenguaje disponibles a día de hoy siguen perdiéndose en el contexto, lo que puede llevar a alucinaciones graves. En la primera parte ofrecemos un ejemplo de este problema, además de proponer una solución (simplificar y atomizar las solicitudes individuales).

- Incluso en tareas en las que el modelo no alucina información falsa, existe un problema: para toda la información que no des explícitamente, la IA va a trabajar con los supuestos que surjan en su proceso de generación. Es necesario ser extraordinariamente explícito, incluso en detalles aparentemente obvios al humano, en cada una de las peticiones a un modelo, y vigilar cautelosamente la salida. En la segunda parte ofrecemos un ejemplo en el contexto del desarrollo de un sitio web para P2.3. Si bien es un ejemplo de desarrollo y no de gestión, es muy demostrativo del riesgo que queremos documentar.

CONCLUSIÓN

Si no se usan con harto cuidado, los LLM son el caballo de Troya del mundo moderno: sus outputs son tan razonables a la vista que cuesta descubrir por qué son tan destructivos. Un director de proyectos puede integrar estos modelos en su trabajo, y probablemente le sean útiles para acelerar la labor o mejorar la calidad en infinidad de tareas, pero debe ser consciente en todo momento de las limitaciones a las que se enfrenta con estas herramientas.

Por supuesto, como añadido, cuidado con la dependencia excesiva en la organización. El coste operativo de estos modelos supera con creces el precio actual que refleja el mercado, y algunos cambios en la industria apuntan a una burbuja económica que podría estallar pronto. Son herramientas utilísimas, pero un objetivo fundamental de toda organización debe ser evitar tenerlas como punto de fallo único; sus trabajadores deberían ser capaces de ejercer por su cuenta toda labor que deleguen en los modelos.

Ya lo decía IBM en sus manuales allá por 1979[5]: "A COMPUTER CAN NEVER BE HELD ACCOUNTABLE, THEREFORE A COMPUTER MUST NEVER MAKE A MANAGEMENT DECISION". Esta máxima, hoy más que nunca, es esencial; ignorarla es el camino al desastre.

REFERENCIAS

[5] "AI decision-making: Where do businesses draw the line?", Doug Bonderud (IBM): https://www.ibm.com/think/insights/ai-decision-making-where-do-businesses-draw-the-line.

No comments:

Post a Comment