Guardrails: filtrar entradas y salidas alrededor de un LLM

Un modelo de lenguaje hará alegremente cosas que nunca quisiste que hiciera. Responderá una pregunta fuera de su cometido, repetirá el encuadre hostil de un usuario, filtrará instrucciones que se le dijo mantener en privado o producirá una salida que tu código posterior no puede analizar. Nada de esto significa que el modelo esté roto. Significa que un modelo en bruto es una capacidad, no un producto. Los guardrails son la capa que convierte lo primero en lo segundo: las comprobaciones que ejecutas sobre lo que entra y lo que sale, para que el sistema se mantenga dentro de límites que puedas defender.

Qué es realmente un guardrail

Quita el marketing y un guardrail es un filtro con una decisión adjunta. Algo —un texto, una petición, una respuesta generada— pasa por una comprobación, y la comprobación lo permite, lo bloquea o lo transforma. Esa comprobación puede ser una regla simple, un clasificador u otra llamada a un modelo. Lo importante es la decisión: un guardrail que detecta un problema pero no hace nada es solo registro.

Los guardrails vienen en dos familias, y la distinción es la más útil que conviene tener en mente:

• Los guardrails de entrada se sitúan entre el usuario y el modelo. Inspeccionan la petición antes de que llegue a la generación.
• Los guardrails de salida se sitúan entre el modelo y el usuario (o el siguiente sistema). Inspeccionan lo que produjo el modelo antes de que alguien actúe sobre ello.

La mayoría de los sistemas reales necesitan ambos, porque las dos familias capturan fallos distintos. Filtrar la entrada no garantiza una salida segura, y una salida de aspecto limpio puede provenir de una petición que nunca debió atenderse.

Filtrar la entrada

Los guardrails de entrada responden a una pregunta: ¿deberíamos siquiera pasar esto por el modelo? Varias comprobaciones se ganan su lugar aquí.

La primera es la moderación: filtrar contenido con el que has decidido no interactuar en absoluto. Este es el caso más claro para un clasificador dedicado en lugar de reglas escritas a mano, porque las categorías son difusas y los usuarios adversarios sondean los bordes constantemente.

La segunda es la conciencia de inyección de prompts. Cuando tu aplicación incorpora texto del exterior —una página web, un documento subido, un correo—, ese texto puede contener instrucciones dirigidas a tu modelo en lugar de contenido para procesar. Un guardrail de entrada no puede resolver del todo la inyección, pero puede marcar patrones sospechosos y, sobre todo, te recuerda mantener la entrada no confiable claramente separada de tus propias instrucciones.

La tercera es el alcance. Muchos productos están pensados para hacer una sola cosa. Un asistente de soporte para una app bancaria no tiene por qué escribir poesía ni dar consejos médicos, no porque sean dañinos, sino porque están fuera de su misión y erosionan la confianza. Una comprobación temática ligera mantiene al sistema honesto sobre para qué sirve.

La disciplina a adoptar pronto: nunca confíes en la entrada solo porque venga de tu propia interfaz. El campo de texto es la puerta de entrada, y la puerta de entrada es por donde entran los problemas.

Filtrar la salida

Los guardrails de salida son donde la mayoría de los equipos invierten de menos, y a menudo son la mitad más importante. El modelo ya ha generado algo, y antes de que llegue a un humano o desencadene una acción, tienes una última oportunidad de detectar un problema.

Comprobaciones de salida útiles incluyen:

• Seguridad y política. ¿Produjo el modelo contenido que viola tu política declarada, independientemente de cómo se le indujo? Este es tu respaldo para los intentos de inyección y jailbreak que la capa de entrada pasó por alto.
• Formato y estructura. Si tu código espera una forma específica —un conjunto concreto de campos, una categoría de una lista fija—, verifícalo antes de analizar. Un modelo que devuelve prosa donde esperabas datos estructurados debe detectarse aquí, no con un fallo tres funciones más abajo.
• Fundamentación. Para sistemas que responden a partir de una fuente de conocimiento, comprueba si la respuesta está realmente respaldada por el material recuperado y no inventada. Esto es más difícil que las demás comprobaciones y rara vez perfecto, pero incluso una versión tosca detecta la fabricación segura.
• Fugas. ¿Reveló la respuesta instrucciones del sistema, identificadores internos o datos de otro usuario? Una comprobación simple contra cadenas sensibles conocidas es barata y vale la pena ejecutarla.

La razón por la que los guardrails de salida importan más de lo que parecen es que son la capa más cercana a las consecuencias. Para cuando algo llega a la comprobación de salida, toda la astucia previa ya ha ocurrido. Esta es la última puerta honesta.

Elegir cuán estricto ser

Todo guardrail tiene dos formas de fallar. Puede dejar pasar algo que debería haber bloqueado (un fallo por omisión), o puede bloquear algo perfectamente correcto (una falsa alarma). No puedes llevar ambos a cero, y fingir lo contrario produce un sistema que es o inseguro o inutilizable.

El equilibrio correcto depende por completo de lo que esté en juego. Un guardrail delante de una acción que mueve dinero o envía un correo a un cliente debería inclinarse a lo estricto y fallar de forma cerrada: ante la duda, bloquea y escala. Un guardrail sobre un asistente de lluvia de ideas puede inclinarse a lo permisivo, porque el coste de una falsa alarma (un usuario frustrado) pesa más que el coste de un fallo ocasional (una respuesta algo desviada que el usuario simplemente ignora). Decide dónde se sitúa cada guardrail en este espectro antes de ajustarlo, porque la pregunta "¿cuán estricto?" no tiene respuesta sin saber qué hay al otro lado de la puerta.

Construirlo sin frenarlo todo

Los guardrails añaden trabajo, y el trabajo añade latencia y coste. Unos cuantos patrones lo mantienen manejable.

Ejecuta primero las comprobaciones baratas. Los filtros simples basados en reglas y las coincidencias de cadenas no cuestan casi nada; ejecútalos antes de cualquier comprobación que requiera una llamada a un modelo, y deja que un bloqueo temprano cortocircuite el resto. Reserva las costosas comprobaciones de clasificador y modelo para la entrada que ya haya pasado las puertas baratas.

Ejecuta en paralelo las comprobaciones independientes donde puedas, para que la latencia total sea la de la comprobación más lenta y no la suma de todas. Y separa las comprobaciones bloqueantes de las de monitorización: una comprobación que debe pasar antes de que el usuario vea una respuesta tiene que ejecutarse en línea, pero una comprobación que solo quieres para analítica puede ejecutarse después, fuera del camino crítico.

Por último, registra cada decisión de los guardrails: qué se disparó, sobre qué y qué ocurrió. Los guardrails son tan buenos como tu capacidad de ver dónde están demasiado flojos o demasiado apretados, y esa visibilidad viene enteramente de los registros.

Lo que los guardrails no pueden hacer

Vale la pena ser honesto sobre el techo. Los guardrails reducen el riesgo; no lo eliminan. Un adversario decidido encontrará formulaciones que tus filtros pasan por alto, y un modelo suficientemente capaz producirá de vez en cuando algo sorprendente que ninguna comprobación anticipó. Los guardrails tampoco sustituyen a que el modelo se comporte bien de entrada: son una capa de defensa, no la única defensa.

Trátalos como una parte de una postura más amplia que incluye un modelo elegido e instruido para la tarea, acceso de mínimo privilegio para cualquier acción que el modelo pueda desencadenar, revisión humana donde las apuestas lo exijan y un plan de incidentes para cuando algo se cuele. Una capa de guardrails que te deje dormir por la noche es producto de todo esto en conjunto, no de un único filtro ingenioso.

En resumen

Los guardrails son la diferencia entre un modelo y un producto que puedes poner frente a usuarios reales. Filtra la entrada para decidir qué vale la pena ejecutar, filtra la salida para decidir qué es seguro accionar y ajusta la severidad de cada puerta a lo que tiene detrás. Mantén primero las comprobaciones baratas y deja raras las costosas, registra cada decisión y mantente humilde sobre el techo. Un modelo te da capacidad; los guardrails te dan los límites que hacen que esa capacidad sea segura de lanzar.