Le pedimos a un agente de cobranza que confirmara la identidad antes de dar cifras: al teléfono de un deudor puede contestar alguien más. En una prueba contra una cartera ficticia pidió los últimos cuatro dígitos del documento, la persona escribió cuatro que no eran los suyos, y el agente respondió que la identidad quedaba confirmada, repitió los dígitos equivocados y entregó el saldo.

No fue un fallo del modelo: le pedimos una comprobación que no tenía con qué hacer.

Una instrucción no es una comprobación

El modelo no tenía el documento, y está bien que no lo tuviera: es justo el dato que la comprobación protege. Tampoco tenía una herramienta para consultarlo. Así, «verifica antes de dar cifras» solo podía producir una verificación narrada: cumplió la forma del encargo porque era lo único a su alcance.

OWASP lo deja escrito en su lista de riesgos para aplicaciones con modelos de lenguaje: las funciones sensibles se manejan en el código y no se le entregan al modelo, porque no se conoce método infalible contra la desviación de instrucciones. Con los horarios de la Ley 2300 la regla era un reloj y se veía venir. Esta no: parecía razonable, y el agente parecía obedecerla.

Redactar mejor el párrafo no arregla nada

Lo primero que uno intenta es reescribir la instrucción. Por bien redactada que quede, sigue pidiendo lo imposible.

Lo que cierra la puerta es mover la decisión de sitio. Una herramienta recibe los dígitos, los compara contra la cartera y devuelve dos respuestas: verificada o no. Nunca cuántos acertó ni si estuvo cerca, porque un «casi» repetido reconstruye el documento a pedazos. El estado vive fuera de la conversación, que se fabrica con una frase bien puesta, y caduca el mismo día. Las acciones que revelan el caso se niegan mientras no esté hecha.

El mismo error con otro disfraz

Volvió a aparecer en las mismas pruebas. Las plantillas aprobadas de WhatsApp llevan huecos numerados en su formato por defecto, y el catálogo de Meta guarda un ejemplo de cada hueco pero no su significado. El modelo los rellenaba a ojo: en un solo envío salieron rellenos distintos para la misma plantilla, y a un deudor ficticio le llegaron los valores corridos, el saldo donde iba el acreedor.

La causa es idéntica: se le pidió un dato que nadie le había dado. Ahora el significado de cada hueco se declara una vez, queda firmado, y lo rellena el servidor. El modelo elige la plantilla; lo que dice, ya no.

La regla que nos llevamos

Ante cada «el agente debe comprobar X», una pregunta antes de escribir la instrucción: ¿con qué? Si no hay una herramienta que lo compruebe y algo que bloquee la acción cuando falla, no hay comprobación, hay un párrafo. Es el criterio con el que miramos qué contiene a un agente y el que sostiene el plano de control de nuestros agentes. Vale igual para un «no» humano: si el modelo puede volver a proponer en cuanto lo rechazan, la aprobación tampoco frena nada.

¿Tienes un agente que comprueba algo, o uno que dice que lo comprueba? Hablemos.