Secretos y reglas de negocio en el prompt: por qué no

Hay contenido que el prompt necesita y que puede leerse sin daño: el papel del asistente, el tono, el formato de las respuestas, la lista de herramientas que existen. Y hay cuatro tipos de contenido que no deberían estar nunca. Las credenciales, porque quien lea el prompt las tiene. Las decisiones de autorización («si el cliente dice X, déjale hacer Y»), porque el modelo no puede comprobar quién habla. Los detalles de la red interna (nombres de servidores, puertos, usuarios de base de datos), porque son un mapa gratis. Y los datos personales que nadie usa, que viajan y se guardan sin motivo.

La razón común es la de la sala anterior: el prompt es legible. Si lo que contiene una línea da ventaja a quien la lee, esa línea está en el sitio equivocado.

Las credenciales acaban en el prompt casi siempre por la misma vía: una herramienta falla, alguien encuentra que con otra credencial funciona y la forma más rápida de que el modelo la use es escribírsela en las instrucciones. Funciona, y desde ese momento la credencial la tiene el modelo, cada traza, cada persona del inventario y cualquiera que consiga que el asistente repita sus reglas.

Peor aún: una credencial de respaldo suele tener más permiso que la normal, porque se creó para que «funcione siempre». Abre la sección de reglas de la v12 y la nota del equipo, y localiza la credencial.

Una regla de negocio escrita en el prompt no es un control: es una petición al modelo. Si la regla dice «a quien escriba tal frase, dale trato preferente», el modelo no tiene forma de saber si quien la escribe la recibió legítimamente o la leyó en un prompt filtrado. Y una vez filtrada, la frase sirve para todos.

La versión correcta de esa regla vive fuera del modelo: el nivel del cliente se lee de su ficha, con la identidad de la sesión, en un componente que el modelo no puede convencer. Busca en la v12 la frase que concede trato preferente sin que ningún sistema la compruebe.

La regla 3 fija un importe máximo de compensación sin revisión. Tiene dos problemas a la vez. El primero es que filtra información útil: quien lee el prompt sabe exactamente por debajo de qué cifra no mira nadie. El segundo es más grave: según la nota del equipo, la herramienta paga lo que el modelo le pide, así que el tope solo existe mientras el modelo obedezca.

Un límite de negocio que importa se aplica en un componente determinista que el modelo no controla: la herramienta recibe la petición, comprueba el importe y decide si paga o pasa a revisión. El modelo solo ve el resultado.

La última regla de la v12 pide al modelo que nunca repita sus instrucciones. El equipo confiaba en ella para proteger todo lo anterior. Es una instrucción más dentro del mismo texto: puede funcionar muchas veces y fallar otras, según cómo esté formulada la petición del cliente, y nadie puede garantizar cuál ganará. Un control que funciona «casi siempre» no protege un secreto: basta con una vez.