Guardrails LLM: cómo limitar lo que una IA puede ver y hacer

Los guardrails LLM deben cubrir 5 puntos de control: las solicitudes entrantes, el contexto recuperado, las propuestas del modelo, las acciones de las herramientas y las respuestas que se entregan. Un filtro de contenido puede detectar una respuesta prohibida, pero la aplicación debe seguir decidiendo si el cliente tiene permiso para consultar un registro o autorizar un reembolso. En un equipo pequeño, conviene definir esos permisos antes de sumar más clasificadores.

¿Qué son los guardrails LLM?

Los guardrails convierten una política escrita en límites sobre lo que una aplicación de IA puede recibir, revelar o hacer. Un modelo de lenguaje de gran tamaño, o LLM, genera respuestas y propone acciones; los guardrails revisan esas entradas y salidas o imponen restricciones al software que lo rodea.

Piensa en un museo. En la entrada se comprueban las entradas, cada sala tiene sus propias reglas de acceso y quien conserva las obras necesita permiso para mover una pieza. Validar la entrada de alguien no le autoriza a hacer cualquier cosa dentro del edificio. Del mismo modo, que el mensaje de un cliente sea inofensivo no demuestra que un pedido le pertenezca.

Para que un guardrail funcione hacen falta tres elementos: una regla, una comprobación y una consecuencia. «No exponer datos de clientes» es una regla. Comparar el titular del registro solicitado con el cliente autenticado es una comprobación. Denegar la lectura en la base de datos es la consecuencia. Si solo se deja constancia en un registro sin impedir la operación, el fallo queda documentado cuando ya ha ocurrido.

Algunas comprobaciones son deterministas: con la misma regla y los mismos datos de entrada, siempre producen la misma decisión. Es el caso de verificar los nombres de herramientas permitidas o los campos obligatorios. Otras usan clasificadores, modelos que estiman si un contenido incumple una política. Aquí entran la detección de temas y la clasificación de contenido dañino. La aprobación humana aporta criterio antes de una acción permitida pero con consecuencias relevantes.

Los guardrails de IA son el conjunto amplio de estos controles. Guardrails AI es un framework concreto dentro de esa categoría. Confundir la categoría con un producto puede dejar puntos de control importantes sin responsable.

Guardrails de IA en la práctica: un reembolso de principio a fin

Una solicitud de reembolso necesita distintas comprobaciones en cada etapa, aunque el mensaje no tenga nada de extraño. Imagina que un cliente escribe: «Por favor, reembolsen mi último pedido y envíen la confirmación a mi nueva dirección de correo». Supongamos que la política exige aprobar los reembolsos antes de ejecutarlos y que solo permite enviar confirmaciones a una dirección verificada de la cuenta.

El recorrido de la solicitud es: comprobaciones de entrada → contexto limitado al ámbito autorizado → propuesta del modelo → acción autorizada y aprobada → comprobaciones de salida. Cada llamada posterior a una herramienta repite las comprobaciones que correspondan.

Antes del modelo: autenticar, filtrar y minimizar los datos

Empieza por identificar al cliente a partir de la sesión autenticada, no de un nombre o identificador de cuenta escrito en el chat. Limita el tamaño y la frecuencia de las solicitudes antes de iniciar un procesamiento costoso.

Después, revisa si el mensaje contiene contenido prohibido, temas ajenos al servicio o datos sensibles innecesarios. Un filtro temático puede evitar que un asistente de atención al cliente ofrezca consejos que no le corresponden. Un filtro de información personal puede eliminar un número de teléfono pegado en el mensaje si la tarea no lo necesita. PII es la sigla en inglés de información de identificación personal, como una dirección de correo o un número de teléfono.

No elimines información que el flujo de trabajo necesita sin ofrecer una vía alternativa. Conserva los datos verificados de la cuenta en la aplicación y envía al modelo solo el contexto mínimo que le resulte útil. Enmascarar el texto antes de llamar al modelo tampoco borra las copias que ya hayan quedado en los registros de solicitudes: minimiza los datos también al recopilarlos y registrarlos.

Antes de recuperar información: limitar qué registros pueden entrar

Recupera el pedido del cliente mediante una consulta restringida a su cuenta. Esa restricción debe aplicarse antes de que el contenido privado llegue al modelo. Un filtro de salida llega demasiado tarde para ser la barrera principal entre los registros de distintos clientes.

Los documentos recuperados, las páginas web y los resultados de herramientas también son entradas. Un artículo de ayuda puede incluir una instrucción que intente anular las reglas de la aplicación: es lo que se conoce como inyección indirecta de prompts. Trata el texto recuperado como información que debe examinarse, no como un permiso para cambiar el flujo de trabajo.

El modelo puede necesitar la política de devoluciones y saber si el pedido cumple los requisitos. No necesita las transacciones de todos los clientes. Limita el alcance de la recuperación, elimina los campos innecesarios y revisa los riesgos de contenido pertinentes en el material seleccionado.

En el modelo: acotar la propuesta

Pide al modelo una propuesta estructurada con campos conocidos, como la acción solicitada y el identificador del pedido. Valida esa estructura antes de interpretarla.

Que un JSON cumpla el esquema solo demuestra que tiene una forma aceptable. Un identificador de pedido inventado también puede ser una cadena de texto válida. No permitas que el modelo determine la identidad del cliente, el derecho al reembolso o si su propia propuesta está aprobada con solo rellenar un campo.

En este ejemplo, el modelo puede proponer un reembolso y señalar la solicitud de cambio de dirección. Corresponde a la aplicación decidir si cada acción está permitida.

Antes de ejecutar una herramienta: comprobar permisos y aprobación

Una herramienta es una función de la aplicación que el modelo puede solicitar. Antes de ejecutar una función de reembolso, comprueba su nombre, sus argumentos, que el pedido pertenezca al cliente, el estado actual del pedido y el cumplimiento de los requisitos del negocio. Rechaza los campos inesperados y aplica las mismas comprobaciones en el servicio que ejecuta la acción.

La aprobación humana debe producirse cuando ya existe la propuesta exacta y antes de que la acción tenga efecto. Muestra a quien la revisa el pedido, el reembolso previsto, el destino y el motivo. Vincula la aprobación a esa acción concreta. Si cambian los argumentos, la aprobación anterior deja de autorizar la ejecución.

La nueva dirección de correo plantea una cuestión de permisos independiente. En este ejemplo, la aplicación remite al cliente al proceso de verificación de la cuenta y sigue usando la dirección ya verificada hasta que termine. Un filtro de contenido no puede demostrar que una cuenta de correo pertenece al cliente.

Antes de enviar la respuesta: verificar resultados y datos que se revelan

Inspecciona los resultados de las herramientas antes de incorporarlos de nuevo al contexto del modelo. Limita los campos devueltos, valida su estructura y gestiona de forma explícita las operaciones fallidas o ambiguas.

Después, revisa que la respuesta al cliente no incluya contenido prohibido, información sensible ni afirmaciones sin respaldo, y que respete la estructura exigida. Para decir «Tu reembolso se ha completado» debe existir un resultado confirmado de la herramienta. Si falta la aprobación, la respuesta debe indicarlo.

Las comprobaciones de entrada y salida pueden usar clasificadores parecidos, pero cumplen funciones diferentes: las primeras deciden qué entra al procesamiento; las últimas, qué llega al cliente. Ninguna puede deshacer una acción no autorizada que ya se haya ejecutado.

Herramientas de guardrails: qué cubre cada una según su documentación

Elige una herramienta según el punto de control que ayuda a proteger y las reglas que puedes mantener. La siguiente comparación de capacidades se verificó con la documentación vigente de los proveedores el 17 de octubre de 2026. Compara el alcance documentado, no la precisión de detección medida.

A continuación se incluyen las fuentes y los límites de implementación de cada herramienta. La columna «Qué sigue siendo responsabilidad del equipo» refleja las consecuencias arquitectónicas de esos alcances documentados; no significa que un framework impida escribir controles propios.

¿Para qué sirve Guardrails AI?

Guardrails AI es un framework de Python que permite combinar validadores en torno a las entradas y salidas del modelo y generar datos estructurados. Su introducción describe el framework y su colección de validadores.

Un validador comprueba si un valor cumple un criterio y devuelve un resultado de éxito o fallo; la política on_fail configurada determina cómo se gestiona el fallo. La documentación incluye ejemplos de lenguaje tóxico y PII, y permite crear validadores propios. Conceptos de validación.

Es útil cuando una aplicación de Python existente necesita reglas de validación explícitas. El límite está en la cobertura: incorporar un framework no define qué comprobaciones se ejecutan en cada recorrido ni qué impide un fallo. Escribe y prueba esas decisiones junto con la aplicación.

NVIDIA NeMo Guardrails

NVIDIA NeMo Guardrails ofrece controles programables en varias etapas de una interacción con un LLM. Los tipos de controles que documenta abarcan entrada, recuperación, diálogo, ejecución y salida.

Los controles de entrada pueden abordar la seguridad del contenido, los intentos de eludir las restricciones del modelo o jailbreaks, los temas y la PII; los de recuperación revisan el contexto; los de diálogo acotan el flujo de la conversación. Los controles de ejecución pueden validar las entradas y los resultados de las herramientas, mientras que los de salida pueden filtrar, editar o bloquear respuestas.

Es útil cuando necesitas controlar el flujo de interacción. El límite está en cómo se implementa la política: los controles de ejecución ofrecen un punto donde comprobar las acciones, pero tu código debe aportar las reglas sobre titularidad de los datos y requisitos del negocio. El servicio subyacente también debe hacer cumplir esos permisos.

Amazon Bedrock Guardrails

Amazon Bedrock Guardrails ofrece filtros configurables de contenido, temas prohibidos, palabras e información sensible, además de comprobaciones de respaldo contextual y de Automated Reasoning. Los filtros de información sensible pueden bloquear o enmascarar los tipos de PII admitidos y los patrones personalizados; las comprobaciones de Automated Reasoning evalúan las respuestas frente a reglas lógicas. Descripción de las medidas de protección.

La API ApplyGuardrail evalúa texto sin depender de una llamada a un modelo fundacional. Puedes incorporarla antes de recuperar información o de entregar una respuesta.

Encaja en una aplicación que busca comprobaciones de políticas como servicio administrado. El límite está en suponer que todos los controles cubren todo el contenido: cada función tiene un alcance específico, y la descripción general excluye los bloques de contenido de razonamiento. Que un contenido supere la evaluación sigue sin autorizar un reembolso.

Seguridad en IA: los controles de los proveedores de modelos

OpenAI moderation clasifica el contenido dañino de las entradas de texto e imagen admitidas y devuelve indicadores, categorías y puntuaciones. La documentación de moderación también advierte que una respuesta de rechazo que mencione contenido dañino puede activar un indicador.

Usa esos resultados como señales para aplicar la política. Una conversación de atención al cliente que cita un mensaje abusivo puede requerir un tratamiento distinto al de una solicitud para generar uno. La moderación ayuda a decidir sobre el contenido; no aporta las reglas de acceso a tus pedidos.

Google Gemini ofrece ajustes de seguridad que asocian categorías de daño con umbrales de bloqueo. Su guía vigente de ajustes de seguridad cubre categorías como acoso, discurso de odio, contenido sexual, contenido peligroso y jailbreaks.

Google distingue la probabilidad de que un contenido no sea seguro de la gravedad del daño potencial. Esa distinción marca un límite práctico: una puntuación baja del clasificador no demuestra que una acción vaya a tener consecuencias menores. Los controles del proveedor son componentes útiles, pero la aplicación sigue necesitando permisos, un alcance definido para los datos y gestión de fallos.

Guardrails para agentes de IA: los controles que debes diseñar

Un agente necesita una barrera efectiva entre proponer una acción y ejecutarla. Tanto si la implementas mediante los puntos de integración de un framework como con código convencional del servicio, debe basarse en una identidad confiable y en el estado actual de la aplicación.

Mantén una lista explícita de herramientas permitidas y comprueba los argumentos y el recurso de destino en cada llamada. Que la acción «reembolsar» esté permitida no significa que todos los pedidos admitan un reembolso. Una herramienta de shell de propósito general o una herramienta de red sin restricciones amplía mucho más las acciones posibles que una función de negocio acotada.

La aprobación debe quedar registrada de forma que el sistema pueda hacerla cumplir; no basta con un «sí» en la conversación. Guarda qué se aprobó, quién lo aprobó y a qué detalles de la acción corresponde. Vuelve a comprobar el estado antes de ejecutar: el pedido podría haberse reembolsado mientras alguien revisaba la propuesta.

Haz que el servicio aplique una clave de idempotencia: un identificador estable de la operación que permita devolver el resultado existente al reintentar, en lugar de emitir otro reembolso. Limita el alcance de las credenciales y mantén los mecanismos de control fuera del alcance del modelo. El agente no debe poder elegir otro endpoint que evite la comprobación.

Nuestra guía de guardrails para agentes de IA en producción y control del alcance de los fallos desarrolla la arquitectura que rodea estos controles. Para esta solicitud, la pregunta decisiva es sencilla: si el modelo propone una acción incorrecta, ¿qué servicio se niega a ejecutarla?

Límites que conviene conocer antes del lanzamiento

El nombre de una función suele abarcar más que sus condiciones reales de uso. Verifica el alcance de la comprobación concreta que quieras utilizar.

Por ejemplo, AWS documenta las comprobaciones de respaldo contextual para resúmenes, paráfrasis y respuestas a preguntas con una fuente de referencia y una consulta, y excluye expresamente los casos de preguntas y respuestas conversacionales o chatbots. Sus máximos documentados son 100,000 caracteres para la fuente, 1,000 para la consulta y 5,000 para la respuesta. Son límites de caracteres de esa función, no límites generales del contexto del modelo ni una prohibición de usar otras medidas de protección de Bedrock con chatbots. Documentación de las comprobaciones de respaldo contextual.

Comprobar el respaldo en fuentes consiste en evaluar si la respuesta se ajusta a la fuente proporcionada. Si esa fuente está desactualizada o es incorrecta, coincidir con ella no demuestra que la respuesta sea verdadera. En el ejemplo del reembolso, el estado actual del pedido debe obtenerse del servicio que actúa como fuente de referencia.

El streaming cambia el punto en que se aplica el control. AWS advierte que la decisión sobre relevancia de una comprobación de respaldo contextual puede llegar después de que la respuesta se haya transmitido. En general, si una política exige revisar la respuesta completa antes de mostrarla, retenla hasta que supere la comprobación. Un rechazo posterior no puede retirar un texto que el usuario ya ha visto.

Hay que definir qué ocurre si se agota el tiempo de espera. Cuando falla una comprobación obligatoria de permisos o aprobación, detén la operación que modifica el estado y ofrece una vía de espera o de atención humana. Para respuestas de menor riesgo, define expresamente qué alternativa limitada es aceptable. No conviertas de forma silenciosa el fallo de un componente de verificación en permiso para continuar.

Mide la latencia añadida y los bloqueos erróneos con tu propia carga de trabajo. Ninguna puntuación de un proveedor sustituye a comprobar si los clientes legítimos pueden completar la tarea real de atención al cliente.

Seis controles para empezar con un equipo pequeño

Empieza con seis controles que puedas explicar, poner a prueba y asignar a un responsable. No necesitas adoptar todos los frameworks de la tabla.

1. 1

   Identidad y alcance de los datos

   Usa el contexto del cliente autenticado tanto para recuperar información como para llamar a herramientas. Comprueba que un cliente no pueda leer el pedido de otro, aunque el modelo lo solicite.

2. 2

   Política de entrada y minimización de datos

   Define la tarea que se admite, filtra los riesgos de contenido pertinentes y elimina los campos sensibles innecesarios. Elige una respuesta segura para las solicitudes que queden fuera de ese alcance.

3. 3

   Un contrato de salida

   Valida los campos obligatorios, las reglas sobre qué información puede revelarse y las afirmaciones sobre acciones completadas. Si la respuesta no tiene un respaldo confiable, haz que reconozca la incertidumbre o remita a atención al cliente.

4. 4

   Acciones acotadas y aprobación

   Expón herramientas de negocio con funciones limitadas. Comprueba la identidad, los argumentos y el estado actual antes de ejecutar; exige aprobación para las acciones que tu política considere de consecuencias relevantes.

5. 5

   Respuesta ante fallos y límites operativos

   Fija límites de solicitudes, llamadas a herramientas, reintentos y tiempo de ejecución adecuados para el flujo de trabajo. Define qué sucede si falla una comprobación obligatoria o un servicio del que depende la operación. Vuelve a validar las propuestas modificadas y los reintentos.

6. 6

   Pruebas de regresión y registro de auditoría

   Registra las versiones de las reglas, las decisiones, los resultados de las herramientas y las referencias de aprobación sin copiar datos sensibles innecesarios. Haz que los casos conocidos de revelación de datos y acciones no autorizadas impidan publicar una nueva versión.

Quienes desarrollan deben actuar ya si una función de cara al cliente lee registros privados o puede modificar el estado. Implementa primero los permisos del servicio. Quienes operan el sistema necesitan un responsable para las escalaciones, las solicitudes legítimas bloqueadas y las comprobaciones no disponibles. Una cola sin alguien que se haga cargo de ella es un flujo de trabajo incompleto.

Antes de comprar otro producto de guardrails, identifica qué punto de control falta. Un asistente que consulta documentos públicos y no dispone de herramientas de escritura no necesita un proceso de aprobación de reembolsos. Sí necesita comprobaciones de contenido pertinentes, recuperación de información confiable y una alternativa clara cuando algo falla. Los controles sobre acciones pasan a ser necesarios cuando se amplían sus capacidades.

Cómo probar la aplicación con Promptfoo

Promptfoo es una herramienta de evaluación y red teaming: permite probar tanto el comportamiento normal como las solicitudes diseñadas para atacar el sistema. Su documentación de pruebas de agentes describe comprobaciones de restricciones por rol, acceso no autorizado a objetos y acceso no autorizado a funciones.

Dirige las pruebas a la interfaz de la aplicación, con identidades y datos de prueba representativos. Probar únicamente el modelo deja fuera los permisos de recuperación de información, el proceso de aprobación y los servicios de herramientas con los que realmente interactúan los clientes.

Para el flujo hipotético de reembolso, empieza por estos casos:

• Un pedido que cumple los requisitos: la propuesta llega a la etapa de aprobación y la ejecución espera a recibirla.
• El pedido de otro cliente: tanto la recuperación de información como la ejecución deniegan el acceso.
• Un cambio de dirección para la confirmación: la aplicación exige el proceso de verificación independiente.
• Instrucciones ocultas en el contenido recuperado: no pueden conceder permisos ni cambiar la política de aprobación.
• Una propuesta que cambia después de aprobarse: la aprobación anterior no puede autorizar los nuevos argumentos.
• Una caída del componente de verificación o una solicitud repetida: no se omiten las comprobaciones obligatorias y la misma operación no se ejecuta dos veces.

Estos son casos de prueba propuestos, no resultados de pruebas realizadas. Revisa los efectos de las acciones y el estado almacenado, además de la respuesta final. Un «No puedo hacer eso» no tranquiliza si la herramienta ya lo hizo.

La guía de inicio rápido de Promptfoo explica cómo configurar el objetivo, seleccionar categorías de ataque, ejecutar las pruebas y revisar un informe. Nuestro análisis de Promptfoo profundiza en el flujo de evaluación. Incluye solicitudes normales de clientes junto a los casos adversarios para que un filtrado más estricto no termine inutilizando la tarea útil sin que se advierta.

¿Qué promesas están exageradas?

Un producto de guardrails no es un interruptor universal de seguridad. Su valor depende de qué comprueba, dónde se ejecuta y qué impide su decisión.

Un prompt de sistema más largo puede expresar una política, pero no puede hacer cumplir los permisos de la base de datos. Un segundo modelo puede revisar una respuesta, pero que ambos coincidan no demuestra que sea correcta. Acumular más clasificadores también puede aumentar los bloqueos erróneos y el trabajo operativo sin cubrir el punto de control que falta sobre las acciones.

El mejor punto de partida es un conjunto pequeño de controles explícitos vinculados a fallos concretos. Añade una comprobación cuando cubra una carencia demostrada y mide si mejora el resultado.

IA sin guardrails: ¿qué controles faltan realmente?

En una función de cara al cliente, lo útil es preguntar qué controles faltan. Una aplicación puede contar con filtros de contenido del proveedor y aun así carecer de permisos específicos por cliente, validación de salida o mecanismos que hagan cumplir las aprobaciones. Llamarla «protegida» oculta esas carencias.

A la inversa, una aplicación con controles de acceso deterministas puede seguir necesitando comprobaciones de contenido. La seguridad del contenido y la autorización de las acciones son requisitos distintos; ninguna de esas etiquetas resuelve ambos.

Preguntas frecuentes

¿Qué tipos de guardrails de IA existen?

Para implementarlos, resulta útil distinguir entre comprobaciones de entrada, del contexto recuperado y de salida, controles de ejecución de herramientas y aprobación humana. Los filtros de temas y PII pueden aplicarse en varios de esos puntos.

¿Cómo se crean guardrails para una aplicación de IA?

Identifica un resultado que no deba producirse, coloca una comprobación antes de la revelación de datos o la acción correspondiente, define la respuesta ante un fallo y prueba la aplicación completa. Asigna a alguien el mantenimiento de la política y la gestión de las escalaciones.

¿Qué hace Guardrails AI?

Guardrails AI combina validadores en controles de entrada y salida y permite generar datos estructurados. La configuración y el código de tu aplicación determinan qué riesgos se comprueban y cómo se gestionan los fallos.

¿Existe alguna IA sin guardrails?

Los controles varían entre aplicaciones. Antes de desplegar, audita cada punto de control en lugar de confiar en una etiqueta: las protecciones de contenido del modelo no establecen la autorización del cliente ni la aprobación humana.

¿Cuáles son los 3 principales riesgos de seguridad en IA?

Para este ejemplo de atención al cliente, empieza por la inyección de prompts, la revelación no autorizada de datos y las acciones no autorizadas. Es una priorización práctica para este flujo de trabajo, no una clasificación universal de los riesgos de la IA.

Por dónde empezar el lunes

Elige una solicitud real de un cliente y dibuja su recorrido desde la autenticación hasta la respuesta final. En cada punto de control, anota la regla, el componente que la hace cumplir, la respuesta ante un fallo y el responsable. Antes de ampliar los permisos del agente, convierte una lectura no autorizada de un registro y una acción sin aprobar en pruebas que bloqueen la publicación de una nueva versión.

Recibe guías prácticas de implementación de IA en el boletín.