Los agentes de inteligencia artificial funcionan bien en el camino feliz y se rompen en las excepciones, que es exactamente donde vive la parte difícil de cualquier empresa. El pedido estándar se procesa solo; el pedido con una entrega parcial, un cliente con incidencia abierta y una condición comercial negociada por teléfono es donde se decide si la automatización aporta o estorba.
En los procesos que hemos mapeado, ese conjunto de casos «raros» representa habitualmente entre el 15% y el 30% del volumen. No es un residuo: es una cuarta parte de la operación, y suele concentrar una proporción mucho mayor del valor y del riesgo.
Porque no se pueden enseñar en veinte minutos. Una demo tiene que ser comprensible, y las excepciones son, por definición, lo que no es comprensible sin conocer el negocio.
Esto genera un sesgo sistemático en las decisiones de compra. Se evalúa la herramienta por el 70% que es fácil, se firma, y el 30% difícil aparece en producción, cuando ya no es una decisión de compra sino un problema de proyecto. Es la misma dinámica que describimos al hablar del purgatorio del piloto: el piloto evita por diseño aquello que hace difícil la producción.
Hay además una razón técnica. Un modelo de lenguaje no distingue entre «no sé» y «no encaja con lo que he visto». Ante un caso atípico no se detiene: completa. Produce una respuesta plausible construida a partir de los patrones que conoce, y esa respuesta tiene el mismo tono de seguridad que las correctas. En un proceso automatizado, esa confianza indistinguible es el problema, no la alucinación ocasional.
|
Tipo |
Ejemplo |
Cómo tratarla |
|
Dato ausente o contradictorio |
El cliente aparece con dos NIF distintos |
Detener y escalar: nunca elegir uno |
|
Regla de negocio no escrita |
Condición pactada verbalmente con un cliente |
Documentar la regla o excluir al cliente del flujo |
|
Umbral superado |
Importe, volumen o descuento fuera de rango |
Validación humana obligatoria |
|
Estado incompatible |
Pedido a un cliente con impago abierto |
Bloqueo con motivo explícito |
|
Caso legalmente sensible |
Datos de salud, menores, decisiones sobre personas |
Fuera del alcance del agente |
La utilidad de esta tabla no es teórica: es el guion de una sesión de trabajo de dos horas con las personas que ejecutan el proceso hoy. La pregunta que hay que hacerles no es «cómo funciona el proceso» —eso lo contarán en su versión ideal— sino «cuéntame el último caso que te dio problemas». Tres o cuatro personas respondiendo a esa pregunta producen el mapa de excepciones completo en una tarde.
El diseño más importante de un sistema automatizado es lo que ocurre cuando no está seguro. Y para que ocurra algo, tiene que existir la posibilidad de que el sistema declare incertidumbre.
Esto requiere tres decisiones de diseño:
Definir qué es una condición de parada. No una puntuación de confianza abstracta, sino condiciones de negocio concretas: falta este dato, este importe supera el umbral, este cliente está en esta situación. Las condiciones legibles por una persona son las que se pueden auditar y discutir en un comité.
Definir a dónde escala. Una cola específica, con un responsable y un plazo. Una excepción que escala a un buzón genérico no se ha resuelto: se ha aplazado.
Definir qué información acompaña al escalado. El agente debería entregar el caso preparado: qué encontró, qué le falta y qué opciones ve. Ahí está la mayor parte del ahorro de tiempo, y se conserva aunque la decisión final la tome una persona.
Un sistema diseñado así no automatiza el 100% del proceso. Automatiza el 70% completo y prepara el 30% restante. En casi todos los casos que hemos medido, eso produce más ahorro neto que intentar automatizar el 100% y tener que revisarlo todo por desconfianza.
Hay una consecuencia cultural que conviene anticipar. Cuando el indicador que se presenta al comité es el «porcentaje de automatización», el equipo tiene un incentivo para reducir los escalados, y la forma más rápida de reducirlos es ampliar el alcance del agente a casos que no debería tocar.
Por eso el indicador correcto no es el porcentaje automatizado, sino el coste total por caso resuelto correctamente. Un sistema que automatiza el 70% y escala bien el 30% suele salir más barato que uno que automatiza el 95% y genera retrabajo, reclamaciones y desconfianza en el 25% que no debería haber tocado.
Una tasa de escalado saludable no es una tasa baja. Es una tasa estable y explicable.
No hace falta reescribirlo. El camino habitual tiene tres pasos y se puede ejecutar sin parar la operación:
El error a evitar es intentar instrumentarlo todo a la vez. Un sistema con dos capas bien registradas es infinitamente más gobernable que uno con cinco capas registradas a medias.
El trabajo de mapear excepciones no es un preliminar del proyecto de IA: es el proyecto. Cuando se hace bien, produce cuatro entregables que valen por sí mismos, con independencia de que después se automatice o no:
Es exactamente el trabajo que hacemos antes de proponer cualquier automatización, y la razón por la que insistimos en que primero se define el proceso y después se automatiza . No es una preferencia metodológica: es la única forma de saber qué parte del proceso es automatizable sin descubrirlo en producción.
Cuando un proveedor presente una solución basada en agentes, pide una cosa concreta: que la demo incluya el caso raro que tú elijas.
No un caso raro genérico. Uno de los tuyos, con tus datos incompletos y tu regla de negocio no escrita. La respuesta a esa petición separa a quien ha construido un sistema de quien ha construido una presentación.
Si la respuesta es que ese caso se tratará en una fase posterior, ya sabes dónde va a estar el sobrecoste del proyecto.
Porque un modelo de lenguaje no distingue entre «no sé» y «esto no encaja con lo que he visto»: ante un caso atípico no se detiene, completa. Produce una respuesta plausible con el mismo tono de seguridad que las correctas, lo que hace que el error sea difícil de detectar dentro de un proceso automatizado.
En los procesos que hemos mapeado, habitualmente entre el 15% y el 30% del volumen, aunque concentran una proporción mayor del valor y del riesgo. No es un residuo estadístico: es una parte sustancial de la operación real.
Preguntando a quienes lo ejecutan por el último caso que les dio problemas, en lugar de pedirles que describan el proceso. Con tres o cuatro personas se obtiene el mapa completo en una sesión. Los tipos habituales son: dato ausente o contradictorio, regla no escrita, umbral superado, estado incompatible y caso legalmente sensible.
Detenerse y escalar, con tres elementos definidos de antemano: condiciones de parada expresadas en términos de negocio, una cola concreta con responsable y plazo, y un paquete de información que incluya qué encontró, qué le falta y qué opciones ve.
Normalmente no. Automatizar el 70% completo y preparar el 30% restante suele producir más ahorro neto que automatizar el 95% y generar retrabajo, reclamaciones y desconfianza en los casos que no debían automatizarse. El indicador correcto es el coste por caso resuelto correctamente, no el porcentaje automatizado.
Que incluya un caso raro elegido por el cliente, con sus datos incompletos y sus reglas de negocio no escritas. Si el proveedor aplaza ese caso a una fase posterior, ahí es donde aparecerá el sobrecoste del proyecto.
|
Antes de automatizar, mapeamos. Identificamos el proceso real, las reglas no escritas y las excepciones que romperían cualquier automatización, y te decimos qué parte merece automatizarse. Dos horas de análisis sin compromiso. Hablemos → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
