Agentes SOC de IA frente a SOAR: ¿Qué cambió realmente?

Agentes SOC de IA frente a SOAR: ¿Qué cambió realmente?

Durante los últimos dos años, dos afirmaciones han dominado el marketing de operaciones de seguridad (SecOps), y se contradicen entre sí. 

• La primera: SOAR ha muerto y los agentes SOC de IA lo reemplazan. 
• La segunda: los agentes SOC de IA son simplemente SOAR con un modelo de lenguaje añadido. 

Ambas posturas son erróneas, y la diferencia entre ellas es donde se gasta mal gran parte del presupuesto de evaluación. 

El ciclo de sobreexpectación de Gartner para 2024 situó a SOAR en la fase de "obsoleto antes de alcanzar su punto máximo", lo que justificó la primera afirmación. Sin embargo, la estructura de mercado de una categoría y las necesidades de sus clientes son dos cosas distintas, y solo una de ellas desapareció. El resto de este blog analiza lo que respalda la evidencia, narrando la historia de lo que hizo SOAR, qué cambios experimentó, qué no cambió y hacia dónde convergen las implementaciones de producción con arquitectura de dos capas.

Lo que el mercado acertó sobre la caída de SOAR 

SOAR hizo una cosa excepcionalmente bien: codificó procedimientos conocidos en flujos de trabajo ejecutables. Si anotas cómo tu equipo gestiona un correo electrónico de phishing reportado (analizarlo, eliminar archivos adjuntos, verificar la URL, buscar otros destinatarios, ponerlo en cuarentena, notificar), SOAR ejecuta ese procedimiento de forma idéntica, a velocidad de máquina, diez mil veces al día, con un registro de cada paso.

Sus virtudes eran el determinismo, la repetibilidad y la auditabilidad. La misma entrada producía el mismo resultado. Se podía mostrar a un auditor exactamente qué se ejecutó y por qué.

Sus limitaciones radicaban en la otra cara de la moneda. Los manuales de procedimientos solo contemplaban las situaciones que sus autores habían previsto. Su creación y mantenimiento requerían un esfuerzo de ingeniería y un flujo de datos estructurado que la mayoría de los equipos subestimaban. La crítica de Gartner se centró en esa carga de mantenimiento, además de la consolidación del mercado y el coste. Y un manual de procedimientos no podía ejercer criterio propio. Ante la ambigüedad, solo se ramificaba en función de las condiciones previamente definidas. 

Esto generó una división de la carga de trabajo que cualquiera que haya asistido a una revisión de herramientas de SOC reconocerá. Los equipos automatizaron la parte predecible y repetible de su volumen de alertas y se vieron abrumados por el resto ambiguo, las alertas que requerían que un analista las revisara, reflexionara y decidiera. Los manuales de procedimientos gestionaron el volumen. El proceso de investigación siguió siendo humano.

¿Qué agentes? de hecho cambió 

Los agentes SOC de IA abordan las alertas restantes con un enfoque fundamentalmente distinto al de SOAR, sin realizar cambios incrementales. Un agente no sigue una ruta predefinida; crea la suya propia. Lee la alerta, decide qué evidencia la confirmaría o refutaría, consulta los sistemas para obtener dicha evidencia, realiza revisiones a medida que se obtienen los resultados y emite un veredicto con una justificación escrita. 

Los manuales de procedimientos codifican el procedimiento. Los agentes realizan un juicio aproximado.

Se trata de un cambio real de capacidad, no de un simple cambio de marca. La automatización determinista no podía investigar de forma estructural alertas novedosas y ambiguas. Ahora es parcialmente posible. El argumento de que basta con usar SOAR con un LLM no se sostiene al comprobar su funcionamiento en un entorno real.

¿Qué agentes no cambiaron?

El juicio implica un intercambio. Los agentes actúan de forma probabilística. Si se realiza la misma investigación dos veces, se pueden obtener resultados diferentes y, ocasionalmente, conclusiones distintas. Pueden estar completamente equivocados.

Un bucle de razonamiento LLM tampoco es la herramienta adecuada para un trabajo que ya era determinista. Ningún responsable de seguridad quiere un modelo que improvise una secuencia de contención, un paso de preservación de pruebas o una cadena de notificación a los reguladores. Estos procesos deben ejecutarse con exactitud, siempre y con pruebas.

Por eso falla la narrativa de reemplazo. La ejecución determinista, el proceso estricto, la infraestructura de integración y la auditoría no dejaron de ser necesarios. Se volvieron aún más necesarios, porque ahora un sistema probabilístico se encuentra dentro del ciclo y necesita precisamente esas propiedades.

Hacia dónde convergen las implementaciones de SOAR y SOC de IA 

En la producción, ambas capacidades se combinan en capas.

• Capa 1, razonamiento del agente: Triaje, investigación, veredicto, recomendación. El punto medio ambiguo.
• Capa 2, ejecución determinista: Se especifican las acciones permitidas en cada nivel de autonomía, qué requiere aprobación humana, cómo se ejecuta la contención, qué se registra y qué sucede cuando disminuye la confianza del agente. La guía de evaluación de Gartner para 2026 apunta en la misma dirección, recomendando el cumplimiento de las medidas de seguridad en acciones de alto impacto y la escalada como opción predeterminada en situaciones de ambigüedad.

Podríamos llamarlo agentes con mecanismos de control. La capa de razonamiento es probabilística; la capa de permisos y ejecución no lo es. Los equipos que implementan agentes sin la segunda capa confían en la autolimitación del modelo, y una solicitud no constituye un control. Los equipos que se mantienen fieles al enfoque SOAR siguen pagando a analistas para realizar un análisis inicial que ahora las máquinas pueden gestionar.

¿Qué implica esto para la evaluación de la automatización del SOC? 

La cuestión de la arquitectura del SOC de IA se convierte en cuatro preguntas de compra, y estas segmentan el mercado más rápido que cualquier matriz de características:

1. ¿Es posible rastrear el veredicto de un agente hasta las pruebas que consultó y reproducir ese rastro para un auditor?
2. ¿Dónde residen los permisos de acción: en el mensaje o en una capa de política aplicada fuera del modelo?
3. ¿Qué ocurre cuando la confianza es baja y quién establece ese umbral?
4. ¿La capa de ejecución determinista del proveedor era anterior a la IA, o llegó como una capa adicional posteriormente?

Esa última pregunta es la que los compradores suelen pasar por alto. Los proveedores que consideran la orquestación como algo obsoleto terminan ofreciendo agentes que no se pueden auditar. Los proveedores que consideran los agentes como un complemento ofrecen un botón de resumen. En Swimlane, seguimos invirtiendo en la capa de ejecución en lugar de reemplazarla, porque sabemos que la autonomía gobernable requiere ambas y que la parte determinista es mucho más difícil de adaptar.

En resumen: ¿qué pasó con el mercado SOAR? 

El mercado de SOAR independiente desapareció, absorbido por plataformas más amplias, tal como lo describió Gartner. La disciplina, sin embargo, se mantuvo. La orquestación, la ejecución determinista y la auditoría se convirtieron en la base que permite gestionar la autonomía de los agentes.

Lo que cambió fue la división del trabajo. Las máquinas toman la decisión inicial y los humanos las controlan. El sistema que implementa este control rara vez se somete a la demostración y es el que decide si todo esto sobrevive al contacto con el auditor.