Cómo evaluar las afirmaciones de los agentes SOC de IA: Solicite el registro de fallos.

Cómo evaluar las afirmaciones de los agentes SOC de IA: Solicite el registro de fallos.

Cada SOC de IA Las demostraciones de proveedores que he visto, incluida la nuestra, son excelentes. Se ejecutan con alertas predefinidas, integraciones funcionales y sin amenazas. La pregunta que distingue a las plataformas reales de las presentaciones genéricas no es "¿puede cerrar una alerta?", sino "¿en qué falló el trimestre pasado y cómo lo descubrió?".“

Los agentes SOC de IA prometen automatizar la capa de investigación; el trabajo de clasificación, enriquecimiento y veredicto, y la evaluación estructurada es la forma de verificar si esa automatización realmente funciona en su entorno. La guía de Gartner sobre este mercado comienza con una proyección que debería guiar toda evaluación: 701 TP3T de grandes SOC implementarán agentes de IA para el trabajo de Nivel 1/Nivel 2 para 2028, y solo 151 TP3T verán una mejora medible en sus operaciones de seguridad de la información sin una evaluación estructurada. La evaluación estructurada no es una tabla de puntuación de las respuestas del proveedor. Es un conjunto de requisitos de evidencia. Este es el conjunto que yo usaría.

1. Solicite el registro de errores.

Un sistema de IA de producción que realiza trabajo de investigación comete errores. Eso no es motivo de descalificación; los analistas humanos también cometen errores. Lo que sí es motivo de descalificación es un proveedor que no puede caracterizarlos.

Preguntar: ¿Cuál es su tasa medida de falsos negativos en alertas cerradas, cómo la mide y cuáles fueron sus últimos tres errores importantes? Un proveedor maduro realiza un control de calidad continuo, que incluye el muestreo de alertas cerradas por agentes para su revisión humana, el seguimiento de las tasas de revocación de veredictos y las pruebas de regresión del comportamiento del agente cuando cambian los modelos. Pueden responder con cifras. Un proveedor que responde con marketing de precisión ("precisión 99%") pero no puede describir la metodología de medición le está diciendo que no tiene una. En todas las evaluaciones que he realizado, los proveedores que no pueden proporcionar un registro de fallos o no miden o no quieren que usted lo sepa.

2. Solicitar investigaciones que se puedan reproducir

Para cada veredicto, debería poder ver: cada consulta que realizó el agente, cada resultado que obtuvo, el razonamiento en cada paso, el nivel de confianza al final y la acción tomada. No un párrafo de resumen; el registro completo, conservado inmutablemente.

Esto es importante por tres razones distintas:

1. Desde el punto de vista operativo, es la forma en que sus analistas calibran la confianza y detectan las desviaciones. 
2. Desde el punto de vista contractual, es la forma de exigir responsabilidades al proveedor por sus reclamaciones. 
3. Y, desde el punto de vista institucional, se trata de cómo se defiende una decisión automatizada a posteriori, ante un auditor, un regulador, una aseguradora cibernética o la propia junta directiva. 

Si opera bajo FedRAMP, En PCI, DORA o sus equivalentes sectoriales, un veredicto inexplicable es una conclusión inevitable. Gartner incluye la gobernanza y la explicabilidad como una de sus siete categorías de evaluación precisamente por este motivo: un agente que no puede articular un razonamiento auditable es una caja negra.

3. Hacer explícitos y técnicos los límites de la autonomía.

Obtenga la respuesta precisa a las siguientes preguntas: ¿qué acciones puede realizar este sistema sin intervención humana, dónde se aplica esta restricción y puedo configurarlo según el tipo de acción y el nivel de riesgo?

El punto de aplicación es el aspecto que la mayoría de las evaluaciones pasan por alto. “Se le indica al agente que no desactive las cuentas” es una sugerencia, no un control. Un control es una lógica de flujo de trabajo externa al modelo que imposibilita la acción sin una aprobación previa, actuando como un mecanismo de control determinista que limita el razonamiento probabilístico. El marco de Gartner insiste en esta misma distinción: ¿cómo se aplican los mecanismos de control para acciones de alto impacto, como la desactivación de cuentas o el aislamiento de la red, y el sistema recurre por defecto a la escalada, en lugar de a la acción, ante la ambigüedad?

El diseño de las medidas de seguridad cobra mayor importancia cuando el sistema gestiona una amenaza activa; es precisamente en esos momentos cuando los agentes están bajo mayor presión para actuar y tienen más probabilidades de cometer errores. Si un proveedor no puede mostrarle el mecanismo, no la política, sino el mecanismo, dé por hecho que no existe.

4. Pruebe la profundidad de integración, no la cantidad de integraciones.

Selecciona las cinco herramientas más importantes de tu conjunto de herramientas y prueba tres niveles para cada una: 

1. ¿Puede el agente leerlo? 
2. ¿Puede realizar consultas durante la investigación (obtener un árbol de procesos, buscar en los registros de identidad, examinar un buzón de correo)? 
3. ¿Puede actuar a través de él, sujeto a sus límites? 

Una página de integración con 300 logotipos suele quedar en modo de solo lectura en las herramientas que te interesan. Por eso, no te fíes de la cantidad de logotipos. Además, pregúntate sobre la arquitectura: ¿la plataforma requiere centralizar tus datos o puede consultar dónde se encuentran? Los costos y las implicaciones de la migración varían considerablemente.

5. Mide los resultados en comparación con tu línea de base, en tu entorno.

Define el éxito antes de que comience el POV, en tus alertas, comparándolo con tus cifras actuales. Las métricas en las que vale la pena basarse son:

1. Tiempo medio de contención (MTTC): La métrica de referencia recomendada por Gartner, porque la contención es donde se reduce el riesgo.
2. Reducción de falsos positivos: Llegar a los analistas, con precisión en la escalada (de qué se escala y cuánto se lo merece).
3. Tasa de falsos negativos muestreada: Tus analistas sénior revisan una muestra aleatoria de alertas cerradas por los agentes. Este es el paso que la mayoría de los equipos omite y el único que valida los cierres que de otro modo nunca revisarías.
4. Coste por alerta resuelta a la carga: Simula un día de alertas masivas. El precio por alerta y por token puede convertir un ataque en un evento de facturación.

Ejecútalo en un flujo de trabajo controlado y de alto volumen, ya sea para phishing o triaje de endpoints, durante 30 a 60 días. Las métricas de volumen, como "se investigaron 40 000 alertas", representan actividad, no resultados; considéralas como información de marketing. 

6. Evalúe al proveedor, no solo el producto.

Este mercado es joven, está saturado y en proceso de consolidación. Los resúmenes de Gartner para 2026 incluyen quince o más proveedores, muchos de ellos con menos de cinco años de antigüedad. Algunos serán adquiridos; otros desaparecerán. Gartner recomienda considerar la viabilidad de los proveedores como una cuestión de riesgo de terceros y optar por plazos de suscripción más cortos mientras el mercado evoluciona. Pregunte sobre el cumplimiento de las normas SOC 2 y FedRAMP, las políticas de manejo de datos y entrenamiento de modelos, y qué sucede con sus flujos de trabajo e historial de auditoría si el producto deja de funcionar.

El resumen incómodo

La mayoría de las evaluaciones de SOC de IA fracasan porque se estructuran como demostraciones más llamadas de referencia, los dos canales que los proveedores controlan mejor. Reestructure la suya en torno a evidencia que el proveedor no controla: sus alertas, su línea base, el análisis de casos cerrados realizado por sus analistas sénior y un registro de fallos que el proveedor posee o no.

Los proveedores que han desarrollado soluciones para producción lo recibirán con agrado. Quienes no lo han hecho lo considerarán innecesario. Esa reacción es, en sí misma, la evaluación más rápida que se puede realizar.