Un product manager sin experiencia en SOC gana BlueSec1 con un agente de IA para triaje

La competición BlueSec1 tiene un planteamiento sencillo: hay que construir un agente de IA que analice alertas en lugar de un analista de primera línea del SOC. Consta de cuatro fases. El autor del relato en Habr es un especialista de producto del área de gestión de vulnerabilidades y no analiza alertas en su trabajo. Su primer mensaje a su compañero de IA fue: «no entiendo el sentido de esto, explícamelo». Aun así, ganó la fase abierta. Después, según escribe, las puntuaciones se «anularon».

El texto de Habr está publicado como el relato de un participante. En el anuncio al que hemos tenido acceso no hay métricas de precisión, ni descripción de la arquitectura del agente, ni información sobre la composición del jurado. A continuación figura solo lo que se afirma en él y el contexto en el que se lee esta historia.

Qué problema se resuelve

La primera línea del SOC (security operations center) se encarga del triaje. El analista recibe una alerta de un SIEM, un EDR u otro sistema, revisa el contexto y decide: cerrarla como falso positivo, escalarla o solicitar más datos. Es un trabajo monótono, voluminoso y que escala mal con personas. Por eso es lo primero que se intenta delegar en agentes basados en LLM.

El formato de BlueSec1 comprueba hasta qué punto un agente puede desempeñar ese papel. El participante no solo tiene que conectar un modelo: debe describir cómo razona ante una alerta, qué datos solicita y cuándo se detiene.

Por qué la historia del autor es reveladora

El dato principal aquí no es el puesto en la tabla, sino el perfil del ganador de la fase abierta. Una persona sin experiencia en el análisis de alertas obtuvo un agente funcional porque usó la IA tanto como ejecutora como para que le explicara el ámbito. Su primera réplica, «explícame cuál es el sentido», fue el inicio del proceso: primero el modelo pone al autor al día y luego construyen la solución juntos.

Esto plantea una pregunta incómoda sobre qué mide exactamente la competición. Si un novato supera a los especialistas en la fase abierta, o bien las tareas de esa fase se formalizan bien y se prestan a los prompts, o bien la métrica no evalúa todo lo que importa en un SOC real. El propio autor insinúa el problema: tras el primer puesto, las puntuaciones se «anularon». Qué significa eso en la práctica (un recálculo, una puesta a cero o un cambio de metodología) no queda claro en el anuncio. Para responderlo hace falta el texto completo.

Qué se sabe a partir del anuncio

• Formato: competición BlueSec1 para crear un agente de IA para la primera línea del SOC.
• Estructura: cuatro fases.
• Tarea del agente: analizar alertas en lugar del analista L1.
• Autor: especialista de producto en gestión de vulnerabilidades, sin práctica en el análisis de alertas.
• Resultado: primer puesto en la fase abierta.
• Desarrollo posterior: las puntuaciones se «anularon»; los detalles están en el artículo completo.

Qué aplicar en la práctica

Para un equipo que esté pensando en usar IA en el SOC, esta historia deja tres lecciones útiles.

Primera: pilote el agente con alertas cuyo veredicto ya se conoce. Si el ganador de la fase abierta puede ser un novato, conviene comprobar también con los datos propios que el agente no se está ajustando a la respuesta esperada.

Segunda: fíjese en cómo está diseñada la evaluación. Un único ranking por alertas cerradas correctamente oculta el coste del error. Un incidente omitido y una escalada innecesaria cuestan cantidades muy distintas, y una métrica honesta los separa.

Tercera: use la IA para introducirse en el ámbito, como hizo el autor. Pida al modelo que explique cómo toma decisiones un analista y deje constancia de ello en las instrucciones del agente. Pero la lógica final de escalado debe aprobarla una persona del SOC.

El relato completo sobre las cuatro fases y lo que ocurrió con las puntuaciones puede leerse en el artículo original en Habr.