VTB explicó por qué los pilotos de AI se atascan antes de llegar a producción y cómo la arquitectura puede corregirlo

El 8 y 9 de abril, en la conferencia Data Fusion de VTB, VTB reconoció públicamente un problema familiar para casi todo cliente corporativo de IA: los pilotos parecen convincentes, pero pocos llegan a la producción real. El enfoque del análisis no es la calidad de un modelo individual, sino la propia arquitectura de implementación.

Por Qué los Pilotos se Rompen

La idea clave es simple: un piloto normalmente prueba un paso en condiciones controladas, pero en producción surge toda una cadena de acciones donde los errores se acumulan. Si ocho eslabones funcionan con una precisión del 85%, la confiabilidad general de la cadena cae al 27%. En una presentación, tal sistema todavía se ve "casi bien", pero en un proceso real, tres de cada cuatro resultados salen mal, y lo más peligroso es que no está claro de antemano cuáles son.

Por eso el problema no se manifiesta como un bug único, sino como una degradación sistémica de la calidad al escalar. Esto también lleva a una conclusión más desagradable: el mercado a menudo optimiza la IA no por precisión, sino por autonomía. La métrica "qué porcentaje de tareas se completan sin intervención humana" es conveniente para marketing e informes, pero muestra poco cómo el sistema permanece anclado a la realidad a largo plazo.

El artículo vincula esto al sesgo de automatización y al deskilling: las personas cada vez más confían en sugestiones incorrectas y simultáneamente pierden la habilidad de tomar decisiones 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 Humanos

En lugar de autonomía total, se propone un esquema de baja entropía, donde los humanos están integrados en el sistema como un elemento obligatorio, no como un botón de emergencia. Divide el trabajo en cuatro niveles: desde un operador de campo cerca del objeto hasta un experto de dominio que verifica las recomendaciones del modelo y realimenta correcciones al entrenamiento.

La lógica es "descargar" la incertidumbre en cada nivel, en lugar de dejarla subir incontroladamente por la cadena.

• Nivel 0 — un operador o especialista en el sitio que ve el objeto real y valida datos de entrada.
• Nivel 1 — modelos estrechos para señales específicas: temperatura, humedad, defectos, imágenes u otros parámetros físicos.
• Nivel 2 — un coordinador que recopila resultados de modelos, razona y formula una recomendación para humanos.
• Nivel 3 — un experto de dominio que confirma o corrige la conclusión y así proporciona una señal de aprendizaje al sistema.

En tal diseño, la tarea de la IA no es reemplazar al especialista, sino expandir su alcance de acción y productividad. El autor proporciona el ejemplo de un gemelo digital de un ecosistema forestal que cubre más de 180 mil hectáreas: conforme la cobertura creció de 2 a 50 mil hectáreas, los gastos de capital aumentaron 2,1 veces, los gastos operacionales aumentaron 2,2 veces, y el equipo creció solo de cuatro a ocho personas. Con un enfoque tradicional, según la estimación del autor, se habrían requerido muchos más empleados de campo.

Por Qué la API No Es Suficiente

Un punto separado se refiere al stack. El artículo sostiene que tal esquema es difícil de construir solo sobre APIs públicas de modelos grandes, porque la experiencia de dominio debe vivir no solo en prompts o RAG, sino en los pesos de un modelo localmente controlado. Para esto, se proponen adaptadores LoRA o QLoRA, que se ajustan finamente en pares verificados de respuestas y preferencias de expertos. Después del día de trabajo, los logs se validan por humanos, el ajuste fino se ejecuta por la noche, y por la mañana el sistema inicia con conocimiento de dominio actualizado.

"Un prompt se olvida al final de la ventana de contexto.

Un adaptador — nunca."

Esta lógica apuesta por infraestructura propia. El benchmark de hardware mencionado en el material es aproximadamente 900 mil a 1,2 millones de rublos: un servidor con RTX 4090 o 5090 para el coordinador y entrenamiento nocturno, varios Raspberry Pi para modelos estrechos en el sitio, y almacenamiento de logs separado. El argumento principal no es que los modelos en la nube sean inútiles, sino que se utilizan mejor como una herramienta de investigación externa en lugar de una capa de toma de decisiones en bucles de producción crítica.

Lo Que Esto Significa

Para el mercado, este es un cambio importante: la pregunta 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 arraiga, las implementaciones corporativas se construirán cada vez más alrededor de modelos locales, verificación continua y bucles humano-máquina, en lugar de promesas de autonomía total.