Las seis fases de la metodología CPMAI

Fase I. Comprensión del negocio (Business Understanding)

Esta primera fase me resulta especialmente cercana por mi vinculación con el análisis de negocio.

Antes de plantearnos qué modelo utilizar o qué tecnología incorporar, necesitamos comprender qué problema queremos resolver y por qué consideramos que la inteligencia artificial puede ser una solución adecuada.

Parece que esto es algo obvio, pero no siempre lo es.

En ocasiones, la decisión de utilizar una tecnología precede al análisis de la necesidad. Primero decidimos que queremos incorporar IA y después buscamos dónde aplicarla.

CPMAI plantea justamente lo contrario.

Durante esta fase se trabaja en la identificación del problema, la comprensión de los interesados, la definición de objetivos y criterios de éxito, la evaluación inicial de viabilidad y el análisis del retorno esperado.

También se identifica qué patrón o patrones IA pueden encajar con el caso de uso.

Y aquí recuperaría una pregunta que considero fundamental en cualquier iniciativa de transformación: ¿estamos seguros de que necesitamos IA para resolver un problema?

Puede que la respuesta sea afirmativa, pero también puede ocurrir que una mejora de un proceso, una automatización basada en reglas o una modificación de los sistemas existentes resulte más sencilla y perfectamente suficiente.

No utilizar IA también puede ser una buena decisión de negocio.

Fase II. Comprensión de los datos (Data Understanding)

Una vez identificado el problema y planteada una posible solución, necesitamos comprender los datos con los que vamos a trabajar.

Y esto va bastante más allá de saber que existe una base de datos o que podemos extraer información de determinado sistema.

Hay que identificar fuentes, conocer su origen, comprender su significado, analizar su calidad y comprobar si realmente responden a las necesidades del proyecto.

También necesitamos revisar cuestiones relacionadas con la privacidad, la seguridad, los permisos de acceso y las restricciones legales sobre su utilización.

Vuelvo al ejemplo de la aseguradora.

Podríamos disponer de millones de registros históricos y descubrir que algunos campos relevantes se han utilizado con criterios diferentes a lo largo de los años, que existen datos incompletos o que las clasificaciones realizadas por distintas áreas no son homogéneas.

Tener muchos datos no significa necesariamente disponer de buenos datos.

Desde la perspectiva de la gestión de proyectos de IA, me parece fundamental identificar e involucrar desde el principio a quienes conocen el significado de los datos y el contexto en el que se generan. Sin ese conocimiento, corremos el riesgo de considerar válida información que, aunque técnicamente parezca adecuada, puede comprometer la fiabilidad del modelo y los resultados del proyecto.

Fase III. Preparación de los datos (Data Preparation)

Si la fase anterior permite comprender qué información tenemos y qué necesitamos, esta se centra en conseguir que los datos sean adecuados para desarrollar la solución.

Hablamos de limpieza, tratamiento de valores ausentes, normalización, integración de fuentes, transformación, etiquetado y preparación de los flujos de datos que utilizará el modelo.

Puede parecer un trabajo principalmente técnico, pero también tiene implicaciones importantes para la gestión del proyecto.

Los problemas de calidad pueden afectar a los plazos y obligarnos a revisar hipótesis que inicialmente dábamos por válidas.

Además, determinados tratamientos pueden modificar el comportamiento del modelo. Por eso necesitamos documentar las transformaciones y garantizar que los resultados puedan reproducirse.

Desde mi experiencia en gestión de procesos, veo aquí una conexión interesante. Los datos no aparecen por generación espontánea. En una organización se crean, modifican y utilizan mediante actividades y procesos concretos.

Si un proceso genera información incompleta, inconsistente o difícil de interpretar, podemos invertir enormes esfuerzos en preparar esos datos para una solución de IA y seguir teniendo el mismo problema de origen.

En numerosas ocasiones, mejorar la calidad de los datos exige revisar también cómo trabaja la organización.

Fase IV. Desarrollo del modelo (Model Development)

Llegamos a la parte que probablemente más personas relacionan con un proyecto de IA.

Seleccionamos las técnicas y herramientas adecuadas, entrenamos o adaptamos modelos, ajustamos parámetros y realizamos pruebas para comprobar su comportamiento.

Dependiendo del caso, podemos trabajar con técnicas de aprendizaje supervisado, no supervisado, modelos preentrenados o soluciones de IA generativa.

Lo interesante desde la perspectiva de dirección de proyectos es que no necesitamos convertirnos en científicos de datos para comprender qué decisiones debemos gestionar.

Lo que sí necesitamos, es conocer las implicaciones de las alternativas, sus dependencias, recursos necesarios y riesgos asociados.

Y debemos aceptar que el desarrollo puede requerir varias iteraciones antes de encontrar una solución satisfactoria.

Un resultado insuficiente puede deberse a la técnica utilizada, a la configuración del modelo o incluso a problemas en los datos que inicialmente no habíamos identificado.

Avanzar no siempre consiste en desarrollar más funcionalidades. A veces consiste en volver a una fase anterior y corregir una hipótesis.

Fase V. Evaluación del modelo (Model Evaluation)

Probablemente la fase que más claramente demuestra la necesidad de combinar conocimientos técnicos y de negocio.

Una cosa es que el modelo sea técnicamente perfecto y otra que sus resultados sean suficientemente buenos para el uso que pretendemos darle.

Podemos evaluar aspectos como la precisión, sensibilidad, falsos positivos o la capacidad de generalización, dependiendo del tipo de solución, pero esas métricas, por sí solas, no responden a todas las preguntas.

Regresemos al ejemplo de detección de fraude.

Un modelo podría identificar correctamente muchos casos sospechosos y, al mismo tiempo, generar tantas alertas injustificadas que el equipo encargado de investigarlas no tuviera capacidad de gestionarlas. ¿Podríamos considerar exitoso ese modelo?

Técnicamente, podría ofrecer resultados interesantes, pero operativamente, quizá estaríamos creando un nuevo problema.

Por eso CPMAI contempla la evaluación del rendimiento técnico junto con indicadores de negocio, riesgos y las condiciones necesarias para utilizar la solución.

También resulta necesario comprobar posibles sesgos, requisitos de explicabilidad y cumplimiento normativo.

Esta fase permite por tanto, tomar una decisión especialmente relevante: continuar, revisar el trabajo o descartar el despliegue.

Y creo que conviene recordar algo que a veces cuesta asumir: decidir no poner en producción una solución que no cumple los criterios establecidos también puede ser una decisión correcta de gestión.

Fase VI. Puesta en operación (Model Operationalization)

Aquí aparece otra conexión directa con la gestión de procesos y la transformación de las organizaciones, ya que desarrollar un modelo que funciona en un entorno de pruebas no significa que la organización esté preparada para utilizarlo.

Necesitamos integrarlo con sistemas y procesos existentes, establecer mecanismos de seguimiento, definir responsabilidades y preparar a las personas que trabajarán con la solución.

Además, los modelos de IA pueden perder rendimiento cuando cambian los datos o las condiciones del entorno. Es lo que conocemos, entre otros fenómenos, como data drift o model drift:

• Hablamos de data drift cuando los datos que recibe un modelo cambian con el tiempo respecto a los que se utilizaron para entrenarlo. Por ejemplo, si cambian el perfil de los clientes o sus hábitos, el modelo puede empezar a ofrecer resultados menos fiables, aunque inicialmente funcionara correctamente.
• Hablamos de model drift cuando el rendimiento de un modelo se deteriora con el tiempo y empieza a ofrecer resultados menos fiables que cuando se puso en funcionamiento. Por ejemplo, un modelo diseñado para detectar operaciones fraudulentas puede perder precisión porque aparecen nuevas formas de fraude que no había aprendido a identificar durante su entrenamiento.

Por todo esto debemos contemplar la monitorización, el control de versiones, la gestión de incidencias y los posibles procesos de reentrenamiento, sin olvidar la adopción.

Podemos desarrollar soluciones técnicamente excelentes que nunca lleguen a incorporarse de verdad a la operativa, porque los usuarios no confían en sus resultados, porque no comprenden cómo utilizarlas o porque necesitan mantener procedimientos paralelos para comprobar todo lo que hacen.

Este problema no es exclusivo de la IA. Lo encontramos constantemente en iniciativas de transformación.

Lo particular es que, en este caso, además de conseguir que la solución se utilice, necesitamos comprobar que continúa funcionando correctamente a medida que cambian las condiciones en las que opera.