El informe de brechas de IBM de 2026 señala una brecha del 92% en los controles de acceso a la IA
El informe de brechas de IBM de 2026 llegó a Google News con un dato alarmante: según los informes, el 92% de las organizaciones afectadas a través de sistemas de IA carecía de controles de acceso adecuados.
La cifra importa porque las empresas ya no usan la IA únicamente para redactar textos o resumir documentos. Los modelos y agentes se conectan cada vez más a datos corporativos, servicios en la nube, herramientas de software y flujos de trabajo de producción. Por tanto, los errores de acceso pueden exponer información o autorizar acciones en varios sistemas.
El titular también refleja un giro más amplio en la IA empresarial. Las compañías adoptaron la IA para mejorar la productividad y reforzar la seguridad, pero muchas la implementaron sin las salvaguardas de identidad que se exigen habitualmente a empleados y aplicaciones convencionales. Los hallazgos de IBM sugieren que los atacantes han detectado esa brecha.
El titular de IBM en Google News apunta a un cambio más amplio en la seguridad de la IA
La estadística sobre controles de acceso es alarmante, pero los hallazgos más amplios de IBM muestran que la IA ya afecta a ambos lados de una brecha de datos.
IBM publicó su informe Cost of a Data Breach 2026 el 29 de julio. La investigación fue realizada por Ponemon Institute y posteriormente patrocinada y analizada por IBM. Examinó brechas sufridas por 602 organizaciones de 17 sectores entre marzo de 2025 y febrero de 2026.
La cifra reportada del 92% se refiere a organizaciones que sufrieron ataques relacionados con sus modelos o aplicaciones de IA. En términos prácticos, esas organizaciones carecían de controles capaces de limitar de forma fiable quién o qué accedía a los sistemas de IA afectados.
El control de acceso determina si una persona, aplicación o identidad de máquina puede acceder a un recurso. También define qué acciones puede realizar esa identidad. Para un agente de IA, esos permisos podrían incluir leer registros de clientes, llamar a una interfaz de programación de aplicaciones, modificar un ticket o activar un flujo de trabajo automatizado.
La estadística no debe interpretarse como prueba de que el 92% de todas las empresas carece de controles de acceso para IA. IBM estudió organizaciones que habían sufrido brechas, y la cifra se aplica a un grupo más reducido con incidentes relacionados con IA. Esta distinción es importante al evaluar la prevalencia del problema.
Incluso dentro de ese grupo más reducido, el hallazgo describe un grave fallo de control. Más del 20% de las organizaciones de la muestra de IBM reportó una brecha dirigida a modelos o aplicaciones de IA. Las API, aplicaciones o complementos comprometidos representaron el 27% de las causas citadas. Las configuraciones erróneas de la nube que afectaban a cargas de trabajo de IA representaron otro 27%.
Estos hallazgos desplazan la atención de los escenarios dramáticos en los que un modelo derrota espontáneamente la seguridad. Las debilidades más inmediatas suelen situarse alrededor del modelo. Los atacantes pueden explotar interfaces expuestas, cuentas de servicio con privilegios excesivos, complementos vulnerables y recursos en la nube mal configurados.
El informe de brechas de 2026 de IBM también pone en contexto lo que está en juego desde el punto de vista financiero. El coste medio global de una brecha alcanzó los 4,99 millones de dólares, lo que representa un aumento anual del 12%. IBM describió esta cifra como un máximo histórico.
Los incidentes relacionados con IA modificaron aún más la economía. IBM informó de que una de cada cuatro brechas maliciosas fue habilitada por IA, un aumento del 56% respecto al año anterior. Estos incidentes costaron a las organizaciones una media de 6 millones de dólares, aproximadamente 1 millón por encima de la media global.
Eso no significa que todos los ataques habilitados por IA se dirigieran directamente a un modelo de IA. IBM utiliza la categoría para incluir ataques en los que los actores de amenazas emplearon IA, incluida la suplantación mediante deepfakes y el malware asistido por IA. La distinción separa los ataques que usan IA de los ataques contra sistemas de IA.
En conjunto, las categorías describen un riesgo de dos caras. Los atacantes pueden usar IA para aumentar la velocidad o la escala de tácticas ya establecidas. También pueden atacar los modelos, agentes, almacenes de datos e interfaces que las empresas están incorporando rápidamente a su infraestructura.
Por eso, el enfoque de Google News no debería reducirse a un único porcentaje sensacionalista. El acontecimiento subyacente es un cambio en la superficie de ataque empresarial, con la IA convirtiéndose tanto en una herramienta del atacante como en un objetivo.
El verdadero punto débil está alrededor del modelo
Las cifras de IBM indican que los fallos habituales de identidad, API y nube siguen siendo fundamentales en las supuestamente nuevas brechas de IA.
Los debates sobre seguridad de IA suelen centrarse en el comportamiento del modelo, como las alucinaciones, los resultados perjudiciales o la inyección de prompts. Estos riesgos siguen siendo relevantes, pero los datos de IBM apuntan a un problema menos exótico. Las organizaciones están conectando la IA a recursos valiosos sin aplicar de forma consistente controles de seguridad establecidos.
Por sí solo, un modelo normalmente no puede acceder a una base de datos de clientes ni desplegar software. Obtiene ese alcance a través de componentes circundantes. Entre ellos se incluyen complementos, credenciales de API, sistemas de recuperación, roles en la nube, cuentas de servicio y capas de orquestación de agentes.
Cada conexión amplía el número de decisiones que una organización debe gobernar. ¿Qué documentos puede recuperar el sistema? ¿Puede ver los registros de todos los clientes? ¿Puede llamar a un servicio externo? ¿Puede escribir datos o solo leerlos? ¿Su acceso expira cuando termina una tarea?
Una identidad agéntica es la identidad digital asignada a un agente de IA que actúa en sistemas conectados. Los programas tradicionales de identidad suelen centrarse en empleados, contratistas, dispositivos y cargas de trabajo de software. Los agentes introducen otra categoría que puede tomar decisiones e invocar herramientas con una participación humana limitada.
IBM recomienda controles dinámicos basados en identidad para estos agentes. También pide permisos estrictamente delimitados, aplicación de controles en tiempo de ejecución, atribución humana y actividad auditable. La aplicación en tiempo de ejecución implica comprobar los permisos mientras un agente opera, en lugar de aprobar un acceso amplio una vez durante el despliegue.
Este enfoque aborda una incompatibilidad clave. Un empleado normalmente se autentica mediante una cuenta conocida, mientras que un agente puede actuar a través de varias credenciales compartidas. Si los registros solo anotan la cuenta de servicio compartida, los investigadores pueden tener dificultades para identificar qué agente inició una acción o qué empleado solicitó que se realizara.
El resultado es una brecha de responsabilidad. Una empresa podría saber que un token de API accedió a datos sensibles sin saber qué modelo, flujo de trabajo o usuario provocó la solicitud. Eso dificulta detener la actividad inapropiada y reconstruir una brecha posterior.
El principio de mínimo privilegio ofrece una respuesta conocida. Este principio concede a cada identidad solo el acceso necesario para una tarea definida. Sin embargo, aplicarlo a la IA puede resultar difícil porque los agentes suelen realizar trabajos cambiantes y de varios pasos.
Los permisos amplios hacen que un agente sea más útil en más situaciones. También aumentan el daño potencial derivado de un prompt manipulado, una credencial robada, una decisión errónea o una integración comprometida. El mismo acceso que permite la automatización puede ampliar el radio de impacto de una brecha.
Pensemos en un asistente interno de investigación conectado a documentos, correo electrónico, registros de clientes y sistemas de proyectos. Una configuración restringida podría permitirle recuperar archivos aprobados para un equipo. Una configuración amplia podría exponer información de repositorios jurídicos, financieros, de ingeniería y ventas.
La diferencia de seguridad no reside en la capacidad de redacción del modelo. Reside en la calidad del límite de identidad que rodea sus datos y herramientas.
El acceso al conocimiento también merece una atención especial. Las organizaciones quieren que los asistentes encuentren contexto relevante sin exponer todas las fuentes a todos los usuarios. Una base de conocimientos de IA cuidadosamente diseñada debería preservar los permisos de origen en lugar de crear una nueva vía para sortearlos.
El mismo problema aparece en los flujos de trabajo autónomos. Un agente que gestiona solicitudes de soporte podría necesitar leer el perfil de un cliente y proponer una respuesta. No necesita automáticamente permiso para exportar la base de datos de clientes, cambiar datos de facturación o desactivar ajustes de seguridad.
La IA puede difuminar estos límites porque el contexto útil suele tratarse como un único conjunto. Cuando los permisos desaparecen durante la indexación, la recuperación o la ejecución del agente, el sistema puede revelar información a la que el usuario solicitante no podría acceder directamente.
El envenenamiento de contexto crea otro riesgo. Ocurre cuando información engañosa o maliciosa entra en el material que una IA utiliza para tomar decisiones. Un atacante podría insertar instrucciones dentro de un documento que un agente recupera posteriormente.
El filtrado tradicional de resultados no aborda por completo ese escenario. La organización debe controlar en qué fuentes confía el agente, qué herramientas puede invocar y si las acciones sensibles requieren aprobación. Los registros también deben conservar suficiente contexto para explicar la decisión.
Las barreras de seguridad de un modelo y los controles de acceso de una empresa cumplen propósitos diferentes. Las barreras pueden influir en el contenido que produce un modelo. Los controles de acceso deciden si puede acceder a un sistema de nóminas, un repositorio de código fuente o una consola de producción.
Confundir ambos conceptos puede generar una falsa sensación de seguridad. Un modelo de buen comportamiento con permisos excesivos sigue siendo peligroso si sus credenciales son robadas o sus entradas son manipuladas. Por el contrario, un acceso estrictamente delimitado puede limitar los daños incluso cuando un modelo se comporta de manera inesperada.
Por tanto, el informe de IBM cuestiona la idea de que la seguridad de IA requiere un universo de seguridad completamente separado. Muchos fallos siguen implicando descubrimiento de activos, gestión de credenciales, configuración de la nube, monitorización y respuesta a incidentes. La nueva dificultad radica en aplicar esos controles a sistemas que actúan con mayor autonomía.
La adopción de IA prometía velocidad, pero los equipos de seguridad heredaron el riesgo
El conflicto principal se produce entre el rápido despliegue de la IA y el trabajo más lento de definir identidades, permisos, propiedad y evidencias.
Los equipos empresariales afrontan fuertes incentivos para desplegar IA con rapidez. Los empleados ya utilizan asistentes de consumo, extensiones de navegador, servicios de transcripción y funciones de IA integradas en software empresarial. Las unidades de negocio a menudo pueden activar estos servicios antes de que los equipos de seguridad los hayan inventariado.
Este comportamiento produce IA en la sombra, es decir, herramientas o modelos de IA utilizados sin aprobación ni gobernanza formales. Se parece a la TI en la sombra, pero la exposición puede ir más allá del almacenamiento o la adquisición de software. Un modelo no autorizado puede procesar datos sensibles, conservar prompts, llamar a herramientas o influir en decisiones empresariales.
La investigación de IBM de 2025 estableció una referencia importante. En ese momento, el 13% de las organizaciones estudiadas reportó brechas que involucraban modelos o aplicaciones de IA. Entre esas organizaciones, el 97% afirmó que carecía de controles de acceso adecuados para IA.
Los hallazgos de 2025 también revelaron que el 63% de las organizaciones afectadas por brechas carecía de una política de gobernanza de IA o todavía la estaba desarrollando. Solo el 34% de las organizaciones con una política auditaba regularmente la IA no autorizada.
Una de cada cinco organizaciones de ese estudio reportó una brecha que involucraba IA en la sombra. Las organizaciones con un alto uso de IA en la sombra experimentaron costes medios de brechas 670.000 dólares superiores a los de aquellas con un uso bajo o inexistente de IA en la sombra.
El paso del 97% en el subgrupo afectado por brechas de 2025 al 92% reportado en 2026 sugiere una mejora limitada, no un problema resuelto. Las muestras y las definiciones precisas de los incidentes pueden diferir, por lo que los porcentajes no deben tratarse como una medición interanual directa.
Aun así, ambas cifras apuntan en la misma dirección. Casi todas las organizaciones afectadas en los grupos pertinentes carecían de controles adecuados en torno al acceso a la IA. Esa coherencia es más significativa que la diferencia de cinco puntos.
Los equipos de seguridad reciben presión desde varias direcciones a la vez. Deben descubrir el uso autorizado y no autorizado de IA, asignar responsables, clasificar los datos conectados, gobernar las identidades no humanas, inspeccionar complementos y supervisar las acciones en tiempo de ejecución.
Mientras tanto, los equipos de producto están ampliando lo que los agentes pueden hacer. Un asistente que solo redacta texto tiene una autoridad operativa limitada. Un agente que actualiza registros de clientes, fusiona código, programa pagos o modifica recursos en la nube entra en una categoría de riesgo diferente.
Esto crea un desfase de gobernanza. Compras puede aprobar el software, mientras los equipos de identidad siguen sin conocer sus cuentas de servicio. Un desarrollador puede conectar un agente a datos de producción antes de que el equipo de privacidad evalúe el flujo.
La organización puede terminar con varias visiones incompletas. Seguridad ve el tráfico de API, TI ve las licencias, el área legal ve los contratos de proveedores y los equipos de negocio ven la productividad. Nadie mantiene un inventario completo del agente, sus datos, sus credenciales y las acciones que tiene permitidas.
Las políticas por sí solas no pueden cerrar esa brecha. Un documento puede prohibir que los empleados carguen información confidencial en modelos públicos. No puede impedir la actividad a menos que la empresa pueda detectar la herramienta, clasificar los datos y aplicar la restricción.
Los controles técnicos por sí solos también se quedan cortos sin una responsabilidad clara. Una plataforma de seguridad puede señalar un acceso inusual, pero alguien debe decidir cómo es la actividad normal de cada agente. El responsable debe saber qué herramientas necesita y qué acciones deben requerir la aprobación de una persona.
La tensión se agudiza cuando los ejecutivos exigen una adopción medible de IA. Los equipos pueden contabilizar licencias habilitadas, tareas automatizadas o uso por parte de los empleados como señales de avance. Esas métricas premian el alcance y la rapidez, mientras que las revisiones de permisos y la preparación de auditorías parecen ralentizar el despliegue.
La investigación de IBM sugiere que el coste oculto surge después del despliegue. La falta de responsables dificulta contener los incidentes. Las credenciales compartidas dificultan atribuir las acciones. Los accesos excesivos permiten que un único componente comprometido alcance más datos.
Entre las organizaciones sometidas a mayor presión se encuentran las empresas de servicios financieros y energía. IBM determinó que los sectores de infraestructuras críticas representaron el 62% de los ataques impulsados por IA notificados. Las brechas en servicios financieros promediaron 6,3 millones de dólares, mientras que las del sector energético promediaron 5,2 millones de dólares.
Estos sectores operan sistemas interconectados cuya interrupción puede afectar a clientes, cadenas de suministro o servicios esenciales. También poseen datos financieros, de identidad, operativos y de propiedad intelectual de gran valor. Las integraciones de IA pueden crear nuevas rutas de acceso a esos entornos.
Los desarrolladores también asumen consecuencias prácticas. Las revisiones de seguridad requieren cada vez más diagramas de arquitectura, inventarios de flujos de datos, documentación de modelos, responsables de credenciales y pruebas de testeo. Un equipo que no puede explicar el acceso de un agente tendrá dificultades para demostrar que el despliegue está contenido.
Por ello, los compradores empresariales deberían mirar más allá de si un producto ofrece inicio de sesión único. Deben saber si conserva los permisos a nivel de origen, admite roles granulares, separa inquilinos, registra las llamadas a herramientas y permite revocar rápidamente las credenciales.
Una casilla de verificación de compras puede confirmar que existe un control. No puede establecer que todos los agentes lo utilicen correctamente. La verdadera prueba es si una organización puede rastrear una acción sensible desde la persona que la solicita, pasando por el modelo, hasta el sistema de destino.
La IA está elevando y reduciendo los costes de las brechas
La inversión central de IBM es que la IA amplifica los ataques, mientras que la automatización de la seguridad puede reducir sustancialmente el coste resultante.
El informe de 2026 no presenta la IA como algo uniformemente perjudicial. Las organizaciones que utilizaron ampliamente IA y automatización en las operaciones de seguridad ahorraron una media de 1,93 millones de dólares frente a las organizaciones que no utilizaron ninguna de ellas.
Ese hallazgo plantea la disyuntiva más importante del informe. Negarse a utilizar IA no elimina a los atacantes asistidos por IA ni los servicios vulnerables de terceros. Sin embargo, desplegarla de forma descuidada puede añadir identidades y rutas de datos sin gestionar.
IBM afirma que los ataques habilitados por IA aumentaron un 56% interanual. La suplantación mediante deepfakes representó la categoría más común en los informes secundarios, citada por el 45% de los encuestados. El malware y el phishing habilitados por IA también contribuyeron al aumento.
Estas herramientas reducen el coste de producir mensajes personalizados, suplantar a personas de confianza y modificar código malicioso. No eliminan la necesidad de un punto de entrada. Las credenciales robadas, los servicios expuestos, el software vulnerable y el engaño humano siguen siendo partes esenciales de muchos ataques.
La IA también puede ayudar a los defensores a clasificar alertas, detectar comportamientos inusuales, correlacionar eventos y contener incidentes. La automatización importa porque los costes de las brechas aumentan cuando las organizaciones tardan más en descubrir y corregir sistemas comprometidos.
La ejecutiva de seguridad de IBM, Suja Viswesan, presentó el problema como un desequilibrio económico. Los atacantes pueden lanzar operaciones de forma más rápida y barata, mientras que las víctimas gastan millones en detectar, contener y recuperarse de una brecha.
Su recomendación se centra en cerrar el retraso entre el descubrimiento y la corrección. Esto incluye integrar las soluciones en los flujos de trabajo de desarrollo, proteger las identidades durante la operación y abordar las debilidades a la velocidad a la que los atacantes las explotan.
La adopción sigue siendo desigual. Una de cada cuatro organizaciones del estudio de IBM no había introducido IA ni automatización en las operaciones de seguridad. Más de la mitad utilizaba agentes para la detección y contención de amenazas, pero solo el 18% los aplicaba a la gestión de vulnerabilidades.
Esa brecha importa porque la detección ocurre después de que aparece una actividad sospechosa. La gestión de vulnerabilidades aborda debilidades conocidas antes de que un atacante las explote. Una detección rápida no puede compensar sistemas expuestos que permanecen sin parches o mal configurados.
El estudio de IBM también concluyó que el 85% de los encuestados en una investigación posterior planeaba aumentar el gasto en seguridad tras conocer las capacidades avanzadas de los modelos de frontera. Solo el 64% había previsto aumentar el gasto después de sufrir una brecha en la investigación inicial.
Este resultado sugiere que las organizaciones están empezando a responder a capacidades anticipadas, no solo a incidentes ya consumados. Sin embargo, la intención de gasto no demuestra si las inversiones mejorarán los controles de identidad o simplemente añadirán más productos de detección.
La metodología del informe también merece escrutinio. IBM y Ponemon estudiaron organizaciones que experimentaron brechas, no una muestra representativa de todas las empresas. Las estimaciones de costes combinan varias categorías, incluidas detección, escalada, pérdida de negocio, notificación y respuesta posterior a la brecha.
El informe puede identificar patrones dentro de su muestra. No puede demostrar que añadir un producto de seguridad generará el ahorro medio citado en todas las organizaciones. Las grandes empresas, los sectores regulados y los incidentes complejos pueden tener estructuras de costes muy diferentes.
Los incentivos de los proveedores también deberían permanecer visibles. IBM vende software y servicios de seguridad relacionados con identidad, protección de datos, gestión de la nube y respuesta a incidentes. Su informe puede contener investigación valiosa y, al mismo tiempo, respaldar una narrativa comercial.
Eso no invalida los datos. Significa que los lectores deben separar los hallazgos medidos de las afirmaciones prescriptivas. La muestra muestra asociaciones entre una amplia automatización de la seguridad y costes medios más bajos, pero la madurez organizativa puede contribuir a ambas cosas.
Un programa de seguridad maduro tiene más probabilidades de adoptar la automatización de forma eficaz. También puede contar con mejores inventarios, personal capacitado, planes de respuesta probados y respaldo ejecutivo. Estos factores pueden reducir los costes de las brechas independientemente de las herramientas.
El hallazgo del 92% sobre controles de acceso requiere una cautela similar. El porcentaje no muestra que la ausencia de controles causara cada incidente. Demuestra una fuerte superposición entre las brechas relacionadas con IA y controles inadecuados en el grupo afectado.
Las API comprometidas y las configuraciones erróneas en la nube proporcionan un mecanismo plausible que conecta controles débiles con incidentes. Sin embargo, la causalidad puede variar. Un atacante podría explotar una vulnerabilidad de software incluso cuando existen políticas de identidad, o robar una credencial con privilegios legítimos.
La cobertura independiente ha destacado la misma doble amenaza. Un análisis del sector señaló que los delincuentes están tanto atacando sistemas de IA como utilizando IA para acelerar ataques ya establecidos. Ese enfoque refleja mejor el informe que una afirmación simple de que los modelos están causando brechas.
La conclusión práctica no es elegir entre IA o seguridad. Las empresas deben gobernar los despliegues de IA y, al mismo tiempo, utilizar la automatización allí donde mejore la defensa. El resultado depende de si las organizaciones conectan la capacidad con una autoridad definida de forma estricta.
Lo que la cifra del 92% no demuestra
El titular identifica una crisis de controles, pero no revela la calidad de los controles de cada organización ni establece una tasa de incidentes universal.
Los porcentajes pueden circular por Google News más rápido que sus definiciones. Los lectores pueden encontrarse con la cifra del 92% sin ver los límites de la muestra, el periodo de investigación o la distinción entre ataques habilitados por IA y ataques dirigidos a la IA.
La primera incertidumbre se refiere a la terminología. Los “controles adecuados de acceso a la IA” pueden abarcar varias prácticas, entre ellas autenticación, diseño de roles, rotación de credenciales, permisos de origen, políticas de ejecución y registros de auditoría. Una medición binaria puede ocultar grandes diferencias de madurez.
Una organización podría no tener controles específicos. Otra podría utilizar sistemas de identidad establecidos, pero no aplicarlos a un complemento. Ambas podrían aparecer en la misma categoría de controles inadecuados, aunque su postura de seguridad sea diferente.
La segunda incertidumbre se refiere a la detección. Las organizaciones no pueden informar de incidentes que nunca descubren. Las empresas con una supervisión más sólida podrían identificar más actividad relacionada con IA que las organizaciones con visibilidad limitada, creando un aparente aumento que refleje en parte una mejor observación.
El ocho por ciento de las organizaciones del estudio de IBM de 2025 afirmó no saber si los modelos o aplicaciones de IA habían sido comprometidos. Esa incertidumbre ilustra el problema del inventario. Una empresa no puede evaluar un modelo cuya existencia desconoce.
La tercera incertidumbre se refiere al significado de una brecha relacionada con IA. Un atacante podría dirigirse a un endpoint de modelo, robar datos de entrenamiento, explotar una API asociada o utilizar phishing generado por IA contra un empleado. Estos eventos tienen mecanismos diferentes y requieren defensas distintas.
La inversión de modelos, por ejemplo, intenta inferir información sensible a partir de las salidas de un modelo. IBM informó de un coste medio global de 6 millones de dólares para las brechas que involucraban este tipo de ataque. Ese escenario difiere de un bucket de almacenamiento en la nube expuesto mediante una aplicación de IA mal configurada.
La suplantación mediante deepfakes vuelve a diferir. Utiliza medios sintéticos para imitar a una persona de confianza, a menudo con el fin de manipular a un empleado o un proceso de negocio. Los controles de acceso pueden limitar el daño resultante, pero la verificación de identidad y los controles de proceso también importan.
La cuarta incertidumbre se refiere a las comparaciones de tendencias. El informe de IBM de 2025 estudió 600 organizaciones con brechas desde marzo de 2024 hasta febrero de 2025. El informe de 2026 estudió 602 organizaciones durante los 12 meses siguientes.
Estas muestras de tamaño similar permiten una comparación amplia, pero las organizaciones participantes y la combinación de incidentes pueden cambiar. Los lectores no deberían tratar cada variación como una medida precisa de la tasa global de brechas.
La quinta incertidumbre implica los promedios de costes. Un pequeño número de incidentes costosos puede elevar una media. El sector, el tamaño de la empresa, la regulación, la interrupción operativa y el tiempo de recuperación influyen en la cantidad final.
La media global de IBM aumentó de 4,44 millones de dólares en 2025 a 4,99 millones en 2026. El incremento es notable, pero no significa que todas las empresas deban esperar que un incidente cueste exactamente esa cantidad.
Un enfoque más útil es interpretar los hallazgos como evidencia direccional. Los sistemas de IA se están convirtiendo en componentes materiales de la infraestructura empresarial. Los atacantes están interactuando con esos sistemas, y muchas organizaciones afectadas no les han extendido los controles básicos.
Los responsables de seguridad deberían comprobar si el titular se corresponde con su propio entorno. ¿Pueden enumerar todos los modelos y agentes? ¿Pueden identificar al propietario? ¿Pueden ver a qué fuentes de datos accede cada sistema? ¿Pueden revocar sus credenciales sin deshabilitar una plataforma completa?
También deberían preguntarse si los registros conservan la atribución humana. Si un empleado indica a un agente que actualice un registro de cliente, el rastro de auditoría debe vincular al empleado, el agente, la credencial, la llamada a la herramienta y el cambio final.
La supervisión continua es importante porque el comportamiento de un agente puede cambiar según su contexto. Nuevas herramientas, prompts, fuentes de datos y versiones de modelo pueden alterar lo que hace, incluso cuando sus permisos formales se mantienen constantes.
El análisis externo sobre la seguridad de los agentes ha puesto el énfasis en las identidades, el acceso estrictamente controlado, las acciones auditables, las rutas de escalado y los interruptores de desconexión. Estas medidas tratan la autonomía como un riesgo operativo, no meramente como un problema de calidad del modelo.
Un interruptor de desconexión es un mecanismo que detiene a un agente o revoca su capacidad de actuar. Debe funcionar con rapidez y previsibilidad, especialmente cuando un agente puede acceder a sistemas financieros, de producción o de clientes.
La aprobación humana también sigue siendo útil para acciones de alto impacto. Un agente puede preparar un pago, un cambio de código o una modificación de cuenta sin recibir autoridad para finalizarlo. Esta separación preserva la automatización al tiempo que limita los resultados irreversibles.
Los controles deben ajustarse al riesgo. Un asistente que resume documentos públicos necesita menos restricciones que un agente que accede a información de pacientes o infraestructura de producción. Aplicar la misma política a ambos puede generar una fricción excesiva o una protección insuficiente.
Por tanto, el valor del titular reside en impulsar preguntas concretas. Su limitación es que no puede responderlas para todas las organizaciones.
Tres señales que vigilar tras el informe de IBM de 2026
La siguiente prueba es si las empresas convierten la preocupación en controles de identidad medibles, corrección de vulnerabilidades y resultados verificables de forma independiente.
La primera señal es la adopción de controles de identidad específicos para agentes. Las organizaciones deberían ir más allá de las claves API compartidas y asignar identidades distintas a agentes, cargas de trabajo y flujos de trabajo.
La evidencia de progreso incluiría credenciales de corta duración, permisos a nivel de tarea, atribución humana y registros que cubran cada llamada a herramienta. Es probable que los proveedores de seguridad amplíen sus productos en esta área, pero las métricas de adopción importan más que los anuncios de funcionalidades.
Si las organizaciones pueden inventariar las identidades de los agentes y revocarlas individualmente, la advertencia central de IBM comenzará a perder fuerza. Si los agentes siguen heredando cuentas de servicio con amplios privilegios, el titular del 92% seguirá siendo relevante.
La segunda señal es si los equipos de seguridad aplican la automatización a la gestión de vulnerabilidades. IBM descubrió que más de la mitad de las organizaciones utilizaban agentes para la detección y contención de amenazas, mientras que solo el 18% los utilizaba para la gestión de vulnerabilidades.
Ese desequilibrio favorece la reacción frente a la prevención. El progreso implicaría conectar inventarios de activos, datos de exposición, propiedad del código y flujos de trabajo de corrección para que las debilidades conocidas lleguen rápidamente al equipo responsable.
La métrica que debe vigilarse no es el número de alertas de IA. Es el tiempo entre el descubrimiento de una debilidad explotable y el despliegue de una corrección verificada. Tiempos de corrección más cortos respaldarían el argumento de IBM de que los defensores pueden contrarrestar ataques más rápidos con automatización.
La tercera señal es la evidencia independiente sobre la frecuencia y los costes de las brechas. El informe anual de IBM ofrece una referencia ampliamente citada, pero los compradores deberían compararlo con divulgaciones regulatorias, datos de seguros, hallazgos de respuesta a incidentes e investigación revisada por pares.
Resultados consistentes entre esas fuentes reforzarían la conclusión de que los controles débiles de acceso a la IA están impulsando pérdidas materiales. Grandes discrepancias sugerirían que las definiciones, el muestreo o las prácticas de detección explican parte de la tendencia.
Las empresas también deberían observar cómo cambia la cifra reportada del 92% en el próximo estudio de IBM. Una disminución significativa, acompañada de mejores resultados de inventario y auditoría, indicaría que la gobernanza se está poniendo al día.
Un porcentaje menor por sí solo no sería suficiente. Las organizaciones podrían simplemente detectar menos incidentes o redefinir qué califica como sistema de IA. Una mejora creíble requiere pruebas de que los controles se despliegan, se prueban y se aplican durante la operación.
La cuestión más amplia es si la IA empresarial puede madurar desde la experimentación hasta convertirse en infraestructura responsable. Los modelos y agentes ya interactúan con documentos, datos de clientes, código, comunicaciones y procesos empresariales. La seguridad debe seguir esas conexiones.
Google News puede amplificar la estadística, pero los consejos de administración y los equipos técnicos deben traducirla en preguntas a nivel de sistema. ¿Qué identidades existen, a qué pueden acceder y quién sigue siendo responsable cuando actúa un agente?
Los hallazgos de IBM ofrecen una advertencia, no un veredicto final. Los próximos tres meses deberían mostrar si las empresas tratan el acceso a la IA como un problema central de identidad o como otro documento de políticas pendiente de implementación.
Revise cada agente de IA que pueda acceder a datos sensibles o desencadenar una acción externa. Asígnele un propietario identificado, una identidad distinta, permisos estrictamente delimitados y una ruta auditable hasta la persona que realizó la solicitud. Después, compruebe si la organización puede detenerlo rápidamente.
Ese trabajo es menos llamativo que un titular de Google News. También es donde es más probable que se prevenga el próximo incidente costoso relacionado con IA.
