Un agente de IA mal configurado puede hacer algo que ningún empleado con dos días de formación haría nunca: prometerle a un cliente un descuento que no existe, un plazo de entrega que la empresa no puede cumplir, o una garantía que va más allá de lo que dicen las condiciones reales del servicio. No lo hace por mala fe, lo hace porque un modelo de lenguaje, si no se le pone freno, tiende a generar la respuesta que "suena mejor" en el momento, aunque no tenga ninguna base real detrás. Este es uno de los riesgos más concretos y menos hablados de poner un agente de IA a hablar directamente con clientes.
Por qué este es un riesgo real, no teórico
Un modelo de lenguaje genera texto prediciendo qué es plausible decir a continuación, no consultando una base de datos de lo que la empresa puede o no puede ofrecer, salvo que se le obligue explícitamente a hacerlo. Si un cliente insiste en pedir un descuento y el agente no tiene una instrucción clara de qué puede y qué no puede ofrecer, existe un riesgo real de que "invente" una respuesta razonable en apariencia —un porcentaje de descuento, una fecha de entrega optimista— simplemente porque es la respuesta que mejor encaja con lo que el cliente quiere oír. El problema no es hipotético: es la consecuencia directa de cómo funciona este tipo de tecnología si no se le pone un límite explícito.
Dónde se define lo que el agente puede y no puede ofrecer
La solución no es esperar que el modelo "tenga sentido común", sino definir por escrito, antes de lanzar el agente, un catálogo cerrado de lo que puede prometer: qué descuentos existen y bajo qué condiciones, qué plazos de entrega son reales para cada producto o zona, qué cubre exactamente la garantía y qué no. Ese catálogo se convierte en la fuente de verdad que el agente debe consultar antes de responder cualquier pregunta sobre condiciones comerciales, y cualquier petición que caiga fuera de ese catálogo —un descuento especial, una excepción a la política habitual— debe derivarse automáticamente a una persona, nunca resolverse con una respuesta generada sobre la marcha.
Verificar contra una fuente de verdad, no contra la memoria del modelo
Aquí es donde entra en juego una distinción técnica importante: un agente bien diseñado no responde preguntas sobre precios, plazos o condiciones "de memoria", sino consultando en tiempo real el catálogo real de la empresa —a través de la misma generación aumentada con herramientas que le permite consultar un ERP o una base de datos—, de forma que la respuesta que da siempre está anclada a lo que existe de verdad en ese momento, no a lo que el modelo cree recordar de conversaciones anteriores. Esta diferencia entre "responder de memoria" y "consultar la fuente real antes de responder" es, probablemente, el control técnico más importante para evitar promesas infundadas.
Qué pasa si el agente promete algo por error de todas formas
Ningún sistema es perfecto, y conviene asumir que, tarde o temprano, un agente cometerá este error a pesar de los controles. Cuando ocurre, la empresa tiene que decidir de antemano —no en el momento de la crisis— cómo actuar: si se honra la promesa aunque no fuera correcta, asumiendo el coste puntual a cambio de no dañar la confianza del cliente, o si se explica el error y se ofrece una alternativa razonable. Sea cual sea la política, debe estar decidida antes de que ocurra el primer caso, con alguien identificado que revise estos incidentes y ajuste el agente para que no se repitan, del mismo modo que se revisaría cualquier error recurrente de un empleado nuevo.
Cómo probarlo antes de lanzarlo delante de clientes reales
Antes de poner un agente en producción, tiene sentido intentar activamente "romperlo": plantearle las preguntas más forzadas que un cliente insistente podría hacer —pedir un descuento inexistente, presionar por un plazo imposible, insistir en una excepción a la política de devoluciones— y comprobar que responde dentro de los límites definidos en lugar de ceder a la presión conversacional. Este ejercicio de prueba deliberada, antes de exponer el agente a clientes de verdad, es exactamente lo que describimos en cómo se prueba un agente de IA antes de ponerlo delante de clientes reales, y es la diferencia entre descubrir este tipo de fallos en un entorno controlado o descubrirlos con un cliente real y enfadado.
Un límite adicional: separar "informar" de "comprometerse"
Un matiz útil a la hora de diseñar las respuestas del agente es distinguir entre información general —"nuestros plazos de entrega habituales son de tres a cinco días laborables"— y un compromiso concreto con un cliente concreto —"tu pedido llegará el jueves sin falta"—. La primera es relativamente segura de automatizar porque describe una política, no una promesa individual; la segunda exige normalmente comprobar datos específicos del pedido en cuestión antes de afirmarla, y cuanto más se acerque la respuesta del agente a un compromiso personal con consecuencias si no se cumple, más justificado está exigirle que verifique el dato real antes de decirlo, en lugar de generalizar a partir de la política habitual de la empresa.
Conclusión
Un agente de IA no promete de más porque sea poco fiable por naturaleza, sino porque nadie le ha puesto límites explícitos y una fuente de verdad contra la que verificar antes de hablar de condiciones comerciales. Definir ese catálogo cerrado, anclar sus respuestas a los datos reales de la empresa y probarlo a fondo antes de lanzarlo son los tres controles que marcan la diferencia entre un agente fiable y uno que, tarde o temprano, acaba comprometiendo a la empresa con algo que no puede cumplir.
En MG Solutions diseñamos estos límites como parte del propio agente, no como un parche posterior. Reserva una primera reunión y revisamos juntos qué controles necesitaría el tuyo.