IBM: el 92% de las empresas con incidentes de IA carecía de un control de acceso básico

IBM investigó incidentes de seguridad corporativos en sistemas de IA y detectó un patrón que cambia las prioridades en la protección de la inteligencia artificial: el 92% de las empresas que sufrieron un incidente de este tipo no tenía un control de acceso básico a sus herramientas de IA. Además, en la mayoría de los casos registrados, el modelo en sí —su arquitectura, sus pesos o su algoritmo— no fue la causa original del problema.

Dónde surge realmente la vulnerabilidad

El 92% de las empresas con incidentes de IA no limitaba quién podía acceder a sus sistemas de IA ni con qué permisos. Es la cifra clave del estudio de IBM. El control de acceso, la auditoría de permisos y la monitorización de las consultas al modelo no existían justo donde debían actuar como primera barrera de protección.

Por lo general, los atacantes no iban directamente contra el modelo. Explotaban vectores más sencillos: comprometían una cuenta con permisos excesivos y accedían a la interfaz de IA, y a partir de ahí era el propio sistema el que les entregaba la información que buscaban.

• 92% de las empresas víctimas de incidentes de IA no tenía un control de acceso suficiente a sus sistemas de IA
• El modelo de IA rara vez fue la causa original de la brecha de seguridad
• Principales vectores de ataque: permisos excesivos de usuarios y cuentas de servicio
• La ausencia de monitorización de consultas anómalas al sistema de IA agravó el alcance de los incidentes

El control de acceso a un sistema de IA no se limita a un usuario y una contraseña. En un entorno corporativo implica permisos granulares: qué datos y bases de conocimiento están al alcance del modelo, y qué empleados y contratistas pueden enviar consultas y en qué volumen.

Por qué los sistemas de IA se han convertido en un objetivo atractivo

Las herramientas de IA corporativas reciben cada vez más acceso amplio a datos críticos del negocio: bases de clientes, documentos financieros, correspondencia interna y materiales estratégicos. Eso es lo que las convierte en un objetivo valioso, no por vulnerabilidades del propio modelo, sino por los datos a los que se puede llegar a través de él con consultas corrientes.

Una instalación corporativa típica de IA conecta el modelo con documentos, datos de CRM, chats de trabajo y bases de conocimiento. Si no hay restricciones sobre lo que el sistema puede «ver» y devolver ante una consulta, el alcance de una posible filtración depende únicamente de lo amplio que fuera el acceso a datos de la cuenta comprometida.

«El modelo en sí rara vez resulta ser el problema», se desprende del

estudio de IBM, que señala factores organizativos y de configuración como la causa principal de la mayoría de los incidentes de IA registrados.

Por qué las medidas básicas siguen sin implantarse

La rápida adopción de la IA en el entorno corporativo ha creado una situación en la que los sistemas de IA se conectan a datos de producción antes de que se construya a su alrededor el perímetro de seguridad necesario. Con frecuencia, estas herramientas se perciben como «un SaaS más» y no como una infraestructura con acceso a recursos corporativos críticos.

El principio de mínimo privilegio (least privilege), la auditoría periódica de accesos, la monitorización de consultas anómalas y la segregación de entornos de prueba y producción no son conceptos nuevos. La seguridad informática los aplica a CRM, ERP y bases de datos desde hace décadas. Según IBM, al desplegar sistemas de IA este paso se omite de forma sistemática.

Qué significa

El estudio de IBM traslada el debate sobre seguridad de la IA del terreno de los riesgos algorítmicos al de la madurez organizativa. Las discusiones públicas sobre amenazas de la IA suelen centrarse en vulnerabilidades de los propios modelos: prompt injection, alucinaciones, comportamiento impredecible. Pero el panorama real de los incidentes, según IBM, es otro: nueve de cada diez empresas que sufrieron una brecha relacionada con IA habrían podido evitarla con medidas que los especialistas en seguridad de la información aplican desde hace décadas.

Para los CISO y los equipos de TI, esta es la conclusión clave: antes de escalar la infraestructura de IA, hay que asegurarse de que a su alrededor rigen los mismos estándares de control de acceso que se aplican a cualquier otra herramienta corporativa crítica.