Barreras de seguridad que se ganan su latencia

La primera barrera que despliega un equipo suele ser una llamada de moderación sobre el mensaje del usuario. Caza el abuso obvio, todo el mundo se queda más tranquilo, y no hace casi nada contra los fallos que de verdad llegan a los clientes: el asistente que se inventa con aplomo una política de devoluciones, el que cita los precios de un competidor, el que devuelve datos de otro inquilino porque el filtro de recuperación estaba mal.

Las barreras merecen construirse. También son un impuesto sobre cada petición, y las que se pagan solas se eligen a conciencia en vez de instalarse como categoría.

La entrada y la salida son trabajos distintos

Las comprobaciones de entrada ocurren antes de gastar una llamada al modelo. Son baratas, fallan rápido y tienen un techo bajo. Las útiles: límites de longitud y de tokens para que un documento pegado no cueste veinte veces un turno normal, límites de frecuencia por usuario y por inquilino, detección de abuso obvio, y detección de datos personales donde estés obligado contractualmente a no reenviarlos a un proveedor.

Lo que el filtrado de entrada no puede hacer es detener la inyección de prompt. La superficie de ataque es el lenguaje natural, no hay gramática que rechazar, y cada filtro que publicas es un objetivo público. Tratar un clasificador de entrada como control de inyección es el error, y las alternativas arquitectónicas son el tema de inyección de prompt.

Las comprobaciones de salida son donde está el valor, porque la salida es lo que llega al usuario y de lo que respondes. Las que merecen la pena:

• Validación de esquema. Si pediste salida estructurada, valídala y reintenta si falla. Es la barrera más barata que existe y caza una proporción sorprendente de problemas reales.
• Fundamentación. Para un sistema de recuperación, comprueba que las afirmaciones de la respuesta se apoyan en el contexto recuperado. Es lo más parecido a un control de alucinaciones que funciona de verdad.
• Comprobaciones de política. Nada de nombres de competidores, nada de consejo legal o médico, nada de compromisos sobre devoluciones o precios, lo que sea que tu dominio prohíba.
• Comprobaciones de fuga. Nada del contenido del prompt de sistema, ninguna clave de API, ningún identificador de otro inquilino.
• Formato y tono, que importa para la marca más de lo que se admite.

Reglas, clasificadores y jueces

Tres mecanismos, de menor a mayor coste y capacidad. Usa el más barato que funcione.

Reglas deterministas. Expresiones regulares, listas de prohibidos, validación de esquema, comprobación de identificadores. Microsegundos, gratis, completamente predecibles, y solo cazan lo que enumeraste. Comprobar que la respuesta no contiene ninguna cadena que coincida con el identificador de otro inquilino es una regla, y es mejor que cualquier modelo en ese trabajo.

Clasificadores pequeños. Un modelo de moderación o de temática hecho para eso. Decenas de milisegundos, barato, razonablemente robusto, y generalizan más allá de la redacción exacta. Buenos para abuso, toxicidad y fronteras temáticas.

Un modelo como juez. Otra llamada al modelo preguntando si la respuesta está fundamentada, se ajusta a la política o está completa. De cientos de milisegundos a segundos, el coste de una llamada completa, y lo único que maneja juicios con matiz como "¿esta afirmación se apoya en este documento?". Usa un modelo más pequeño y rápido que tu generador cuando puedas, y dale una pregunta estrecha en vez de una general. El problema de calibración que introduce es el mismo que se describe en evaluar una funcionalidad con LLM.

El patrón que funciona en la práctica: reglas siempre, un clasificador donde la categoría esté bien definida, y un juez solo en las comprobaciones que más importan, a menudo solo sobre una fracción muestreada del tráfico para vigilar y no para bloquear.

Decidir si merece la pena

Toda barrera tiene tres costes. Latencia añadida a cada petición, incluidas las que estaban bien. Dinero, si es una llamada al modelo. Y falsos positivos, que son el caro, porque una barrera que bloquea respuestas legítimas erosiona la confianza en el producto más rápido de lo que lo hace una mala respuesta ocasional.

La aritmética que hay que hacer antes de desplegar una: con qué frecuencia ocurre de verdad el fallo que evita, qué cuesta una ocurrencia, y qué cuesta la barrera por cada mil peticiones incluidos los falsos positivos. Un juez de fundamentación que añade ochocientos milisegundos a cada respuesta para cazar un problema que ocurre en una de cada doscientas suele ser el intercambio equivocado, y la versión correcta es ejecutarlo de forma asíncrona sobre una muestra y alertar cuando la tasa se mueva.

Reserva el bloqueo síncrono para los fallos genuinamente inaceptables: fuga de datos entre inquilinos, salida que crea un compromiso legal, contenido que acabaría con la relación con el cliente.

El streaming rompe las barreras de salida

Es la restricción que nadie planifica. Si envías tokens al usuario según se generan, no puedes comprobar una respuesta completa antes de mostrarla, porque parte ya está en pantalla.

Tres opciones, ninguna gratis. Acumular la respuesta entera, comprobarla y soltarla, lo que elimina el beneficio de latencia percibida que te hizo usar streaming. Comprobar por fragmentos según llegan, que caza algunas clases de problema y no puede evaluar la respuesta como un todo. O emitir de forma optimista y retractarse, que es técnicamente posible y le resulta alarmante al usuario.

Decide esto antes de construir la interfaz, porque añadir una barrera a posteriori sobre un producto con streaming suele significar cambiar el producto.

Qué pasa cuando salta

La acción importa tanto como la detección, y hay cuatro opciones.

Bloquear y disculparse. Seguro, y la peor experiencia. Resérvalo para salidas genuinamente inaceptables.

Regenerar. Reintentar, a menudo con una instrucción añadida sobre qué falló. Cuesta otra llamada y funciona sorprendentemente a menudo en fallos de esquema y de formato. Pon un tope a los reintentos, porque un bucle aquí es caro.

Degradar. Devolver una respuesta reducida: las fuentes recuperadas sin la síntesis, o una respuesta de plantilla, o una pregunta aclaratoria. Suele ser la mejor opción ante un fallo de fundamentación, porque el usuario recibe algo útil y nada falso.

Escalar a una persona. La respuesta correcta cuando lo que está en juego es alto y hay alguien disponible, y necesita que el encaminamiento exista en vez de ser una aspiración. Dónde poner esa frontera es el tema de la persona en el bucle.

Elijas lo que elijas, dile al usuario algo honesto. "No he encontrado apoyo para eso en tus documentos" es mejor experiencia que una negativa genérica, y le enseña a la gente cómo funciona el sistema.

Mide la barrera, no solo el modelo

Una barrera es un clasificador, y un clasificador sin medir deriva hacia la inutilidad o hacia la obstrucción.

Registra cada disparo con la entrada, la salida, la comprobación que saltó y la acción tomada. Muestrea los disparos y etiquétalos: ¿era un verdadero positivo? Sigue la tasa de falsos positivos como métrica principal, porque es la que destruye el producto en silencio. Sigue la tasa de disparo en el tiempo, ya que un cambio brusco suele significar que cambió la versión de un modelo o que alguien te está sondeando.

Versiona las barreras junto a los prompts, en el mismo repositorio, con la misma revisión y el mismo conjunto de evaluación, como en versionar prompts y evaluar automatizaciones. Un cambio de barrera es un cambio de producto y merece la misma puerta. Y mete los disparos en tu observabilidad, porque la tasa de disparo es una de las señales más útiles que emite una funcionalidad de IA, que es el argumento de observabilidad para automatizaciones con IA.

Lo que se olvida

• Las barreras no son un modelo de permisos. Ninguna comprobación de salida sustituye a filtrar la recuperación por los derechos de acceso del usuario.
• El prompt de sistema no es una barrera. Es una instrucción a un componente al que se puede convencer de no seguirla.
• Cobertura de idiomas. Los modelos de moderación son mucho más débiles fuera del inglés. Si sirves a usuarios europeos o globales, prueba en los idiomas que recibes de verdad.
• Al juez también se le puede atacar. Si el contenido no confiable llega al prompt del juez, se le puede convencer de aprobar.
• Alguien tiene que leer los registros. Una barrera que salta dos mil veces al día y que nadie ha mirado es una señal que se tira a la basura.

Qué hacer esta semana

Coge cincuenta conversaciones reales de producción y lee las salidas buscando una sola cosa: una respuesta que afirmó algo que el contexto recuperado no apoyaba. Cuéntalas. Esa tasa es el argumento para una comprobación de fundamentación y, si la tasa es baja, es el argumento para ejecutarla de forma asíncrona en vez de pagarla en cada petición. Dimensionamos así las barreras en un proyecto de IA aplicada.