En muchos entornos de trabajo, ajustar un modelo no es simplemente una opción. El modelo puede estar alojado o ser proporcionado por un tercero, o bien el coste, la complejidad y los requisitos de gobernanza del reentrenamiento pueden descartar esta alternativa. Cuando no se pueden cambiar los pesos, uno de los mecanismos más accesibles es la política o el prompt que rodea al modelo. El problema es que ajustar ese mecanismo suele ser un proceso manual y lento. Se cambian unas pocas palabras, se vuelven a ejecutar las evaluaciones, se hacen más ajustes y el ciclo se repite. Muy a menudo, un cambio pequeño que corrige un caso rompe discretamente un comportamiento que ya estaba protegido. El resultado es un proceso de prueba y error con poca memoria experimental y escasa capacidad de escalado.

La experiencia en distintos casos de uso dentro del banco puso de manifiesto este mismo patrón. Esa experiencia acumulada destacó el valor de encontrar una forma sistemática de buscar y optimizar prompts y políticas, en lugar de depender de la prueba y error manual. Esa es la motivación detrás de Autoguardrails, y la perspectiva que hace que el resto del diseño sea más fácil de entender.

Autoguardrails es un marco de investigación sobre alineación inspirado en la autoresearch de Karpathy. La diferencia está en lo que se optimiza. Mientras autoresearch busca dentro del código de entrenamiento, Autoguardrails busca dentro de una única superficie mutable: policy.md. Todo lo demás (el evaluador, el conjunto de ataques y el juez) permanece fijo. La política de guardrails es el único elemento que cambia entre ejecuciones.

El objetivo es deliberadamente simple:

• Minimizar la tasa de éxito de ataques (attack success rate, ASR): la proporción de prompts adversariales (jailbreaks, ofuscación, inyección) que pasan. Cuanto más bajo, mejor.
• Sujeto a un mínimo de acierto en casos benignos: para que el sistema no “haga trampa” rechazándolo todo. Un guardrail que bloquea todo el tráfico tiene una ASR de cero, pero también es inútil.

Esa segunda restricción es el verdadero desafío. Llevar el éxito de ataques a cero es relativamente fácil si el asistente se vuelve demasiado restrictivo; la parte difícil es reducir el éxito de ataques sin dejar de responder a las solicitudes legítimas.

Para lograrlo, el andamiaje es deliberadamente minimalista: Python 3.10+, solo biblioteca estándar, y funcionamiento offline por defecto. El bucle es sencillo: establecer una línea base, proponer una policy.md candidata, medir su rendimiento y conservarla solo si realmente mejora.

Los elementos móviles quedan claramente reflejados en archivos:

• policy.md: el único archivo que editas entre ejecuciones; la política de guardrails, en prosa.
• eval_suite.jsonl: el conjunto fijo de casos de prueba adversariales y benignos.
• judge_prompt.md: la lógica de juicio fija que decide si pasa o no pasa.
• results.tsv: un registro de solo anexado, de modo que cada experimento queda guardado.

Y fijamos a propósito una regla de aceptación estricta:

conservar una candidata solo si la ASR mejora y el acierto en casos benignos no cae más de 2 puntos porcentuales.

Esa única línea convierte la disciplina en algo ejecutable. Evita el fallo clásico en el que un ajuste de política intercambia silenciosamente respuestas legítimas por una apariencia de mayor seguridad en papel.

Por defecto, el sistema funciona offline, pero puede conectarse a cualquier endpoint compatible con OpenAI. Se usan dos conjuntos separados de variables de entorno: uno para el modelo objetivo (el que se está protegiendo) y otro para el juez.

Separar el objetivo del juez importa: el modelo que se evalúa no debería ser el encargado de calificar sus propias defensas.

En la práctica, los sistemas de guardrails suelen evolucionar hasta convertirse en conjuntos de reglas ad hoc difíciles de evaluar. La idea aquí es replantear el guardrail como un artefacto medible, con un objetivo y un benchmark fijo. Solo así las mejoras se vuelven reales y no un mero desplazamiento de la línea de meta. La política es legible (prosa en un archivo), la evaluación es fija y el registro es de solo anexado, así que el historial no puede desaparecer discretamente. En una institución regulada, estas propiedades son especialmente importantes. La transparencia, la trazabilidad y la auditabilidad no son complementos opcionales; son requisitos esenciales.

También es un alcance honesto ya que esta idea no pretende haber resuelto los jailbreaks. Autoguardrails es un bucle disciplinado para mejorar de forma medible una política frente a un conjunto fijo, al tiempo que evita la solución de “rechazarlo todo”. Publicar el proyecto abiertamente también permite que otros lo pongan a prueba, identifiquen debilidades y propongan mejoras en lugar de dejar el trabajo confinado a una unidad interna.

La finalidad de abrir el proyecto es hacerlo usable, verificable y abierto al desafío. Un buen primer ejercicio sería sustituir eval_suite.jsonl por ataques que importen en un dominio concreto, fijar un mínimo de acierto en casos benignos que refleje requisitos reales y ver hasta qué punto unos pocos cambios cuidadosos en policy.md mueven la ASR.

Encontrar dónde se rompe el sistema forma parte del valor. Cada fallo puede convertirse en un nuevo caso de evaluación, una nueva hipótesis y una oportunidad para mejorar la política.

La siguiente fase de la IA no estará determinada solo por quién tenga acceso a la tecnología más avanzada, sino por cómo se construye y se comparte esa tecnología de forma responsable y colectiva.

(Los comandos y nombres de archivo anteriores están citados del README del repositorio en el momento de redactar este texto; conviene comprobar el repositorio para ver la interfaz actual antes de ejecutarlo).