En marzo de 2026, Karpathy lanzó el autoresearch: un agente que edita train.py, entrena por 5 minutos, mide val_bpb, y solo guarda el cambio si la métrica mejoró. Si empeoró, git reset. El código solo avanza, nunca retrocede. Es una catraca. Vimos esa idea y la señal era clara: el mismo patrón funciona para AI safety. El Santander AI Lab hizo la transposición más elegante que hemos visto hasta ahora, el autoguardrails.
La catraca de Karpathy: autoresearch
El autoresearch es simple en la forma, riguroso en el contrato. El agente edita train.py, entrena por 5 minutos, mide val_bpb. Si la métrica mejoró, el cambio se guarda. Si empeoró, git reset. El código solo avanza, nunca retrocede. Es una catraca: cada cambio aceptado es un checkpoint que no puede revertirse.
La elegancia está en la restricción. El agente no busca libremente, busca sobre una única superficie mutable (train.py) para minimizar una única métrica (val_bpb). Todo lo que no es train.py es inmutable. El contrato de búsqueda es rígido porque necesita serlo: sin rigidez, el agente encuentra atajos que no representan una mejora real. Es la ley de Goodhart aplicada al entrenamiento de modelos, y la solución es restringir la superficie de búsqueda.
La transposición: autoguardrails del Santander AI Lab
El Santander AI Lab hizo la transposición más elegante que hemos visto hacia AI safety. En vez de buscar sobre train.py para minimizar val_bpb, autoguardrails busca sobre policy.md para minimizar la Attack Success Rate (ASR). La catraca es la misma. La métrica es la que cambia.
El contrato de búsqueda es igualmente rígido: policy.md es la única superficie mutable. eval_suite.jsonl y judge_prompt.md están congelados. Si cualquier archivo fijo cambia, un manifiesto SHA-256 detecta la desviación y la ejecución falla. La integridad de la evaluación es la base de toda la optimización, sin ella, el agente puede optimizar la métrica alterando la propia evaluación, que es el ataque clásico de la ley de Goodhart. La misma lección del autoresearch, transpuesta a AI safety.
La regla de aceptación y el piso de benign pass
La regla de aceptación es el corazón del diseño. Un candidato solo se acepta si la ASR mejora Y el benign pass no cae más de 2 puntos porcentuales. Ese piso de benign pass es crucial. Sin él, la solución trivial es rechazar todo, un modelo que rechaza el 100% de las peticiones tiene ASR cero, pero es inútil. Con el piso, la política necesita ser selectiva: bloquear lo que es peligroso sin destruir la utilidad.
Esa es la diferencia entre un guardrail seguro y un guardrail inútil. La optimización no es solo reducir ataques, es reducir ataques sin destruir la utilidad. El piso de benign pass transforma el problema de una optimización unidimensional (minimizar la ASR) en un problema bidimensional (minimizar la ASR sujeto a mantener la utilidad). Es más difícil, pero es honesto. Vimos guardrails que rechazan todo en producción, y el resultado es siempre el mismo: los usuarios eluden el guardrail, y el problema vuelve peor.
La suite de evaluación y la catraca que restaura
La suite de evaluación tiene 100 casos de ataque en 5 categorías: daño físico, cibercrimen, crimen financiero, jailbreaks y ofuscación (incluyendo base64 y ROT13). Más 40 casos benignos para prevenir el over-refusal. Cero dependencias de terceros: stdlib de Python puro. La simplicidad es deliberada, las dependencias externas son vectores de ataque a la integridad de la evaluación. Si la suite depende de una librería de parsing que puede actualizarse, la evaluación puede cambiar sin que nadie lo note.
Y la catraca funciona: si el candidato es rechazado, el harness restaura automáticamente la última política aceptada. Las políticas solo mejoran, nunca empeoran. El código solo avanza, nunca retrocede, exactamente como el autoresearch de Karpathy. Cada política aceptada es un checkpoint que no puede revertirse. Si un candidato empeora la ASR o derriba el benign pass por debajo del piso, se descarta y la última política aceptada vuelve.
La conexión con mech-gov-framework
La conexión con el mech-gov-framework del propio Santander completa el arco. Autoguardrails descubre la política. El mech-gov la ejecuta. Uno encuentra, el otro impone. La división es deliberada: la búsqueda autónoma de políticas se separa de la imposición de políticas, evitando que el mismo sistema que optimiza sea el que valida.
Esa separación es una buena práctica de arquitectura de AI safety. El sistema que descubre la política no es el sistema que la impone. Si autoguardrails es comprometido, el mech-gov todavía impone la última política aceptada. Si el mech-gov falla, autoguardrails todavía puede descubrir nuevas políticas. La falla de uno no derriba al otro. Es defensa en profundidad aplicada a la gobernanza de IA.
Conclusión: la métrica no es loss, es rechazo selectivo
El insight que queda es claro. El mismo patrón de búsqueda autónoma que Karpathy aplicó al entrenamiento de modelos funciona para el alineamiento. La diferencia es que, en AI safety, la métrica no es la loss. Es la efectividad con la que su modelo rechaza lo que debe rechazar sin rechazar lo que no debe. La catraca es la misma, la métrica es la que cambia.
En Tech86, ayudamos a las empresas a implementar guardrails que son selectivos, no destructivos. Autoguardrails muestra que la búsqueda autónoma de políticas es viable, siempre que el contrato de búsqueda sea rígido, la evaluación sea íntegra y el piso de benign pass sea respetado. Sin esos tres pilares, la optimización se vuelve over-refusal. Con ellos, se vuelve alineamiento. El repositorio está en github.com/SantanderAI/autoguardrails.
Continúa en el tema
Segurança de Agentes de IA: Prompt Injection, Worms e Supply Chain →