La arquitectura del sistema es la organización funcional de todos los módulos que participan en el procesamiento de texto y la generación de alertas. No se trata solo de “tener modelos”, sino de definir:

• qué entra al sistema,
• qué se procesa en cada etapa,
• qué decisiones se toman,
• y qué sale como resultado.

En un entorno de ciberseguridad, esta arquitectura debe responder a una lógica operativa: recibir texto, analizarlo, priorizarlo y apoyar decisiones.

8.1.1. Componentes mínimos de una arquitectura PLN para SOC

Ilustración 1 muestra el pipeline del presente curso de Procesamiento de Lenguaje Natural.

Descripción de cada bloque:

• Fuente textual: es el punto de entrada del sistema, por ejemplo: correos sospechosos, tickets de soporte, mensajes corporativos, reportes narrativos.
• Preprocesamiento: transforma el texto crudo en texto analizable, incluye: tokenización, normalización, eliminación del ruido, lematización. Este componente proviene del reto 1.
• Vectorización: convierte el lenguaje en representaciones numéricas, utilizando: TD-IDF, embeddings, representaciones híbridas. Este paso permite alimentar los modelos posteriores.
• Clasificador de amenazas: estima si el texto pertenece a clases como: phishing, malware, ingeniería social, incidente técnico, legítimo. Corresponde al reto 2.
• Modulo semántico: permite detectar reformulaciones, identificar intención, analizar señales discursivas, y reconocer evasión semántica. Reto 3.
• Motor de decisión: integra resultados del clasificador y del módulo semántico. Ejemplo:
  • si clase = phishing y señal semántica alta → alerta crítica
  • si clase = legítimo pero anomalía alta → revisión humana
• Salida explicable: emite alerta y la justifica. Ejemplo:
  • Alerta: posible phishing.
  • Razones: urgencia + acción + autoridad + similitud con ataques previos.

8.1.2. Diferencia entre modelo y sistema

Aunque tanto el modelo como el sistema son tecnológicos, es decir sistemas cerrados (artificiales), en tecnología hay diferencia entre modelo y sistema, no son lo mismo.

La arquitectura organiza varios modelos y reglas en un único flujo funcional.

8.1.3. Requisitos de una arquitectura útil en ciberseguridad

La arquitectura convierte componentes aislados en un sistema capaz de apoyar decisiones reales. Una arquitectura básica adecuada es:

• Modular: cada componente puede mejorarse por separado
• Explicable: las decisiones deben tomarse y justificarse
• Robusta: debe tolerar reformulación o evasión.
• Ética: debe controlar sesgos y prteger datos.
• Operativa: debe ser útil para analistas humanos.

La arquitectura del curso puede resumirse de la siguiente manera:

• Reto 1: prepara datos
• Reto 2: clasifica amenazas
• Reto 3: detecta intención maliciosa
• Semana 7: valida y controla éticamente
• Semana 8: integra todo en un sistema único.

Al momento, el sistema cuenta con dos capacidades distintas:

• Integración clasificación + semántica.
• Al momento, el sistema cuenta con dos capacidades distintas:
• Clasificador (Reto 2) → identifica qué tipo de amenaza es el texto
• Módulo semántico (Reto 3) → interpreta cómo está construido el mensaje (intención, evasión, señales discursivas)

Cada uno resuelve un problema diferente. Sin embargo, en un entorno real de ciberseguridad, ninguno es suficiente por sí solo:

• El clasificador puede fallar ante reformulaciones.
• El análisis semántico puede detectar intención, pero no clasificar el tipo de amenaza.

La integración permite construir un sistema más robusto, preciso y contextualizado. Las ventajas de la integración pueden resumirse en:

• Detecta ataques explícitos y evasivos
• Reduce dependencia de palabras clave
• Mejora balance precision/recall
• Permite decisiones más inteligentes
• Facilita explicabilidad

Mientras, los riesgos si se integra mal, pueden ser:

• Exceso de falsos positivbos (modelo demasiado sensible)
• Pérdida de ataques reales (modelo demasiado estricto)
• Decisiones inconsistentes
• Falta de interpretabilidad

La clasificación dice qué es el mensaje, la semántica dice cómo está construido, y la integración decide qué hacer con él.

8.2.1. Tipos de integración (Eisenstein, 2019)

A continuación se ejemplifica las cuatro integraciones más conocidas:

8.2.2. Tipos de integración en Python

Ilustración 3 muestra un pseudocódigo que integra clasificación y semántica.

8.2.3. Integración con explicabilidad

El sistema también debe devolver el por qué, como el pseudocódigo de Ilustración 4.

Un ejemplo de salida final de los pseudocódigos presentados en Ilustración 3 y 4, es:

• Texto (input): “Actualice su contraseña inmediatamente”
• Output:
  • Clase: phishing
  • Semántica: ataque
  • Decisión: [urgencia, dato sensible]

Si un sistema no controla sesgos, protege datos y explica sus decisiones, no es confiable. Para pasar de la dimensión técnica a la dimensión responsable del sistema, hay que preguntarse si el sistema funcional (puede ser utilizado en un entorno real de ciberseguridad):

• ¿es justo? (sesgos)
• ¿respeta la información? (privacidad)
• ¿se puede confiar en sus decisiones? (explicabilidad)

8.4.1. Sesgos

Ocurre cuando el modelo: favorece o penaliza ciertos patrones lingüísticos, aprende asociaciones incorrectas, o generaliza de forma injusta a partir de ciertos datos. Por ejemplo, si el dataset tiene muchos ataques con lenguaje urgente, el mensaje puede aprender que todo mensaje urgente es un ataque, generado: falsos positivos en comunicaciones legítimas, y decisiones injustas o incorrectas. A continuación tipos de sesgos y la manera de mitigarlos sugerida (Jurafsky,2023).

8.4.2. Privacidad en análisis de texto

Los sistemas de PLN en ciberseguridad pueden analizar: correos electrónicos, tickets internos, chats corporativos, reportes técnicos. Todos los anteriores pueden contener: nombres, credenciales e información sensible.

Los riesgos por privacidad pueden ser (Cavoukian,2010): exposición de datos confidenciales, almacenamiento y uso indebido de información personal. Los principios de privacidad en PLN incluyen: minimización de datos (usar solo lo necesario), anonimización (eliminar identificadores), y seguridad de almacenamiento (proteger datasets).

Un ejemplo conceptual práctico de formas de anonimización

8.4.3. Explicabilidad (en contexto operativo) (Eisenstein, 2019)

Es un requisito del sistema final que debe explicar:

• La manera en que detecta una amenaza
• La señales que encontró
• Su nivel de confianza
• El módulo influyente (clasificador o semántico)

Si el sistema no explica lo anterior, corre el riesgo de que el analista pierda confianza, no se pueda auditar decisiones, y rechazo del sistema en entorno real.

8.4.4. Ilustración 7 ejemplifica en pseudocódigo un sistema confiable.

Es la evaluación integral del sistema completo, no de componentes aislados. En esta etapa se verifica si el sistema:

• funciona correctamente de extremo a extremo,
• cumple con los objetivos del curso,
• es consistente en distintos escenarios,
• y es suficientemente confiable para apoyar decisiones en ciberseguridad.

Ya no se evalúa solo: modelo → resultado, sino:

entrada real → procesamiento → integración → decisión → explicación

8.5.1. Dimensiones de validación del sistema completo

• Dataset incluye (Ilustración 8 con ejemplo)
  • Casos reales o simulados
  • Ataques explícitos
  • Ataques evasivos
  • Textos legítimos
  • Casos ambiguos

  Figura 8

  Dataset con todas las opciones

  
  

• Correctitud funcional:
  • Si el sistema procesa correctamente los textos
  • Si los módulos están bien conectados
• Desempeño global:
• Precision, Recall, F1
• ROC / AUC
• Comportamiento ante distintos umbrales
• Robustez
  • Funcionamiento con textos reformulados
  • Resistencia a evasión semántica
  • Desempeño frente a casos ambiguos
• Explicabilidad
  • Justificación de decisiones
  • Coherencia de la explicación
• Ética y control
  • Evita decisiones injustifficadas
  • Aplica revisión humana cuando corresponde.

8.5.2. Evaluación

• Evaluación automática (Ilustración 8), que incluye métricas globales.

Figura 9

Evaluación sistema PLN




• Evaluación cualitativa, se debe analizar
• ¿Dónde falla el sistema?
• ¿Qué errores comete?
• ¿Son errores críticos (seguridad) o tolerables?
• Pruebas de estrés (stress testing)
• Reformulación: “Valide su acceso para mantener operatividad”
• Ambigüedad: “Sería bueno revisar esto pronto”
• Ruido: “*** urgente!! Validar cuenta ahora!!! ***”
• Validación de consistencia
• Estable: no cambiar decisiones sin razón
• Coherente: decisiones alineadas con lógica definida
• Reproducible: mismos resultados con mismos datos
• Validación de umbrales
• Niveles de alerta del sistema: bajo, medio, alto.
• Verificar
  • Si son adecuador
  • Si hay muchas alertas
  • Si se pierden amenazas reales

En un entorno de ciberseguridad, el sistema no “termina” cuando genera una predicción. Su valor real depende de cómo comunica los resultados a los analistas humanos. Un modelo altamente preciso puede ser inútil si:

• no presenta la información de forma clara,
• no prioriza correctamente las alertas,
• no explica sus decisiones.

Por ello, la última etapa del sistema consiste en transformar los outputs técnicos en información accionable, es decir, en insumos que permitan tomar decisiones operativas dentro de un SOC.

8.6.1. Entregables del sistema completo

• Clasificación del evento: phishing / malware / ingeniería social / legítimo
• Nivel de riesgo: alto / medio / bajo
• Explicación: señales detectadas (urgencia, autoridad, acción) / similitud semántica / factores de decisión.
• Recomendación operativa: bloquear mensaje / escalar a analista / monitorear / permitir.
• Ejemplo de salida completa
  • ALERTA: phishing
  • NIVEL: alto
  • EXPLICACIÓN
    • Urgencia detectada (“inmediatamente”)
    • Solicitud de acción (“verifique su cuenta”)
    • Similitud con ataques previos
  • RECOMENDACIÓN: Escalar a analista SOC y bloquear remitente.

8.6.2. Diseño de la salida del sistema

Estructuración de la información en forma directa, clara y jerárquica, como indica el pseudocódigo de la Ilustración 10.

8.6.3. Principios de comunicación efectiva

La salida del sistema observa:

• Claridad: evitar términos técnicos innecesarios
• Prioridad: destacar alertas críticas primero
• Trazabilidad: permitir entender cómo se llegó a la decisión
• Accionabilidad: siempre incluir una recomendación.

Validación de la comunicación:

Evaluar si la información es comprensible, las explicaciones son suficientes, la recomendación es coherente, y si facilita la toma de decisiones.

El sistema completo tiene los siguientes componentes:

Datos → Preprocesamiento → Clasificación → Semántica → Evaluación → Ética → Comunicación → Decisión

8.6.4. Error común

Un error frecuente es general salidas muy técnicas e incomprensibles como: “Predicción: 0.873”. Esto es inútil para un SOC. Debe transformarse en: “Alerta de alta riesgo con justificación clara”.

El objetivo del PLN en ciberseguridad no es solo analizar texto, sino convertir lenguaje en decisiones informadas.