Quién responde si el agente se equivoca
·7 min de lectura
De mis primeras experiencias desarrollando agentes, obtuve una primera lección fundamental. Se desarrollaron dos agentes de IA, de los primeros proyectos con capa agéntica que abordábamos. El primero generaba el clausulado de contratos de arrendamiento en función del modelo de explotación, del cliente y de las características de la vivienda: debía captar la información disponible y redactar el clausulado específico conforme a la realidad de cada alquiler. No era un generador de texto libre. Era un agente que tenía que decidir, entre un conjunto de cláusulas posibles, cuáles correspondían exactamente a esa combinación concreta de variables, algo que hasta entonces hacía una persona con criterio y experiencia acumulada.
El segundo era un chatbot conversacional que respondía a solicitudes de clientes sobre sus propios contratos: dudas sobre condiciones, plazos, incidencias, cualquier vicisitud habitual en la relación con un servicio de alquiler. La promesa era razonable: liberar al equipo humano de las consultas repetitivas y dar respuesta inmediata a lo que antes tardaba horas o días en resolverse.
Los dos funcionaban bien la mayor parte del tiempo. Y los dos fallaron exactamente donde más dolía.
La tesis
Un agente de IA que funciona correctamente el 95% de las veces no es un agente resuelto. Es un agente que todavía no ha encontrado su peor caso. Y si nadie ha decidido de antemano quién responde cuando lo encuentre, el problema no es técnico. Es de gobierno.
Dónde se rompió, exactamente
En el agente de contratos, el fallo vino de una mala especificación: acabó tomando cláusulas que no correspondían a la combinación real de cliente, vivienda y modelo de explotación. No era que el modelo "alucinara" sin motivo. Era que la definición de qué cláusula aplicaba a qué escenario no estaba lo suficientemente acotada, y el agente rellenó ese hueco con su propio criterio, que no siempre coincidía con el correcto.
En el chatbot, el problema fue distinto y más delicado: en varios casos, el agente no era capaz de identificar correctamente al cliente cuando coincidían nombre y apellidos con otro distinto. Eso abría la puerta a que la información de un contrato se mezclara con la de otro cliente completamente ajeno. Nunca llegó a producción real, se detectó en fase beta, pero el riesgo era exactamente el que más debería preocupar a cualquier servicio que maneja datos personales: dar la información a la persona equivocada.
Ninguno de los dos fallos fue un incidente aislado que apareciera de la nada. Veníamos con cautela desde el principio, precisamente porque ambos eran de los primeros proyectos con capa agéntica que abordábamos, y eso obligaba a verificar de forma sistemática que no hubiera alucinaciones antes de dar nada por bueno. La cautela no nació del fallo. El fallo confirmó que la cautela estaba justificada.
Por qué es tan fácil no verlo
El problema de fondo no es que los agentes se equivoquen. Es que se equivocan justo en el borde: en el 5% de casos atípicos que ninguna demo enseña y que casi nadie prueba a fondo antes de escalar. Un agente que responde bien a mil preguntas genéricas en una demo transmite una sensación de fiabilidad que no dice nada sobre qué hace cuando dos clientes se llaman igual, o cuando una vivienda tiene una combinación de características que no estaba bien representada en el entrenamiento.
Y hay una segunda razón, más organizativa: en muchos casos, o por exceso de entusiasmo o por puro desconocimiento, se subestima el impacto real del uso de un agente y la necesidad de un modelo de entrenamiento exhaustivo detrás. La conversación se queda en el caso de uso positivo, en lo bien que queda la demo, con poca visión crítica sobre los riesgos potenciales del despliegue real. Hace unos años, no éramos capaces de preguntarnos, qué pasa el día que el agente se equivoque con un dato personal o con una cláusula legal, y quién responde ese día.
Y hay una tercera razón que rara vez se dice en voz alta: cuanto más convincente es el agente, más confianza genera, y esa confianza tiende a extenderse por igual a todos los casos, incluidos los que nunca se probaron. Un agente que redacta cláusulas con fluidez y coherencia gramatical suena fiable, aunque el contenido jurídico de esa cláusula sea incorrecto. Un chatbot que conversa con naturalidad transmite la sensación de que "entiende" a quién tiene delante, aunque por dentro esté identificando al cliente equivocado. La calidad del lenguaje generado no dice nada sobre la calidad de la decisión que hay detrás, pero es fácil confundir una cosa con la otra si no se separan deliberadamente ambas evaluaciones.
Cómo lo aplico ahora
El modelo que aplicamos en estos proyectos se apoya en dos pilares. El primero es una definición muy exhaustiva, con mucho contexto, reglas e instrucciones explícitas, para conseguir que el agente no se extralimite en su función. No basta con darle acceso a la información y confiar en que interprete bien; hay que acotar deliberadamente qué puede decidir y qué no.
El segundo pilar es una capa de validación estructurada con lógica semafórica. En el caso de los contratos, eso significó segmentar por tipo de cliente y definir con claridad en qué segmentos podíamos dar la automatización por completamente válida, y en cuáles todavía hacía falta revisión humana antes de que el clausulado saliera adelante. En el caso del chatbot, la respuesta fue distinta pero con la misma lógica de fondo: introdujimos un sistema mixto donde el cliente debía identificarse mediante login antes de que el agente actuara. Una vez resuelta la identificación de forma fiable, el agente podía personalizar la respuesta sobre las características reales de ese contrato sin margen de confusión con otro cliente.
Donde sí tiene sentido la autonomía completa
Esto no significa que todo agente necesite semáforo y validación humana constante. Cualquier proyecto tipo FAQ, donde el modelo de conocimiento es estanco o muy cerrado, permite dar mucha más autonomía sin ese nivel de control. Si el universo de respuestas posibles está acotado y no hay riesgo de mezclar información sensible entre personas, el coste de frenar cada respuesta para validarla manualmente supera con creces el riesgo real de un error.
La diferencia no está en si el agente usa IA generativa o no. Está en si el error, cuando ocurre, es reversible y de bajo impacto (una respuesta genérica ligeramente imprecisa) o si es de los que generan una consecuencia legal, económica o de privacidad que no se puede deshacer después.
Un asistente que responde preguntas sobre horarios de atención, procedimientos generales o dudas frecuentes sobre el servicio puede equivocarse de vez en cuando sin que eso comprometa nada serio: el usuario reformula, o simplemente contacta con una persona si la respuesta no le convence. Ese mismo nivel de tolerancia al error es exactamente el que no te puedes permitir cuando el agente decide una cláusula contractual o accede a los datos personales de un cliente concreto. El criterio para decidir cuánta autonomía dar no es la sofisticación del modelo, es la reversibilidad del daño si se equivoca.
La objeción que me tomo en serio
La objeción más habitual frente a meter semáforos y validación es que esto ralentiza el retorno de la automatización: si cada acción del agente necesita revisión, ¿para qué se ha invertido en IA?
Es una objeción que merece respuesta honesta, y la respuesta pasa por señalar de dónde viene, casi siempre, esa prisa: de desconocer, por exceso de entusiasmo o por puro desconocimiento técnico, el impacto real que tiene desplegar un agente sin control, y la necesidad de un entrenamiento exhaustivo que respalde esa autonomía. Es fácil quedarse en el caso de uso positivo, el que se enseña en la demo, sin haber hecho el ejercicio crítico de pensar en los escenarios donde el agente puede hacer daño real. La prisa por escalar automatización sin esa visión crítica no acelera el retorno, lo pospone: cualquier incidente serio con datos de clientes o con un contrato mal redactado cuesta, en reputación y en corrección, mucho más de lo que se ahorró saltándose la validación.
Para el lunes
La próxima vez que revises un proyecto de IA agéntica, no preguntes solo qué tan bien responde en la demo. Pregunta qué pasa en el peor caso razonable: el cliente con nombre repetido, la combinación de variables que nadie probó, el contrato con una cláusula atípica. Si nadie en la sala puede decirte qué hace el agente en ese caso, ni quién revisa esa respuesta antes de que llegue al cliente, todavía no tenéis un agente listo para producción. Tenéis una demo con mucha confianza y poca definición.
También te puede interesar
Reflexiones
El día que un proyecto brillante técnicamente no cambió nada
El cálculo puede ser perfecto y el proyecto puede fracasar igual. La distancia entre las dos cosas se llama decisión, y ahí es donde casi nadie mira.
·7 min
PropTech
El dato no es el activo, es la trazabilidad del activo
Tener trece mil ofertas en un sistema no significa tener trece mil ofertas reales. Significa tener trece mil registros, y solo la trazabilidad te dice cuántos de ellos puedes creerte.
·6 min
Transformación digital
Transformar no es migrar
Cambiar de herramienta es fácil de aprobar y difícil de justificar. La pregunta que de verdad transforma algo casi nunca es "¿qué sistema necesitamos?".
·7 min