La investigación de SecurityHQ sobre agentes de IA concluye que las políticas superan a la responsabilidad ante incidentes
SecurityHQ publicó una investigación que muestra que el 76% de los responsables de ciberseguridad encuestados cuenta con políticas formales de responsabilidad para la IA, mientras que solo el 17% podía reconstruir la actividad de los agentes en cuestión de minutos. La investigación de SecurityHQ sobre agentes de IA, desarrollada junto con Datadog, expone una tensión práctica: asignar responsabilidades no convierte necesariamente una decisión automatizada en algo explicable.
Publicados el 15 de octubre de 2026, los hallazgos llegan mientras los agentes empresariales obtienen permisos para realizar tareas en distintos sistemas de negocio. Los agentes de IA son sistemas de software que utilizan modelos y herramientas conectadas para llevar a cabo tareas. Su autoridad plantea preguntas que las políticas escritas por sí solas no pueden responder.
La expansión de Security Copilot por parte de Microsoft ofrece una referencia concreta de este giro hacia el trabajo de seguridad delegado. La presión recae ahora en los responsables de seguridad, los propietarios de aplicaciones y los proveedores, que deben vincular las acciones automatizadas con evidencia y una autoridad humana responsable.
La investigación de SecurityHQ sobre agentes de IA separa la política de la preparación
El estudio encuestó a 204 responsables de ciberseguridad de organizaciones medianas y grandes. Según el anuncio de la investigación, el 45% había experimentado un incidente relacionado con agentes de IA o automatización en el que la responsabilidad no estaba clara.
Esa redacción merece atención. La categoría de incidentes incluye la automatización, por lo que el resultado no establece que el 45% haya sufrido una brecha causada por un agente autónomo de IA. La falta de claridad sobre la responsabilidad también describe un problema organizativo, no un fallo técnico concreto ni un determinado nivel de daño.
El hallazgo se refiere a si las organizaciones pueden explicar las acciones delegadas cuando se disputa la responsabilidad. Una política puede identificar a un responsable sin mostrar qué instrucción, permiso o interacción de sistemas produjo un resultado.
Los hallazgos públicos sobre responsabilidad de SecurityHQ también distinguen la visibilidad histórica de la preparación inmediata para investigar. Solo el 49% afirmó poder reconstruir por completo las acciones de un agente durante los 30 días anteriores.
Esa distinción cambia la forma en que los compradores deberían interpretar los resultados. Conservar registros y responder preguntas urgentes son capacidades relacionadas, pero cubren necesidades operativas distintas. Una organización podría preservar evidencia relevante y aun así requerir un trabajo manual considerable para vincularla.
A la inversa, un panel podría resumir la actividad reciente sin conservar suficiente detalle para una investigación posterior. Ninguna de estas posibilidades establece qué ocurrió dentro de las organizaciones encuestadas. Ambas explican por qué una única afirmación de visibilidad exige un examen más detenido.
El cambio importante es el enfoque de la investigación. SecurityHQ sitúa la titularidad de las políticas junto a la capacidad de establecer una secuencia de acciones, haciendo visible la distancia entre ambas capacidades.
Para los compradores empresariales, esto plantea una pregunta de adquisición más exigente. La explicación de un proveedor sobre su gobernanza debería estar conectada con la evidencia que recibe un cliente después de que actúe un agente.
Para los equipos internos de seguridad, la misma distinción afecta a los informes. La existencia de un proceso de aprobación no demuestra que los investigadores puedan recuperar la aprobación asociada a una acción en disputa.
Una política de responsabilidad sigue siendo útil porque define expectativas. Su valor operativo depende de que las personas puedan aplicar esas expectativas a un evento específico.
La encuesta no establece que las organizaciones con políticas hayan experimentado menos incidentes. Tampoco demuestra que adquirir supervisión adicional resolvería la incertidumbre sobre la responsabilidad.
Su contribución más acotada sigue siendo relevante. Las empresas pueden asignar formalmente responsabilidades sin contar con la evidencia necesaria para ejercer esa responsabilidad bajo presión.
Por eso la historia importa más allá de otra encuesta sobre el riesgo de la IA. La investigación cuestiona si las medidas de gobernanza conocidas describen una preparación real cuando el software recibe autoridad delegada.
El trabajo de seguridad delegado somete a presión a compradores y operadores
Los responsables de seguridad afrontan presión porque los agentes operan dentro de sistemas que ya dividen la responsabilidad entre distintos equipos. Un propietario de aplicación puede autorizar un flujo de trabajo mientras otro equipo gestiona sus credenciales y otro se ocupa de la respuesta a incidentes.
Una credencial es la prueba digital que presenta el software al solicitar acceso. Cuando varios flujos de trabajo comparten esa prueba, identificar la cuenta puede dejar sin resolver quién fue el iniciador real.
Una cuestión de titularidad aparentemente directa se divide entonces en varias preguntas. ¿Quién aprobó la tarea, quién concedió el acceso, quién mantuvo la integración y quién podía detener la ejecución?
Estos roles no tienen por qué pertenecer a la misma persona. La dificultad surge cuando la organización no puede conectarlos durante una investigación.
Delegar trabajo aumenta la importancia de saber dónde empieza, cambia y termina la autoridad. Un ejecutivo designado no puede resolver un incidente simplemente por figurar en un documento de gobernanza.
Las consecuencias operativas se extienden más allá de los departamentos de seguridad. Los propietarios de negocio necesitan entender si la acción de un agente cumplió un objetivo aprobado. Los equipos de aplicaciones necesitan suficiente contexto para diferenciar el comportamiento esperado del uso indebido.
Los equipos jurídicos y de riesgos afrontan otra preocupación: si el registro disponible respalda la explicación que la empresa ofrece posteriormente. Una narrativa convincente tiene un valor limitado cuando la evidencia que la respalda sigue fragmentada.
Los proveedores también afrontan presión porque los clientes dependen del diseño del producto para obtener parte de ese registro. Los clientes no pueden recuperar de forma independiente información que un servicio nunca expone ni conserva.
Microsoft ilustra por qué estas preguntas se han vuelto inmediatas. Su anuncio de agentes de seguridad de marzo de 2025 presentó agentes para tareas como la clasificación de phishing, es decir, ordenar y evaluar mensajes presuntamente engañosos.
La empresa presentó esas capacidades como una forma de reducir el trabajo rutinario de los defensores. Esto aporta un contexto concreto de despliegue sin establecer que los productos de Microsoft presenten las brechas comunicadas por SecurityHQ.
La comparación se refiere a la propuesta de compra. Microsoft describe el trabajo que los agentes pueden asumir; SecurityHQ pregunta si las organizaciones pueden dar cuenta de la actividad delegada después.
Estas propuestas pertenecen a la misma conversación de compra. Una afirmación de eficiencia resulta más útil cuando los compradores también pueden evaluar el esfuerzo de investigación, las opciones de intervención y la disponibilidad de evidencia.
Para un centro de operaciones de seguridad, el equipo responsable de supervisar y responder a amenazas, reducir la carga de trabajo rutinaria resulta claramente atractivo. Sin embargo, las acciones no resueltas generan trabajo en otros ámbitos.
Un analista que recibe la conclusión de un agente aún necesita entender su fundamento cuando cambian las circunstancias. Otro investigador puede necesitar revisar esa decisión después de que termine la tarea original.
Por tanto, la presión alcanza tanto la aprobación del despliegue como las operaciones continuas. Los compradores necesitan evidencia de cómo se comporta el sistema tras su adopción, incluso cuando sus acciones requieren explicación.
Esto no hace que la autonomía sea intrínsecamente inadecuada para el trabajo de seguridad. Hace que el alcance de la autoridad delegada sea fundamental para evaluar si el acuerdo operativo vale la pena.
La automatización útil aún necesita un rastro de acciones explicable
La tensión central se sitúa entre el tiempo que los agentes ahorran durante el trabajo ordinario y el esfuerzo necesario para explicar resultados excepcionales. Una ejecución más rápida solo crea valor dentro de límites que la organización pueda defender.
Consideremos la clasificación de phishing como un flujo de trabajo ilustrativo, no como un incidente comunicado por SecurityHQ. Un agente revisa un mensaje sospechoso, consulta información conectada y genera una decisión.
Una investigación útil conectaría el mensaje, la información consultada, la identidad del agente y la acción resultante. Si se aplicó una aprobación, los investigadores también tendrían que vincular esa aprobación con la acción.
Registrar que una tarea se completó responde a una pregunta más limitada. Establece un punto final sin explicar necesariamente cómo llegó el sistema a él.
Un rastro de acciones responsable debe conectar instrucciones, autoridad, ejecución y resultado. La conexión importa porque cualquiera de esos elementos puede convertirse en la parte en disputa de un incidente.
La instrucción podría haber sido adecuada mientras que el permiso era excesivo. El permiso podría haber sido adecuado mientras que la información encontrada durante la ejecución redirigió la tarea.
Como alternativa, el agente podría haber seguido correctamente el flujo de trabajo solicitado mientras que la regla de negocio subyacente era errónea. La responsabilidad también debe contemplar esa posibilidad.
Un registro centrado por completo en el modelo corre el riesgo de pasar por alto estas distinciones. Un modelo es solo una parte de la aplicación que recibe instrucciones, recupera información y llama a herramientas conectadas.
Una interfaz de programación de aplicaciones, o API, es una interfaz de software mediante la cual un sistema solicita las funciones de otro sistema. La actividad de los agentes puede atravesar esas interfaces y sus registros separados.
Cada servicio puede describir con precisión su interacción local y, aun así, dificultar la reconstrucción de la tarea completa. El elemento que falta es la relación entre registros que, por lo demás, son válidos.
Los hallazgos sobre seguridad de agentes de Salt Security del 13 de octubre ofrecen una visión independiente de ese problema. Su investigación combinó más de 380 respuestas de encuestas con telemetría de producción.
Solo el 12,5% de los encuestados afirmó poder rastrear de manera consistente las rutas completas de los agentes en todos los agentes. Salt también informó de que el 17,5% podía detener automáticamente a un agente con comportamiento inesperado en producción.
Estas cifras miden capacidades distintas de las preguntas de SecurityHQ sobre reconstrucción. No deben combinarse en una puntuación común ni tratarse como estimaciones equivalentes.
Su relevancia es conceptual: rastrear una acción e interrumpir una acción son partes separadas del control. Una explicación completa después de un incidente no revierte sus consecuencias.
Del mismo modo, detener un flujo de trabajo no explica por qué se comportó de forma inesperada. Los compradores deben evaluar ambas capacidades sin asumir que una garantiza la otra.
Por lo tanto, la comparación comercial es más amplia que una competencia entre proveedores individuales. SecurityHQ hace hincapié en la responsabilidad operativa, Microsoft describe tareas de seguridad delegadas y Salt destaca el rastreo y la contención.
Estas perspectivas convergen en un problema compartido por los clientes. Las empresas necesitan que el trabajo delegado siga siendo comprensible entre los límites de los productos, donde la responsabilidad suele ser más difícil de establecer.
La aprobación humana no puede cargar con toda la responsabilidad
La revisión humana sigue siendo una respuesta atractiva porque sitúa a una persona cerca de una decisión relevante. Su utilidad depende de lo que esa persona pueda inspeccionar y autorizar.
Una aprobación vinculada a un objetivo impreciso deja margen para discrepar sobre las acciones permitidas. Una aprobación vinculada a una acción específica establece un límite más claro.
Incluso entonces, los investigadores necesitan saber si la ejecución se ajustó a la solicitud aprobada. La aprobación y la ejecución describen momentos distintos, potencialmente separados por cambios en la información o las condiciones del sistema.
La supervisión humana contribuye a la rendición de cuentas cuando el registro de aprobación coincide con la autoridad realmente ejercida. La participación de una persona no aporta automáticamente el historial técnico que falta.
Esta distinción importa para los líderes empresariales que esperan que un revisor final asuma la responsabilidad de todo un flujo de trabajo. Un revisor no puede evaluar de manera significativa información que el sistema oculta.
También importa para los equipos de producto que deciden dónde situar los pasos de aprobación. Interrumpir cada acción introduce fricción, mientras que aprobar una tarea completa delega una discrecionalidad más amplia.
La disyuntiva práctica consiste en determinar qué decisiones requieren intervención y qué límites puede aplicar directamente el software. Distintos flujos de trabajo justifican respuestas diferentes porque sus posibles consecuencias difieren.
Un sistema que solo recomienda una respuesta plantea una cuestión de autoridad distinta de otro que modifica accesos. La comparación relevante es la acción permitida, no la presencia de una etiqueta de IA.
La identidad también cobra mayor importancia a medida que los agentes actúan más allá de los límites organizativos. La autenticación establece quién o qué realiza una solicitud; la autorización determina qué puede hacer ese solicitante.
Ninguna de las dos funciones explica por sí sola el propósito empresarial detrás de una solicitud. Una investigación se beneficia de conectar la identidad técnica con la tarea y con la persona o el proceso que la delegó.
El trabajo de NIST sobre identidad de agentes proporciona una referencia institucional para este desafío. En septiembre, identificó el desarrollo de software como su primer caso de uso de implementación.
Ese trabajo se centra en identificar, autenticar y autorizar agentes dentro del ciclo de vida de desarrollo de software. Es un esfuerzo de implementación, no una prueba de que la rendición de cuentas empresarial se haya resuelto.
La dirección importa porque la rendición de cuentas depende en parte de cómo viaja la autoridad a través del software. Las normas y demostraciones pueden ayudar a expresar esas relaciones de manera más coherente.
Sin embargo, una identidad técnica no puede decidir quién debe asumir un resultado empresarial controvertido. Las organizaciones aún necesitan una responsabilidad explícita para el despliegue, el mantenimiento, la revisión y la intervención de emergencia.
Los registros claros y los roles claros se refuerzan mutuamente. Los registros ayudan a establecer qué ocurrió, mientras que los roles determinan quién debe evaluar y responder a esa evidencia.
La misma distinción se aplica al conocimiento organizativo. Una base de conocimientos de equipo con capacidad de búsqueda puede facilitar el acceso a políticas y responsabilidades, mientras que la evidencia de ejecución establece lo que los sistemas realmente hicieron.
Mantener diferenciadas esas funciones ayuda a evitar un error conocido. Documentar el flujo de trabajo esperado no demuestra que una ejecución concreta lo haya seguido.
La encuesta plantea preguntas que no puede resolver
La investigación de SecurityHQ sobre agentes de IA aporta evidencia sobre la experiencia y la confianza declaradas por los encuestados. No mide de forma independiente el comportamiento de cada agente dentro de sus organizaciones.
La preparación declarada puede diferir del desempeño durante un incidente real. Los encuestados pueden interpretar de manera distinta la reconstrucción, la rendición de cuentas y la actividad de los agentes.
Un líder podría describir una sólida supervisión central mientras los despliegues descentralizados permanecen fuera de esa visión. Otro podría informar una preparación limitada pese a contar con equipos competentes y procesos internos poco conocidos.
Estas posibilidades no invalidan los hallazgos. Limitan la certeza de las conclusiones extraídas de ellos.
La encuesta respalda un examen riguroso de la preparación empresarial, en lugar de una estimación universal del fallo de los agentes. Sus resúmenes públicos no deberían sustituir las pruebas de despliegues individuales.
El anuncio público y la página de destino no ofrecen suficiente detalle metodológico para establecer una representatividad amplia. Los lectores deberían evitar asumir que la muestra refleja todos los sectores o tamaños de empresa.
La combinación de agentes de IA y automatización en la pregunta sobre incidentes crea otra limitación. No deja claro qué proporción de la incertidumbre declarada surgió de agentes más recientes frente a flujos de trabajo automatizados ya establecidos.
Esta distinción importa al interpretar la novedad. Las organizaciones llevan mucho tiempo teniendo dificultades para asignar responsabilidades entre integraciones de software, servicios externalizados y procesos operativos compartidos.
Los despliegues de agentes pueden complicar ese problema existente sin convertir en nuevas todas las debilidades subyacentes. Tratar toda la cuestión como exclusiva de la IA corre el riesgo de ocultar fallos de control ya conocidos.
La relación entre las políticas y los incidentes también sigue sin resolverse. Los hallazgos agregados no establecen qué encuestados tenían políticas cuando ocurrieron incidentes concretos.
Por tanto, no pueden demostrar que las políticas no lograran prevenir incidentes ni que las organizaciones sin políticas tuvieran un peor desempeño. Cualquiera de las dos afirmaciones requeriría evidencia adicional.
La investigación de SecurityHQ sobre agentes de IA también procede de organizaciones con intereses comerciales en seguridad y monitorización. Ese contexto merece divulgarse sin descartar automáticamente sus observaciones.
La respuesta escéptica adecuada consiste en examinar definiciones, metodología y evidencia reproducible. El patrocinio comercial y los hallazgos útiles pueden coexistir.
Una cautela similar se aplica a las comparaciones con los resultados de Salt. Las distintas preguntas, poblaciones y métodos de medición impiden una clasificación clara de la preparación empresarial entre los estudios.
La coincidencia en una preocupación general no demuestra coincidencia en la prevalencia medida. Los estudios aportan observaciones separadas sobre visibilidad, autoridad e intervención.
La investigación tampoco establece que centralizar más registros siempre mejore la seguridad. Los registros pueden contener información sensible, y el acceso a la evidencia de investigación crea sus propias responsabilidades.
La implicación analítica es más limitada: las organizaciones necesitan evidencia suficiente para las decisiones que delegan. Lo que cuenta como suficiente depende de la acción y sus consecuencias.
Una respuesta convincente mostraría cómo un flujo de trabajo específico sigue siendo atribuible durante un fallo. Una afirmación más amplia de que una plataforma hace responsables a todos los agentes requiere una base probatoria mucho mayor.
Observe la evidencia de incidentes, los controles de producto y las implementaciones de identidad
Durante los próximos meses, los avances más útiles mostrarán si las organizaciones pueden convertir la rendición de cuentas declarada en una capacidad operativa demostrable. Los anuncios de adopción por sí solos dejarán esa cuestión sin resolver.
La primera señal es la calidad de las reconstrucciones de incidentes y los ejercicios controlados publicados. Los relatos útiles conectarían la tarea delegada, la autoridad pertinente, la secuencia de acciones y la intervención.
También deberían identificar qué no pudieron recuperar los investigadores. Una reconstrucción incompleta pero sincera aporta más evidencia que la garantía de que un equipo mantuvo el control.
Las demostraciones repetidas en distintos flujos de trabajo reforzarían la confianza en que las prácticas de rendición de cuentas funcionan más allá de un ejemplo preparado. Las brechas persistentes reforzarían la preocupación planteada por SecurityHQ.
La segunda señal es la evidencia de producto que conecta la ejecución de agentes con la investigación y la contención. Los compradores deberían observar qué exponen los proveedores a los clientes, en lugar de depender de un lenguaje amplio de gobernanza.
Una demostración significativa mostraría cómo un investigador sigue una tarea a través de servicios conectados. También mostraría qué ocurre cuando un operador autorizado interrumpe el flujo de trabajo.
El momento y el alcance de la interrupción importan. Evitar la siguiente acción difiere de revertir cambios ya completados, y las demostraciones de producto deberían hacer comprensible esa distinción.
Controles más claros respaldarían una delegación más amplia allí donde los clientes puedan verificar su comportamiento. Las brechas sin explicación entre registros locales reforzarían el argumento a favor de una autoridad más limitada.
La tercera señal es el progreso de implementación en torno a la identidad y autorización de agentes. El caso de uso de desarrollo de software anunciado por NIST ofrece un lugar concreto donde observar resultados técnicos.
Los ejemplos prácticos podrían aclarar cómo la autoridad delegada sigue siendo atribuible a medida que el software se desplaza entre servicios. Su valor dependerá de si las organizaciones pueden aplicar el enfoque a flujos de trabajo reales.
El progreso reduciría la ambigüedad sobre la identidad técnica, aunque dejaría las decisiones de titularidad empresarial en manos de la empresa. Los retrasos dejarían a los clientes dependiendo más de enfoques específicos de cada producto.
El próximo referente útil es determinar si las organizaciones pueden explicar e interrumpir la actividad delegada en condiciones realistas. Ese referente conecta los hallazgos de la investigación con las decisiones que los compradores ya afrontan.
Para los lectores que evalúan un despliegue, la investigación de SecurityHQ sobre agentes de IA ofrece un motivo para examinar la evidencia detrás de las garantías existentes. Comience con un flujo de trabajo relevante que ya tenga un responsable. Pida a esa persona que explique una ejecución completada utilizando los registros disponibles hoy. Siga la instrucción, el permiso, la acción y el resultado. Después, identifique quién puede intervenir cuando esos elementos dejan de coincidir. Las conexiones ausentes revelan un problema más específico que una preocupación general sobre la seguridad de la IA. También generan una conversación más clara con proveedores y equipos internos sobre qué debe mejorar. Antes de conceder una autoridad más amplia, solicite una demostración que haga visible el historial de acciones y el límite de intervención. ¿Puede su organización defender la explicación cuando el resultado es objeto de disputa?
