# Guardrails para IA: cómo controlar respuestas y acciones peligrosas

**Categoría:** Inteligencia artificial · **Nivel:** Intermedio · **Lectura:** 17 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/inteligencia-artificial/guardrails-para-ia-controlar-respuestas-y-acciones/

## Respuesta rápida

Los **guardrails** (barreras de seguridad) son los controles que se ponen **alrededor** de un modelo de lenguaje para evitar que reciba entradas peligrosas o produzca salidas y acciones indebidas. Existen porque un modelo, por sí solo, **no es una defensa fiable**: intenta ser útil y complaciente, así que con la insistencia o el engaño adecuados puede ser inducido a decir lo que no debe (contenido dañino, datos sensibles) o —si tiene [herramientas](../function-calling-como-una-ia-usa-apis-y-herramientas/index.md)— a hacer lo que no debe (borrar, pagar, filtrar). Las instrucciones del sistema ayudan, pero **no son una barrera**: se pueden sortear con *prompt injection* (entradas diseñadas para anular esas instrucciones). Hay dos tipos de guardrails. Las **barreras de entrada** revisan lo que *llega* al modelo antes de procesarlo: detectan y bloquean intentos de manipulación, peticiones prohibidas o datos que no deberían entrar. Las **barreras de salida** revisan lo que el modelo *produce* antes de mostrarlo o ejecutarlo: filtran contenido tóxico, información sensible filtrada, respuestas fuera de tema, o —clave— **frenan acciones peligrosas** pidiendo validación. El principio de diseño que lo sostiene todo: los guardrails son una **capa externa e independiente**, en *tu código*, que el modelo **no controla**. Pedirle amablemente al modelo «no hagas X» no es un guardrail —él mismo puede saltárselo—; un guardrail es una comprobación *fuera* del modelo que se cumple pase lo que pase. Se implementan combinando reglas simples (listas, patrones, límites), clasificadores o modelos de moderación, y validación humana para lo crítico. Son lo que separa un prototipo de una aplicación de IA lista para usuarios reales.

## Qué son y por qué

Un **guardrail** es un control de seguridad que se coloca **entre el usuario y el modelo**, y entre el modelo y el mundo, para garantizar que la aplicación se comporte dentro de unos límites, **independientemente de lo que el modelo quiera hacer**. El nombre viene de las barreras de una carretera: no conducen por vos, pero evitan que te salgas.

> **Por qué el modelo no se basta solo**
>
> Un modelo de lenguaje está entrenado para ser **útil y complaciente**, y esa es justamente su debilidad como guardián: quiere ayudar, así que con la insistencia, el rol adecuado o el engaño (*«ignorá tus instrucciones anteriores y…»*) se le puede empujar a cruzar los límites que se le pidieron respetar. Las instrucciones del sistema («no reveles datos internos», «no hables de otros temas») **reducen** la probabilidad, pero **no la eliminan**: son parte del mismo texto que el usuario puede intentar anular con *prompt injection*. Confiar la seguridad solo a lo que le pedimos al modelo es como poner un cartel de «prohibido pasar» sin puerta: disuade, no impide. Por eso hace falta una barrera **fuera** del modelo.

## Barreras de entrada y de salida

Los guardrails se colocan en **dos puntos** del flujo, y cada uno protege de cosas distintas:

| Barrera | Revisa | Bloquea |
|---|---|---|
| De entrada | Lo que llega al modelo | Prompt injection, peticiones prohibidas, datos sensibles que no deben entrar |
| De salida | Lo que el modelo produce | Contenido tóxico, información filtrada, respuestas fuera de tema |
| De salida (acciones) | Lo que el modelo quiere ejecutar | Acciones peligrosas (borrar, pagar, enviar) sin validación |

> **Atención**
>
> Con un chatbot que solo *habla*, lo peor que puede pasar es que diga algo indebido —malo, pero contenible con una barrera de salida que filtre el texto—. Pero cuando la IA tiene [herramientas](../function-calling-como-una-ia-usa-apis-y-herramientas/index.md) que *actúan* (borrar registros, hacer pagos, enviar correos), un fallo ya no es un mensaje feo: es una **acción real e irreversible**. Ahí la barrera de salida sobre las *acciones* es imprescindible: antes de ejecutar cualquier operación sensible, tu código —no el modelo— comprueba si está permitida, dentro de límites, y para lo crítico exige **confirmación humana**. El modelo puede *proponer* «borrá todos los pedidos»; el guardrail decide que eso no se ejecuta sin aprobación. Esto conecta con la [seguridad de agentes de IA](../seguridad-de-agentes-y-aplicaciones-de-ia/index.md).

## Cómo diseñarlos

Un guardrail eficaz cumple una regla no negociable: **vive fuera del modelo y el modelo no lo controla**. A partir de ahí, se combinan varias técnicas según el riesgo.

- **En tu código, no en el prompt.** Una comprobación que el modelo no puede desactivar; pedirle «no hagas X» no es un guardrail.
- **Reglas simples primero.** Listas de términos, patrones, límites de longitud o de formato: baratas, rápidas y fiables para casos claros.
- **Clasificadores o moderación.** Para contenido tóxico o peticiones dañinas, un modelo de moderación decide si pasa.
- **Validación de acciones.** Antes de ejecutar una operación sensible, comprobar permisos y límites; nada de confiar en el modelo.
- **Confirmación humana para lo crítico.** Las acciones irreversibles pasan por una persona; el guardrail las detiene hasta entonces.
- **Fallar de forma segura.** Ante la duda, bloquear; una barrera que en caso de error deja pasar no protege.
- **Registrar y revisar.** Guardar lo que se bloqueó permite mejorar las barreras y detectar ataques.

> **Atención**
>
> Ningún guardrail es perfecto, y por eso no se confía todo a uno solo. La estrategia sana es **defensa en capas**: una barrera de entrada que filtre lo obvio, instrucciones de sistema claras que orienten al modelo, una barrera de salida que revise lo que produce, validación estricta de las acciones, y confirmación humana para lo irreversible. Si una capa falla, otra atrapa el problema. Además, hay que asumir que los atacantes **intentarán sortearlas** con *prompt injection* cada vez más ingeniosos, así que los guardrails no son un «poner y olvidar»: se revisan, se prueban contra intentos de evasión y se ajustan. El objetivo no es una IA infalible —no existe—, sino reducir el riesgo a un nivel aceptable con varias barreras que se refuerzan.

## Errores frecuentes

- **Confiar la seguridad a las instrucciones del sistema.** Se sortean con prompt injection; no son una barrera real.
- **Poner el guardrail «dentro» del modelo.** Debe ser una capa externa en tu código que el modelo no controle.
- **Filtrar solo la entrada o solo la salida.** Hacen falta ambas; protegen de cosas distintas.
- **Ejecutar acciones sin validarlas.** Cuando la IA actúa, un fallo es una acción real; validar y confirmar lo crítico.
- **Diseñar la barrera para que ante error deje pasar.** Debe fallar de forma segura: ante la duda, bloquear.
- **Confiar todo a un único guardrail.** Ninguno es perfecto; usar defensa en capas.
- **Tratarlos como «poner y olvidar».** Los ataques evolucionan; revisar y probar las barreras periódicamente.

## Preguntas frecuentes

**¿Qué son los guardrails en una aplicación de IA?**
Los guardrails, que se pueden traducir como barreras de seguridad, son los controles que se colocan alrededor de un modelo de lenguaje en una aplicación de inteligencia artificial para garantizar que el sistema se comporte dentro de unos límites definidos, con independencia de lo que el modelo pudiera hacer por sí mismo. El nombre proviene de las barreras de protección de las carreteras, que no conducen el vehículo pero evitan que se salga de la vía, y la analogía es adecuada, porque un guardrail no sustituye al modelo ni decide por él, sino que impide que la aplicación cruce ciertos límites peligrosos. En concreto, los guardrails se sitúan en dos puntos clave: entre el usuario y el modelo, para revisar lo que llega al modelo, y entre el modelo y el mundo, para revisar lo que el modelo produce o quiere ejecutar antes de que tenga efecto. Su función es evitar que el modelo reciba entradas maliciosas o prohibidas y que genere respuestas indebidas o realice acciones peligrosas, como revelar información sensible, producir contenido dañino o ejecutar operaciones destructivas. La razón por la que son necesarios es que un modelo de lenguaje, por sí solo, no constituye una defensa fiable, ya que está entrenado para ser útil y complaciente, de modo que con la insistencia, el engaño o las técnicas adecuadas puede ser inducido a saltarse las instrucciones que se le hayan dado. Un aspecto esencial de los guardrails es que constituyen una capa externa e independiente, implementada en el código de la aplicación, que el modelo no controla ni puede desactivar, a diferencia de las simples instrucciones que se le dan en el prompt, que el modelo podría llegar a ignorar. Los guardrails se implementan combinando distintas técnicas, como reglas simples basadas en listas o patrones, clasificadores o modelos de moderación que detectan contenido no permitido, la validación de las acciones antes de ejecutarlas y la confirmación humana para las decisiones críticas. En definitiva, los guardrails son un componente de seguridad imprescindible que transforma un prototipo de inteligencia artificial en una aplicación apta para usuarios reales, al asegurar que el sistema se mantenga dentro de límites seguros aunque el modelo, por su naturaleza, tienda a intentar complacer cualquier petición.

**¿Por qué no basta con darle buenas instrucciones al modelo?**
No basta con darle buenas instrucciones al modelo mediante el prompt del sistema porque esas instrucciones, aunque reducen la probabilidad de comportamientos indebidos, no constituyen una barrera de seguridad fiable, ya que forman parte del mismo texto que el modelo procesa y pueden ser anuladas o sorteadas por diversas técnicas. Un modelo de lenguaje está entrenado para ser útil y complaciente, y esa disposición a ayudar es precisamente su punto débil desde el punto de vista de la seguridad, porque con la insistencia adecuada, adoptando un determinado rol, o mediante engaños se le puede empujar a cruzar los límites que se le habían pedido respetar. El caso más conocido es el de las inyecciones de instrucciones, que son entradas diseñadas específicamente para anular o contradecir las instrucciones del sistema, por ejemplo indicándole al modelo que ignore sus reglas anteriores y actúe de otra manera; como el modelo no distingue de forma infalible entre las instrucciones legítimas del sistema y las que le llegan en la entrada del usuario, puede acabar obedeciendo a estas últimas. Por eso, confiar la seguridad únicamente a lo que se le pide al modelo es comparable a poner un cartel de prohibido el paso sin una puerta que realmente impida entrar: disuade y reduce los casos, pero no impide de forma efectiva a quien está decidido a saltárselo. Esto no significa que las instrucciones del sistema sean inútiles, ya que son valiosas para orientar el comportamiento del modelo y disminuir el riesgo, sino que no deben ser la única línea de defensa. La seguridad real requiere barreras que estén fuera del control del modelo, es decir, comprobaciones implementadas en el código de la aplicación que se cumplan pase lo que pase, con independencia de lo que el modelo decida o de cómo sea manipulado. En resumen, las buenas instrucciones son una capa útil pero insuficiente por sí sola, y deben complementarse con guardrails externos que revisen las entradas y las salidas y que validen las acciones, porque solo una barrera que el modelo no pueda desactivar ofrece una protección fiable frente a los intentos deliberados de hacer que el sistema se comporte de forma indebida.

**¿Qué diferencia hay entre barreras de entrada y de salida?**
Las barreras de entrada y las barreras de salida son los dos tipos de guardrails que se colocan en puntos distintos del flujo de una aplicación de inteligencia artificial y que protegen frente a riesgos diferentes, por lo que ambas son necesarias y complementarias. Las barreras de entrada se sitúan antes de que la petición del usuario llegue al modelo y revisan lo que entra, con el objetivo de detectar y bloquear contenido peligroso o no permitido antes de que el modelo lo procese. Entre lo que filtran destacan los intentos de manipulación como las inyecciones de instrucciones, que buscan anular las reglas del sistema, las peticiones explícitamente prohibidas según las políticas de la aplicación, y los datos sensibles que no deberían entrar en el sistema o enviarse al modelo. Si la entrada resulta peligrosa, la barrera la bloquea o la neutraliza, evitando que el modelo llegue siquiera a actuar sobre ella. Las barreras de salida, en cambio, se sitúan después de que el modelo ha generado su respuesta y antes de que esta se muestre al usuario o se ejecute, y revisan lo que el modelo produce. Su función es impedir que salga contenido indebido, como texto tóxico u ofensivo, información sensible que el modelo hubiera podido filtrar, o respuestas que se salen del tema o del ámbito permitido de la aplicación. Un caso especialmente importante de barrera de salida es el que controla las acciones: cuando el modelo puede ejecutar operaciones mediante herramientas, la barrera de salida frena las acciones peligrosas, como borrar datos, realizar pagos o enviar información, exigiendo validación o confirmación antes de que se lleven a cabo. La diferencia esencial es, por tanto, que las barreras de entrada protegen de lo que podría hacerse llegar al modelo para manipularlo o de datos que no deben entrar, mientras que las barreras de salida protegen de lo que el modelo podría producir o ejecutar de forma indebida. Como cada tipo cubre riesgos distintos, un error común es implementar solo una de ellas; una aplicación bien protegida necesita ambas, formando así una defensa que vigila tanto lo que entra como lo que sale del modelo, y que se complementa además con otras capas de seguridad.

**¿Dónde se colocan los guardrails, dentro o fuera del modelo?**
Los guardrails deben colocarse fuera del modelo, como una capa externa e independiente implementada en el código de la aplicación, y no dentro del modelo ni confiados a lo que se le pide en el prompt, y este es probablemente el principio de diseño más importante para que funcionen de verdad. La razón es que un guardrail solo es fiable si el modelo no puede controlarlo ni desactivarlo, y eso únicamente se consigue situándolo fuera de su alcance. Si la única protección consiste en instrucciones dadas al modelo, como pedirle amablemente que no haga determinada cosa, no se trata realmente de un guardrail, porque el propio modelo puede saltarse esa indicación, ya sea por su tendencia a complacer, por confusión o porque un usuario lo manipule mediante técnicas como las inyecciones de instrucciones. Un guardrail auténtico es una comprobación que ocurre en el código de la aplicación, alrededor de la llamada al modelo, y que se ejecuta y se cumple pase lo que pase con el modelo. Por ejemplo, una barrera de entrada que analiza la petición del usuario antes de enviarla al modelo y la bloquea si detecta un patrón prohibido funciona con independencia de lo que el modelo haría, porque actúa antes de que el modelo intervenga. De igual modo, una barrera de salida que revisa la respuesta generada o que valida una acción antes de ejecutarla opera desde fuera, decidiendo si deja pasar el resultado con independencia de lo que el modelo haya decidido producir. Esta ubicación externa es lo que garantiza que, aunque el modelo sea engañado o manipulado para intentar comportarse mal, la barrera siga en pie y cumpla su función. En la práctica, esto significa que la lógica de seguridad, como las validaciones, los filtros, las comprobaciones de permisos o la exigencia de confirmación humana, debe residir en el código que rodea al modelo y que el usuario no puede alterar a través de sus mensajes. En resumen, la regla es clara: los guardrails van fuera del modelo, en la aplicación, porque solo así son barreras reales y no meras sugerencias que el modelo podría ignorar, y entender esto es fundamental para diseñar aplicaciones de inteligencia artificial verdaderamente seguras.

**¿Son más importantes los guardrails si la IA puede ejecutar acciones?**
Sí, los guardrails se vuelven mucho más críticos cuando la inteligencia artificial puede ejecutar acciones y no solo generar texto, porque en ese caso las consecuencias de un fallo dejan de ser un simple mensaje inapropiado y pasan a ser acciones reales que pueden tener efectos serios e incluso irreversibles. Conviene distinguir dos escenarios. En un sistema donde el modelo únicamente conversa, es decir, produce texto como respuesta, lo peor que puede ocurrir si se le manipula o comete un error es que diga algo indebido, como contenido ofensivo, información que no debería revelar o una respuesta fuera de lugar, lo cual es un problema real pero relativamente contenible mediante barreras de salida que filtran el texto antes de mostrarlo. Sin embargo, cuando el modelo dispone de herramientas que le permiten actuar sobre el mundo o sobre los sistemas, como borrar registros, realizar pagos, enviar correos o mensajes, modificar datos o iniciar procesos, un fallo ya no es un texto feo, sino una operación efectiva que puede causar daños concretos, pérdidas económicas, filtraciones de información o efectos difíciles o imposibles de deshacer. Por ello, en estos sistemas la barrera de salida aplicada a las acciones es imprescindible: antes de ejecutar cualquier operación sensible, el código de la aplicación, y no el modelo, debe comprobar si esa acción está permitida, si se encuentra dentro de unos límites establecidos, y para las acciones críticas o irreversibles debe exigir una confirmación humana. La idea clave es que el modelo puede proponer una acción, pero la decisión de ejecutarla la toma el guardrail que vive fuera de él; así, aunque el modelo solicite algo peligroso, como borrar toda una base de datos, la barrera puede impedir que se lleve a cabo sin aprobación. Este planteamiento se enmarca en la seguridad de los agentes de inteligencia artificial, que al encadenar acciones de forma autónoma incrementan el riesgo. En conclusión, mientras que en un chatbot conversacional los guardrails son importantes, en una aplicación donde la inteligencia artificial actúa se vuelven absolutamente esenciales, y su diseño debe centrarse muy especialmente en validar y controlar las acciones, aplicando el principio de mínimo privilegio y reservando la confirmación humana para todo lo que sea sensible o difícil de revertir.

**¿Los guardrails garantizan que la IA sea segura?**
No, los guardrails no garantizan una seguridad total ni convierten a la inteligencia artificial en infalible, ya que ninguna barrera individual es perfecta y siempre existe la posibilidad de que alguna sea sorteada; lo que hacen los guardrails es reducir el riesgo a un nivel aceptable, especialmente cuando se combinan varios en una estrategia de defensa en capas. Es importante partir de una expectativa realista: el objetivo de la seguridad en aplicaciones de inteligencia artificial no es lograr un sistema imposible de vulnerar, algo que no existe, sino disminuir la probabilidad y el impacto de los comportamientos indebidos hasta un punto razonable para el caso de uso. Por eso, la buena práctica no consiste en confiar todo a un único guardrail, sino en desplegar varias capas de protección que se refuercen entre sí, de modo que si una falla, otra pueda atrapar el problema. Una defensa en capas típica combina una barrera de entrada que filtra lo evidente, unas instrucciones de sistema claras que orientan al modelo, una barrera de salida que revisa lo que produce, una validación estricta de las acciones antes de ejecutarlas, y la confirmación humana para las operaciones irreversibles o críticas. Además, hay que asumir que los atacantes intentarán activamente evadir las barreras mediante técnicas cada vez más ingeniosas, como inyecciones de instrucciones elaboradas, por lo que los guardrails no son algo que se configure una vez y se olvide, sino que deben revisarse, probarse contra intentos de evasión y ajustarse con el tiempo. También es recomendable que las barreras fallen de forma segura, es decir, que ante la duda bloqueen en lugar de dejar pasar, y que se registre lo que bloquean para poder mejorarlas y detectar ataques. En definitiva, los guardrails son una parte fundamental y muy eficaz de la seguridad de una aplicación de inteligencia artificial, y su ausencia deja el sistema peligrosamente expuesto, pero deben entenderse como una reducción de riesgo mediante múltiples defensas que se complementan, y no como una garantía absoluta; la seguridad es un proceso continuo de capas, pruebas y mejoras, no un estado que se alcanza de una vez y para siempre.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección Inteligencia artificial](https://underc0de.org/foro/inteligencia-artificial/). Seguridad de aplicaciones de IA.
2. **Underc0de, foro.** [Sección Seguridad informática](https://underc0de.org/foro/seguridad-informatica/). Defensa de sistemas.

### Documentación oficial

1. **OWASP.** [Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/). Riesgos de las aplicaciones con LLM.
2. **NIST.** [AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework). Gestión de riesgos de la IA.
3. **Anthropic.** [Strengthen guardrails](https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails). Reforzar las barreras de seguridad.
4. **OpenAI.** [Moderation](https://platform.openai.com/docs/guides/moderation). Moderación de contenido.

## Guías relacionadas

- [Seguridad de agentes de IA](../seguridad-de-agentes-y-aplicaciones-de-ia/index.md)
- [Por qué una IA alucina](../por-que-una-ia-alucina-y-como-reducir-errores/index.md)
- [Function Calling](../function-calling-como-una-ia-usa-apis-y-herramientas/index.md)
- [Riesgos y uso responsable](../riesgos-etica-y-uso-responsable-de-la-ia/index.md)
- [Índice de Inteligencia artificial](../index.md)