La puerta que no se puede eludir: por qué construí AXON, un compilador para LLM

5:10 de la mañana

5:10 de la mañana, julio de 2025. Me desperté y no volví a dormir. La culpa la tenía un test en rojo.

Tenía listo un agente en Python con LangChain. Su trabajo era escribir código, y ahí estaba la desconfianza: ¿qué le impide escribir código débil, con puertas abiertas a una vulnerabilidad?

Para eso le había montado un guardrail de validación. Revisaba el código que generaba y además lo protegía contra inyección de prompts, que en ese momento era de lo más común. Montar ese escudo no era simple, y ya lo tenía. El último test salió rojo. Pydantic no reconocía la validación, aunque el BaseModel se lo había pasado a la herramienta como args_schema.

Toda la noche le di vueltas a la misma línea:

@tool(args_schema=MiValidacionArgs)

Si esto valida los inputs, lo que llega es JSON limpio. Y si el modelo se equivoca, sale un error de validación. ¿Dónde estaba el hueco?

Esa terminal me tronaba el cerebro.

El error, y lo que quedó después del error

La causa la encontré: las clases tenían que declarar de forma explícita los argumentos, y yo estaba dejando que se infirieran. Un error de los que se arreglan en cinco minutos cuando por fin lo ves.

Pero me quedé con algo más incómodo que el error. Con la validación bien puesta, el agente a veces la ignoraba igual. La validación estaba ahí, y el agente podía pasar por el lado.

Es la diferencia entre un control y una sugerencia. Un control que se aplica solo cuando el sistema elige pasar por él es una sugerencia con buena presentación. Y en un sistema cuyo componente central es un modelo que muestrea sus decisiones, "a veces" no es un caso raro: es una probabilidad que, en suficientes ejecuciones, se cumple.

La otra cosa que estaba investigando esa mañana

Esa misma mañana seguía investigando otra cosa: cómo eliminar las copias en el FFI (Foreign Function Interface) para que mi kernel fuera una tubería limpia. Y venía con una idea en la cabeza: un kernel es una puerta que no puedes eludir.

Es una idea vieja en seguridad, y muy precisa. En un sistema operativo, un programa no toca el disco, la red ni la memoria de otro proceso directamente: se lo pide al kernel, y el kernel decide. No hay otro camino, porque el hardware no lo permite. En los años setenta esto se formalizó como el monitor de referencia, un mecanismo que tiene que cumplir tres condiciones para merecer el nombre: se invoca siempre, no se puede manipular y es lo bastante pequeño para verificarlo.

Mi guardrail no cumplía la primera.

Donde se cruzaron las dos ideas

Ese test en rojo se cruzó con esa idea. Mi guardrail era una puerta que el agente podía rodear. Yo necesitaba una que no se pudiera eludir.

Esa palabra se volvió la clave: eludir. Me empujó a entender por qué tenía sentido construir en AXON un mecanismo que haga esa validación en la compilación. Así la protección no se puede omitir: el código que la salta no compila.

Y ahí está la respuesta a la pregunta que más me hacen, que es por qué un lenguaje y no una librería más. Una librería vive dentro del programa, y todo lo que vive dentro del programa se puede no llamar. El compilador vive antes del programa. Un programa que no pasa el compilador no existe: no hay ejecución que pueda elegir otro camino, porque no hay ejecución. El sistema de tipos es la única puerta que un programa no puede rodear, por la misma razón que un proceso no puede rodear al kernel: no hay otro camino hacia fuera.

Lo que hay hoy

De esa mañana salió AXON, el lenguaje de programación que construyo desde entonces —AXON programming language en la documentación, axon-lang en la terminal—. Es un lenguaje compilado cuyo destino no es un procesador, sino un modelo: escribes un programa, el compilador lo verifica, y un runtime lo ejecuta contra un LLM.

La idea de la puerta está en su centro. Un dato regulado lleva su clase en el tipo, y cada frontera por la que cruza tiene que declarar un control que la cubra. Si quitas el control, el programa no compila. Lo muestro con la salida real del compilador en HIPAA y LLM: la fuga de datos de pacientes como error de tipo, y la regla completa está en la documentación, en cumplimiento en compilación.

La misma idea se extiende a otras puertas: que una conjetura del modelo no pueda escribirse como un hecho en un sistema de registro, que un agente no pueda gastar más de su presupuesto, que la autoridad delegada solo pueda reducirse. Cada una es un guardrail que dejó de ser opcional.

Lo que la puerta no hace

Una puerta que no se puede eludir no es lo mismo que una puerta correcta. El compilador garantiza que el control está en cada frontera; no que el control sea el adecuado. Si declaras un escudo que protege contra lo que no era, compila igual. Elegir qué revisa la puerta sigue siendo trabajo de quien la diseña.

Eso no le quita valor. Le da el tamaño exacto. El fallo que me despertó a las 5:10 no era que mi guardrail estuviera mal diseñado. Era que el agente podía no pasar por él. Ese fallo concreto, el de la puerta rodeada, es el que el compilador hace imposible.

Para llevarte

• Un guardrail que el sistema puede elegir no usar es una sugerencia, no un control.
• Validar la entrada de una herramienta no obliga al agente a usar esa herramienta.
• Un kernel funciona porque no hay otro camino hacia el hardware. Un compilador puede hacer lo mismo con el código: si no hay otro camino hacia la ejecución, la puerta no se puede rodear.
• La garantía es estrecha: asegura que el control está, no que sea el correcto. Por eso es exacta.