Por qué la negociación de un agente de IA debe validarse con código, no con prompts

Un modelo de lenguaje instruido por prompt casi siempre respeta los límites que le pides; un validador determinista los respeta siempre. En cobranza regulada, donde cada oferta pronunciada compromete dinero real y obligaciones legales, esa diferencia — entre "casi siempre" y "siempre" — es toda la diferencia. Por eso la negociación de un agente de IA debe validarse con código, no con instrucciones.

Este artículo explica el problema técnico de fondo, el patrón de arquitectura que lo resuelve y cómo se ve implementado en una operación real.

El problema: los prompts son instrucciones, no restricciones

Cuando configuras un agente de voz con un prompt del estilo "nunca ofrezcas más del 20% de descuento ni más de 12 cuotas", estás haciendo una petición a un sistema probabilístico. Los modelos actuales son notablemente buenos siguiendo instrucciones — y aun así:

• La conversación presiona. Un deudor insistente, una historia difícil, veinte minutos de negociación: los modelos tienden a ceder ante presión conversacional sostenida, igual que un asesor humano sin supervisión.
• El contexto se diluye. En conversaciones largas, las instrucciones iniciales compiten con todo lo dicho después. El límite que era nítido en el turno 2 es borroso en el turno 40.
• Los números se transforman. "20% de descuento" puede convertirse, en el razonamiento del modelo, en "20% sobre el saldo con intereses" o "20% más la condonación de cargos" — variaciones que suenan iguales y no lo son.
• El fallo es silencioso. Cuando el modelo excede el límite, no suena ninguna alarma. La oferta indebida se pronuncia con la misma voz segura que la oferta correcta.

Nada de esto es una crítica a los modelos: es su naturaleza. Un LLM optimiza plausibilidad conversacional, no cumplimiento contractual. Pedirle que sea tu mecanismo de control es usar la herramienta equivocada.

El patrón: la IA propone, el validador aprueba

La solución es separar dos responsabilidades que el prompt mezcla:

1. Proponer es trabajo del modelo. Escuchar, entender la situación del deudor, formular la siguiente oferta razonable. Aquí la flexibilidad conversacional es una virtud.
2. Aprobar es trabajo de código determinista. Antes de que cualquier oferta se pronuncie, se valida contra la política del operador: ¿el descuento está dentro del máximo? ¿las cuotas no exceden el tope? ¿el pago inicial cumple el mínimo?

La política contra la que se valida es el sobre de negociación (offer envelope): la estructura de límites que el operador define por segmento — descuento máximo, número máximo de cuotas, pago mínimo, condiciones especiales. El sobre no es una sugerencia en el prompt; es un objeto de configuración contra el que corre una función:

oferta_propuesta = modelo.proponer(conversación)
resultado = validar(oferta_propuesta, sobre_del_segmento)

si resultado == APROBADA  → la oferta se pronuncia
si resultado == RECHAZADA → se bloquea, se registra y el
                            modelo propone dentro del sobre

La propiedad clave: una oferta fuera del sobre es imposible de pronunciar. No improbable — imposible. El modelo puede equivocarse proponiendo; el sistema no puede equivocarse aprobando, porque la aprobación es una comparación determinista, no una inferencia.

Por qué esto importa más en cobranza que en casi cualquier vertical

En un chatbot de soporte, una respuesta fuera de política es un mal rato. En cobranza, una oferta fuera de política es:

• Un compromiso exigible. El deudor escuchó "le acepto el 40% de descuento" de un representante del acreedor. Deshacer eso tiene costo legal y reputacional.
• Un problema de trato justo. Descuentos inconsistentes entre deudores comparables — uno logró presionar al agente, otro no — son exactamente el tipo de arbitrariedad que un regulador cuestiona.
• Un hueco en el P&L. En un portafolio de miles de deudores, un punto porcentual de descuento indebido repetido a escala es dinero grande.

Y hay una asimetría que agrava todo: el agente de IA hace miles de llamadas por día. La tasa de error que era tolerable en un call center de 30 personas se multiplica por dos órdenes de magnitud.

La segunda mitad del patrón: la evidencia

Validar no basta si no puedes demostrarlo. Cada decisión del validador — aprobada o bloqueada — debe quedar escrita en una traza de auditoría inmutable: qué propuso el modelo, contra qué sobre se validó, qué resultado dio, qué se pronunció finalmente.

Esa traza convierte una conversación de cumplimiento incómoda ("¿cómo sabemos que la IA no se salió de la política?") en una consulta trivial: aquí está cada oferta de cada llamada, con su validación, encadenada criptográficamente para que nadie pueda editarla después. La respuesta ante una disputa del titular o un requerimiento de la SIC deja de depender de la memoria institucional.

Cómo se ve en producción

En Gesto, este patrón es la arquitectura central, no una funcionalidad opcional:

• El operador define sobres de negociación por segmento en la consola: descuento máximo, cuotas, pago mínimo.
• Los agentes de voz negocian en español colombiano natural, con turnos por debajo de un segundo — y cada oferta que formulan pasa por el validador determinista antes de pronunciarse.
• Cada propuesta, validación, bloqueo y acuerdo queda encadenado en la traza de auditoría, junto a la grabación y la transcripción completa de la llamada.

El resultado práctico: puedes darle al agente toda la flexibilidad conversacional que hace que la gente negocie a gusto, sabiendo que el perímetro económico y regulatorio de la negociación está garantizado por código.

La pregunta para evaluar cualquier plataforma de negociación con IA es una sola: ¿qué es físicamente imposible que el agente diga? Si la respuesta empieza por "le indicamos al modelo que…", sigue buscando.