SecRespond descubre que 23 modelos de IA de frontera no detectan intrusiones silenciosas
SecRespond llegó a Google News con un resultado contundente: ninguno de los 23 modelos de frontera completó la detección y remediación en ninguno de los hosts comprometidos evaluados. Los agentes gestionaron mucho mejor las alertas visibles que la evidencia silenciosa, lo que expone una brecha entre el triaje asistido por IA y la respuesta autónoma a incidentes.
Investigadores de Alibaba Group presentaron el artículo de SecRespond el 29 de julio de 2026. Evaluaron modelos de varias familias principales mediante OpenCode, un entorno de agentes que permite a los modelos inspeccionar archivos y utilizar herramientas de línea de comandos.
La prueba comienza después de que un atacante ya haya tenido éxito. Ese detalle genera el conflicto central del estudio. Los agentes de IA pueden seguir una alerta, pero un centro de operaciones de seguridad necesita investigadores que también encuentren amenazas que nadie haya señalado.
Por ello, SecRespond cuestiona una promesa habitual de la automatización. Un modelo que resume alertas puede reducir la carga de trabajo de los analistas, pero eso no lo convierte en un respondedor de incidentes independiente. El benchmark encontró la diferencia en artefactos de disco, mecanismos de persistencia, pasos de limpieza incompletos y planes de remediación sin verificar.
Qué cambió realmente el benchmark SecRespond
SecRespond desplaza el objetivo de evaluación de la interpretación de alertas a la investigación de una máquina ya comprometida.
Muchas pruebas de ciberseguridad comienzan antes del compromiso. Piden a un modelo identificar una vulnerabilidad, resolver un desafío capture-the-flag, clasificar malware o razonar sobre registros de seguridad seleccionados. Estas tareas miden capacidades útiles, pero reducen la incertidumbre que define una brecha real.
SecRespond comienza más tarde. Cada agente recibe una instantánea forense congelada del disco de un host en la nube comprometido. También recibe resultados sintéticos similares a alertas, análisis de vulnerabilidades y comprobaciones de referencia de seguridad de un producto de protección de hosts.
Una instantánea forense de disco es una copia preservada de los archivos y artefactos de un sistema en un momento concreto. Puede contener evidencia que las alertas nunca mencionaron, incluidos archivos de inicio modificados, cuentas con puertas traseras, registros borrados, tareas programadas o binarios maliciosos.
El agente debe inspeccionar ese material y reconstruir lo ocurrido. Después genera informes sobre intrusiones, vulnerabilidades, riesgos de referencia y remediación. La tarea también exige un archivo de progreso, creando un registro de la investigación en lugar de aceptar una única respuesta final pulida.
El benchmark contiene 10 cyber ranges, es decir, entornos aislados diseñados para reproducir incidentes de seguridad. Estos entornos cubren cuatro tipos de punto de entrada inicial, 21 técnicas del catálogo MITRE ATT&CK y cinco sistemas operativos.
Los investigadores tradujeron esos entornos en 52 elementos de capacidad y 280 puntos de control detallados. Los puntos de control preguntan si un agente encontró evidencia concreta, la atribuyó correctamente, recomendó una acción adecuada y cubrió la verificación necesaria.
La detección y la planificación de la remediación reciben puntuaciones separadas. La detección tiene un máximo de tres puntos por cada punto de control aplicable. La planificación tiene un máximo de dos, mientras que los puntos de control que no se aplican a una dimensión se excluyen de ese agregado.
Esta separación importa porque encontrar un archivo malicioso no responde qué deberían hacer los respondedores a continuación. Una respuesta segura puede requerir aislar un host, preservar evidencia, terminar procesos, eliminar la persistencia, rotar credenciales, bloquear infraestructura, restaurar servicios y verificar la recuperación.
El conjunto de datos público de SecRespond incluye las instrucciones de las tareas, los materiales de evaluación, las listas de verificación, resultados de seguridad sintéticos y archivos forenses. Su publicación hace que la afirmación central pueda ser comprobada por equipos más allá de los autores originales.
SecRespond también define un límite más estricto para la respuesta a incidentes mediante IA. Un agente no recibe crédito completo porque probablemente haya comprobado algo. Su informe debe indicar el hallazgo y citar evidencia que cumpla la lista de verificación pertinente.
Esta regla convierte el lenguaje de seguridad impreciso en rendimiento medible. “Investigar actividad sospechosa” no equivale a identificar un proceso, archivo, cuenta, endpoint o ruta de persistencia concretos. “Aplicar parches al servidor” no equivale a un plan de recuperación completo, secuenciado y verificado.
La cobertura de Google News se centró en el fracaso principal de los 23 modelos. El cambio más profundo es metodológico. SecRespond pregunta si un agente puede seguir pistas que nunca se le entregaron y luego conectar esos descubrimientos con un proceso de limpieza defendible.
Por qué la atención de Google News importa para los compradores de seguridad de IA
El benchmark presiona a proveedores y líderes de seguridad para que distingan la asistencia con alertas de la respuesta autónoma a incidentes.
La IA ya ayuda a los centros de operaciones de seguridad a resumir alertas, enriquecer indicadores, buscar documentación, redactar consultas y preparar notas de casos. Estos flujos de trabajo siguen siendo valiosos porque los analistas suelen enfrentarse a evidencia fragmentada y trabajo administrativo repetitivo.
Sin embargo, SecRespond mide un nivel superior de independencia. Un respondedor autónomo debe decidir dónde investigar, reconocer evidencia faltante, poner a prueba explicaciones alternativas y continuar después de que se haya resuelto la alerta más evidente.
El resultado central del benchmark muestra por qué importa esta distinción. Entre los 23 modelos evaluados, ningún agente logró una detección y remediación completas ni siquiera en un cyber range.
El mejor modelo general del experimento informado fue Claude Opus 4.7. Alcanzó una puntuación media de puntos de control a nivel de rango del 79,0 por ciento en detección y del 65,7 por ciento en planificación.
El artículo también informa un promedio del 72,4 por ciento al combinar esas dimensiones para el modelo líder. Ese rendimiento aún dejó artefactos maliciosos sin tocar y una remediación incompleta, especialmente en rangos con cadenas de ataque más largas y amplias.
Otros resultados destacados incluyeron Claude Opus 4.6, con un 78,2 por ciento en detección y un 58,0 por ciento en planificación. GLM-5.1 alcanzó un 76,3 por ciento y un 59,2 por ciento, mientras que Qwen3.7 Plus alcanzó un 75,6 por ciento y un 58,8 por ciento.
Estas cifras no deberían convertirse en una clasificación general de los modelos subyacentes. Describen un entorno de agentes, una versión del benchmark, un diseño de tareas y un proceso de evaluación específicos.
En cambio, los resultados exponen un patrón de fallos compartido. Los modelos encontraron evidencia relacionada con alertas existentes de forma más fiable que evidencia que requería una búsqueda no solicitada en el disco.
Este patrón presiona a los proveedores de seguridad que emplean etiquetas amplias como “analista de IA” o “SOC autónomo”. Los compradores deben preguntar qué partes del ciclo de vida de la respuesta realiza realmente el sistema sin una pista creada por un humano.
Un producto puede resumir con precisión una alerta de endpoint y, aun así, pasar por alto un segundo mecanismo de persistencia. Puede recomendar eliminar un binario malicioso sin terminar su proceso, retirar su cargador, rotar las credenciales expuestas o verificar la recuperación del servicio.
Cada paso omitido cambia el resultado operativo. Un atacante puede regresar mediante una cuenta, tarea programada, webshell, servicio, entrada de registro o gancho de shell que no se haya tratado. Por tanto, una primera acción técnicamente correcta puede crear una falsa sensación de contención.
Los líderes de seguridad también deben separar la calidad de la investigación de la calidad del informe. Los modelos suelen producir explicaciones fluidas, pero SecRespond evalúa si esas explicaciones contienen la evidencia y los detalles de remediación requeridos.
Este es un problema conocido en el trabajo intensivo en conocimiento. Una narrativa segura puede ocultar una recuperación incompleta. Los equipos que crean una base de conocimiento consultable afrontan una exigencia relacionada: las conclusiones deben seguir siendo rastreables hasta el material de origen.
El benchmark vuelve concreta esa trazabilidad para la respuesta a incidentes. Un agente debe mostrar qué artefacto respalda cada conclusión y qué acción aborda cada condición identificada.
La visibilidad en Google News puede llevar esta distinción más allá de los investigadores de benchmarks. Los equipos de compras, CISOs, proveedores de seguridad gestionada y grupos de auditoría interna tienen ahora un ejemplo público de por qué “gestiona alertas” y “gestiona incidentes” no son afirmaciones equivalentes.
El verdadero punto ciego es la investigación sin guía
El comportamiento más débil de los modelos aparece cuando un incidente no deja una alerta evidente que apunte al siguiente artefacto.
SecRespond agrupa el rendimiento en cinco áreas de capacidad. Estas cubren entidades de intrusión, mecanismos de persistencia, riesgos de referencia, riesgos de vulnerabilidades y la calidad general de la investigación y la respuesta.
Una entidad de intrusión es un objeto malicioso concreto, como un proceso, archivo, endpoint de red o artefacto manipulado. Los modelos rindieron mejor en esta categoría porque estos objetos a menudo se alineaban con señales de seguridad visibles.
Entre los modelos, la detección media alcanzó el 75,4 por ciento para entidades de intrusión. Varios sistemas líderes rindieron considerablemente mejor, entre ellos Qwen3.7 Plus con un 88,4 por ciento y Claude Opus 4.6 con un 86,0 por ciento.
Los mecanismos de persistencia produjeron un resultado distinto. La persistencia se refiere a cambios que permiten que el acceso del atacante sobreviva a un reinicio o a una limpieza inicial. Los ejemplos incluyen tareas programadas, servicios, ganchos de inicio de shell, webshells, puertas traseras de cuentas y suscripciones de Windows Management Instrumentation.
La detección media cayó al 58,8 por ciento para la persistencia. La caída importa porque la persistencia es precisamente lo que los respondedores deben encontrar antes de declarar limpio un host.
El benchmark no demuestra que los modelos carezcan de todo razonamiento forense. Pueden conectar una alerta con un proceso o archivo relevante y a menudo describen correctamente la amenaza inmediata. El fallo aparece cuando la investigación debe ampliarse más allá de ese punto de partida.
Pensemos en un servidor web comprometido. Una alerta podría identificar un proceso malicioso o una conexión saliente. Seguir esa señal puede revelar un ejecutable, pero una investigación completa debe preguntar cómo entró el atacante, qué credenciales quedaron expuestas y qué sobrevive a la terminación.
El respondedor también puede necesitar inspeccionar scripts de inicio, definiciones de servicios, entradas de cron, cuentas de usuario, historiales de comandos, directorios de aplicaciones y registros alterados. Ninguna alerta individual identifica necesariamente esas ubicaciones.
Esto crea un problema de búsqueda con límites inciertos. El agente debe decidir qué hipótesis merecen probarse y durante cuánto tiempo continuar. Debe reconocer que la ausencia de un artefacto no elimina otras rutas de persistencia.
Los agentes actuales basados en modelos de lenguaje a menudo se optimizan en torno a la evidencia ya presente en el contexto. Las alertas crean anclajes de alta relevancia, por lo que el agente puede dedicar su presupuesto a explicar esos anclajes en lugar de buscar evidencia no mencionada.
Las cadenas de ataque más largas amplifican esa debilidad. Cada técnica adicional introduce otra rama, tipo de artefacto, marca de tiempo, cuenta o servicio que el modelo debe correlacionar.
El artículo descubrió que el rendimiento disminuía a medida que los ataques se volvían más largos y amplios. Ese resultado encaja con el desafío operativo: la respuesta a incidentes no es una única decisión de clasificación, sino una secuencia de juicios vinculados bajo información incompleta.
Un benchmark de threat hunting de 2026 informó de un problema relacionado. Cinco modelos de frontera buscaron en registros sin procesar de eventos de Windows de 26 campañas de ataque, y el mejor modelo encontró solo una pequeña fracción de los eventos maliciosos.
Los dos estudios evalúan flujos de trabajo distintos, por lo que sus puntuaciones no son directamente comparables. Sin embargo, ambos sugieren que la búsqueda sin guía sigue siendo más difícil que el razonamiento sobre evidencia preseleccionada.
Esta es la inversión central del benchmark. Los agentes parecen más capaces allí donde las herramientas de seguridad convencionales ya han reducido la incertidumbre. Se vuelven menos fiables allí donde los investigadores humanos aportan más valor al cuestionar lo que la alerta no reveló.
Un equipo de seguridad aún puede usar la IA de forma productiva dentro de este límite. El modelo puede resumir evidencia, proponer hipótesis, redactar consultas, comparar artefactos y mantener una cronología de la investigación.
El salto inseguro consiste en tratar esas capacidades como prueba de que el modelo ha investigado todo el incidente. SecRespond muestra que una respuesta bien articulada puede coexistir con persistencia no descubierta y una explicación incompleta de la actividad del atacante.
Las puntuaciones de detección ocultan una brecha mayor en la remediación
Encontrar más evidencia no se tradujo en planes de limpieza igualmente completos, lo que convierte la remediación en el segundo gran fallo del benchmark.
Todos los modelos evaluados obtuvieron una puntuación más alta en detección que en planificación. Para GPT-5.5, la brecha reportada alcanzó los 34,7 puntos porcentuales.
Los investigadores atribuyen este patrón a que los agentes aplican una primera corrección evidente mientras omiten las acciones restantes. Este comportamiento se parece al truncamiento de listas de verificación: una vez que el objeto malicioso central recibe una respuesta, el modelo actúa como si el incidente estuviera resuelto.
La remediación real rara vez termina con una sola eliminación o cambio de configuración. Un responsable de respuesta debe considerar dependencias, preservación de evidencia, impacto empresarial, continuidad del servicio, exposición de credenciales y las rutas alternativas de acceso del atacante.
La puntuación de planificación de SecRespond pregunta si una acción es correcta y completa. También examina la verificación y los efectos secundarios cuando el punto de control pertinente así lo requiere.
La verificación no es un trámite. Un plan para eliminar una tarea programada debe confirmar que la tarea ya no existe y que su carga útil no puede iniciarse mediante otro mecanismo.
Un plan para bloquear la dirección de un atacante debe abordar tanto el tráfico entrante como el saliente cuando corresponda. También debe evitar dar a entender que bloquear una dirección elimina el malware, las credenciales robadas o la persistencia ya presente en el host.
Los problemas de configuración estandarizados resultaron más sencillos. Claude Opus 4.7 alcanzó el 74,8 por ciento en planificación para riesgos de referencia y el 72,6 por ciento para riesgos de vulnerabilidades.
Estas tareas suelen corresponder a acciones conocidas, como reforzar una configuración o actualizar el software afectado. El agente puede recuperar un patrón de remediación reconocible y aplicarlo al hallazgo.
La calidad de la investigación y la respuesta siguió siendo mucho menor. El rendimiento medio de planificación en esa categoría alcanzó solo el 31,8 por ciento.
Esta categoría abarca trabajo que depende de la síntesis, en lugar de una única corrección conocida. Incluye la reconstrucción de la cadena de ataque, la calidad de la evidencia, la honestidad respecto a la incertidumbre, la exhaustividad, la verificación y la conciencia del impacto operativo.
El mejor resultado de detección en esa categoría alcanzó el 75,5 por ciento. Casi todos los modelos se mantuvieron por debajo del 50 por ciento en planificación, según el artículo.
Estos resultados cuestionan una estrategia simple de escalado. Dar a un modelo más alertas no crea automáticamente un plan de respuesta completo. Más hallazgos visibles pueden, en cambio, generar más recomendaciones inconexas.
Un plan creíble necesita una secuencia. Los equipos pueden aislar una máquina antes de modificarla, preservar evidencia volátil antes de terminar procesos y rotar credenciales después de determinar el alcance de la exposición.
También necesitan considerar la reversión y el servicio. Eliminar un componente comprometido sin comprender sus dependencias puede interrumpir la producción o destruir evidencia necesaria para la atribución.
SecRespond evalúa planes escritos, no remediación en vivo sobre sistemas de producción. Esto limita lo que el benchmark puede establecer, pero también mantiene visible la cuestión de la seguridad.
Si un modelo no puede describir de forma consistente una remediación completa y verificada en un entorno controlado, las organizaciones tienen pocos fundamentos para concederle autoridad sin restricciones sobre un host activo.
Por ello, el benchmark respalda un modelo operativo más limitado. La IA puede sugerir acciones, organizar evidencia y señalar campos ausentes, mientras que los responsables humanos conservan la aprobación de los pasos de contención y recuperación.
Este enfoque no es un rechazo de la automatización del SOC. Es una respuesta a la asimetría específica de los datos. Los sistemas eran mejores para identificar objetos conocidos que para garantizar que cada consecuencia recibiera un tratamiento seguro.
Los equipos de seguridad deberían reflejar esa asimetría en los controles de acceso. El acceso forense de solo lectura implica un riesgo distinto al permiso para terminar procesos, eliminar archivos, deshabilitar cuentas o modificar políticas de red.
Un agente que pasa por alto un artefacto oculto produce un informe incompleto. Un agente que actúa basándose en ese informe incompleto puede interrumpir la recuperación mientras deja intacta la ruta alternativa del atacante.
Lo que las cifras no demuestran
SecRespond es una evidencia sólida de una limitación compartida, pero no es un veredicto definitivo sobre todos los modelos ni sobre cada configuración de SOC en producción.
El artículo es una prepublicación de arXiv, no el resultado de una revisión por pares concluida. Entre sus autores hay investigadores de Tongyi Lab y Alibaba Cloud, y el benchmark evalúa modelos mediante un entorno de prueba representativo.
La elección de OpenCode ayuda a estandarizar el uso de herramientas entre sistemas. También significa que los resultados miden una combinación de modelo y entorno de prueba, no una capacidad abstracta del modelo desligada de los prompts, las herramientas, la gestión de contexto y la política de ejecución.
Una infraestructura diferente puede cambiar el rendimiento. Un agente de respuesta a incidentes podría usar una lista de verificación obligatoria para la investigación, utilidades forenses especializadas, recuperación sobre procedimientos internos, varios agentes cooperantes o scripts de validación deterministas.
SecRespond sigue siendo útil porque esas mejoras pueden probarse frente a los mismos escenarios. Sin embargo, las cifras publicadas no deben tratarse como límites permanentes para cada familia de modelos.
La evaluación también utiliza un proceso de LLM como juez, lo que significa que modelos de lenguaje califican los informes generados frente a listas de verificación detalladas. Se utilizaron de forma independiente tres jueces propietarios para reducir la dependencia de un único evaluador.
Esos jueces fueron Claude Opus 4.7, Gemini 3.1 Pro y GPT-5.4 Pro. Varios jueces reducen el sesgo individual, pero no eliminan todos los problemas de calibración.
Un evaluador podría interpretar una redacción incompleta de manera distinta a un especialista forense humano. También podría premiar un lenguaje explícito en el informe sin resolver por completo si el proceso de investigación subyacente fue sólido.
Las instrucciones de puntuación intentan controlar ese riesgo. Los jueces deben citar evidencia y conceder crédito únicamente por contenido presente de forma explícita en los informes.
Los 280 puntos de control del benchmark aportan estructura adicional. Sin embargo, toda lista de verificación incorpora decisiones sobre qué artefactos, pasos de respuesta y cualidades merecen mayor peso.
Los 10 escenarios son lo bastante diversos como para revelar comportamientos repetidos. No cubren todos los sistemas operativos, arquitecturas cloud, plataformas de identidad, productos de endpoint ni técnicas de ataque.
Los entornos también están controlados. Los investigadores aprovisionaron y comprometieron los hosts para el benchmark, y luego depuraron las credenciales y los datos personales.
Este diseño permite la reproducibilidad y evita exponer información de producción. No puede reproducir por completo el ruido, la telemetría incompleta, las restricciones organizativas y las dependencias empresariales de un incidente real en una empresa.
Un resultado también ilustra cómo el comportamiento de seguridad puede afectar a la cobertura del benchmark. Claude Opus 4.7 rechazó la tarea npm-worm, por lo que el artículo omitió ese modelo de la tabla detallada de puntos de control del escenario.
Una negativa puede reducir la utilidad operativa durante una investigación defensiva legítima. También puede reflejar el esfuerzo de un proveedor por impedir que la asistencia de doble uso derive hacia orientación perjudicial.
SecRespond no resuelve esa disyuntiva de política. Muestra que un despliegue seguro necesita definiciones de tareas que distingan el trabajo forense autorizado de las instrucciones ofensivas.
Los autores del benchmark afirman que la evidencia publicada procede de entornos aislados y no contiene cadenas de explotación ejecutables. Los materiales públicos están destinados a la investigación defensiva.
Esta restricción importa al interpretar las afirmaciones sobre la respuesta en el “mundo real”. Los escenarios recrean compromisos de extremo a extremo sobre protocolos de red reales, pero el paquete publicado contiene evidencia forense depurada en lugar de herramientas de ataque activas.
Tampoco existe un estudio de campo independiente que muestre cómo las puntuaciones de SecRespond se traducen en tiempo de analista ahorrado, reducción de la gravedad de los incidentes o mejora de la velocidad de contención. Esos resultados requieren evaluaciones dentro de equipos operativos.
Para los compradores, la lectura correcta debe ser mesurada. El benchmark cuestiona con fuerza las afirmaciones sin respaldo sobre respuesta autónoma a incidentes. No demuestra que la asistencia de IA carezca de valor dentro de un SOC liderado por humanos.
Tampoco establece que un modelo concreto vaya a mantenerse por delante en versiones futuras. La serie Claude reportada mejoró entre lanzamientos, mientras que el progreso entre otras familias no fue universal.
La unidad de evaluación significativa es el sistema desplegado. Esto incluye el modelo, las herramientas, los prompts, los permisos, las fuentes de recuperación, las puertas de revisión, los registros y los procedimientos de recuperación.
Tres señales que vigilar tras el ciclo de Google News de SecRespond
La próxima prueba será si los proveedores mejoran el descubrimiento sin guía, la verificación de la remediación y la evaluación reproducible en producción.
La primera señal es la reproducción independiente. Investigadores y proveedores de seguridad pueden ejecutar el repositorio del benchmark público con otros entornos de prueba, prompts, herramientas y versiones de modelos.
La reproducción mostrará si la brecha de las intrusiones silenciosas sobrevive a los cambios en la infraestructura. Si los agentes forenses especializados siguen sin detectar persistencia sin alertas, el juicio central del artículo se refuerza.
Si los procedimientos de búsqueda deterministas producen grandes mejoras, la lección cambia ligeramente. El cuello de botella estaría menos en el conocimiento del modelo y más en el diseño de la investigación, el enrutamiento de herramientas y la cobertura obligatoria.
Eso seguiría debilitando las afirmaciones sobre agentes autónomos de propósito general. También proporcionaría una ruta de ingeniería más clara para sistemas más seguros.
La segunda señal es si los proveedores publican resultados separados de detección y remediación. Una sola cifra de “precisión de respuesta a incidentes” puede ocultar la brecha de planificación que SecRespond reveló.
Las evaluaciones útiles deberían indicar qué encontró el sistema, qué pasó por alto, qué acción propuso y cómo verificó su finalización. También deberían informar sobre negativas, fallos de herramientas y casos que requirieron intervención humana.
Preste atención a las pruebas sobre mecanismos de persistencia específicamente. Las mejoras en malware vinculado a alertas importan, pero no abordan el principal punto ciego del benchmark.
Observe también si los planes cubren la amplitud de la limpieza. Un agente más sólido debería gestionar procesos, archivos, cuentas, ejecución programada, controles de red, rotación de credenciales, recuperación de servicios y validación posterior a la remediación cuando corresponda.
La tercera señal es la evidencia de despliegues supervisados en SOC. Los proveedores deben mostrar cómo rinden sus agentes con telemetría real, procedimientos internos, controles de acceso y puertas de aprobación de analistas.
La evidencia operativa más sólida no será solo un caso de estudio pulido. Incluirá tasas de omisión, tasas de escalamiento, afirmaciones sin respaldo, frecuencia de correcciones y el porcentaje de recomendaciones que los analistas aprueban sin cambios.
Un despliegue creíble debe conservar un registro de auditoría. Los revisores necesitan rastrear las conclusiones hasta los artefactos y determinar qué búsquedas completó el agente antes de detenerse.
Las organizaciones también deberían probar los límites de permisos. La investigación de solo lectura, las acciones recomendadas y la ejecución autónoma representan tres niveles de riesgo distintos.
SecRespond respalda la adopción en los dos primeros niveles, al tiempo que impone una elevada carga de prueba sobre el tercero. Sus resultados no justifican entregar amplios poderes de contención a un modelo que no ha demostrado un descubrimiento exhaustivo.
El titular de Google News se desvanecerá, pero el benchmark deja a los equipos de seguridad con una pregunta de compra duradera: ¿qué encuentra el agente cuando ninguna alerta le indica dónde buscar?
Pida a los proveedores que respondan a esa pregunta con evidencia reproducible. Después, pregunte cómo verifica el sistema cada paso de limpieza y cómo comunica la incertidumbre a un operador humano.
Las respuestas revelarán si los productos de AI SOC están evolucionando hacia investigadores o si siguen siendo asistentes rápidos que operan en torno a detecciones existentes. Por ahora, SecRespond sitúa a los 23 modelos evaluados del lado asistente de esa línea.
