AI Guardrails

Controles en puntos protegidos

AI Guardrails son controles de runtime o de aplicación que detectan, restringen, transforman, pausan, rechazan o escalan entradas, salidas o acciones AI según criterios o políticas explícitas. Un guardrail protege un punto del flujo y toma una decisión acotada; no convierte el sistema entero en seguro ni garantiza que cada comportamiento no previsto sea detectado.

El punto protegido puede estar antes de una inferencia, después de una respuesta, alrededor de una llamada a una herramienta o en una transición entre etapas. El control puede permitir, rechazar, modificar, pedir revisión, seleccionar otra ruta o detener la ejecución. La responsabilidad debe ser visible: qué se inspecciona, qué criterio se aplica, qué incertidumbre existe y qué ocurre si el control no puede decidir.

Los guardrails son una forma de defensa en profundidad. No sustituyen autenticación, autorización, least privilege, sandboxing, diseño seguro de herramientas, límites de datos, protección de secretos ni controles de supply chain. Un detector que clasifica una solicitud no crea una identidad ni concede autoridad al modelo.

Guardrail no es instruction

Una instrucción orienta el comportamiento esperado del modelo. Un prompt como «no reveles secretos» puede ser una guía útil, pero por sí solo no impide que una salida los contenga ni que una herramienta intente leerlos. Un guardrail comprueba o aplica un control en una frontera protegida, fuera de la mera obediencia a una frase.

Persistent Instructions mantiene una guía en interacciones o scopes determinados. Su persistencia no la convierte automáticamente en enforcement. Una política puede informar qué debe ocurrir y un guardrail puede verificar una condición concreta; ambos pueden componerse sin ser la misma responsabilidad. Tampoco una instrucción que el modelo repite demuestra que el control se aplicó.

La diferencia no depende de que ambos usen texto o un modelo. Una regla determinista puede implementar un guardrail; un clasificador puede ayudar a decidir; una instrucción puede existir sin ningún control ejecutable. La pregunta es qué ocurre cuando el contenido no coopera: si solo cambia la solicitud al modelo, hay orientación; si una frontera rechaza, limita o escala una operación, hay un control aplicado.

Guardrail y Structured Generation

Structured Generation controla o guía la forma de una salida: campos, tipos, alternativas o una gramática. Un guardrail controla criterios de comportamiento o política. Un objeto JSON válido puede incluir instrucciones peligrosas, datos de otro usuario o una decisión no autorizada. La conformidad estructural no demuestra conformidad de política.

Un schema puede participar en un guardrail cuando el sistema rechaza o desvía una instancia que viola un contrato relevante. En ese caso la responsabilidad de guardrail está en la decisión aplicada, no en la existencia del schema. Parsing, validación estructural y enforcement de política responden preguntas diferentes. «Es JSON válido» no equivale a «es seguro», «es correcto» ni «está autorizado».

Guardrail y evaluación

Agent Evaluation juzga comportamiento entre casos y ejecuciones mediante criterios explícitos. Un guardrail toma una decisión durante una ejecución concreta. Un evaluador, clasificador o modelo-as-judge puede ser el mecanismo de una comprobación, pero el propósito distingue ambas actividades: evaluación mide o juzga para aprender sobre el sistema; guardrail permite, restringe o escala un paso.

Un guardrail que pasó no demuestra que el sistema sea correcto en general. Una suite de evaluación puede descubrir falsos positivos, falsos negativos y rutas que el control no cubre. Inversamente, un score alto de evaluación no aplica una política a la próxima acción. Compartir un clasificador no borra la frontera entre medición y control de runtime.

Guardrail y verification

Verification recoge evidencia de que un resultado concreto satisface requisitos de una tarea. Guardrail comprueba o aplica una política durante la ejecución. Verificar que un archivo compila no autoriza publicarlo; bloquear una salida que contiene un secreto no demuestra que el resultado resuelva la tarea. Ambos pueden ejecutarse sobre una salida, pero sus preguntas, autoridad y consecuencias son distintas.

Guardrail, permission y approval

Agent Permissions and Approval Boundaries define qué recursos y acciones puede utilizar una identidad y cuándo hace falta una autorización adicional. Un guardrail puede inspeccionar argumentos o activar una approval boundary, pero un detector de contenido no sustituye al sistema que verifica el principal, el recurso y la operación. «El modelo parece confiable» no concede permiso.

Approval es un evento de autorización explícita para un paso o alcance. Un guardrail puede pausar una acción para que una persona revise, pero la pausa y la decisión humana no son equivalentes. Human in the Loop cubre intervención, revisión, corrección y escalamiento; un guardrail puede invocarla, aunque no toda intervención humana sea un guardrail.

Un guardrail de acción puede decir que una operación parece riesgosa y exigir aprobación. El control de permisos debe todavía impedir que una identidad sin autoridad la ejecute. Una aprobación tampoco amplía automáticamente privilegios ni cambia el sandbox: el alcance de esa transición debe ser explícito.

Guardrail y sandbox

Agent Sandboxing restringe técnicamente el entorno, recursos y efectos disponibles para una ejecución. Un guardrail aplica una decisión de política en la aplicación o runtime. Un sandbox puede limitar filesystem, procesos o red incluso cuando el modelo intenta una acción; un guardrail puede rechazar un argumento antes de invocar una herramienta. Son controles complementarios.

Un modelo que clasifica una solicitud como segura no reemplaza aislamiento de procesos. Una instrucción de no acceder a secretos no reemplaza restricciones de lectura. Container, VM, workspace separado y aprobación son mecanismos con garantías distintas; ninguno adquiere las propiedades de los demás por aparecer en el mismo flujo.

Input Guardrails

Los inputs pueden incluir mensaje del usuario, archivos, contenido recuperado, resultados de herramientas, parámetros estructurados y contexto compuesto. Un input guardrail puede revisar formato, tamaño, rango, sensibilidad, alcance, presencia de instrucciones maliciosas, datos requeridos o señales de una política antes de permitir que el material llegue a una inferencia o etapa posterior.

El contenido recuperado merece atención especial. Un documento puede contener texto que intenta modificar instrucciones, pedir secretos o redirigir una acción. Retrieval-Augmented Generation recupera evidencia para apoyar generación; no eleva ese texto a una instrucción confiable. El guardrail puede detectar algunas señales, pero la separación entre instrucciones, datos y autoridad debe estar aplicada por el diseño del contexto y las herramientas.

Los controles de input pueden normalizar, eliminar, etiquetar, rechazar o escalar contenido. Transformar una entrada también puede quitar información necesaria o esconder el motivo de una decisión. La aplicación debe conservar suficiente evidencia para explicar qué se cambió y por qué, sin copiar datos sensibles a logs o respuestas. Un filtro de palabras no cubre todas las formas de una conducta ni entiende de manera perfecta el contexto.

Un input guardrail no demuestra autorización. Verificar que el mensaje tenga el formato esperado no prueba que el usuario pueda consultar el recurso nombrado. Tampoco una detección negativa demuestra ausencia de prompt injection, abuso o contenido dañino. Las decisiones de identidad, permisos y límites de datos permanecen en sus mecanismos propios.

Output Guardrails

Los outputs pueden revisarse antes de mostrarlos, almacenarlos, enviarlos a otra persona o entregarlos a una etapa con efectos. Un output guardrail puede comprobar información sensible, contenido prohibido, instrucciones peligrosas, cumplimiento de política, campos obligatorios, restricciones de downstream o señales que exigen revisión.

La revisión puede permitir, rechazar, redactar, transformar, pedir regeneración, ofrecer una respuesta limitada o escalar. Regenerar no garantiza resolver la causa: puede producir otra salida incompatible y aumentar costo o latencia. Redactar tampoco garantiza que no exista una fuga en metadata, trazas, citas, errores o una llamada posterior.

Output guardrails no sustituyen escaping, encoding, autorización, validación de negocio ni controles del consumidor. Una cadena que pasa una clasificación de seguridad puede romper un contexto HTML; un número que cumple un rango puede referir a una cuenta no autorizada; una respuesta sin una palabra prohibida puede seguir dando instrucciones inseguras. La frontera debe corresponder al efecto que se intenta proteger.

Tool y action guardrails

Antes o alrededor de una acción, un guardrail puede inspeccionar identidad de la herramienta, argumentos, destino, recurso, tipo de operación, riesgo, alcance, política y resultado previo. Puede rechazar una llamada, pedir aprobación, cambiar a una operación de solo lectura, limitar parámetros o detener la ejecución después de observar una respuesta inesperada.

Tool Use incorpora capacidades externas; el guardrail añade una decisión de control sobre su uso. Una tool registrada no queda autorizada para todos los recursos, y un argumento que cumple un schema puede apuntar al tenant incorrecto. Action guardrails no son permission checks, approvals ni sandboxing, aunque se compongan con ellos.

La posición del control importa. Revisar el texto antes de generar argumentos no basta si el runtime puede modificar esos argumentos después. Revisar una intención sin validar el destino real deja abierta otra ruta. Para acciones con efectos laterales conviene definir qué evidencia se observa antes, qué se bloquea después y qué ocurre si la herramienta devuelve un estado parcial o ambiguo.

Mecanismos y señales

Los guardrails pueden usar reglas deterministas, schemas, validadores, listas, expresiones de política, clasificadores, modelos, servicios externos o escalamiento humano. No todo guardrail es model-based y no todo model-based guardrail es determinista. Un regex puede ser predecible respecto de su patrón y aun ser incompleto para la conducta que se quiere detectar. Un clasificador puede generalizar, pero sus scores no son una autorización.

Probabilistic vs Deterministic Software conserva la diferencia entre propiedades locales de un mecanismo y comportamiento global del sistema. Un guardrail determinista aplicado a un valor bien definido puede ofrecer una decisión repetible; no prueba que la extracción del valor, la fuente, el contexto o la política hayan sido correctos. Un control probabilístico necesita umbrales, calibración, casos adversariales y una respuesta para incertidumbre.

Componer controles puede reducir huecos, pero también introducir conflictos. Un filtro puede eliminar evidencia necesaria; un clasificador puede derivar una acción que otro control rechaza; una política puede cambiar sin que se actualicen todos los detectores. La observabilidad debe registrar decisión, versión de política, alcance y resultado sin convertir secretos o contenido privado en telemetría indiscriminada.

Falsos positivos y negativos

Un falso positivo bloquea o transforma comportamiento aceptable. Puede impedir una tarea legítima, degradar accesibilidad, ocultar evidencia o producir una regeneración innecesaria. Un falso negativo permite comportamiento que el control debía restringir. Ambos son propiedades del sistema bajo una distribución de entradas, no defectos que una etiqueta «AI» elimine.

La respuesta depende del riesgo. Un control de alto impacto puede preferir escalar ante incertidumbre; otro puede permitir una respuesta limitada y registrar la decisión. Umbrales más estrictos pueden reducir algunos falsos negativos a costa de más falsos positivos. No existe un nivel universal de sensibilidad ni una afirmación responsable de detección perfecta.

La evaluación debe incluir entradas legítimas difíciles, variaciones lingüísticas, contenido transformado, casos límite y rutas que no pasan por el guardrail esperado. El resultado debe analizarse por tipo de entrada, contexto, impacto y versión del control. Una media agregada puede ocultar que un tenant, idioma o acción concreta tiene una tasa inaceptable.

Fail-open y fail-closed

Un guardrail puede fallar, expirar, quedar indisponible o devolver incertidumbre. Fail-open permite continuar cuando el control no decide; fail-closed bloquea o detiene. La elección depende del riesgo, reversibilidad, disponibilidad de revisión, costo de interrupción, alcance de la operación y controles independientes. No es una regla universal que un tipo de guardrail siempre deba abrir o cerrar.

Para una respuesta informativa de bajo impacto puede ser razonable degradar con una respuesta limitada. Para una acción irreversible, un sistema puede pausar o requerir autorización adicional. En ambos casos debe hacerse visible que el control no pudo concluir: tratar un timeout como «pasó» crea un falso éxito, y bloquear silenciosamente dificulta recuperar una tarea legítima.

Un fallback también necesita estar protegido. Cambiar a una ruta sin guardrail, usar una herramienta más privilegiada o enviar contenido a otro proveedor no es una degradación neutra. La aplicación debe conocer qué garantías se pierden y conservar la misma frontera de autorización y datos.

Guardrails y AI Security

AI Security es más amplia que este patrón. Incluye autenticación, autorización, least privilege, límites de confianza, sandboxing, diseño seguro de herramientas, protección de datos, secretos, supply chain y respuesta ante amenazas. Guardrails pueden contribuir a defensa en profundidad, pero no reemplazan esos controles ni convierten un modelo de clasificación en una autoridad de seguridad.

Los guardrails pueden ayudar frente a algunas formas de prompt injection, exfiltración o uso riesgoso de herramientas. Prompt Injection es una amenaza o clase de comportamiento; guardrail es un mecanismo de control. No se materializa aquí un canonical de AI Security ni se afirma que un detector resuelva toda la amenaza. Los permisos, el aislamiento y el diseño de la interfaz deben seguir funcionando si el modelo y el contenido no confiable se comportan adversarialmente.

Confusiones frecuentes

• Guardrail = prompt o instruction: orientar no equivale a imponer un control ejecutable.
• Guardrail = persistent instruction: persistencia cambia alcance temporal, no enforcement.
• Guardrail = schema o structured output: forma válida no implica política válida.
• Guardrail = evaluation: evaluar mide; el guardrail decide durante una ejecución.
• Guardrail = verification: verificar un resultado y restringir una política son tareas diferentes.
• Guardrail = permission: detectar riesgo no concede ni revoca por sí solo autoridad real.
• Guardrail = approval: un control puede activar aprobación, pero no es la decisión autorizante.
• Guardrail = sandbox: una clasificación no aísla filesystem, procesos, red ni secretos.
• Guardrail = Human in the Loop: escalar puede invocar una persona, pero la intervención humana es más amplia.
• Guardrails = AI Security: son una capa parcial de defensa en profundidad.
• Más guardrails = AI segura: controles redundantes o mal ubicados pueden crear huecos y fricción.
• Model-based guardrail = enforcement determinista: un modelo aporta una señal probabilística salvo que otra capa aplique la decisión.
• Guardrail passed = result correct: pasar una política no prueba corrección, verdad, pertinencia ni autorización completa.

Fuentes

• Guardrails and human review, OpenAI.
• AI Risk Management Framework, NIST.
• OWASP Top 10 for Large Language Model Applications, OWASP.
• Building effective agents, Anthropic.