VTB explica por qué los pilotos de IA se quedan atascados antes de llegar a producción y cómo resolverlo con arquitectura

El 8 y 9 de abril, en la conferencia Data Fusion, VTB reconoció públicamente un problema que conoce casi cualquier cliente corporativo de IA: los pilotos resultan convincentes, pero pocos llegan a producción real. El análisis no se centra en la calidad de un modelo concreto, sino en la propia arquitectura de implantación.

Por qué fallan los pilotos

La idea clave es sencilla: un piloto suele validar un único paso en condiciones controladas, mientras que en producción aparece toda una cadena de acciones en la que los errores se acumulan. Si ocho eslabones funcionan con una precisión del 85%, la fiabilidad total de la cadena cae al 27%. En una presentación, ese sistema todavía parece «casi bueno», pero en un proceso real tres de cada cuatro resultados son erróneos y, lo más peligroso, no se sabe de antemano cuáles. Por eso el problema no aparece como un fallo puntual, sino como una degradación sistémica de la calidad al escalar.

De ahí se desprende una conclusión aún más incómoda: el mercado a menudo optimiza la IA para la autonomía, no para la precisión. La métrica «qué porcentaje de tareas se completa sin intervención humana» resulta cómoda para el marketing y los informes, pero refleja mal hasta qué punto el sistema sigue conectado con la realidad a largo plazo. El artículo lo relaciona con el automation bias y el deskilling: las personas confían cada vez más en sugerencias erróneas y, al mismo tiempo, pierden la capacidad de decidir sin la máquina. Como resultado, la empresa no solo obtiene un pipeline frágil, sino también una erosión gradual de su propia experiencia.

Arquitectura con el humano dentro

En lugar de la autonomía total, se propone un esquema de baja entropía en el que el humano forma parte del sistema como elemento obligatorio, y no como un botón de emergencia. El trabajo se divide en cuatro niveles: desde el operador de campo junto al objeto hasta el experto de dominio, que revisa las recomendaciones del modelo y devuelve las correcciones al entrenamiento. La lógica consiste en «descargar» la incertidumbre en cada nivel, en vez de dejar que ascienda sin control por la cadena.

• Nivel 0: el operador o especialista sobre el terreno, que ve el objeto real y valida los datos de entrada.
• Nivel 1: modelos especializados para señales concretas: temperatura, humedad, defectos, imágenes u otros parámetros físicos.
• Nivel 2: un coordinador que reúne los resultados de los modelos, razona y elabora una recomendación para el humano.
• Nivel 3: el experto de dominio, que confirma o corrige la conclusión y, con ello, aporta al sistema una señal de entrenamiento.

En este diseño, la tarea de la IA no es sustituir al especialista, sino ampliar su radio de acción y su productividad. El autor pone como ejemplo un gemelo digital de un ecosistema forestal de más de 180.000 hectáreas: al ampliar la cobertura de 2.000 a 50.000 hectáreas, el gasto de capital se multiplicó por 2,1 y el operativo por 2,2, mientras que el equipo solo pasó de cuatro a ocho personas. Con un enfoque tradicional, según el autor, habrían hecho falta muchos más trabajadores de campo.

Por qué no basta con una API

Otro argumento se refiere al stack. El artículo sostiene que es difícil construir este esquema solo sobre las API públicas de los grandes modelos, porque la experiencia de dominio no debe residir en los prompts ni únicamente en RAG, sino en los pesos de un modelo bajo control local. Para ello se proponen adaptadores LoRA o QLoRA, que se reentrenan con pares verificados de respuestas y preferencias de los expertos. Tras la jornada laboral, los logs pasan una validación humana, por la noche se lanza el reentrenamiento y por la mañana el sistema arranca con el conocimiento del dominio ya actualizado.

«El prompt se olvida al final de la ventana de contexto.

El adaptador, nunca».

Esta lógica apuesta por la infraestructura propia. Como referencia de hardware, el artículo cita entre 900.000 y 1,2 millones de rublos: un servidor con una RTX 4090 o 5090 para el coordinador y el entrenamiento nocturno, varias Raspberry Pi para los modelos especializados sobre el terreno y un almacenamiento separado para los logs. El argumento principal no es que los modelos en la nube sean inútiles, sino que conviene usarlos como herramienta de investigación externa y no como capa de toma de decisiones en un circuito de producción crítico.

Qué significa esto

Para el mercado supone un giro importante: la cuestión ya no es cuántas personas se pueden eliminar del proceso, sino cómo mantener la calidad al escalar la IA. Si esta lógica se consolida, las implantaciones corporativas se articularán cada vez más en torno a modelos locales, verificación continua y circuitos humano-máquina, y no en torno a promesas de autonomía total.