Ayer tuve la oportunidad de presentar “Del problema al modelo: el rol del profesional que conecta IA y organización” en la sede San Joaquín de Duoc UC.
Fue una experiencia distinta y enriquecedora. Me habría gustado contar con una participación más amplia, pero quienes asistieron me permitieron tener una conversación interesante. Una de las personas, por ejemplo, se acercó con preguntas concretas sobre cómo incorporarse al mercado laboral, posteriormente me contactó por LinkedIn y quedamos en contacto. Solo eso ya hace que la experiencia haya valido la pena.
Pero la charla también terminó enseñándome algo que, curiosamente, estaba muy relacionado con aquello que intentaba explicar.
Antes del modelo está el problema
Una de las ideas centrales de la presentación era bastante sencilla: un proyecto de inteligencia artificial no debería comenzar escogiendo un modelo.
Antes necesitamos comprender qué queremos cambiar.
En la presentación lo representé como un recorrido desde una situación actual hacia la identificación de una brecha o un potencial, que puede expresarse como problema u oportunidad. Recién después viene la exploración, el aprendizaje, la formulación de una hipótesis de solución y, finalmente, su alineamiento con la organización.
Esta distinción me parece especialmente importante porque en tecnología tenemos cierta tendencia a enamorarnos rápidamente de las soluciones.
- “Necesitamos IA”.
- “Necesitamos un chatbot”.
- “Necesitamos automatizar”.
- “Necesitamos un modelo predictivo”.
Pero ninguna de esas frases describe realmente un problema.
Una oportunidad puede ser técnicamente interesante y, aun así, no tener demasiado sentido para una organización. Puede no estar alineada con su estrategia, resolver una decisión poco relevante o generar un valor demasiado pequeño respecto del esfuerzo necesario para implementarla.
Y también puede ocurrir lo contrario: que identifiquemos una oportunidad valiosa, diseñemos una solución técnicamente correcta y, aun así, fracasemos porque nadie la utiliza.
Por eso conectar problema, oportunidad, solución y estrategia organizacional no es un paso previo al proyecto. Es parte del proyecto.
Las organizaciones no entregan problemas perfectamente definidos
Para intentar transmitir esta idea diseñé una actividad práctica.
Los participantes recibían distintos roles dentro de una organización ficticia. Cada uno conocía solamente una parte de la situación, tenía determinados intereses y debía defender su propia perspectiva. La información estaba deliberadamente fragmentada y sesgada.
La idea era reproducir algo bastante habitual en las organizaciones: nadie posee por sí solo una representación completa del problema.
Finanzas ve costos y retorno. Operaciones ve continuidad y restricciones reales. Tecnología conoce capacidades y datos disponibles. Las áreas regulatorias observan riesgos que otros pueden subestimar. Los usuarios conocen aspectos del proceso que muchas veces nunca han sido formalizados.
El trabajo consiste entonces en conversar, contrastar perspectivas, descartar supuestos y construir progresivamente una representación compartida del problema.
Sin embargo, durante la actividad apareció una variable que yo no había considerado suficientemente: las personas también pueden simplemente no tener demasiado interés en participar.
La mayoría finalmente se incorporó a la dinámica y pude adaptarla, pero la situación me dejó pensando.
En un proyecto real ocurre exactamente lo mismo.
Podemos diseñar correctamente la arquitectura, seleccionar una buena tecnología, demostrar un caso económico e incluso tener respaldo estratégico. Nada de eso garantiza que quienes deben utilizar la solución tengan interés en hacerlo.
La adopción no ocurre porque un diagrama diga que debería ocurrir.
Y la gestión del cambio tampoco comienza cuando el sistema está terminado. Comienza mucho antes, entendiendo incentivos, temores, expectativas y formas reales de trabajo.
En cierto modo, la propia charla me presentó en vivo un nuevo problema-oportunidad que debía interpretar y resolver.
IA es bastante más que modelos generativos
Otra de las láminas que consideraba importante era deliberadamente panorámica.
Hoy es fácil que una conversación sobre inteligencia artificial se transforme rápidamente en una conversación sobre modelos generativos. ChatGPT, Claude, Gemini y otros modelos han acercado la IA a millones de personas y probablemente sean hoy su expresión más visible.
Pero IA no es sinónimo de IA generativa.
El mapa que utilicé mostraba, entre otras áreas, IA simbólica, Machine Learning, Deep Learning, procesamiento de lenguaje natural, visión por computador, series de tiempo, aprendizaje por refuerzo e IA generativa. No pretendía ser una taxonomía estricta —varias de estas áreas naturalmente se superponen—, sino recordar algo fundamental: cada tipo de problema requiere preguntarse qué técnica tiene realmente sentido utilizar.
Una organización que necesita pronosticar demanda puede necesitar modelos de series de tiempo. Un problema de detección puede requerir visión por computador. Una decisión operacional puede necesitar predicción combinada con optimización. En otros casos, unas buenas reglas explícitas pueden ser suficientes.
Incluso puede ocurrir que la conclusión correcta sea que el problema no necesita IA.
Eso también es una buena decisión tecnológica.
Un proyecto de IA tampoco termina cuando el modelo funciona
La tercera idea que quise dejar instalada fue la diferencia entre un proyecto tradicional y un sistema basado en IA.
No porque los proyectos tradicionales estén libres de incertidumbre, sino porque en IA aparecen nuevas fuentes de riesgo y, sobre todo, porque algunas permanecen durante todo el ciclo de vida.
En un desarrollo convencional solemos pensar en requisitos, construcción, integración, pruebas y puesta en marcha. En un sistema de IA debemos agregar una preocupación permanente por datos, entrenamiento, validación, comportamiento del modelo, despliegue y monitoreo. El riesgo no desaparece porque el sistema haya llegado exitosamente a producción.
- Los datos pueden cambiar.
- La relación que el modelo aprendió puede dejar de representar adecuadamente la realidad.
- Su desempeño puede degradarse.
Aparecen conceptos como data drift, cuando cambia la distribución de los datos que recibe el modelo, o concept drift, cuando cambia la relación entre esos datos y aquello que intentamos predecir.
Y existen además riesgos de naturaleza más adversarial, como el data poisoning, donde un atacante busca contaminar deliberadamente los datos utilizados durante el entrenamiento o aprendizaje de un sistema.
No alcancé a profundizar en todos ellos durante la charla, pero creo que refuerzan una idea importante: implementar IA no consiste solamente en entrenar un buen modelo; implica administrar una capacidad durante todo su ciclo de vida.
Eso exige monitoreo, gobierno, trazabilidad, evaluación y eventualmente actualización o retiro.
¿Tuve un “drift” durante la charla?
Pensándolo después, resulta tentador describir lo que ocurrió durante la actividad como una especie de drift.
Mi “modelo” previo asumía un determinado nivel de participación. La realidad produjo observaciones diferentes y tuve que modificar mi comportamiento.
Técnicamente, por supuesto, eso no es model drift. No había un modelo de Machine Learning degradándose.
Pero como analogía me gusta.
Porque recuerda que cualquier diseño se construye sobre supuestos acerca del mundo y que, cuando el mundo se comporta de manera diferente, tenemos dos alternativas: insistir en nuestro diseño original o aprender y adaptarnos.
Eso también ocurre en los proyectos.
Podemos diseñar procesos, modelos, roadmaps y arquitecturas con bastante cuidado, pero la realidad siempre termina agregando información que no estaba completamente representada en nuestro diseño inicial.
Lo que me quedó de la experiencia
Después de la charla me quedé principalmente con dos sensaciones.
La primera es que enseñar produce una satisfacción especial. Poder compartir algo de la experiencia acumulada y que eso pueda servirle a otra persona —aunque sea a una— tiene valor.
La segunda es que adaptarse cuando algo no resulta exactamente como estaba planificado depende bastante de haber hecho el trabajo previo. Conocer el tema, haber pensado las razones detrás de cada lámina y tener claridad respecto del mensaje permite abandonar el guion sin perder la conversación.
Y quizás ese sea también un buen resumen de lo que intentaba transmitir.
Las tres láminas que, para mí, sostenían conceptualmente toda la charla decían esencialmente esto:
el problema va antes que el modelo; la inteligencia artificial es bastante más amplia que la tecnología que hoy está de moda; y construir sistemas de IA requiere pensar su ciclo de vida y sus riesgos de una forma diferente.
El resto de la presentación desarrollaba esas ideas mediante un caso: desde el descubrimiento de una oportunidad y su alineamiento organizacional hasta la decisión, los datos, la arquitectura, la adopción, la captura de valor, el aprendizaje y finalmente la gobernanza.
Porque al final el desafío no consiste en poner IA dentro de una organización.
Consiste en entender suficientemente bien una organización como para saber cuándo, dónde y para qué tiene sentido utilizarla.
Y, de vez en cuando, estar preparados para que la realidad cambie nuestros propios supuestos.