La llegada de ataques asistidos por inteligencia artificial está empujando a los equipos de seguridad a buscar algo más que un SIEM con un chatbot encima. En septiembre de 2026, varios proveedores han presentado servicios de SOC agéntico capaces de investigar señales, priorizar exposiciones y ejecutar acciones de contención con menos intervención manual. La cuestión práctica es otra: ¿cómo saber si una plataforma realmente aporta respuesta autónoma y no solo marketing?
Qué significa SOC agéntico y qué no significa
Un SOC tradicional centraliza registros, genera alertas y ayuda a los analistas a investigar incidentes. Un SOC agéntico añade agentes especializados que pueden encadenar tareas: enriquecer una alerta, consultar fuentes de inteligencia, reconstruir una línea temporal, proponer una hipótesis, abrir una acción de contención y dejar trazabilidad de cada paso.
La diferencia importante no está en que el sistema utilice un modelo de lenguaje, sino en el grado de autonomía y control. Un asistente que redacta un resumen no equivale a un agente que puede aislar un equipo, bloquear un dominio o revocar una sesión siguiendo políticas definidas.
- Copiloto: recomienda o resume, pero no actúa por sí mismo.
- Automatización clásica: ejecuta reglas fijas y predecibles.
- SOC agéntico: interpreta contexto, decide entre varias herramientas y ejecuta acciones dentro de límites autorizados.
La primera prueba: qué puede hacer sin intervención humana
Para evaluar una plataforma, pide un flujo de demostración completo y no una presentación de diapositivas. El escenario debe empezar con una señal ambigua y terminar con una acción medible.
- Detectar una anomalía en una cuenta o una aplicación.
- Relacionarla con otras señales de identidad, endpoint, red y nube.
- Explicar por qué la actividad parece maliciosa.
- Proponer una acción concreta y justificar su impacto.
- Ejecutar la acción dentro del perímetro permitido.
- Registrar quién autorizó, qué cambió y cómo revertirlo.
Si el proveedor solo enseña un chat que responde preguntas sobre logs, estás viendo una interfaz de consulta, no necesariamente un SOC agéntico.
Seis criterios para separar capacidades reales de marketing
1. Orquestación entre fuentes
Un agente útil debe poder consultar varias capas sin obligar al analista a copiar y pegar datos. Como mínimo, conviene comprobar si integra identidad, EDR, correo, DNS, nube, WAF y gestión de vulnerabilidades. La pregunta clave es si el agente mantiene el contexto al saltar de una fuente a otra.
2. Acciones reversibles
La autonomía sin reversión es un riesgo operativo. Exige que el sistema pueda deshacer un aislamiento, restaurar una regla o recuperar una configuración anterior. También debe ofrecer una vista previa cuando la acción tenga impacto amplio.
3. Políticas por nivel de riesgo
No todo incidente debe resolverse igual. Una plataforma madura permite que el agente actúe automáticamente ante señales de alta confianza, pero requiera aprobación para acciones destructivas o masivas. Esa matriz debe ser editable y auditable.
4. Evidencias, no solo conclusiones
El agente debe mostrar las evidencias que sustentan su hipótesis: procesos, usuarios, IP, tiempos, cambios de configuración y fuentes consultadas. Un veredicto sin pruebas es difícil de defender ante auditorías y fácil de cuestionar cuando aparece un falso positivo.
5. Gestión de errores y límites
Pregunta qué sucede cuando una API falla, un dato está incompleto o dos fuentes se contradicen. Los sistemas fiables tienen modos de degradación, reintentos, límites de tiempo y una ruta clara de escalado a un analista.
6. Evaluación con datos propios
La mejor prueba es un piloto con incidentes históricos anonimizados y algunos casos sintéticos. Mide tiempos, falsos positivos, porcentaje de acciones automáticas y número de pasos manuales que desaparecen.
Qué métricas conviene medir durante un piloto
| Métrica | Qué indica | Cómo interpretarla |
|---|---|---|
| MTTA | Tiempo hasta aceptar o clasificar una alerta | Debe bajar sin aumentar los falsos positivos |
| MTTR | Tiempo hasta contener y recuperar | Es la métrica más útil si el agente puede actuar |
| Acciones autónomas válidas | Porcentaje de acciones ejecutadas sin corrección humana | Más no siempre es mejor: importa la precisión |
| Tasa de reversión | Cuántas acciones deben deshacerse | Una cifra alta revela políticas demasiado agresivas |
| Cobertura de fuentes | Qué sistemas entran en la investigación | La telemetría aislada limita el valor del agente |
| Trazabilidad | Si cada decisión puede auditarse | Debe incluir entradas, herramientas y cambios |
Una arquitectura mínima para un SOC agéntico seguro
No hace falta sustituir todo el stack para empezar. Una arquitectura razonable separa cuatro capas:
- Telemetría: logs, eventos y señales de endpoint, identidad, red y nube.
- Razonamiento: agentes especializados para triaje, investigación y respuesta.
- Guardarraíles: políticas, permisos, límites de alcance y aprobaciones.
- Verificación: registros de auditoría, métricas y reversión.
La capa de razonamiento no debe tener acceso ilimitado. Es preferible conceder permisos estrechos por herramienta y por tipo de incidente. Si una integración permite ejecutar comandos o modificar reglas, esa capacidad debe estar separada de las funciones puramente analíticas.
Preguntas que debes hacer al proveedor
- ¿Qué acciones puede ejecutar el agente hoy y cuáles están todavía en roadmap?
- ¿Qué permisos necesita cada conector?
- ¿Cómo se registran las decisiones y qué datos se envían a los modelos?
- ¿Puede operar con modelos distintos o existe dependencia de un único proveedor?
- ¿Cómo se prueban las nuevas versiones antes de activarlas en producción?
- ¿Qué ocurre si el agente se equivoca o una integración deja de responder?
- ¿Se puede limitar por usuario, aplicación, segmento de red o tipo de activo?
Señales de alerta en una demo
Desconfía de las demostraciones que muestran únicamente un caso perfecto, no enseñan los permisos, omiten los falsos positivos o confunden una recomendación con una acción automática. También es una mala señal que el proveedor no pueda explicar qué modelo se utilizó, qué datos entraron en el razonamiento o cómo se audita la respuesta.
Otra señal problemática es la ausencia de un modo seguro. Un agente que no permite simulación, aprobación manual o rollback puede acelerar un incidente, pero también amplificarlo.
Cómo encaja con la seguridad que ya tienes
Un SOC agéntico no sustituye de golpe a un EDR, un WAF o una plataforma de identidad. Su valor suele estar en unir piezas que ya existen y reducir el tiempo de investigación y respuesta. En Bitzeta ya hemos explicado cómo Palo Alto Networks combina varios modelos para detectar exposiciones y cómo F5 acelera el parcheo virtual ante vulnerabilidades activas. Son enfoques distintos, pero comparten una idea: la velocidad solo sirve si la acción se apoya en señales fiables.
También conviene revisar el riesgo de las propias herramientas de IA. El caso de Gemini durante una prueba de ciberseguridad demuestra que un agente con acceso a Internet y una configuración incorrecta puede salir del perímetro previsto. Por eso, el diseño de permisos es tan importante como el modelo.
Conclusión
La pregunta no es si una plataforma utiliza IA, sino si puede investigar y contener incidentes con contexto, límites y trazabilidad. Para evaluar un SOC agéntico, exige una prueba con datos propios, mide MTTA y MTTR, revisa las acciones reversibles y comprueba que cada decisión deja evidencias auditables.
Si el producto solo resume alertas, probablemente estás ante un copiloto. Si puede coordinar fuentes, aplicar políticas y ejecutar acciones acotadas con rollback, entonces sí merece la pena estudiarlo como una capa de respuesta agéntica.
Preguntas frecuentes
¿Un SOC agéntico sustituye a los analistas?
No. Reduce tareas repetitivas y acelera la investigación, pero sigue necesitando supervisión humana para decisiones de alto impacto, casos ambiguos y revisión de políticas.
¿Es lo mismo que un SOAR?
No exactamente. Un SOAR ejecuta playbooks definidos. Un SOC agéntico puede seleccionar pasos, adaptar la investigación al contexto y combinar varias herramientas, aunque lo habitual es que ambos enfoques convivan.
¿Qué empresas deberían probarlo primero?
Las que ya tienen telemetría integrada, un volumen alto de alertas y procesos de respuesta relativamente maduros. Si faltan datos o permisos bien definidos, la autonomía añadirá complejidad antes que valor.
Deja una respuesta