A medida que las empresas despliegan agentes de IA, aparece una pregunta legítima sobre seguridad, y con ella una confusión frecuente. Se oye con naturalidad la frase "el agente tiene guardrails, así que los datos están protegidos". Esa frase mezcla dos cosas que operan en planos diferentes. Los guardrails y el control de acceso al dato son ambos necesarios, pero no son intercambiables, y uno no puede hacer el trabajo del otro. Este artículo explica qué es cada uno, para qué sirve, y —sobre todo— por qué los guardrails, por buenos que sean, no protegen el dato.
Qué son los guardrails
Un guardrail es una capa de control que se sitúa entre el usuario y el modelo de lenguaje, y entre el modelo y la respuesta final. Su función es inspeccionar lo que entra y lo que sale: examina el prompt antes de que llegue al modelo y examina la respuesta antes de que llegue al usuario, bloqueando o reformulando lo que incumple unas reglas definidas.
Los guardrails sirven para cosas valiosas y reales:
- Bloquear prompt injection y jailbreaks — intentos de manipular las instrucciones del sistema para que el modelo haga algo que no debe.
- Filtrar contenido tóxico, ofensivo o fuera de tema — mantener al agente dentro de los asuntos para los que se diseñó.
- Detectar y redactar PII en lo que el modelo va a emitir.
- Reducir alucinaciones mediante comprobaciones o verificación contra una base de conocimiento.
Herramientas como NeMo Guardrails (NVIDIA), Guardrails AI o LLM Guard implementan exactamente esto. Son piezas serias y útiles. El punto importante es entender cómo funcionan, porque de ahí se deduce qué pueden y qué no pueden garantizar.
Cómo funcionan: el control es del comportamiento, no del dato
Un guardrail actúa sobre el lenguaje: sobre el texto que entra y el texto que sale del modelo. Detecta patrones —adversariales, tóxicos, sensibles— y decide en función de ellos. Y esa detección es, por naturaleza, estadística: un clasificador, una comparación de embeddings, un conjunto de ejemplos, un modelo que estima la probabilidad de que un texto sea un ataque o contenga algo indebido.
Esto tiene una consecuencia que conviene afrontar sin rodeos: un mecanismo estadístico acierta casi siempre, pero no siempre. Existe ya investigación empírica dedicada a evadir guardrails — a construir entradas que sortean los detectores de prompt injection y jailbreak. Que exista todo un campo de estudio sobre cómo burlarlos no es un defecto de una implementación concreta: es la naturaleza de cualquier defensa basada en reconocer patrones en lenguaje. Siempre hay una formulación nueva que el clasificador no vio.
Para muchos usos, ese "casi siempre" es perfectamente aceptable. Que un asistente evite, el 99,5% de las veces, responder con groserías o salirse de tema es un resultado excelente. Pero hay un dominio donde "casi siempre" no basta, y es precisamente el del dato.
Por qué los guardrails no protegen el dato
Aquí está el núcleo del argumento. Un guardrail vigila lo que el agente dice. No gobierna a lo que el agente accede.
Veámoslo con un ejemplo. Supongamos un agente de análisis de cartera en una entidad financiera. Su tarea legítima es evaluar la adecuación de la cartera de un cliente. Para eso necesita las posiciones de ese cliente — y nada más. No necesita su historial médico declarado, ni los datos de otros clientes, ni su scoring de riesgo crediticio.
Con un enfoque basado en guardrails, el dato sigue siendo técnicamente accesible para el agente; lo que se intenta es que no lo saque — que no incluya en su respuesta lo que no debería. Si por una formulación inesperada de la tarea, una cadena de razonamiento imprevista o una entrada maliciosa el agente accede a datos de otro cliente, el guardrail tiene una única oportunidad de atraparlo: detectar, en el texto de salida, que ahí hay algo que no debería estar. Si no lo detecta —y un mecanismo estadístico fallará alguna vez— el dato ya ha salido. Peor aún: el agente ya accedió a él, lo tuvo en su contexto, pudo combinarlo con otra información y derivar conclusiones. El daño no es solo lo que se emite; es lo que se tocó.
El guardrail, por diseño, llega tarde para el dato. Vigila la puerta de salida del lenguaje, cuando el problema ya ocurrió en la puerta de entrada al dato.
El otro modelo: control estructural del acceso
El enfoque de opendome opera en el plano contrario. No intenta que el agente no diga lo que no debe: hace que el agente no pueda acceder a lo que su tarea no justifica. El control no está en la salida del lenguaje, sino en el acceso al dato.
El mecanismo es lo que llamamos el Modelo de Celda. Cada acceso se decide individualmente, en el momento en que se produce, evaluando cuatro dimensiones a la vez: qué agente pregunta, para qué tarea, sobre qué dato concreto —al nivel del campo, no de la ficha— y en qué contexto. Solo cuando la combinación es legítima, la celda se abre; si falla cualquiera de las cuatro, el dato no es accesible. No hay accesos heredados, no hay permisos que sobran, no hay una puerta trasera por la que el dato pueda salir.
En el ejemplo anterior, el agente de análisis de cartera no "se contiene" para no mostrar los datos de otro cliente: sencillamente esos datos nunca entran en su alcance. La política no se le pide al agente vía prompt — se impone por infraestructura, por debajo de él, donde el agente no tiene capacidad de sortearla porque no participa en la decisión.
La diferencia clave: reproducibilidad
Y aquí está la propiedad que lo cambia todo, y la que conviene subrayar: la decisión del Modelo de Celda es reproducible, no estadística.
Un guardrail estima. Ante la misma entrada formulada de dos maneras distintas, puede acertar una vez y fallar la otra, porque su veredicto depende de un reconocimiento de patrones que tiene un margen de error. El Modelo de Celda no estima: evalúa una regla determinista. Dada la misma combinación de agente, tarea, dato y contexto, la decisión es siempre idéntica — hoy, mañana, y la millonésima vez. No hay un percentil de acierto: hay una respuesta correcta que se produce siempre.
Esta diferencia —entre lo estadístico y lo reproducible— es exactamente lo que separa una buena intención de una garantía. En un entorno regulado por el GDPR, DORA o el EU AI Act, no basta con reducir la probabilidad de una fuga: hay que poder demostrar, ante un auditor, que un acceso indebido no podía ocurrir, y que cada acceso que sí ocurrió quedó registrado con su contexto completo. Una medida estadística no se puede demostrar: solo se puede medir su tasa de acierto. Una medida reproducible sí — porque su comportamiento es el mismo siempre y queda inscrito en la propia arquitectura.
Es la misma diferencia que hay entre poner un vigilante atento en la salida de una sala llena de documentos confidenciales, y no dejar entrar a la sala más que los documentos que la tarea requiere. El vigilante, por bueno que sea, tiene un mal día. La sala a la que solo entra lo justo no depende de que nadie tenga un buen día.
No es elegir: es entender qué hace cada uno
Nada de esto significa que los guardrails sobren. Al contrario: son complementarios, porque protegen frente a cosas distintas. Los dos modelos, juntos, cubren un espectro que ninguno cubre solo:
- Los guardrails protegen el comportamiento lingüístico del agente: que no sea manipulado por prompt injection, que no genere contenido tóxico o fuera de tono, que no se desvíe del propósito conversacional. Operan sobre el lenguaje, y para eso son la herramienta adecuada.
- El control estructural del acceso protege el dato: que el agente solo pueda tocar lo que su tarea justifica, de forma reproducible y auditable. Opera sobre el acceso, y es la única forma de garantizar la protección del dato.
Donde no llegan los guardrails: a impedir el acceso a un dato, a garantizar de forma demostrable que algo no puede ocurrir, a producir un registro auditable de qué se tocó y por qué. Donde sí llegan: a moderar y encauzar lo que el agente dice, a frenar ataques sobre su comportamiento, a mantenerlo dentro de su propósito.
La conclusión es sencilla y vale la pena fijarla. Si la pregunta es "¿se comporta bien mi agente?", los guardrails son parte de la respuesta. Si la pregunta es "¿están protegidos mis datos?", los guardrails no son la respuesta — lo es un control de acceso estructural y reproducible. Confundir ambas preguntas es lo que lleva a creer que el dato está a salvo porque el agente "tiene guardrails". No lo está. Está a salvo cuando el dato que no le corresponde nunca llega a estar a su alcance.
Fuentes
- AI Safety Directory, LLM Guardrails: The Complete Guide (definición, input/output/system guardrails, EU AI Act) — https://aisecurityandsafety.org/en/guides/llm-guardrails/
- Langfuse, LLM Security & Guardrails (escáneres de entrada/salida, PII, toxicidad) — https://langfuse.com/docs/security-and-guardrails
- WitnessAI, LLM Guardrails: Securing LLMs for Safe AI Deployment (prompt injection, jailbreaks, RAG) — https://witness.ai/blog/llm-guardrails/
- Bypassing LLM Guardrails: An Empirical Analysis of Evasion Attacks (arXiv:2504.11168) — https://arxiv.org/pdf/2504.11168
- NVIDIA NeMo Guardrails — tipos de rail (input, dialog, retrieval, execution, output) — https://appsecsanta.com/nemo-guardrails