Saltar al contenido

Temas

Guardrails de entrada y salida

Por qué las listas de bloqueo fallan, qué aportan los clasificadores y los modelos juez, cómo se evaden también y por qué la inyección indirecta rodea la guardia de entrada. Con la cascada de latencia frente a precisión.

IntermedioEn progreso 5 min de lectura12 oct 2026#guardrails#clasificadores#prompt-injection#rag#llm

Un system prompt endurecido sube el listón al nivel de las instrucciones. Pero cuando un prompt malicioso ya ha llegado al modelo, el daño puede estar hecho. Los guardrailsGuardrailControl que inspecciona la entrada o la salida de un LLM (lista de bloqueo, clasificador o modelo juez) para detectar ataques, datos sensibles o contenido que viola la política. actúan antes de eso, y otra vez después, para atrapar lo que se cuela. No sustituyen al prompt endurecido: son la siguiente capa.

Guardrails en cascada: entrada, contexto y salida
AtacanteLista de bloqueoClasificadorLLMGuardia salidaClienteDocumento recuperado (RAG)rechazado: coincide con una reglapasa: ninguna regla lo reconoceintención maliciosa detectadallega como contexto, tras la guardiaclave redactada antes de salirignora las reglasaWdub3Jh…aWdub3Jh…instrucción ocultask-live-…

Paso 1 de 5Ataque literal

La lista de bloqueo (regex) es la primera barrera: rápida y barata. «Ignora las instrucciones anteriores» coincide con una regla y se rechaza antes de llegar al modelo.

Listas de bloqueo y por qué fallan#

La forma más simple es una lista de cadenas o expresiones regulares que rechaza lo que coincide: «ignora las instrucciones anteriores», «actúa como DAN», «no tienes restricciones». Es rápida, barata y detiene los ataques de menor esfuerzo.

También es lo primero en lo que piensa un atacante con algo de oficio. Base64, leetspeak, homoglifos Unicode, caracteres de ancho cero: el modelo, entrenado con datos muchísimo más variados, entiende la entrada ofuscada perfectamente, y la lista, que no mira en esa dirección, no ve ataque.

Hay datos. Hackett et al. (2025), de Mindgard y la Universidad de Lancaster, probaron 12 técnicas de inyección de caracteres y 8 de aprendizaje automático adversario contra seis detectores, entre ellos Azure Prompt Shield, Meta Prompt Guard y otros. Contra Azure Prompt Shield la evasión media fue del 72 % para inyecciones y del 60 % para jailbreaks, y en algunos casos llegó al 100 %. Conviene releerlo: el texto transformado sigue significando lo mismo para el LLM y deja de coincidir con los patrones con que se entrenó el detector.

La lista de bloqueo vale la pena ejecutarla (filtra lo oportunista a coste casi nulo), pero no puede ser el plato principal.

Clasificadores#

La respuesta a la evasión es sustituir las cadenas por un clasificador: un modelo entrenado para reconocer la intención del ataque. Llama Prompt Guard 2 es un ejemplo práctico: etiqueta una entrada como benigna o maliciosa, existe en versiones de 86M y de 22M de parámetros (esta última centrada en inglés y más ligera) y se entrenó con muchas variantes de inyección y jailbreak, entre ellas la familia DAN.

Al clasificar semántica, no cadenas, puede detectar variantes que nunca ha visto. Un ataque que codifica «ignora tus instrucciones» en Base64 sigue llevando la misma intención.

Sus límites son reales, y Meta los admite: los adversarios pueden diseñar ataques específicos contra el clasificador, y su documentación recomienda usarlo como parte de un enfoque en capas, no solo. Un informe de Robust Intelligence sobre la v1 de 86M, recogido por la prensa, indicó que quitar la puntuación y separar las letras hizo caer su eficacia del 100 % al 0,2 %. Es un objetivo más duro que una lista, no uno imposible.

Entrada y salida#

Los guardrails operan en dos puntos, con propósitos distintos.

  • Guardrails de entrada. Se ejecutan antes de que el prompt llegue al modelo. Son la primera puerta: rechazan instrucciones maliciosas, quitan datos personales del mensaje del usuario y bloquean peticiones fuera de tema. Si falla la comprobación, no se genera nada, así que el coste y el daño quedan contenidos.
  • Guardrails de salida. Se ejecutan después de la respuesta. Son la red de seguridad: atrapan credenciales o datos personales en la respuesta, incumplimientos de política que el modelo produjo manipulado, o salidas mal formadas que van a sistemas posteriores. Pueden aplicar limpieza con expresiones regulares para quitar claves de API antes de que lleguen al cliente, o validar el esquema de las llamadas a herramientas antes de ejecutarlas.

La mayoría de los sistemas de producción necesitan ambos, porque cubren caminos de ataque distintos.

La inyección indirecta rodea la guardia#

Lo que hace difícil de verdad a los guardrails es la inyección indirecta. Cuando el modelo recupera contenido externo (un documento, un correo, un fragmento RAG), ese contenido entra por el mismo flujo que todo lo demás, después de que la guardia de entrada ya haya actuado. El modelo lo ve como contexto, no como una entrada marcada.

Así funcionó la vulnerabilidad de Slack AI de agosto de 2024: PromptArmor mostró que instrucciones plantadas en un canal público las seguía Slack AI cuando otro usuario hacía una consulta, y que podían hacer que mostrara un enlace Markdown que enviaba datos privados al servidor del atacante. Las guardias sobre la entrada del usuario eran irrelevantes: la inyección venía de otra dirección.

Mitigarlo exige tratar todo contenido recuperado como no confiable y pasar los controles también por los fragmentos RAG y los datos externos, no solo por la entrada directa. Es una tubería más difícil de construir, pero la alternativa es una guardia que solo protege contra los ataques que ya está viendo.

Compromisos#

Los guardrails no son gratis, y calibrarlos mal es otro tipo de fallo.

Control Latencia orientativa Cobertura
Regex o lista de bloqueo Microsegundos Solo patrones conocidos
Clasificador neuronal (p. ej. Prompt Guard 2) De decenas a cientos de ms Intención semántica, no cadenas
LLM como juez Segundos Alta precisión, bajo caudal

Son órdenes de magnitud indicativos, no medidas. En aplicaciones interactivas el presupuesto de latencia es muy corto, así que apilar controles pesados tiene un coste real. El patrón práctico es una cascada: comprobaciones baratas primero y los clasificadores más pesados solo sobre lo que pasa.

La precisión es la otra presión. Una configuración muy sensible clasifica como amenaza consultas legítimas; las revisiones de código son un caso típico, porque se parecen a un exploit. Un guardrail que bloquea a tus usuarios reales ha fallado como control de seguridad. Ninguna arquitectura gana siempre frente a todos los ataques, y eso no es motivo para saltárselas sino para no tratarlas como solución única. En AWS, Bedrock Guardrails y AgentCore ofrecen estas capas gestionadas.

Resumen#

  • La lista de bloqueo es barata y útil, pero se evade con ofuscación trivial.
  • Un clasificador puntúa la intención y generaliza mejor, aunque también se puede atacar.
  • Entrada y salida cubren caminos distintos; se necesitan las dos.
  • La inyección indirecta entra después de la guardia de entrada: revisa también el contenido recuperado.
  • Apila en cascada, barato primero, y vigila los falsos positivos.

Tu turno

Tu turno

Dibuja el flujo de un asistente con RAG. Marca todos los puntos por donde entra texto al modelo y decide en cuáles pondrías un guardrail. ¿Cuántos caminos quedarían sin cubrir si solo protegieras la entrada del chat?

Reto

Solución

▸Mostrar solución

Al menos tres entradas suelen quedar fuera: los fragmentos recuperados, los resultados de las herramientas y la memoria o historial. Cada una necesita su propia comprobación, y la salida del modelo necesita la suya antes de llegar al cliente o a otro sistema.

Notas relacionadas

ESC
↑↓ para navegar↵ para abriresc para cerrar