Cómo los Equipos de Ciberseguridad Construyen IA en Entornos Air-Gapped

Hay una ironía particular en cómo se despliegan la mayoría de las herramientas de IA: envían datos a la nube para procesarlos. Para la empresa promedio, esto es una compensación de privacidad que vale la pena. Para los equipos de ciberseguridad, no es una compensación en absoluto — es una condición descalificadora.

"La mayoría de las herramientas de IA procesan la inferencia en la nube, haciendo que los datos sean esencialmente públicos." Esa cita vino de una firma de ciberseguridad con la que hablamos durante nuestras llamadas de descubrimiento. Captura el problema con precisión. Los datos con los que trabajan los equipos de ciberseguridad — inteligencia de amenazas, informes de incidentes, topología de red interna, detalles de vulnerabilidades, analítica de comportamiento y registros de eventos de seguridad — son la categoría de datos más sensible en la mayoría de las organizaciones. Enviarlos a un servicio en la nube de terceros para ser procesados, incluso bajo un acuerdo de procesamiento de datos, anula el propósito de tenerlos asegurados en primer lugar.

Esta guía cubre cómo los equipos de ciberseguridad están construyendo IA en entornos donde los datos se quedan donde pertenecen.

Para Qué Necesitan IA los Equipos de Ciberseguridad

Antes de abordar las restricciones de infraestructura, es útil ser específico sobre los casos de uso de IA que están impulsando la demanda en operaciones de seguridad:

Triaje y clasificación de alertas: Los centros de operaciones de seguridad manejan miles de alertas por día. La gran mayoría son falsos positivos. Un modelo de clasificación bien entrenado que clasifique alertas por probabilidad de verdadero positivo — entrenado con los datos históricos de alertas propios de la organización — puede reducir dramáticamente la fatiga de los analistas y el tiempo medio de respuesta.

Detección de anomalías en logs: Los datos de flujo de red, registros de autenticación, telemetría de endpoints y registros de aplicaciones contienen las señales de movimiento lateral, escalación de privilegios y exfiltración de datos. La detección clásica basada en reglas pierde patrones novedosos. Los modelos de ML entrenados en comportamiento base pueden detectar anomalías estadísticas que las reglas nunca atraparían.

Extracción de inteligencia de amenazas: Los informes de amenazas no estructurados, post-mortems de incidentes y avisos de proveedores contienen indicadores de compromiso valiosos, técnicas de atacantes y sistemas afectados. Los modelos NER entrenados para extraer estas entidades en formatos estructurados aceleran significativamente la ingesta de inteligencia de amenazas.

Triaje de vulnerabilidades: Cuando aparece un nuevo CVE, los equipos de seguridad necesitan evaluar qué sistemas están afectados, cuál es la probabilidad de explotación en su entorno y cómo priorizar la remediación. Los modelos entrenados en el inventario de activos de la organización y datos históricos de vulnerabilidades pueden automatizar la capa inicial de triaje.

Generación de informes de incidentes: Los analistas de seguridad pasan tiempo significativo escribiendo informes de incidentes, post-mortems y resúmenes ejecutivos. Los modelos ajustados entrenados en incidentes históricos pueden generar borradores iniciales a partir de datos de eventos estructurados, con revisión del analista antes de la finalización.

Todos estos casos de uso requieren datos de entrenamiento derivados de los datos operacionales propios de la organización. Ninguno de esos datos puede salir del entorno.

La Restricción Air-Gapped en la Práctica

"Air-gapped" significa sin conectividad de red en tiempo de ejecución. No "auto-hospedado en tu propia cuenta de nube." No "Docker en tus servidores del data center con reglas de firewall." Físicamente desconectado de redes externas, o estrictamente aislado de red sin conectividad de internet de salida.

Esto crea requisitos específicos para cada componente del pipeline de preparación de datos de IA:

Análisis de documentos: Debe ejecutarse completamente local. Sin APIs de OCR en la nube (Google Document AI, Azure Document Intelligence, AWS Textract, todos envían datos). Requiere OCR integrado — Tesseract, Surya o similar — ejecutándose en hardware local.

Funciones asistidas por IA: Cualquier etiquetado asistido por ML, reconocimiento de entidades o puntuación de calidad debe usar modelos hospedados localmente. Esto significa archivos de modelo GGUF descargados al almacenamiento local antes del despliegue, ejecutándose vía Ollama o llama.cpp sin acceso a internet en tiempo de inferencia.

Puntuación de calidad: La deduplicación basada en embeddings y la puntuación de calidad semántica requieren modelos de embedding locales. Sentence-transformers funcionan bien en CPU para la mayoría de las tareas de embedding. Los archivos de modelo deben estar pre-descargados.

Exportación y transferencia: Los datos se mueven entre sistemas vía transferencia segura de archivos (unidades encriptadas, transferencia de red interna), nunca a través de servicios externos.

Actualizaciones: Las actualizaciones de software no se pueden enviar automáticamente. Las actualizaciones deben aplicarse manualmente después de revisión, lo que crea requisitos adicionales de mantenimiento pero también reduce la superficie de ataque.

El modo de falla más común al construir pipelines de IA air-gapped es descubrir a mitad del proyecto que un componente envía datos a casa. Muchas herramientas open-source envían telemetría, verifican actualizaciones o cargan modelos desde APIs externas sin hacerlo explícito. Cualquier herramienta usada en un pipeline air-gapped debe ser auditada para llamadas de red externas antes del despliegue.

Los Tipos de Datos y Sus Requisitos de Preparación

Registros de Eventos de Seguridad

El tipo de datos de mayor volumen en la mayoría de los entornos de seguridad. El formato es típicamente estructurado (CEF, LEEF, syslog, JSON) lo que hace el análisis sencillo. Los desafíos de preparación son:

Volumen: Los registros de seguridad son enormes. Una empresa mediana genera cientos de gigabytes de datos de registro por día. Los datos de entrenamiento necesitan ser muestreados, filtrados y etiquetados — no procesados en su totalidad.
Desequilibrio de etiquetas: Las alertas de verdadero positivo son raras (frecuentemente menos del 0.1% de los eventos). Entrenar un modelo de clasificación requiere estrategias de muestreo deliberadas para obtener suficientes ejemplos positivos, combinadas con generación de datos sintéticos para aumentar el conjunto de entrenamiento de la clase rara.
Contexto temporal: Muchos eventos de seguridad solo tienen significado en secuencia (una serie de intentos de inicio de sesión fallidos, luego uno exitoso desde una nueva ubicación). La preparación de datos de entrenamiento debe preservar el orden temporal y las ventanas de contexto alrededor de los eventos.

Documentos de Inteligencia de Amenazas

Informes no estructurados en formato PDF, Word o HTML. Requisitos de preparación:

Ingesta de documentos con análisis consciente de entidades (IOCs como direcciones IP, hashes, nombres de dominio, identificadores CVE deben preservarse exactamente, no corrompidos por normalización de OCR)
Anotación NER para etiquetar entidades con su tipo (dirección IP vs. dominio vs. hash de archivo vs. nombre de actor de amenaza vs. producto afectado)
Anotación de extracción de relaciones para casos de uso más avanzados (X explota Y; A está asociado con B)

Informes de Incidentes y Post-Mortems

Documentos internos que contienen descripciones técnicas detalladas de incidentes pasados. Estos son los documentos más sensibles en el entorno (describen cómo los atacantes han comprometido sistemas exitosamente) y los más valiosos para entrenamiento (contienen verdad fundamental sobre el comportamiento de atacantes en el entorno específico de la organización).

Requisitos de preparación:

Redacción cuidadosa de PII y sistemas sensibles (nombres de host, direcciones IP internas y nombres de sistemas que aparecen en informes de incidentes pueden necesitar ser anonimizados antes de usar en datos de entrenamiento compartidos más allá del equipo original de incidentes)
Extracción estructurada de atributos del incidente (técnicas MITRE ATT&CK, sistemas afectados, línea de tiempo, pasos de remediación)
Formato consistente para fine-tuning de modelos de resumen de incidentes

Datos de Vulnerabilidades

Datos estructurados de escáneres de vulnerabilidades (Nessus, Qualys, Rapid7) combinados con datos de inventario de activos. Requisitos de preparación:

Unir datos de activos con datos de vulnerabilidades mientras se elimina información identificadora de activos (nombres de host, IPs) antes del entrenamiento
Etiquetar vulnerabilidades históricas con su resultado real de explotación (explotada vs. no explotada en el entorno)

Construyendo el Pipeline: Etapa por Etapa

Ingesta

Todos los documentos pasan por un pipeline de análisis local. Para datos de registro estructurados, esto es conversión de formato directa. Para documentos no estructurados (PDFs, Word, informes de amenazas HTML), esto requiere OCR integrado y análisis de diseño ejecutándose completamente local.

El analizador debe manejar los formatos específicos comunes en entornos de seguridad: informes de amenazas PDF con diseños complejos, exportaciones de registro CSV/JSON, salidas de escaneo de vulnerabilidades XML e informes de incidentes Word.

Limpieza

La deduplicación es importante para datos de entrenamiento derivados de registros donde el mismo tipo de evento aparece miles de veces. La deduplicación semántica identifica eventos casi idénticos que crearían datos de entrenamiento con muy baja diversidad.

Redacción de PII e identificadores sensibles: decide desde el principio qué identificadores deben eliminarse (¿direcciones IP internas? ¿nombres de host? ¿nombres de usuario?) vs. preservarse (estos pueden ser las características que el modelo necesita aprender). Esta es una decisión de expertos de dominio que los ingenieros de ML no deberían tomar solos.

Etiquetado

La experiencia en dominio de seguridad es esencial para la calidad de la anotación. Un analista de seguridad que ha clasificado miles de alertas etiqueta ejemplos con mucha mejor precisión que un ingeniero de ML que ha leído la guía de etiquetado. Las herramientas deben ser accesibles para los analistas — sin configuración de Docker, sin interfaz de línea de comandos, sin entorno Python.

Tipos de anotación para IA de seguridad:

Clasificación de alertas (verdadero positivo / falso positivo / necesita investigación)
Etiquetado de tácticas y técnicas MITRE ATT&CK para eventos e informes
Etiquetado de entidades para NER de inteligencia de amenazas
Calificaciones de severidad para incidentes

Aumentación

La generación de datos sintéticos aborda la clase más rara y valiosa: alertas confirmadas de verdadero positivo. Usando un LLM hospedado localmente (Llama, Qwen, Gemma ejecutándose vía Ollama desde archivos GGUF pre-descargados), el módulo de aumentación genera ejemplos sintéticos plausibles de patrones de ataque no bien representados en datos históricos.

El LLM se ejecuta completamente local — sin llamadas a API, sin egreso de datos. Los controles de temperatura y diversidad aseguran que los ejemplos sintéticos sean lo suficientemente diversos para mejorar la generalización del modelo.

Exportación

Los datos de entrenamiento finalizados se exportan en el formato requerido por el trabajo de entrenamiento del modelo downstream: JSONL para fine-tuning de modelos de lenguaje, CSV para clasificadores de ML clásico, o JSON estructurado para datasets de tool-calling de agentes.

Requisitos de Herramientas para Entornos de Seguridad Air-Gapped

Cualquier herramienta usada en un pipeline de IA de seguridad air-gapped debe satisfacer:

Sin telemetría: Sin datos de uso enviados a casa, sin reporte de errores a servicios externos
Sin auto-actualización: Las actualizaciones deben requerir acción manual explícita
Modelos pre-descargables: Todos los archivos de modelo de IA (para análisis, NER, puntuación de calidad, aumentación) deben ser descargables antes del despliegue y utilizables sin internet en tiempo de ejecución
Sin fallback a la nube: Sin funciones que silenciosamente recurran a APIs en la nube cuando los modelos locales no estén disponibles
Dependencias auditables: Todas las bibliotecas de terceros deben ser auditables para llamadas de red inesperadas

Ertas Data Suite está construido para este caso de uso: aplicación de escritorio nativa, toda la inferencia de IA a través de LLMs hospedados localmente vía Ollama y llama.cpp, sin telemetría, sin verificaciones de actualización en tiempo de ejecución, y archivos de modelo GGUF pre-descargables.

Your data is the bottleneck — not your models.

Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.

Book a Discovery Call Learn about Ertas Data Suite →