En muchas empresas la experimentación con inteligencia artificial ya ha empezado, aunque no siempre de una forma estructurada.
A veces surge desde un departamento que prueba una solución para mejorar una tarea concreta. Otras veces es IT quien impulsa un caso de uso, un proveedor quien propone una prueba o un equipo que empieza a utilizar IA para automatizar parte de un proceso, analizar información, mejorar la atención interna o trabajar con conocimiento corporativo.
El resultado es que empiezan a aparecer iniciativas interesantes en distintos puntos de la organización, pero no siempre existe una visión común sobre cuáles tienen verdadero potencial, cuáles deberían avanzar y qué hace falta para convertirlas en soluciones reales.
Y ahí es donde empieza el reto.
Porque probar una idea es relativamente sencillo, lo difícil es conseguir que esa prueba funcione con datos reales, se integre con los procesos existentes, cumpla con los requisitos de seguridad y gobernanza, sea utilizada por las personas y, además, genere un impacto que justifique seguir invirtiendo en ella.
Por eso, cuando hablamos de Pruebas de Concepto en IA, creo que la conversación debería ir bastante más allá de demostrar que una tecnología funciona.
Una buena PoC debería ayudarnos a tomar decisiones.
Qué es realmente una Prueba de Concepto en IA
Una Prueba de Concepto o PoC es un experimento limitado que permite comprobar si una idea tiene suficiente viabilidad antes de escalarla y comprometer más recursos.
En inteligencia artificial esto es especialmente importante porque muchas soluciones pueden ofrecer resultados muy prometedores en un entorno controlado y comportarse de una manera bastante diferente cuando entran en contacto con la realidad de una empresa.
Por ejemplo, podemos comprobar que una solución es capaz de consultar determinada documentación y devolver respuestas de calidad. Eso demuestra una parte de la viabilidad técnica, pero todavía no nos dice si podrá trabajar con toda la documentación corporativa, si tendrá acceso únicamente a la información que corresponda a cada usuario, si los datos están suficientemente actualizados o si el coste seguirá teniendo sentido cuando aumente el volumen de uso.
Por eso una PoC debería ayudarnos a reducir incertidumbre en varias dimensiones.
Tenemos que saber si la solución funciona técnicamente, pero también si disponemos de los datos necesarios, si aporta un valor suficientemente claro al negocio, si puede integrarse con los sistemas existentes, si las personas la utilizarán y qué riesgos debemos gestionar antes de llevarla más lejos.
También conviene distinguir entre PoC, prototipo, piloto y MVP, porque muchas veces utilizamos estos términos indistintamente.
Una PoC busca comprobar si una idea es viable. Un prototipo nos ayuda a explorar cómo podría funcionar la solución. Un MVP incorpora lo mínimo necesario para empezar a generar valor y un piloto permite probarla en un entorno mucho más próximo a la realidad.
Más que discutir sobre cómo llamar a cada fase, lo importante es saber qué queremos validar en cada una y qué información necesitamos para decidir si avanzamos.
El problema del pilot purgatory
Uno de los fenómenos que estamos viendo en muchas organizaciones es la acumulación de pruebas que nunca terminan de llegar a producción.
Se hacen pilotos, se obtienen algunos resultados, se presentan internamente y durante un tiempo parece que el proyecto va a continuar. Pero después empiezan a aparecer otras prioridades, dependencias técnicas, dudas sobre los datos, necesidades de integración o preguntas sobre seguridad y el proyecto se queda en una especie de limbo.
Es lo que suele denominarse pilot purgatory.
Y con la inteligencia artificial es fácil que ocurra porque hoy podemos experimentar con mucha más rapidez que hace unos años.
Esto tiene la parte positiva de que permite aprender, probar hipótesis y descartar ideas con una inversión relativamente pequeña. Pero por otro lado, el problema aparece cuando confundimos la facilidad para construir una primera versión con la facilidad para implantarla.
Una prueba puede funcionar perfectamente con un conjunto de información cuidadosamente seleccionado y empezar a fallar cuando tiene que enfrentarse a los datos reales de una organización.
Puede ocurrir que existan documentos duplicados, versiones antiguas, fuentes diferentes, permisos poco claros o información que ni siquiera está estructurada para ser utilizada de esa manera.
También podemos desarrollar una automatización que funciona correctamente en los casos más habituales y descubrir posteriormente que el proceso real está lleno de excepciones que requieren decisiones humanas.
Antes de construir, hay que elegir bien qué problema merece una PoC
Una de las partes más importantes de cualquier proyecto de IA ocurre antes de empezar a desarrollar.
Hay que decidir dónde merece la pena experimentar.
En una organización pueden aparecer decenas de posibles casos de uso y no todos deberían convertirse en una Prueba de Concepto.
Antes de aprobar una iniciativa me parece mucho más útil entender primero qué problema estamos intentando resolver y qué impacto tiene actualmente.
¿Dónde se pierde tiempo? ¿Dónde se producen errores? ¿Qué procesos están generando fricción? ¿Qué información es difícil de localizar? ¿Qué decisiones podrían tomarse mejor si dispusiéramos de más información o de mayor capacidad de análisis?
A partir de ahí podemos valorar si la IA tiene realmente sentido.
Para priorizar casos de uso suelo fijarme especialmente en cinco variables.
- El impacto potencial. Qué cambiaría para el negocio si solucionáramos el problema.
- La viabilidad. Si la tecnología disponible permite abordar razonablemente ese caso de uso y con qué nivel de complejidad.
- Los datos. Qué información necesitamos, dónde está, qué calidad tiene, quién puede acceder a ella y si realmente podemos utilizarla.
- El riesgo. Las consecuencias de un error pueden ser completamente diferentes dependiendo del proceso en el que estamos incorporando IA.
- La escalabilidad. Una solución puede tener mucho sentido para un equipo reducido y dejar de ser viable cuando intentamos extenderla a toda la organización.
Esto ayuda a ir con más claridad y evitar que las prioridades se definan únicamente porque una tecnología está de moda, porque un proveedor ha presentado una buena demo o porque un departamento tiene más capacidad para impulsar su propuesta.
Cómo saber si una Prueba de Concepto ha funcionado
Uno de los errores más frecuentes es definir el éxito después de conocer los resultados. Si queremos evaluar una PoC con criterio, los indicadores deberían estar claros antes de empezar.
Una solución puede funcionar muy bien desde el punto de vista tecnológico y no generar suficiente valor para justificar su implantación.
Puede ser precisa, pero demasiado cara.
Puede ahorrar tiempo, pero no encajar en la forma de trabajar de los usuarios.
Puede tener buena adopción, pero introducir riesgos que hagan necesario replantear completamente el diseño.
Por eso necesitamos combinar distintas dimensiones.
En negocio podemos medir reducción de tiempos, costes, errores, mejora de productividad, aumento de capacidad o impacto sobre ingresos.
En la parte técnica tendremos métricas específicas según el caso de uso. Precisión, calidad de respuesta, latencia, disponibilidad o tasa de error, entre otras.
Cuando trabajamos con IA generativa también necesitaremos evaluar aspectos como las respuestas incorrectas, las alucinaciones o la capacidad de recuperar correctamente la información que sirve de base para generar una respuesta.
Y después está el usuario.
Aquí muchas organizaciones todavía miden poco.
No basta con saber cuántas personas tienen acceso a una herramienta. Tenemos que observar si realmente la utilizan, para qué la utilizan, en qué momentos dejan de hacerlo y si la solución está mejorando o complicando su trabajo.
¿Y si la PoC funciona?
Esta es una de las preguntas que más información revela sobre el nivel de madurez del proyecto.
Supongamos que los resultados son buenos.
¿Qué ocurre a continuación?
- Quién será responsable de la solución.
- Qué equipo la mantendrá.
- De qué presupuesto saldrá.
- Qué sistemas necesitamos integrar.
- Cómo gestionaremos los accesos.
- Qué soporte tendrán los usuarios.
- Qué ocurrirá cuando haya una incidencia.
- Cómo controlaremos los costes.
- Quién comprobará que la solución sigue ofreciendo resultados adecuados dentro de seis meses.
Durante una PoC pequeña podemos permitirnos cierta provisionalidad.
En producción, no.
Cuando una solución pasa a formar parte de la operativa de la empresa necesitamos pensar en seguridad, identidad, permisos, monitorización, trazabilidad, mantenimiento, testing, gestión de costes y continuidad.
También habrá que decidir dónde necesitamos supervisión humana.
Hay procesos en los que la IA puede asumir una parte importante del trabajo y otros donde su función debería ser apoyar a la persona que toma la decisión.
Por eso creo que el camino hacia producción debería empezar a diseñarse durante la propia PoC.
No necesitamos resolver desde el primer día todos los detalles de la implantación, pero sí saber cuáles son las condiciones que tendremos que cumplir si la prueba demuestra que merece avanzar.
AI Governance desde el principio, pero de forma proporcional
La gobernanza de IA no debería entrar en escena cuando el proyecto ya está terminado.
Si esperamos hasta ese momento podemos descubrir que determinados datos no pueden utilizarse como habíamos previsto, que existen requisitos de seguridad que obligan a cambiar la arquitectura o que el nivel de riesgo requiere controles que nunca se contemplaron.
Eso no significa llenar cada experimento de procesos y aprobaciones.
Una PoC interna de bajo riesgo no necesita el mismo nivel de control que una solución que vaya a participar en una decisión de alto impacto.
Pero incluso durante una prueba deberíamos saber qué datos estamos utilizando, qué proveedor interviene, quién puede acceder a la información, qué decisiones toma el sistema y qué nivel de supervisión humana necesitamos.
También tendremos que identificar las obligaciones regulatorias que correspondan en cada caso, incluido el Reglamento Europeo de Inteligencia Artificial cuando resulte aplicable.
Gobernar desde el principio evita tener que reconstruir el proyecto cuando ya hemos invertido demasiado en él.
La adopción también forma parte de la prueba
Podemos construir una solución técnicamente excelente y fracasar completamente si las personas no la incorporan a su trabajo.
Y esto no debería descubrirse después del despliegue.
Una PoC también nos permite entender cómo reaccionan los usuarios, qué dudas tienen, dónde aparece resistencia y qué nivel de formación necesitan.
Con inteligencia artificial hay además una cuestión especialmente importante, la confianza.
Los empleados tienen que aprender qué puede hacer la solución, qué no puede hacer, cuándo pueden apoyarse en una respuesta y cuándo necesitan revisarla.
No se trata solamente de enseñar a utilizar una herramienta.
Es entender las capacidades y las limitaciones de la IA para utilizarla con criterio.
Durante estas primeras pruebas suelen aparecer además personas que experimentan más, encuentran nuevos casos de uso y ayudan de forma natural a otros compañeros.
Esos perfiles pueden convertirse posteriormente en AI Champions y jugar un papel importante cuando llegue el momento de ampliar la implantación.
De proyectos aislados a un portfolio de IA
Cuando una organización tiene una o dos iniciativas, todavía puede gestionarlas de manera informal. Pero a medida que la experimentación crece, empieza a ser necesario tener una visión conjunta.
Puede haber proyectos impulsados desde IT, otros desde negocio, pruebas contratadas con proveedores y herramientas que diferentes departamentos han empezado a utilizar por su cuenta.
Si nadie tiene una visión global, empiezan a aparecer duplicidades, costes que se solapan y proyectos muy parecidos desarrollándose al mismo tiempo.
Ahí es donde tiene sentido gestionar un portfolio de iniciativas de IA.
Como mínimo necesitamos saber qué problema intenta resolver cada iniciativa, quién es responsable, qué impacto esperamos, qué datos utiliza, qué riesgos presenta, en qué fase está y qué resultados está obteniendo.
Esto permite comparar proyectos con criterios comunes y decidir dónde merece la pena seguir invirtiendo.
También ayuda a diferenciar entre quick wins, iniciativas estratégicas que necesitarán más tiempo y experimentos que todavía tienen que demostrar su valor.
Un modelo Stage-Gate ayuda a no eternizar los pilotos
Cuando el número de iniciativas empieza a crecer, trabajar con puertas de decisión puede ser especialmente útil.
La primera fase consiste en evaluar la oportunidad. Queremos saber si existe un problema suficientemente relevante y si merece la pena dedicar recursos a explorarlo.
Después viene la Prueba de Concepto, donde intentamos reducir las principales incertidumbres y comprobar la viabilidad.
Si los resultados justifican continuar, podemos pasar a un piloto en condiciones mucho más próximas a la realidad, con usuarios, procesos y datos reales.
La siguiente decisión es si la solución está preparada para producción.
Y solo después tiene sentido hablar de escalado a más equipos, procesos, mercados o países.
Lo importante es que entre cada fase exista una decisión.
- Continuar.
- Modificar.
- O detener.
Una organización madura no debería tener miedo a ninguna de las tres.
¿Tu empresa ya está realizando pruebas con IA pero cuesta decidir cuáles deberían avanzar?
Antes de lanzar nuevas iniciativas puede ser más útil revisar qué casos de uso existen, qué problema intenta resolver cada uno, qué resultados están generando, qué riesgos presentan y qué necesitan para llegar a producción.
Un AI Transformation permite ordenar las iniciativas actuales, priorizar aquellas con mayor potencial y construir una hoja de ruta para pasar de la experimentación a una implantación real de la inteligencia artificial.
Porque no siempre necesitamos más pilotos.
Muchas veces necesitamos tener más claro cuáles merece la pena escalar.
