7.1.1. ¿Qué significa validar semánticamente un sistema?

Validar semánticamente un sistema significa comprobar si el modelo puede reconocer amenazas reformuladas, mensajes ambiguos o variantes lingüísticas que no repiten exactamente las palabras vistas en entrenamiento. Más que responder a: ¿clasifica bien?, es:

¿entiende suficientemente el significado como para detectar evasión?

7.1.2. ¿Qué es un caso de evasión?

Un caso de evasión es un mensaje que intenta evitar la detección automática modificando su forma lingüística sin cambiar su intención. Por ejemplo: “Verifique su cuenta inmediatamente para evitar suspensión.” Su variante evasiva es: “Se recomienda actualizar su acceso a la plataforma para mantener disponibilidad del servicio.”

Aunque las palabras son diferentes, la intención puede seguir siendo:

• inducir acción,
• crear presión,
• obtener información sensible.

7.1.3. ¿Por qué la evaluación cualitativa es necesaria?

Las métricas cuantitativas como Precision o Recall son útiles, pero no explican cómo falla o acierta un sistema semántico. La evaluación cualitativa permite analizar:

• qué tipo de reformulaciones detecta,
• qué señales semánticas reconoce,
• qué casos le generan confusión,
• qué mensajes parecen legítimos pero no lo son.

Esto es especialmente importante en el Reto 3, donde el objetivo no es solo clasificar, sino identificar intención maliciosa más allá de palabras clave.

7.1.4. Tipos de evasión

• Sustitución léxica: Cambiar palabras directas por sinónimos o expresiones más neutrales. Ejemplos: “verifique” → “valide”; “suspensión”→”restricción temporal”.
• Reformulación pragmática: Convertir una orden explícita en una recomendación o sugerencia. Ejemplos: “Debe actualizar sus credenciales”; “Se recomienda actualizar su acceso”.
• Evasión por tono: Reducir urgencia explícita y adoptar un tono institucional o amable.
• Evasión por contexto: Insertar el mensaje malicioso dentro de un contexto aparentemente técnico o administrativo.

7.1.5. Metodología de evaluación cualitativa

La evaluación cualitativa puede estructurarse en una tabla de casos (Eisenstein,2019):

7.1.6. Criterios cualitativos de análisis

Al revisar cada caso, se debe responder:

• ¿Qué señal semántica conserva el mensaje?
• ¿Qué cambió respecto al ataque explícito?
• ¿El modelo detectó la intención o solo coincidencias léxicas?
• ¿La decisión parece justificable?

De esta manera, es posible distinguir entre:

• detección superficial
• comprensión semántica real

7.1.7. Ejemplo Python

Tomando como base el recurso de profundización de la semana 6 (sistema híbrido), se construye el siguiente conjunto de casos de evasión (Ilustración 1):

Figura 1

Evaluación cualitativa de evasión

Con el resultado, se debe discutir:

• ¿Por qué se acertó?
• ¿Por qué falló?
• ¿Qué patrón?

7.1.8. Error comun

Un error frecuente es asumir que si el modelo detecta casos explícitos, también detecta reformulaciones. Esto no ocurre necesariamente, pues muchos sistemas funcionan bien con ejemplos prototípicos, y fallan con lenguaje diplomático, técnico o ambiguo. Por eso es crucia la validación (discusión). Un sistema semántico robusto no solo reconoce ataques típicos, sino también sus disfraces lingüísticos.

En sistemas de PLN aplicados a ciberseguridad no es suficiente que el modelo diga

"ALERTA: posible ataque"; sino que es necesario responder (Eisenstein,2019):

¿Por qué el sistema tomó esa decisión?

La explicabilidad del modelo se refiere a la capacidad de entender, interpretar y justificar las decisiones del sistema. En un SOC (Security Operations Center), esto es crítico porque:

• los analistas deben confiar en el sistema,
• necesitan justificar decisiones operativas,
• deben poder auditar errores o falsos positivos.

Un sistema que no puede explicar sus decisiones se considera una “caja negra”, lo cual es problemático en entornos críticos.

7.2.1. Tipos de explicabilidad

Existen dos niveles principales:

1. Explicabilidad global: Describe cómo funciona el modelo en general.

   Ejemplos:

   • qué variables influyen más,
   • qué patrones detecta,
   • cómo toma decisiones en promedio.
2. Explicabilidad local: Explica por qué el modelo tomó una decisión específica.

   Ejemplo: “Este mensaje fue clasificado como ataque porque contiene urgencia, acción y referencia a autoridad”

   En ciberseguridad, la explicabilidad local es la más importante.

7.2.2. Explicabilidad en modelos de PLN

Dependiendo del modelo, la explicabilidad puede variar (Jurafsky,2023):

Esto genera un trade-off:

Más precisión ≠ más explicabilidad

Ejemplo: en el mensaje: “El equipo de seguridad solicita validar su cuenta inmediatamente”, la salida del sistema puede ser: “ALERTA: posible ataque”.

La posible explicación sería:

• detecta autoridad → “equipo de seguridad”
• detecta acción → “validar”
• detecta urgencia → “inmediatamente”

Esto es: una combinación de señales de ingeniería social

7.2.3. Métodos de explicabilidad

1. Basado en reglas: El más simple y directo (Ilustración 2):

   Figura 2

   Explicabilidad basada en reglas

   
   

   Explicación: “Se detectaron patrones de urgencia y acción”

2. Basado en pesos (TF-IDF): Se pueden identificar las palabras más relevantes, viendo qué terminos influyeron en la decisión. Ilustración 3 muestra código de ejemplo:

   Figura 3

   Explicación vectorizada basada en pesos

   
   

3. Basado en similitud semántica: Explicación: “Este mensaje es similar a otros ataques conocidos”.
4. Métodos avanzados (conceptual): LIME y SHAP permiten explicar modelos complejos, aunque no siempre son necesarios en este curso.

7.2.4. Ejemplo Python

Ilustración 4 muestra una explicación simple usando código Python

Figura 4

Explicar decisión

De esta manera, se amplía el sistema del recurso de profundización de la semana 6, con el código de la Ilustración 5:

Figura 5

Sistema integrado: híbrido y explicación

Así, el sistema se transforma en:

clasificador + justificador

7.2.5. Buenas prácticas

Un buen sistema además de detectar amenazas también puede explicar por qué las detecta. Si el sistema no es explicable:

• los analistas pueden ignorar las alertas,
• no se pueden corregir los errores fácilmente,
• aumenta el riesgo de decisiones incorrectas,
• se pierde trazabilidad del sistema

Por ello, se recomienda las siguientes buenas prácticas

• siempre acompañar predicciones con explicación,
• usar modelos interpretables cuando sea posible,
• documentar criterios de decisión,
• permitir auditoría del sistema.

7.2.6. Niveles de Explicabilidad en PLN para ciberseguridad

La explicabilidad en PLN opera en tres niveles integrados

1. Local (caso específico): ¿por qué este mensaje fue marcado?
2. Global (modelo): ¿cómo decide el sistema en general?
3. Operativo (sistema): ¿Cómo se documenta y audita la decisión?

A nivel de diseño técnico, un sistema PLN explicable en ciberseguridad debe incluir:

• Capa de logging explicativo, con la información mínima del JSON (Ilustración 6).

  Figura 6

  JSON con información explicativa

  
  

• Interfaz de auditoría: visualización de tokens relevantes e historial de decisiones.
• Política de umbrales explicables: justificación del por qué un score (digamos >0.85) implica bloqueo.