La carta abierta sobre la ciberdefensa colectiva establece una arquitectura de decisiones que muchos equipos de seguridad aún no han formalizado:
“Usa modelos capaces y de menor costo para una cobertura amplia, y aplica capacidades de vanguardia a los problemas más difíciles.”
Esto no es solo una recomendación de costos. Es una arquitectura de seguridad en sí misma: cobertura amplia con modelos rápidos y baratos, profundidad con modelos de frontera solo donde realmente hace falta. Esta guía te da un framework concreto para decidir qué tarea va en cada capa.
Por qué "usar el modelo más grande para todo" es un error de diseño
Correr el modelo más potente disponible en cada alerta que genera tu SIEM es lento, caro, y — contraintuitivamente — menos seguro: satura tu presupuesto y tu latencia justo cuando más necesitás velocidad de respuesta. La arquitectura correcta es un pipeline de triage por capas, similar a cómo un SOC humano escala de analista L1 a L3.
Nivel 1: Modelos económicos para triage masivo
Tareas que van acá: alto volumen, patrones conocidos, bajo riesgo de falso negativo costoso..
- Clasificación inicial de alertas (¿es ruido, falso positivo probable, o necesita revisión?).
- Normalización y enriquecimiento de logs.
- Detección de patrones conocidos de phishing (dominios similares, headers sospechosos).
- Resumen automático de tickets para el analista humano.
Características que buscar en el modelo para esta capa: latencia baja, costo por token bajo, buen desempeño en clasificación (no necesita razonamiento profundo).
Python
# Ejemplo simplificado: triage de alertas con modelo económico
def triage_alert(alert):
response = client.messages.create(
modelo="modelo de bajo costo",
max_tokens=200,
mensajes=[{
"papel": "usuario",
"contenido": f"Clasifica esta alerta como NOISE, REVIEW o CRITICAL. Alerta: {alerta}"
}]
)
devolver parse_classification(response)Nivel 2: Escalamiento condicional
Entre la capa económica y la de frontera necesitás una regla de decisión explícita, no "si tengo dudas". Ejemplos de triggers de escalamiento:
- La clasificación de capa 1 marco “ REVIEW” o “CRITICAL”.
- El activo involucrado está en tu lista de infraestructura esencial (definida en el post de auditoría de deuda técnica).
- El patrón no coincide con ninguna firma conocida (posible ataque novedoso).
- Hay indicios de que el ataque en sí usa IA generativa (ver más abajo).
Nivel 3: Modelos de frontera para los casos difíciles
Reservá el modelo más capaz para lo que realmente lo necesita:
- Análisis de malware novel o polimórficodonde se requiere razonamiento sobre comportamiento, no solo firma.
- Investigación de incidentes complejos con múltiples fuentes de evidencia para correlacionar.
- Red teaming y simulación de ataques asistidos por IA (ver la publicación dedicada sobre este tema).
- Generación de playbooks de respuesta para escenarios sin precedente en tu organización.
- Revisión de código generado por IA en componentes de alta criticidad (ver el post dedicado).
Diseño del pipeline completo
Alerta entrante
│
▼
[Capa 1: Modelo económico)] ── RUIDO ──► Archivar (con muestreo aleatorio para QA)
│
REVIEW / CRITICAL / patrón desconocido
│
▼
[Capa 2: Reglas de escalamiento] ── no cumple criterio ──► Analista humano L1
│
cumple criterio de escalamiento
│
▼
[Capa 3: Modelo de frontera] ──► Análisis profundo + recomendación
│
▼
Analista humano L2/L3 (decisión final, el modelo no ejecuta acciones automáticamente en casos críticos)Punto importante: en la capa 3, el modelo recomienda, no ejecuta de forma autónoma acciones irreversibles (aislar un host de producción, revocar credenciales masivamente). Ese es el rol del humano o de automatización con aprobación explícita — algo directamente relacionado con la trazabilidad de identidades agénticas que tratamos en otro post de esta serie.
Midiendo si la arquitectura funciona
- Costo por alerta procesada:debería bajar significativamente vs. usar frontera para todo.
- Tiempo hasta la contención: en casos críticos: no debería empeorar — la capa 3 debe activarse rápido cuando corresponde.
- Tasa de falsos negativos en el capa 1:auditar periódicamente con muestreo manual para confirmar que el modelo económico no está dejando pasar cosas que debieron escalar.
Checklist de implementación
- ☐ Mapear tus tareas de seguridad actuales en las 3 capas
- ☐ Definir reglas explícitas de escalamiento (no discrecionales)
- ☐ Implementar capa 1 con modelo económico para triage de alto volumen
- ☐ Reservar modelo de frontera solo para casos que cumplen criterio de escalamiento
- ☐ Asegurar que acciones irreversibles requieran aprobación humana o automatización auditada
- ☐ Medir costo, tiempo de contención y tasa de falsos negativos periódicamente
Parte de una serie sobre cómo poner en práctica los principios de Carta abierta de OpenAI sobre la defensa colectiva en ciberseguridad (Agosto de 2026). Volver a la guía completa.
