// INTELIGENCIA ARTIFICIAL
Por qué los pilotos de IA no llegan a producción
7 min de lecturanijitech
La distancia entre un piloto de IA que funciona y un sistema que sobrevive en producción no está en el modelo sino en la capa construida a su alrededor. Cuatro puntos de rotura.
Artículo completo
Declarar exitoso un piloto de IA es fácil: corre sobre un conjunto de datos elegido, con ejemplos elegidos, bajo la mirada del desarrollador. Mantener vivo ese mismo sistema en producción es otro oficio. La diferencia casi nunca tiene que ver con el modelo: está en la capa que nadie construyó a su alrededor.
1. La entrada es limpia en el piloto, no en producción
Los datos del piloto suelen estar escogidos a mano: documentos legibles, audio limpio, campos completos. Lo que llega en producción es la foto torcida de una factura escaneada, la grabación de una reunión con tres personas hablando de fondo, un formulario a medio llenar. El modelo es el mismo; lo que cambió es la distribución de la entrada.
Problemas de entrada típicos en producción
- La misma información llegando con una forma distinta según el proveedor
- Campos ausentes o contradictorios
- Idioma, formato o codificación inesperados
- Una distribución que se desplaza con el tiempo: la regla del año pasado ya no vale
El remedio aquí no es un modelo más potente sino una capa que convierta la entrada en una representación común. Los pasos siguientes no deberían necesitar saber de dónde vino el dato.
2. Una salida sin verificar no cuenta como salida
En un piloto, una persona mira la salida. En producción se producen miles de salidas al día y nadie las revisa una por una. Así que el sistema tiene que poder comprobar su propia salida y decir cuándo no está seguro. Sin una capa de verificación, cuando el error se detecta ya ha corrido aguas abajo.
3. El coste es invisible en el piloto y evidente en volumen
El coste por operación de una llamada al modelo es pequeño y pasa inadvertido en un piloto. En un sistema que hace diez mil llamadas al día, ese mismo número decide toda la factura. Mandar cada trabajo al modelo más potente es como alquilar una excavadora para clavar un clavo: funciona, pero no sale a cuenta.
Enrutar parte del trabajo a modelos más pequeños baja la latencia además de la factura. Eso exige una capa de enrutado que decida qué trabajo va a qué modelo: enterrar la decisión en el código de la aplicación convierte cada cambio en una tarea de desarrollo.
4. Una decisión sin dueño es el error más caro
Cuando un sistema autónomo se equivoca, la primera pregunta es: ¿quién tomó esta decisión y sobre qué base? Los montajes sin respuesta suelen apagarse tras el primer error serio. Pedir aprobación humana en los umbrales críticos no frena el sistema; es lo que lo mantiene vivo.
En resumen
Cuatro preguntas en el camino del piloto a producción
- ¿Qué pasa cuando la entrada no llega siempre con la misma forma?
- ¿Quién verifica la salida y puede mostrar su fuente?
- Si el volumen se multiplica por diez, ¿qué ocurre con el coste y la latencia?
- ¿De quién es una decisión equivocada y en qué umbral se pide a una persona?
Las respuestas no están en un modelo sino en la cadena que lo rodea. Por eso todos los productos de nijitech corren sobre la misma columna vertebral.
Del glosario: Decisión aprobada por humanos (human-in-the-loop) · Conjunto de evaluación (eval)