Los sistemas de IA ya recomiendan acciones técnicamente correctas que pueden detener producción o violar regulaciones — el criterio para darles autonomía no es qué tan seguros están de la amenaza
Los equipos de seguridad enfrentan un problema nuevo: las recomendaciones de IA son cada vez más sólidas desde el punto de vista técnico, pero carecen del contexto operativo que determina si ejecutarlas es la decisión correcta. Un modelo puede identificar una vulnerabilidad crítica con exploit público y sugerir un parche inmediato — técnicamente impecable — sin saber que el sistema afectado es un controlador de línea de producción o un dispositivo médico bajo certificación de fabricante, donde un reinicio no programado detiene operaciones o genera incumplimientos regulatorios. La pregunta para los CISO ya no es si la IA puede analizar amenazas con precisión, sino cuánta autonomía darle para actuar sobre esas recomendaciones cuando el contexto que falta puede cambiar por completo la decisión.
Cuando el análisis correcto lleva a la acción equivocada
Un caso documentado ilustra el problema: una cuenta de servicio mostró actividad de autenticación muy por encima de su línea base, conectándose desde un host desconocido a las tres de la mañana. La recomendación automática fue deshabilitarla de inmediato mientras se investigaba. Un analista experimentado revisó el historial completo de la cuenta y encontró que el mismo patrón — mismo pico de actividad, mismo host, mismo horario — se repetía exactamente cuatro veces al año, durante el cierre trimestral de finanzas. La actividad era estadísticamente anómala y completamente normal para ese proceso de negocio específico. Deshabilitar la cuenta habría detenido la liquidación financiera en pleno proceso y obligado al equipo a días de reconciliación manual.
El problema no fue la calidad del análisis de la IA — la anomalía era real — sino la ausencia de contexto sobre cómo se usa realmente ese sistema en esa organización. Ese tipo de conocimiento rara vez está en un inventario de activos, un runbook o cualquier dataset al que un modelo pueda acceder. Los analistas experimentados saben que el servidor catalogado como no crítico sigue soportando un proceso de negocio esencial, recuerdan que aislar un segmento de red durante un incidente anterior derribó otro servicio sin relación aparente, y pueden distinguir actividad hostil de un red team autorizado o trabajo programado de un proveedor.
El radio de impacto como criterio de autonomía
La propuesta que emerge de este análisis es que la autonomía de un sistema de IA en operaciones de seguridad no debería determinarse principalmente por la confianza del modelo o la severidad de la amenaza detectada — ninguno de esos factores predice qué pasa una vez que se ejecuta la acción recomendada. El criterio más útil es la reversibilidad y el radio de impacto potencial de cada acción, evaluados por separado. Aislar un controlador de dominio es técnicamente reversible — basta reconectarlo — pero hacerlo en el momento equivocado puede causar una caída de servicios en toda la organización.
Las acciones de bajo impacto y fácilmente reversibles son mejores candidatas para mayor autonomía, con salvaguardas en su lugar. Las acciones que requieren mayor escrutinio humano son aquellas difíciles de revertir, con amplio impacto potencial, que cruzan límites legales o de confianza, afectan sistemas más allá de la evidencia disponible, o reducen la capacidad de la organización para investigar lo que ocurrió. Un ejemplo concreto: una dirección IP vinculada a actividad maliciosa puede pertenecer también a infraestructura cloud compartida o una red de distribución de contenido de la que dependen servicios empresariales — bloquearla derribaría esos servicios junto con la amenaza.
Qué medir cuando un humano revisa una recomendación de IA
La IA puede dejar a un analista con docenas de recomendaciones para revisar en el tiempo que antes dedicaba a investigar un puñado de casos. Cada analista ahora tiene más decisiones que tomar, y las organizaciones necesitan medir qué pasa con esas decisiones. El KPI elegido determina el comportamiento resultante: si se mide la tasa de automatización, los analistas tienen incentivo para aprobar más recomendaciones; si se mide el tiempo medio de resolución, cierran casos más rápido. Ninguna de esas métricas mide si las decisiones mejoraron.
Una tasa de automatización del noventa por ciento dice muy poco por sí sola. Lo que importa es qué pasó en el diez por ciento de casos donde alguien intervino: si el analista aprobó, editó o rechazó la recomendación, cuánto tiempo dedicó a la revisión, y si su intervención cambió el resultado. Las recomendaciones de IA pueden ser más difíciles de revisar porque llegan con apariencia de estar bien respaldadas — la explicación es fluida, usa la terminología correcta y señala evidencia que parece creíble, incluso cuando no respalda completamente la conclusión. Las señales que los analistas experimentados usaban para detectar análisis débiles se vuelven mucho más difíciles de ver.
La dependencia insuficiente también merece atención. Un analista que cuestiona recomendaciones correctas sin agregar nada reduce la eficiencia que la IA debía proporcionar. La latencia de aprobación es una señal útil aquí: una cola larga de recomendaciones aprobadas casi instantáneamente, especialmente cuando hay presión de tiempo, debería llevar a los líderes a verificar cuánta revisión está ocurriendo realmente.
Nuestro análisis
Este planteo revela un patrón que ya se vio en otras oleadas de automatización en seguridad: la tentación de medir éxito por volumen de acciones ejecutadas en lugar de calidad de decisiones tomadas. La diferencia crítica ahora es que las recomendaciones de IA son lo suficientemente convincentes como para ocultar sus propias limitaciones — el lenguaje técnico correcto y la evidencia real pueden enmascarar que la evidencia no respalda la conclusión, o que falta contexto operativo esencial. Para equipos en América Latina que dependen de proveedores globales de plataformas de seguridad con capacidades de IA integradas, el riesgo es doble: esos sistemas se entrenan con datasets que rara vez incluyen patrones operativos regionales — horarios de cierre fiscal distintos, configuraciones de red heredadas de fusiones locales, dependencias de infraestructura compartida con proveedores regionales — y las organizaciones pueden no tener visibilidad sobre qué acciones el sistema está autorizado a ejecutar automáticamente según la configuración por defecto del vendor.
Lo que todavía no se sabe es cómo escalan estos problemas cuando múltiples sistemas de IA — detección de amenazas, respuesta automatizada, gestión de vulnerabilidades — operan en paralelo y cada uno toma decisiones basadas en su propio modelo del entorno, sin visibilidad compartida del contexto operativo completo. ¿Qué pasa cuando dos sistemas recomiendan acciones técnicamente correctas que, ejecutadas simultáneamente, generan un impacto combinado que ninguno de los dos modeló?