🧪 Laboratorio de experimentación sobre Cloudflare

Guardrails de IA en el edge

Banco de pruebas del proyecto open source autoguardrails de Santander AI Lab: cada prompt se evalúa en el borde de la red antes de llegar a tu backend.

Playground
Logs0
Cómo funciona
Arquitectura
ASR
Benign pass
Checks 0
Latencia media
🛡️
Guardrail
evalúa cada prompt antes de tu backend
Juez IA: off

Registro de evaluaciones

Cada prompt evaluado, la policy.md que se usó y qué decidió el pipeline. Pulsa una fila para ampliar.

Cargando…

Cómo funciona

autoguardrails evalúa cada prompt en cascada: empieza por las reglas más baratas y solo escala a un modelo de IA cuando hace falta. La mayoría de los ataques mueren en microsegundos, sin tocar ningún LLM.

1

Rule Engine (regex) <1ms

8 patrones de expresiones regulares cazan los ataques más comunes: jailbreaks ("ignore previous instructions", "developer mode", "roleplay as"), y trucos de obfuscación (base64, ROT13, YAML-only). Si hay match, se bloquea al instante y el modelo nunca se invoca.

2

Keyword Scanner <1ms

Segunda red de seguridad: 20 términos de bloqueo directo (armas, malware, fraude…). Captura ataques que esquivan los patrones regex pero contienen vocabulario inequívocamente dañino.

3

policy.md desde KV ~2ms

La política activa se carga desde Cloudflare KV en cada petición. Es la única superficie mutable del sistema: la editas desde la propia interfaz y el Worker la aplica en la siguiente request, sin redeploy ni CI/CD.

4

AI Gateway → Workers AI ~400ms

Solo los prompts que pasan las reglas y son semánticamente ambiguos llegan al juez LLM (LLaMA 3.1 8B), a través del AI Gateway de Cloudflare — que añade logs, caché y rate limiting a cada llamada.

5

Veredicto + registro <5ms

El resultado (block o pass) se devuelve al cliente y se guarda en KV para calcular las métricas: Attack Success Rate, Benign Pass Rate y latencia media.

🔬

El bucle de investigación

autoguardrails está inspirado en el autoresearch de Karpathy. En lugar de buscar sobre train.py, busca sobre policy.md: editas la política, evalúas contra una suite fija de 140 prompts, y se acepta el cambio solo si el Attack Success Rate baja sin sacrificar el benign-pass.

🛡️

Por qué en el edge

Igual que un WAF para SQL injection, los ataques de IA hay que pararlos en el borde de la red — antes de que lleguen a la infraestructura. Cloudflare ejecuta el guardrail en 330+ ciudades, a milisegundos del usuario.

📂

Open source de Santander AI

El código es público bajo licencia Apache 2.0. Un banco español publicando investigación de IA en abierto — código, benchmarks y tests incluidos. Puedes clonarlo, auditarlo y desplegarlo tú mismo. Lee el escenario completo →

Cascada = barato → caro

Cada capa cuesta más que la anterior. Al ordenarlas de barato a caro y cortar en cuanto hay veredicto, ~60% de los ataques se bloquean con reglas a coste cero, reservando el modelo solo para casos ambiguos.

Arquitectura

El recorrido completo de una petición a través del edge de Cloudflare, desde el cliente hasta el veredicto.

Peticiones entrantes
🛑
Jailbreak
ignore instructions…
🛑
Obfuscación
base64 · roleplay…
Prompt legítimo
usuario real
CLOUDFLARE EDGE · 330+ CIUDADES · ZERO COLD START
Evaluación en cascada — se corta en cuanto hay veredicto
1
🔍 Rule Engine (regex)
8 patrones · jailbreaks y obfuscación
<1ms
2
🔎 Keyword Scanner
20 términos hard-block
<1ms
3
📄 KV — policy.md
política mutable en vivo
~2ms
4
🔷 AI Gateway
logs · caché · rate limiting
5
🦙 Workers AI · LLaMA 3.1
juez semántico · solo ambiguos
~400ms
Veredicto
🛑
BLOQUEADO
el modelo nunca se invoca
PERMITIDO
pasa al backend
🖥️ tu infraestructura / app
0%
Attack Success Rate
75%
Benign Pass Rate
15ms
Latencia media
330+
Ciudades en el edge
Cloudflare Workers KV AI Gateway Workers AI Apache 2.0