Por Ricardo Davis vía Blog Bilbao.ai
Según Wikipedia, que cita a Stephen B. Hulley, “un estudio piloto, proyecto piloto o experimento piloto es un estudio preliminar a pequeña escala realizado para evaluar la viabilidad, duración, coste, adversidades, y mejorar el diseño de estudio antes del desarrollo de un proyecto de investigación a gran escala”, lo que descalifica el uso de pilotos así concebidos en la implantación de la IAG en la empresa. Es decir, que esta definición de proyecto piloto no funcionará con los pilotos AIG. Y me explico.
EL PILOTO COMODÍN
Un piloto software es un proyecto concebido para comprobar que determinadas tecnologías, presentadas en informes, notas de prensa, artículos en LinkedIn y, sobre todo, en presentaciones PowerPoint de consultoras, “funciona” (en el sentido de que es práctico, rentable y posible) en la empresa. El problema es que todos los proyectos software finalmente funcionan. Claro que la implantación probablemente se habrá extendido más allá de lo previsto, y los costes también; pero esto se mitiga asumiendo que se trata de un mero piloto, pues en el desarrollo final completo lo haremos mejor porque no cometeremos estos errores ni se nos darán tales desviaciones. Y tampoco el piloto funcionará exactamente como estaba previsto, porque resultará que el diseño técnico no arroja los resultados esperados, debido a que la tecnología no estaba tan madura como pensábamos (como alguien pensaba, vamos). Y, claro, como se trata de un piloto, su productividad real es muy limitada, pues no se integra en los procesos esenciales de la compañía y su utilización es más bien la de una “commodity” o “amenity” (utilizando la jerga del “hospitality” J), pues el piloto sólo se utilizará y validará por un conjunto de personas integrantes de la organización y elegidas para el uso y chequeo de ese piloto; lo que significará que en realidad el piloto no se llega a testar en la organización global. El resultado final es que el proyecto piloto sólo ha servido para plantar una piedra presupuestaria que permita a la dirección de la empresa discontinuar esa línea y no abordar más proyectos similares (“tal como dijimos, el piloto no ha funcionado como la tecnología prometía, que no está todavía madura para ser utilizada en nuestra empresa”), o exactamente para lo contrario (“la inversión realizada nos ha ofrecido unos resultados ilusionantes, que todavía tienen que ser refinados profundamente, pero que nos animan a continuar en esa misma dirección”). En definitiva, el piloto, sea cual fuere su resultado, sirve tan sólo como apoyatura en la toma de decisiones para el equipo directivo de la empresa, por lo que la aprobación del piloto en sí supone la piedra angular de tal estrategia (sea la que sea).
MEJORAS SIN MEDIDA
Y si lo anterior es asunto sabido para los pilotos software en general, imaginen la exacerbación que se produce en los pilotos IA, que usualmente siguen a la estela del efecto Wow generado por demostraciones de ChatGPT, adláteres o de alguna herramienta específica de IAG (Firefly, Runway, Decktopus, Synthesia, Midjourney, etc.). Lo que tenemos en la mano es un Wow persistente que nos hace pensar que cualquier aplicación de estas maravillas en la empresa de seguro valdrá la pena, aunque sea en pequeña medida. Y aquí empiezan a darse excesos que nunca hubiéramos pensado que aceptaríamos, como, por ejemplo, la posible mejora sin medida. O lo que es lo mismo: la asunción de un porcentaje de mejora u optimización tan importante que no necesite ser medido, por su grandísima evidencia. O, para entendernos, la falta de KPIs en el piloto IAG.
Resulta que con los proyectos IA lo que quieren las empresas es asombrarse: es decir, alcanzar una ratio perceptible de optimización/coste tan brutal que inste a su desarrollo ulterior en un ramillete de proyectos IA sin tener que justificar exactamente su valía (“porque es evidente”).
IA AD HOMINEM
Es interesante resaltar que en un típico proyecto piloto IA no se testan las opciones tecnológicas utilizados, sino al testador mismo.
Cuando Bloomberg decide meterse en harina con un proyecto propio de LLM financiero de 50 mil millones de parámetros lo hace confiado en promesas tecnológicas de que un LLM especializado batirá fácilmente a un gran modelo de lenguaje generalista como ChatGPT4; lo cual suena plausible, claro. Pero cuando los resultados de ChatGPT4 mejoran, en general, los de ese proyecto, no se estima que las decisiones tecnológicas no hayan “funcionado” como se esperaba, sino que se anuncia que las áreas menores de mejora de su modelo sobre la competencia generalista son las importantes y en las que hay que poner el foco para proseguir el proyecto “en esas direcciones de impresionante mejora”. Así que el foco se sitúa en algunos aspectos funcionales del piloto, lo cual es ciertamente necesario, pero nunca suficiente.
TOPPING PILOTADO
La necesidad comercial de demostrar que un producto (concebido hace unos años y actualmente en el mercado) es “cool” y está actualizado conduce rápidamente a la obligación de implementar en el mismo alguna característica o funcionalidad de IAG. Y así aparecen los pilotos de topping IA: se esparce IAG por encima del producto actual como si fuera espirulina en polvo o virutas de chocolate… inteligente, claro.
Los productos que fueron concebidos y comercializados entre 2020 y 2022 son los que más han parecido necesitar este topping IA, por lo que se han abordado pilotos de todo tipo que, en puridad, no son tales. Porque no se trata de probar ni verificare nada, sino más bien de ensayar tecnologías que forzosamente han de incluirse en estos productos, sea cual sea el coste (intentando disminuirlo, claro) y sea cual sea el resultado (intentando que sea, al menos parcialmente, generativo, utilizando LLMs).
Siguiendo este criterio casi todos los programas y plataformas software han incluido algún botón del tipo “generar X con la IA”, para sugerirnos textos, resumir documentos o generar imágenes o código. Sin duda, en estos casos el piloto somos nosotros, los perplejos usuarios.
EL ABORDAJE DEL PILOTAJE
¿Existe alguna manera de conceptuar y dirigir el piloto de forma correcta? ¡Por supuesto que no! Porque la corrección es un valor que depende del marco evaluador del piloto y, como hemos visto, tal marco puede ser, objetiva y subjetivamente, muy variado.
Lo que sí podemos es ponderar algunas métricas sobre las características del piloto, y exigir que su diseño e implantación se ajusten a aquéllas. Lo importante, naturalmente, es saber qué métricas (o consideraciones) son éstas:
- Reutilización parcial del resultado del piloto: la doctrina comúnmente aceptada de la ingeniería de software promueve que los pilotos sean destruidos cuando hayan demostrado (o dejado de demostrar) la hipótesis y expectativas sobre las que fue construido, de manera que el proyecto que se aborde seguidamente no se apoya en sus endebles y apresuradas bases (se trata de un piloto), sino que desarrolle unas nuevas y más sólidas basadas en la experiencia adquirida en el tal piloto. Pero teniendo en cuenta la rapidísima evolución tecnológica, superior a la de ejecución de los pilotos, este enfoque nihilista no es aconsejable. En realidad, el piloto, más allá del uso de la tecnología IAG, debe ahondar en los entornos software y en los ambientes organizativos en los que va a ser usado; y estos aspectos deberían aprovecharse para sostener una nueva iteración tecnológica (en el próximo piloto o proyecto). Así, por ejemplo, un piloto jurídico debería construir un marco de uso de la IAG (jurisprudencia, doctrina, argumentación) incrustado con el modus operandi de los abogados (expedientes, escenarios, valoraciones de idoneidad, cuestiones de contexto libre, documentación ligada a resultados, etc.). Este marco debería persistir y ser refinado, aunque la parte intermedia pudiera cambiar (el uso técnico de un SMOE open source y una pila RAG ad hoc podrían ser sustituidos, por ejemplo, por la utilización de Microsoft Azure OpenAI con su librería aceleradora RAG).
- Pilotaje organizativo del marco IAG: si bien el núcleo del piloto usualmente no se puede extender a toda la empresa, sí parece razonable que la herramienta marco del mismo se teste por el mayor número posible de personas, reduciendo únicamente el ámbito de las funcionalidades IAG añadidas a tal marco. De esta manera, por ejemplo, una herramienta corporativa en pilotaje podría contener generadores de imágenes o sugerencias para construir presentaciones. Así, al finalizar el piloto será posible evaluar la facilidad de uso de la herramienta, su idoneidad para sus fines previstos y, sobre todo, su capacidad de integrarse con los procesos rutinarios de los empleados y stakeholders de la empresa.
- Evaluación del equipo de desarrollo del piloto: de la misma forma que en Japón (y cada vez en más países) se necesita un contacto personal que ponga a prueba y afiance la incipiente relación de negocio, el piloto debe poner a prueba la capacidad del equipo que lo diseña e implanta, sobre todo si se tiene claro que la IAG está para quedarse y que es inevitable abordar más proyectos de calado IAG en la empresa. De esta forma, lo que se chequea es la capacidad del equipo de trabajo, su habilidad para integrarse en la organización cliente, su flexibilidad en el abordaje de cambios de requerimientos, su gestión racional del riesgo tecnológicos asociado a la implantación de LLMs y, sobre todo, su comprensión global del negocio actual de su cliente y su envisionamiento del negocio futuro en integración con la IAG. Hay que decir, con todo, que este chequeo resultaría muy caro si no se diera el aprovechamiento software y organizativo detallado en los dos puntos anteriores.
- Gestión del cambio tecnológico: durante el desarrollo del piloto se producirán avances y retrocesos en diferentes áreas sensibles (y muy sensible es, por ejemplo, el parche arquitectónico RAG para la infusión y contextualización de prompts y también para la referenciación de documentos concretos en las respuestas). Antes de abordar una solución basada en las presunciones arquitectónicas del equipo de desarrollo se deberán plantear escenarios tecnológicos diferentes que contemplen estrategias también diversas para estas zonas sensibles, susceptibles de cambios de valoración o de la aparición de herramientas de soporte (que inutilicen tácticas de construcción ad hoc, por ejemplo). Se construirá, así, un piloto más robusto ante los cambios, pues cada escenario contemplará pros y contras y una valoración de migración desde otros escenarios, lo que sin duda conducirá a adoptar para el piloto la mejor solución base: esto es, la más sencilla de migrar a otros escenarios. Por esta razón, así explicada, los pilotos razonables tienden más a pagar-y-usar (utilizando plataformas y productos IAG SaaS) que a pagar-y-construir.
- Configuración e integración en lenguaje natural: una consecuencia evidente de la implantación de IAGs en el entorno empresarial es la posibilidad de utilizar interfaces conversacionales no sólo para operar con los LLMs, sino también para configurar su ajuste y también su integración. Así que testar estas funcionalidades en el piloto debería ser obligado. De esta manera se podrían realizar ajustes finos por los propios usuarios, sin necesidad de involucrar al -tantas veces denostado- departamento de sistemas de información: “debes considerar también un CIF al código que contenga guiones, como B-111111111”, o “cambia el correo de notificación de este expediente a xxx@xxxxx.com”. Usualmente este tipo de funcionalidad produce un efecto inmediato de empoderamiento en la organización cliente, por lo que su inserción como objetivo del pilotaje parece incuestionable.
Además de lo anterior, podrían darse también otras métricas que tengan que ver con variaciones sobre el modelo de comunicación, interno y externo, de la empresa, como consecuencia del uso de LLMs; o las asociadas a los costes de formación del personal. En fin: se trata, como ven, de asimilar que los pilotos son, en realidad, área directa de influencia de la consultoría estratégica.
PILOTOS Y COPILOTOS
Por fin, ¿quién (co-)pilotará estos proyectos piloto AIG? He aquí una pregunta necesaria. El piloto debería ser la empresa, el copiloto sería el equipo de dirección y de consultoría estratégica/negocial del proveedor tecnológico, y el cuerpo de boxes el resto del equipo técnico. Pero, como ocurre con la conducción de vehículos, tal vez haya que compaginar roles para lidiar con el cansancio con condiciones de conducción especiales (nieve, lluvia, tormentas… técnicas, etc.). Y el mejor consejo para quien quiera que pilote un proyecto IAG sería… ¡cuidado al empuñar el volante!
