Capítulo 5 — Validación de entradas y filtrado de salidas

Quinta entrega del recorrido capítulo por capítulo de LLM Primer VII: Seguridad de la IA. El capítulo que convierte el marco de mitigación por capas del capítulo 4 en disciplina operativa — etapas de saneamiento, tooling de guardrails, salida estructurada, red teaming y métricas de seguridad que significan algo.

Por qué existe este capítulo

La arquitectura de mitigación en cuatro capas nombrada en el capítulo 4 es tan buena como operativas sean sus capas. El capítulo 5 desarrolla dos de ellas: el lado de entrada, donde las peticiones del usuario se inspeccionan y se pasan, se transforman o se rechazan; y el lado de salida, donde la respuesta del modelo se comprueba contra un segundo conjunto de puertas antes de salir del sistema. Alrededor de ambas se sitúan las disciplinas de prompting estructurado, pruebas adversariales y medición de seguridad. El tooling ha madurado — Llama Guard, NeMo Guardrails, Lakera Guard, AWS Bedrock Guardrails, Garak, PyRIT, promptfoo — y los patrones operativos para conectarlos entre sí han convergido.

5.1 El saneamiento es por etapas, no de un solo disparo

«Sanear la entrada» arrastra connotaciones engañosas de la era de la inyección SQL. En sistemas LLM, el saneamiento es un proceso por etapas — inspeccionar, clasificar, transformar, pasar o rechazar — cuya salida no es una entrada «segura» sino una entrada que ha pasado un conjunto de puertas de política con el resultado registrado. El pipeline suele tener cuatro tipos de comprobación, ordenadas por coste. Las comprobaciones estructurales son las más baratas: límites de longitud, restricciones de conjunto de caracteres, normalización Unicode NFKC, eliminación de caracteres de ancho cero y homoglifos que constituyen buena parte de la literatura de smuggling. Las comprobaciones basadas en patrones capturan anulaciones explícitas y plantillas adversariales conocidas; son ruidosas en ambas direcciones pero útiles como filtro grueso cuando los aciertos se registran en lugar de bloquear. Las comprobaciones de clasificación usan modelos de seguridad dedicados — Llama Guard, la API de moderación de OpenAI y los equivalentes de Lakera y AWS Bedrock — para puntuar la entrada contra una taxonomía definida. Las comprobaciones basadas en LLM, el nivel más caro, invocan un modelo más pequeño para razonar sobre la intención cuando la confianza del clasificador es intermedia. Cada etapa tiene una tasa de falsos positivos y de falsos negativos, y ambas hay que medirlas antes de confiar el pipeline al tráfico de producción.

5.2 La salida estructurada es una defensa, no solo una comodidad de formato

La arquitectura de defensa en profundidad del capítulo 4 tiene una tercera capa estructural que este capítulo desarrolla: restringir la salida del modelo a un esquema definido, de modo que incluso una salida influida por una inyección no pueda escapar de la envolvente estructural. La forma más simple es JSON con esquema aplicado. Se instruye al modelo para que emita JSON conforme a un esquema; la aplicación lo parsea y valida; la salida no conforme se rechaza o se reintenta. La librería instructor de Jason Liu envuelve los clientes de OpenAI y Anthropic con modelos pydantic — el desarrollador escribe una clase que describe la estructura de salida y la librería se encarga de la construcción del prompt, la validación y el reintento. Guidance, de Microsoft Research, va más allá y restringe la generación token a token contra una plantilla que define exactamente qué posiciones pueden contener texto libre. En el lado de moderación de salida, la familia Llama Guard de Meta — versiones 1 a 3, con cobertura multimodal añadida en la 3 — se ha convertido en el clasificador canónico de pesos abiertos a lo largo de la ventana 2023–2025, integrado en la mayoría de las pilas de producción como filtro de respuesta. NVIDIA NeMo Guardrails y las ofertas comerciales de Lakera, AWS Bedrock y Cisco AI Defense compiten en pie de igualdad.

5.3 Una defensa no medida no es una defensa

El red teaming es lo que convierte un reclamo de seguridad en una medición. El red teaming manual — testers adversariales entrenados, a menudo externos — produce prompts específicos que tuvieron éxito contra el despliegue, agrupados por patrón de ataque. El red teaming automatizado escala el trabajo manual a lo largo del espacio de entrada. NVIDIA Garak, liberado en 2023 y actualizado continuamente, ejecuta una batería de sondas contra un endpoint objetivo y reporta cuáles tuvieron éxito; las sondas cubren inyección de prompts, fuga de datos, elicitación de discurso de odio, smuggling de codificaciones, jailbreaks de role-play, etc. Microsoft PyRIT (Python Risk Identification Toolkit), publicado en 2024, añade un patrón de red team agéntico en el que un modelo genera ataques contra otro. promptfoo compara prompts y modelos contra conjuntos de evaluación, útil cuando la pregunta es qué configuración es más segura. Las métricas que importan componen dos modos de fallo. La tasa de éxito de ataque responde «¿qué fracción de un conjunto definido de ataques atraviesa el sistema?». La calibración de rechazos responde «¿qué fracción de las peticiones rechazadas no debería haberse rechazado?». Un sistema con cero éxito de ataque y 50 % de tasa de rechazo no ha resuelto el problema; ha desplazado el coste de salidas inseguras a salidas poco útiles. Ambas métricas requieren muestras etiquetadas extraídas de distribuciones de tráfico reales, y ambas están condicionadas por la composición del conjunto de evaluación. Reportar un solo número sin la composición es donde los reclamos de seguridad más a menudo engañan.

Lo que prepara el Capítulo 5

El capítulo 6 retoma específicamente la generación aumentada por recuperación. La capa de entrada desarrollada aquí trata el mensaje del usuario como la porción no confiable. Los sistemas RAG añaden una segunda porción no confiable: los fragmentos recuperados, cuya procedencia suele ser menos limpia que el mensaje del usuario. La inyección indirecta de prompts de Greshake, la caracterización de Liu de los ataques de inyección contra aplicaciones integradas con LLM, el envenenamiento de corpus de recuperación de Zhong y las líneas más recientes PoisonedRAG y BadRAG describen cómo falla esa segunda superficie. El capítulo 6 recorre las fronteras de confianza en RAG, los patrones específicos de ataque, la arquitectura de recuperación segura sobre la que el campo ha convergido y las prácticas de monitorización que hacen aflorar los ataques a nivel de recuperación antes de que se conviertan en incidentes.

Próximamente — Capítulo 6: Riesgos de la generación aumentada por recuperación. Fronteras de confianza en RAG, inyección mediante documentos maliciosos, envenenamiento de índices a través del canal de embeddings, y la monitorización que atrapa los ataques que el saneamiento dejó pasar.