Pipeline NLP para análisis de riesgos: de documentos no estructurados a JSON estructurado.

En el mundo real (y sobre todo en banca o seguros), la información crítica no viene en una tabla de SQL. Viene en PDFs, correos urgentes o informes de incidencias escritos a mano alzada. Si tienes que analizar 2.000 de estos al día, o tienes un ejército de personas leyendo o te montas algo automático.

En este post os quiero enseñar cómo diseñé un pipeline de NLP para atacar este problema. No es solo "meter IA por meter", sino crear un flujo lógico que clasifica, extrae y limpia la información por nosotros. Lo bueno de este enfoque es que, con un par de ajustes, te sirve igual para riesgos que para clasificar tickets de soporte o contratos legales.

Lo que vamos a construir hace cuatro cosas clave:

• Prioriza. ¿Esto es un incendio o un aviso rutinario?
• Etiqueta. ¿Es fraude, un fallo técnico o un tema legal?
• Detecta datos. Saca IPs, cuentas, correos... lo "duro".
• Entiende el contexto. Identifica qué leyes o empresas se mencionan.

La arquitectura del flujo (Keep it simple)

No hace falta complicarse la vida con modelos gigantes para todo. Aquí combinamos lógica de negocio (reglas) con modelos estadísticos.

El flujo es este:

Documento bruto → Clasificador de Urgencia → Etiquetado de Riesgos → Extractor de Datos Técnicos → NER (Entidades) → JSON Estructurado.

Un caso real para probarlo

Para que no sea todo teoría, vamos a usar este aviso de incidencia (me lo he inventado, pero es muy parecido a lo que te podrías encontrar en un sistema real):

ALERTA DE RIESGO OPERACIONAL - ID-2026-00142 Se ha detectado un fallo crítico en el sistema de procesamiento de transacciones... afecta a tarjetas de crédito. Empezó a las 14:23 UTC y afecta a unos 15.000 clientes. Datos: IP 192.168.1.50 | Error: ERR-DB-TIMEOUT | TXNs: TXN-A7B3C9D2, TXN-F4E8A1B6. Ojo: Supera el umbral del 0.5% de la MiFID II. Hay que avisar a la CNMV.

Clasificando la quemazón: criticidad

Lo primero es saber si tenemos que mandar un mensaje al jefe o si puede esperar a mañana. Para esto, usamos un sistema de pesos. Si aparecen palabras como "sanción" o "fraude", el score sube como la espuma.

class CriticalityClassifier:
    def __init__(self):
        # Aquí definimos qué nos quita el sueño
        self.keywords_critico = {'fraude': 10, 'pérdida': 10, 'incumplimiento': 10, 'multa': 10}
        self.keywords_alto = {'riesgo': 7, 'alerta': 6, 'fallo': 5}
        # ... (otros niveles)

    def _calculate_scores(self, text: str):
        text_lower = text.lower()
        # Sumamos puntos según lo que encontremos
        return {
            'critico': sum(w for k, w in self.keywords_critico.items() if k in text_lower),
            'alto': sum(w for k, w in self.keywords_alto.items() if k in text_lower),
            # ...
        }

Resultado: en nuestro ejemplo, nos daría un nivel ALTO con una confianza del 57%. Suficiente para disparar una alerta automática.

¿De qué estamos hablando? (Categorías)

Un documento puede ser de varias cosas a la vez. Por ejemplo: tecnológico (caída de servidor) y cumplimiento (incumplimos una norma). He usado patrones de Regex precompilados porque, sinceramente, para palabras clave específicas son mucho más rápidos y baratos que una red neuronal.

# Un pequeño mapa de qué buscar para cada riesgo
self.category_keywords = {
    'operacional': ['fallo', 'error', 'caída', 'incidencia técnica'],
    'cumplimiento': ['normativa', 'sanción', 'cnmv', 'mifid'],
    'ciberseguridad': ['ataque', 'malware', 'hackeo', 'brecha']
}

Extracción de "hilos" técnicos

Aquí es donde el NLP brilla ahorrando tiempo. En lugar de que un analista copie y pegue las IPs o los códigos de error, dejamos que las expresiones regulares hagan el trabajo sucio.

Sacamos a la vez:

• IPs: 192.168.1.50
• IDs de transacción: TXN-A7B3C9D2
• Emails: incidencias@banco-ejemplo.com

NER. ¿Quién es quién?

Para extraer entidades (organizaciones, leyes, productos), uso spaCy. Es la navaja suiza para esto. Le añadimos un diccionario personalizado porque spaCy sabe qué es una "persona", pero a veces le cuesta entender qué es la "MiFID II" o la "CNMV" si no se lo decimos.

# Combinamos spaCy con nuestras propias reglas de dominio
self.custom_entities = {
    'normativas': ['mifid ii', 'gdpr', 'pci dss'],
    'organismos': ['cnmv', 'bce', 'banco de españa']
}

El resultado final: JSON

Al final, el pipeline nos escupe algo así de limpio:

{
  "criticality": "alto",
  "categories": ["operacional", "cumplimiento", "tecnológico"],
  "indicators": {
    "ipv4": ["192.168.1.50"],
    "error_code": ["ERR-DB-TIMEOUT"]
  },
  "entities": {
    "normativas": ["MiFID II"],
    "organismos": ["CNMV"]
  }
}

¿Esto escala?

Si lo lanzas de forma secuencial, te puede dar el sueño. Pero usando ThreadPoolExecutor en Python, he conseguido procesar unos 1.500 documentos por minuto. Para la mayoría de empresas, eso sobra para procesar todo el flujo de entrada en tiempo real.

• Métricas reales:
• Latencia: 38ms (vuela).
• Precisión: ~95% (el 5% restante suele ser lenguaje muy ambiguo que requiere ojo humano).

Conclusión

Automatizar esto no es solo por ahorrar costes, es por reacción. Si un sistema detecta un incumplimiento normativo en 40 milisegundos, puedes mitigar el riesgo antes de que se convierta en una multa millonaria.

¿Qué opináis? ¿Meteríais modelos más pesados tipo Transformer (BERT/LLMs) o creéis que para clasificación de riesgos este enfoque híbrido es más estable? Os leo en comentarios.