La colisión de vocabulario: cuando un clasificador de seguridad marca todo tu dominio

Un clasificador de seguridad de propósito general lleva consigo una suposición oculta: que hablar sobre atacantes, exploits y blanqueo de capitales es raro y sospechoso. Apúntalo a un producto de seguridad y cumplimiento, y esa suposición se invierte. Durante un período de producción de 17 días que terminó el 10 de abril de 2026, el alias mistral-moderation-latest de Mistral (que en ese momento resolvía en la versión mistral-moderation-2603) marcó 15 mensajes en nuestra aplicación como dañinos. Todos fueron falsos positivos. La precisión era cero. No degradada, no ruidosa: cero de quince.

Este es un resultado específico y medido en nuestro propio tráfico, y nombra un modo de fallo que es invisible hasta que lees las alertas una por una. Lo llamamos la colisión de vocabulario: en un dominio especializado, el vocabulario de peligro del clasificador es el vocabulario de trabajo del dominio, por lo que la señal que debería ser rara se convierte en la tasa base.

Las alertas

De las 15 alertas, 14 cayeron en la categoría dangerous_and_criminal_content del clasificador y 1 en violence_and_threats. Al revisarlas, el patrón fue inmediato. Todas eran discusiones legítimas de GRC (Gobierno, Riesgo y Cumplimiento):

• Ingeniería inversa de los servicios de un proveedor de la nube, en el contexto de obligaciones de propiedad intelectual. La norma ISO/IEC 27001:2022 Anexo A control A.5.32 es literalmente "Derechos de propiedad intelectual"; un usuario que trabaja ese control debe hablar de ingeniería inversa para razonar sobre él.
• Evaluación de riesgos escrita en español, donde "amenazas" es la palabra ordinaria para aquello que todo registro de riesgos enumera.
• Trabajo contra el blanqueo de capitales, donde "blanqueo" es el tema en cuestión, no una confesión.
• Experiencia en red teaming y pruebas de penetración.
• DAST, escaneo dinámico de una aplicación en busca de vulnerabilidades.

Nada de esto es contenido criminal. Es el vocabulario diario de profesionales de ciberseguridad, oficiales de cumplimiento y auditores. El clasificador no está defectuoso. En el tráfico web general, un mensaje sobre ingeniería inversa de los sistemas de un proveedor es una señal de peligro débilmente plausible, y un clasificador de propósito general está diseñado para tratarlo como tal. Nuestros usuarios son la población para la cual esa misma señal significa lo contrario. Esperaríamos este modo de fallo de cualquier clasificador de propósito general usado de la misma manera, porque surge del marco de propósito general más que de la implementación de un proveedor. El error fue nuestro: tratamos un prior general como si fuera consciente del dominio.

El bloqueo excesivo no es un valor por defecto seguro

El reflejo es tratar los falsos positivos como el lado inofensivo del intercambio precisión-recall. Perder una amenaza real y tendrás un agujero de seguridad; marcar en exceso y tendrás, en el peor de los casos, algo de ruido. En producción, el ruido tenía dientes, y vale la pena ser concreto sobre los costes de segundo orden, porque ahí es donde estuvo el daño real:

1. La fatiga por alertas derrotó la red. Cada evento confirmado enviaba un correo a nuestra bandeja de seguridad. Quince falsas alarmas seguidas entrenaron al equipo para ignorar las alertas de moderación. Una red de seguridad que todos han aprendido a ignorar no es una red de seguridad.
2. Un problema de derecho al olvido. Los hilos marcados se bloqueaban para evitar su eliminación, de modo que no se pudiera destruir la evidencia. Eso es razonable para un abuso genuino. Aplicado a un falso positivo, significaba que un usuario no podía eliminar su propia conversación de cumplimiento, lo que creaba un riesgo bajo el Artículo 17 del GDPR (derecho al olvido). Ese derecho, sujeto a sus propias condiciones y excepciones, cubre la eliminación selectiva, no solo el cierre de una cuenta.
3. Una etiqueta que no podíamos sustentar. Mensajes benignos de usuarios estaban en un almacén cuya semántica era "contenido peligroso y criminal". Esa es una afirmación sobre una persona que no podíamos respaldar.

La métrica que nos perjudicaba era la precisión, no el recall, y su fallo no era cosmético.

Por qué las soluciones obvias no funcionan

Dos soluciones se sugieren y ambas son incorrectas.

Ajustar el clasificador. No puedes. El punto de acceso de moderación es un clasificador fijo. Su API acepta un identificador de modelo y una cadena de entrada, y devuelve puntuaciones de categorías. No hay un prompt de sistema, ni campo de instrucción, ni lugar para decirle "esto es un producto de cumplimiento". Un clasificador fijo te da un dial sin números en él.

Eliminar las categorías ruidosas. Deshabilitar dangerous_and_criminal_content y violence_and_threats eliminaría todos los falsos positivos que habíamos visto. También eliminaría las únicas categorías bajo las cuales una amenaza genuina en nuestro dominio podría aparecer alguna vez. Eso no es calibración, es apagar la red y llamar al silencio éxito.

La solución en dos etapas

Mantén el clasificador rápido como primera etapa; sigue ejecutándose en cada mensaje. Cuando marque algo, pasa el mensaje a un juez de segunda etapa: un pequeño modelo de chat (Mistral Small) con un prompt de sistema que describe los temas legítimos de ciberseguridad y cumplimiento que nuestros usuarios realmente discuten. El juez devuelve uno de dos veredictos: CONFIRMADO o FALSO_POSITIVO.

Solo los eventos CONFIRMADO fluyen hacia la ruta de alerta y bloqueo. Los eventos FALSO_POSITIVO van a un almacén suprimido separado, retenidos para auditoría y detección de deriva, pero con cero consecuencia visible para el usuario: sin correo, sin bloqueo de eliminación, sin etiqueta criminal. El juez se activa aproximadamente una vez al día en un mensaje marcado, por lo que el coste adicional es insignificante. Y falla en modo cerrado: si el juez se equivoca, se agota el tiempo, o devuelve algo que no sea un veredicto limpio, el mensaje se trata como CONFIRMADO. El peor caso es la antigua línea base ruidosa, nunca una amenaza silenciosamente ignorada.

Desplegado el 10 de abril de 2026, esto llevó nuestra tasa de falsos positivos en esas alertas de 15 de 15 a cero sin deshabilitar ninguna categoría.

La trampa: trasladamos el riesgo, no lo eliminamos

Aquí está la parte que vale la pena recordar, porque se generaliza más allá de la moderación. Añadir una segunda etapa indulgente no elimina el riesgo. Lo mueve, de un fallo que puedes ver a uno que no puedes.

Antes, el modo de fallo era el bloqueo excesivo, y era ruidoso: cada falso positivo hacía sonar la campana de alerta. Después, el modo de fallo dominante es que el juez sea demasiado indulgente y deje pasar en silencio algo que debería haber confirmado. Ese fallo es silencioso por construcción. Escribe en un almacén del que nadie recibe un correo.

Obtuvimos una demostración en vivo de lo desorientador que es el régimen silencioso. El 14 de abril de 2026, cuatro días después de la solución, los correos de alerta de moderación cesaron por completo. Desde fuera, un cero repentino es indistinguible de un conducto roto: el clasificador fallando en abierto, una interrupción, un disparador caído. Tuvimos que leer los datos subyacentes para distinguir "saludable y tranquilo" de "oscuridad silenciosa". Una vez que tuvimos acceso de lectura al almacén suprimido, auditamos cada veredicto de Mistral Small que había acumulado desde el despliegue del 10 de abril de 2026: 40 filas suprimidas, y tras nuestra revisión, ninguna era una amenaza real erróneamente desestimada. La ruta confirmada se reconcilió exactamente en el mismo período, 23 eventos confirmados frente a 23 correos de alerta. La red estaba intacta. Pero la única forma de saber eso fue auditar lo que se había vuelto silencioso.

Por lo tanto, la segunda etapa necesita su propia evaluación, en su propio calendario. El almacén suprimido ahora se verifica mensualmente en busca de indulgencia excesiva del juez, y un conteo diario barato en la tabla confirmada vigila si el conducto se oscurece. La lección no es "añade un juez LLM". Es: cuando arreglas un fallo visible con un componente más silencioso, presupuesta la auditoría de lo silencioso, o habrás intercambiado un problema que puedes medir por uno que no puedes.

Lista de verificación portátil

Si estás ejecutando un clasificador de propósito general sobre un corpus especializado —médico, legal, de seguridad, financiero o de cumplimiento—, antes de confiar en su salida:

• Verifica una colisión de vocabulario. Enumera el vocabulario de trabajo normal de tu dominio. Si esas palabras se solapan con las categorías de peligro del clasificador, su precisión en tu tráfico es una pregunta abierta, no una suposición. Mídela.
• Lee las alertas, no solo cuéntalas. Un número de precisión oculta el patrón; los falsos positivos individuales lo revelan. Quince alertas no nos dijeron nada hasta que leímos quince alertas.
• Valora honestamente el bloqueo excesivo. Traza qué desencadena un falso positivo aguas abajo. Fatiga por alertas, un bloqueo de eliminación que choca con un derecho legal de olvido, una etiqueta que no puedes sustentar. El bloqueo excesivo rara vez es gratuito.
• Si el clasificador es fijo, envuélvelo, no lo luches. Cuando no puedes instruir al modelo, añade una etapa consciente del dominio alrededor de él en lugar de deshabilitar categorías al por mayor.
• Falla en modo cerrado en el envoltorio. Un error del juez debe escalar, nunca suprimir, de modo que una interrupción del envoltorio no pueda abrir silenciosamente la red.
• Dale a la etapa silenciosa su propia auditoría. Cualquier componente que suprime en silencio necesita una revisión programada de lo que suprimió, además de una verificación de actividad que distinga "saludable y tranquilo" de "oscuro".

Límites

Este es un producto, un dominio y una muestra pequeños: 15 alertas en una ventana única de 17 días que terminó el 10 de abril de 2026, más 40 filas suprimidas en las semanas siguientes. Es un resultado puntual en el momento sobre el alias mistral-moderation-latest tal como resolvía durante esa ventana, enmarcado como nuestra propia medición en nuestro propio tráfico. No es una afirmación general sobre la calidad de ese clasificador fuera de nuestro dominio. La propia tasa de error del juez está acotada por el valor por defecto de fallo cerrado, pero no es cero, lo que es exactamente por qué se audita en lugar de confiar en él. En lo que sí confiamos es en el mecanismo: cuando el vocabulario de peligro y el vocabulario del dominio son las mismas palabras, la precisión de un clasificador de propósito general es una medición que debes tomar, no una propiedad que puedes asumir.