No se comporta igual dos veces

Un cliente le hace a Aura la misma pregunta dos veces, con las mismas palabras, y recibe dos respuestas que no son idénticas: una más larga, otra que ordena los datos distinto, a veces una que incluye un detalle que la otra omite. La reacción natural del equipo de Brisa es buscar el fallo, pero no hay fallo que buscar: así funciona un modelo de lenguaje. Al construir la respuesta, en cada paso elige el siguiente trozo de texto de entre varios candidatos probables, y esa elección lleva algo de azar.

Para el defensor esto no es un detalle curioso, es una base de trabajo. Un sistema que se comporta igual siempre se puede probar una vez y dar por conocido. Un sistema que varía en cada ejecución exige otra forma de pensar: lo que viste que hacía una vez no es lo que hará la próxima.

La variación no es un misterio: se gobierna con un par de perillas del muestreo. Una de ellas —la suele llamar «temperatura»— decide cuánto azar se permite al elegir cada trozo. Subirla da respuestas más variadas; bajarla las hace más parecidas entre sí. El equipo de Brisa puede bajar esa perilla para que Aura sea más estable, y es razonable hacerlo, pero conviene entender qué compra y qué no.

Bajar el azar reduce la variación; no la elimina ni convierte al modelo en determinista. Aunque lo pongas en su valor más estable, sigue sin haber garantía de que una entrada peligrosa se trate igual que la vez anterior. La perilla es un ajuste de calidad y consistencia, no un control de seguridad: no se puede fijar «lo bastante bajo» como para confiar en que el modelo nunca obedecerá una inyección.

Aquí se junta esto con la grieta de la sala anterior. Si el modelo no separa dato de instrucción y además no responde igual dos veces, entonces cualquier defensa escrita como «el modelo se negará a hacer X» es una apuesta, no una garantía. Puede negarse noventa y nueve veces y ceder a la cien, con una variante del mensaje o por el propio azar del muestreo. Diseñar la seguridad contando con que el modelo acierte es construir sobre algo que, por definición, a veces falla.

De ahí sale la regla que ya viste y que ahora tiene una segunda pata: la contención no vive en que el modelo responda bien, vive fuera del modelo. Un componente determinista —código normal, que sí se comporta igual siempre— es el que autoriza lo sensible. El modelo propone; algo que no sortea nada decide.

La misma propiedad cambia cómo se comprueba que una defensa funciona. Si Aura rechaza un intento de inyección en una prueba, eso demuestra que lo rechazó esa vez, no que lo rechace siempre. Un sistema que varía no se valida con una comprobación única; se mide repitiendo, con variantes, y observando con qué frecuencia se sostiene. Esa idea se desarrolla en el módulo de evaluar y vigilar, pero nace aquí, en el no determinismo.

Por ahora basta con instalar el reflejo: ante un sistema con IA, «lo probé y funcionó» es una frase incompleta mientras no diga cuántas veces y con cuántas variantes. Una golondrina no hace verano, y una respuesta correcta no hace a un modelo seguro.

Ya razonaste que el modelo no se comporta igual dos veces y por qué eso empuja la defensa fuera de él. Compruébalo sobre Aura: abre el registro donde el despliegue repitió la misma entrada varias veces y mira que las salidas no coinciden, y cómo está puesta la perilla del muestreo. El registro cierra con un código de la sala.