Los grandes modelos de lenguaje (LLM) ya están siendo implementados masivamente en operaciones industriales, pero el crecimiento de la autonomía de los sistemas de IA es notablemente más lento de lo que se habla. Según un estudio de Infosistemy Dzhet y Smart Ranking, el 86% de las grandes empresas rusas utilizan o están probando LLM, mientras que solo el 8% tiene agentes de IA completamente autónomos en operación industrial. Oleg Skuratovich, gerente técnico de proyectos en SVOY Tech (clúster de TI del grupo fintech SVOY), explicó por qué después de los primeros escenarios exitosos, la automatización adicional se vuelve más compleja, dónde realmente surgen los errores que parecen ser errores de LLM, y por qué la participación humana se está convirtiendo cada vez más en parte de la arquitectura, y no en una limitación.

Los primeros escenarios proporcionan la mayor parte del efecto

Según el experto, el equipo analizó datos de aproximadamente un año de operación industrial. Este período suaviza la estacionalidad y los picos de carga únicos. Se descubrió que el flujo principal de solicitudes es cubierto por solo unos pocos escenarios típicos. Alrededor del 72% de las solicitudes correspondieron a seis razones comunes, entre ellas el estado de pago y solicitud, confirmación de operación, programación de tiempo de contacto, navegación por el proceso y transferencia a un especialista. Después de su automatización, la carga en la primera línea disminuyó aproximadamente un 24%, y el tiempo promedio de espera se redujo casi un tercio.

Luego, el efecto comenzó a disminuir notablemente. El primer 20-30% de los escenarios automatizados proporcionó más del 70% de todo el ahorro final en tiempo operativo. “Registramos algo simple. Cada escenario siguiente debe evaluarse no por si es técnicamente automatizable, sino por el efecto adicional real que aportará al negocio”. Así explica su enfoque Oleg Skuratovich.

LLM – solo una capa del sistema

El error que el experto considera más común al inicio de los proyectos es la creencia de que el LLM puede reemplazar la arquitectura por completo. Según sus observaciones, un sistema maduro en fintech no es "modelo más telefonía", sino un conjunto de capas, donde cada una es responsable de su parte del riesgo. El sistema está formado por reconocimiento de voz, determinación de intenciones, enrutamiento de solicitudes (routing), acceso a sistemas internos para obtener datos a través de API (interfaz de programación para el intercambio de datos entre sistemas), base de conocimientos, restricciones de cumplimiento y capa de voz. Y solo sobre todo esto funciona el LLM, que formula la respuesta, pero no inventa los hechos.

“Si se conecta un LLM directamente a la telefonía o al CRM, en una demostración se ve impresionante. Las respuestas suenan vivas, el diálogo parece natural. Pero sin enrutamiento, acceso a datos y restricciones, no se obtiene un agente inteligente, sino una interfaz convincente pero poco fiable. En un entorno regulado, esto ya es un riesgo, no solo una deficiencia”. Así lo explica Oleg Skuratovich.

Según él, cualquier equipo en este camino se enfrenta a tres encrucijadas que es mejor discutir antes del piloto, y no después. Cuántas verificaciones y accesos a datos son permisibles en aras de la precisión de la respuesta a cambio de la velocidad. Cuán estrictamente se deben establecer las rutas de diálogo a cambio de la naturalidad del habla. Y cuánto se puede ahorrar en el registro y la actualización de la base de conocimientos sin perder la capacidad de gestión del sistema.

La tasa de automatización no muestra el efecto real

Un problema aparte es la métrica de tasa de automatización, la proporción de solicitudes procesadas sin la participación de un empleado. No siempre refleja el ahorro real. El bot puede llevar a cabo el diálogo de forma autónoma, pero no resolver el problema del cliente, y este volverá a contactar. Formalmente, el escenario estará "automatizado", aunque la carga de trabajo de los empleados no disminuirá. Por lo tanto, el equipo comenzó a considerar un escenario cerrado solo cuando el cliente obtuvo el resultado deseado y después de eso no necesitó un empleado. Se monitorearon por separado los diálogos incompletos, las solicitudes repetidas y las quejas.

Un cambio de enfoque similar se observa en el mercado bancario en general. Según Frank RG y BSS, la proporción de calificaciones máximas para los robots ha aumentado al 75%, pero los clientes aún señalan una comprensión insuficiente de las solicitudes y la falta de flexibilidad en el diálogo. Es decir, una alta proporción de automatización por sí sola no garantiza un cliente satisfecho.

El error puede ocurrir antes de la respuesta del modelo

Quizás la conclusión más inesperada del equipo se refiere a la naturaleza de los errores. Un análisis detallado de los registros mostró que casi el 43% de los fallos registrados se concentraban en un punto de transición del escenario. Al mismo tiempo, el propio LLM en estos diálogos podía entender correctamente la solicitud. El problema surgía antes. El sistema dirigía al modelo a responder donde primero se requería obtener un hecho de un sistema interno o transferir la conversación a un empleado.

“Externamente, esto parece un error del modelo. Internamente, casi siempre resulta ser otra cosa. Una ruta incorrecta, una respuesta vacía de la API, una base de conocimientos obsoleta o una transferencia a un empleado sin contexto. Reemplazar el LLM en tal situación puede mejorar la formulación, pero no eliminará la causa del fallo”, dice Oleg.

Después del análisis, el punto problemático en el escenario se dividió en tres ramas. El sistema puede responder de forma autónoma, primero obtener un hecho o transferir inmediatamente la solicitud a un empleado.

El Handoff se convierte en parte de la arquitectura

La empresa decidió no automatizar completamente algunos escenarios. Se trata de situaciones controvertidas y no estándar, quejas, solicitudes legalmente sensibles, casos con múltiples interpretaciones y un alto costo de error. Una categoría de riesgo aparte es la calidad de los datos. Si los sistemas internos devuelven información incompleta o contradictoria, el LLM no debe inventar la respuesta por ellos.

“Si el sistema no puede determinar inequívocamente la situación u obtener datos fiables, la solución correcta es involucrar a un empleado antes. Dejamos de considerar el handoff, es decir, la transferencia del diálogo del bot al empleado, como un fracaso del servicio de IA. Es una de las ramas estándar de la arquitectura”. Así lo afirma Oleg Skuratovich.

Al mismo tiempo, el empleado debe recibir el contexto ya recopilado junto con la solicitud, y no comenzar el análisis de nuevo.

Este enfoque también se ajusta a las recomendaciones del Banco de Rusia, que aconseja a las organizaciones financieras que garanticen la posibilidad de pasar de la IA a un empleado. Más del 80% de las organizaciones que utilizan constantemente la IA ya siguen esta recomendación.

A veces, menos automatización produce mejores resultados

En una de las etapas del proyecto, el equipo cambió la lógica de algunos escenarios complejos y comenzó a involucrar a los empleados antes. El nivel formal de automatización disminuyó ligeramente. Sin embargo, las solicitudes repetidas disminuyeron aproximadamente un 14%, y las quejas casi un 20%.

“El objetivo del servicio de IA no es prescindir del ser humano el mayor tiempo posible, sino completar correctamente las solicitudes y aliviar la carga real de los empleados”. Así resume Oleg Skuratovich, gerente técnico de proyectos en SVOY Tech.

En su opinión, al lanzar y desarrollar un servicio de IA, es importante verificar no tanto el modelo en sí, sino el sistema que lo rodea. De dónde obtiene los hechos el LLM, qué sucede cuando hay una respuesta vacía o contradictoria de los sistemas internos, dónde está el límite de la transferencia obligatoria a un humano y qué métricas muestran no la temperatura promedio del hospital, sino el punto de falla real. Cuanto más amplia es la automatización, menos depende su resultado de las capacidades de un solo modelo. Y más de la arquitectura, la calidad de los datos y la capacidad del sistema para comprender a tiempo cuándo una tarea no debe resolverse de forma autónoma.