De la PoC a la producción: muchas pruebas de concepto, pero pocas productivas.

Llevamos más de 2 años muy intensos con Inteligencia Artificial en todos los sitios y a todos los niveles. Esto ha provocado e impulsado una inmensidad de pruebas de concepto, la aplicación de diferentes tecnologías en diferentes casos de uso que demuestren un posible retorno para el negocio y los clientes.

Todo esto ha funcionado relativamente bien. Más allá de los cambios y evolución constante de todo el panorama tecnológico relacionado con la IA, no hay grandes problemas hasta que llega el momento de hacerlo productivo.

La realidad de la IA en producción

Como ya comentamos en el primer post de esta serie de tres, la Plataforma de IA ya no es una opción, sino una necesidad. Pero, ¿por qué esa necesidad es tan urgente? En mi opinión, es porque estamos perdiendo dinero, tiempo y oportunidades cada día que pasa.

La mayoría de las empresas están atrapadas en un “día de la marmota” desolador: las pruebas de concepto suelen ser exitosas y las productivizaciones suelen ser dolorosas. La realidad es que los/as Data Scientists hacen magia en sus notebooks y el resultado es prometedor, pero luego, al intentar pasar ese modelo al mundo real, se encuentran con un muro de burocracia, tickets y falta de herramientas estandarizadas, faltas de automatizaciones y problemas con los equipos de seguridad.

Es una auténtica pesadilla. Y esa pesadilla se traduce en cuellos de botella o problemas muy concretos que la Plataforma de IA debe eliminar.

Problema 1: el autoservicio y el dolor del TicketOps

Pongámonos en los zapatos del equipo de IA. Acaban de entrenar un modelo que podría ahorrar millones y lo único que necesitan es, mira tú por dónde, desplegarlo.

¿Y qué pasa? El 90% de las veces tienen que ir a un equipo de infraestructura, abrir un ticket, esperar tres días para que les asignen un namespace, pedir permisos de red y rogar por una base de datos de features. Lo llamamos "TicketOps" y es un problema para el Time-to-Market.

¡¡OJO!! Es necesario, no debemos infravalorar los posibles problemas de seguridad o de incumplimiento de normativas que se podrían producir.

Pero esto está yendo a peor aún, con la irrupción de los LLMs, el problema se ha magnificado. Desplegar un LLM es diferente a desplegar un modelo de regresión simple. Requiere (posiblemente) de GPU, de un almacenamiento específico, y, a menudo, APIs que controlen la complejidad del prompting y el uso de memoria que se sehace. Si no tienen una herramienta self-service para desplegar esto en minutos, simplemente no sucede. La democratización del LLM muere ahí mismo.

Antes, el/la Data Scientist pedía un servidor y con eso se solucionaba todo. Hoy, es necesario desplegar un microservicio que consuma un LLM, que use una base de datos vectorial para la memoria a largo plazo y que además necesita acceso dedicado a un nodo con GPU en el clúster. Si ese proceso no se reduce a un solo comando en nuestra IDP, estamos creando una barrera técnica para cada nueva idea de IA que impacta de manera frontal en el negocio y, por lo tanto, en nuestros clientes.

Problema 2. cumplimiento de compliance / normativo

Cuando hablamos de IA, el riesgo es enorme. Un modelo que toma decisiones sesgadas o que opera con datos obsoletos (o privados) puede costar una fortuna en multas o, directamente, hundir la reputación de nuestra empresa.

Aquí el problema es doble:

1. Calidad

La Plataforma de IA debe garantizar que los datos de entrenamiento son consistentes. Si no estandarizamos cómo se ingestan y se versionan, el modelo en producción se va a desviar sí o sí. Es el Garbage In, Garbage Out llevado al extremo.

El problema de la consistencia lo mata la ausencia de un Feature Store. Los equipos de Data Science suelen calcular la media o la desviación estándar de una columna de datos durante el entrenamiento, pero luego, el código que calcula esa característica en tiempo real en producción es diferente.

Un Feature Store, gestionado por la plataforma, garantiza que el código de cálculo de esa feature es el mismo en el entrenamiento que en el serving (producción). Es la única forma de asegurar la coherencia matemática.

2. Seguridad

¿Quién tiene acceso al modelo? ¿Cómo se registran los cambios en el código y en el dataset? Si no hay trazabilidad y políticas de seguridad by design (integradas en los Golden Paths), la auditoría será imposible. Y, la verdad, a mí me da escalofríos pensar en un equipo de Data Science configurando reglas de firewall manualmente. Es un desastre esperando a ocurrir.

Problema 3: la presión del Time-to-Market (TTM)

Es el punto que interesa a negocio. ¿De qué sirve tener un modelo innovador si tardas seis meses en ponerlo frente al cliente? La competencia no espera y el TTM se convierte en la métrica de negocio más crítica.

Hoy, la presión sobre los equipos de Plataforma para operacionalizar la IA (es decir, hacerla fiable y rápida) es máxima. Necesitan ir a la velocidad de la innovación, no a la velocidad de la infraestructura.

La solución (y aquí es donde el Platform Engineering se vuelve casi ciencia ficción) es pasar del TicketOps al Intent-to-Infrastructure. Es decir, tener en nuestra organización la capacidad de que un perfil de Data Scientist pueda decirle a la plataforma: "quiero un entorno para entrenar un modelo de clasificación con un determinado set de datos". La plataforma, de forma automática, traduce esa intención en toda la infraestructura necesaria (Kubernetes, networking, almacenamiento seguro) en cuestión de minutos.

Esto elimina el cuello de botella más grande: la fricción y dependencia entre equipos. Nos permite pasar de la idea a la producción a la velocidad que exige el negocio.

Conclusión

Si juntamos la burocracia y el proceso duro (muchas veces del proceso de “ticketing”), la importancia de la calidad de los datos y la presión implacable del TTM, entendemos que la IA, sin una plataforma, es un proyecto de investigación caro y frustrante, no una ventaja competitiva.

Las plataformas de IA son la única herramienta que permite a las organizaciones tener control sin sacrificar la velocidad.

Hemos visto los problemas y los cuellos de botella reales que frenan el aporte de valor de la IA al negocio y los clientes. En el último post de esta serie, no vamos a hablar de dolor, sino de soluciones. Vamos a revisar qué está haciendo la industria con ejemplos y casos de uso concretos, y a definir los primeros pasos de una hoja de ruta práctica para que su equipo pueda empezar a construir esa fábrica de modelos hoy mismo.