Diseñar el determinismo en sistemas de inteligencia artificial
No podemos eliminar por completo la naturaleza probabilística de los LLM, pero sí diseñar sistemas que hagan sus decisiones de negocio suficientemente predecibles, trazables y fiab…
Durante años hemos asumido que una parte de nuestros procesos debía adaptarse al software. Y ha tenido sentido. El software estándar nos ha permitido acceder a soluciones maduras, seguras y mantenidas por grandes fabricantes sin asumir el coste de desarrollarlas internamente. El problema aparece cuando confundimos estandarizar aquello que es común con estandarizar aquello que realmente diferencia a nuestro negocio.
Especialmente en las pymes, no todos los procesos encajan bien en una solución diseñada para miles de organizaciones diferentes. Parametrizamos hasta donde podemos y, cuando llegamos al límite, empiezan a aparecer las excepciones: procesos manuales, Excel, integraciones, módulos adicionales o personas que terminan trabajando de una determinada manera simplemente porque es la que permite la herramienta.
A esto se suma otro problema que creo que deberíamos cuestionarnos más desde tecnología y dirección: el coste real de los ecosistemas de software en los que estamos entrando. Una vez adoptamos determinadas plataformas, existe cierta tendencia a resolver cada nueva necesidad incorporando otro módulo o ampliando licencias dentro del mismo ecosistema. Es cómodo, está integrado y reduce algunas complejidades, pero eso no significa necesariamente que sea siempre la decisión más eficiente.
Podemos acabar utilizando soluciones extraordinariamente completas para resolver necesidades relativamente sencillas. Pagamos por decenas de funcionalidades cuando quizá utilizamos una pequeña parte de ellas y, lo que me parece todavía más importante, esa pequeña parte puede no adaptarse completamente a nuestro modelo de ventas, nuestros procesos o nuestra forma de trabajar.
Ahí hay una pregunta que deberíamos hacernos con más frecuencia: ¿conocemos realmente el retorno de nuestras licencias de software?
Normalmente conocemos perfectamente su coste anual, el número de usuarios o cuánto cuesta incorporar un nuevo módulo. Sin embargo, no siempre sabemos con la misma precisión cuánto tiempo nos ahorran, cuántos errores evitan, qué productividad generan o qué porcentaje de las capacidades contratadas estamos utilizando realmente.
No se trata de cuestionar el software estándar. Se trata de gestionar la tecnología como una inversión y no simplemente como un coste recurrente que renovamos porque ya forma parte de nuestro ecosistema.
Y es precisamente aquí donde creo que la IA está cambiando una parte importante de la ecuación. Hasta hace poco, la alternativa al estándar era desarrollar software a medida, con unos costes de análisis, desarrollo, mantenimiento y evolución que hacían difícil justificarlo para muchas necesidades. Hoy esa barrera empieza a reducirse de forma significativa.
Esto nos permite plantearnos una estrategia diferente: comprar aquello que ya está bien resuelto, parametrizar cuando sea suficiente, integrar cuando tenga sentido y construir cuando exista una verdadera particularidad del negocio que justifique hacerlo.
En nuestro caso, por ejemplo, estamos aplicando este principio en la evolución de la gestión de producto. Estamos construyendo un PIM propio porque necesitamos que la información, los procesos y la experiencia se adapten a la realidad de nuestro producto y de nuestro negocio. No porque desarrollar internamente sea mejor por definición, sino porque en determinados puntos el nivel de especialización hace que tenga sentido controlar esa capacidad y evolucionarla según nuestras necesidades.
Pero aquí aparece una responsabilidad importante: que construir sea ahora más accesible no significa que debamos construirlo todo.
De hecho, creo que la IA nos obliga a ser todavía más rigurosos con las decisiones tecnológicas. Cada iniciativa debería tener asociado un resultado de negocio y una forma de medirlo: tiempo ahorrado, productividad, reducción de errores, coste operativo, adopción, time-to-market, capacidad liberada o incremento de ingresos. Y deberíamos aplicar exactamente el mismo criterio tanto al software que compramos como al que desarrollamos.
Por eso cada vez me convence menos hablar del «ROI de la IA». El ROI no está en utilizar IA. Está en conseguir que un proceso que necesitaba tres horas necesite treinta minutos, en reducir errores, en eliminar tareas que no aportan valor o en conseguir que una persona pueda hacer algo que anteriormente requería varias herramientas o departamentos.
La tecnología es el habilitador. El valor está en el resultado.
Creo que la verdadera oportunidad para muchas empresas, y especialmente para las pymes, está precisamente ahí. Durante años hemos tenido que elegir entre adaptarnos a lo que permitía el software estándar o asumir el coste de construir soluciones a medida. La IA está reduciendo la distancia entre ambas opciones y haciendo económicamente viable un nivel de personalización que antes estaba reservado a organizaciones con grandes equipos tecnológicos.
Eso cambia también el papel de quienes dirigimos tecnología. Ya no se trata simplemente de elegir herramientas. Se trata de decidir dónde estandarizar, dónde diferenciarnos, dónde invertir y dónde no hacerlo, entendiendo el coste total y, sobre todo, midiendo el valor que devuelve cada decisión.
Porque quizá la hiperpersonalización no consista en tener más software, sino precisamente en tener el software que necesitamos, donde lo necesitamos y con un retorno que podamos demostrar.