IBM: у 92% компаний с AI-инцидентами не было базового контроля доступа

IBM investigó los incidentes de seguridad corporativa en sistemas de AI y registró un patrón que está cambiando las prioridades en el ámbito de la protección de la IA: el 92% de las empresas que sufrieron un incidente de este tipo no contaban con controles básicos de acceso a sus herramientas de AI. Al mismo tiempo, el propio modelo —su arquitectura, pesos o algoritmo— no fue la causa raíz del problema en la mayoría de los casos documentados.

Dónde surge realmente la vulnerabilidad

El 92% de las empresas con incidentes de AI no restringían quién podía acceder a sus sistemas de AI ni con qué permisos — este es el dato clave de la investigación de IBM. El control de acceso, la auditoría de permisos y el monitoreo de solicitudes al modelo estaban ausentes precisamente donde deberían haber sido la primera barrera de protección.

Al mismo tiempo, los atacantes generalmente no atacaban el modelo directamente. Explotaban vectores más sencillos: comprometían una cuenta con permisos excesivos, obtenían acceso a la interfaz de AI — y el propio sistema les proporcionaba a continuación la información que necesitaban.

• 92% de las empresas víctimas de incidentes de AI carecían de un control de acceso suficiente a los sistemas de AI
• El modelo de AI raramente era la causa raíz de la brecha de seguridad
• Principales vectores de ataque: permisos excesivos de cuentas de usuario y de servicio
• La ausencia de monitoreo de solicitudes anómalas a sistemas de AI agravaba la escala de los incidentes

El control de acceso a un sistema de AI no se limita a un nombre de usuario y una contraseña. En el contexto corporativo, implica permisos granulares: a qué datos y bases de conocimiento puede acceder el modelo, qué empleados y contratistas tienen derecho a enviar consultas y en qué volumen.

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

Las herramientas corporativas de AI acceden cada vez más ampliamente a datos empresariales críticos: bases de clientes, documentos financieros, correspondencia interna y materiales estratégicos. Precisamente esto las convierte en un objetivo valioso — no por las vulnerabilidades del propio modelo, sino por el tipo de datos a los que se puede acceder a través de él mediante consultas ordinarias.

Una instalación corporativa típica de AI conecta el modelo a documentos, datos de CRM, chats de trabajo y bases de conocimiento. Si no existen restricciones sobre lo que el sistema puede «ver» y entregar en respuesta a las consultas, la escala de una posible fuga de datos queda determinada únicamente por la amplitud del acceso a los datos que tenía la cuenta comprometida.

«El modelo en sí raramente resulta ser el problema», concluye la

investigación de IBM, que señala los factores organizativos y de configuración como la causa principal de la mayoría de los incidentes de AI documentados.

Por qué las medidas básicas siguen sin implementarse

La adopción acelerada de la AI en el entorno corporativo ha creado una situación en la que los sistemas de AI se conectan a datos de producción antes de que se establezca a su alrededor el perímetro de seguridad necesario. Las herramientas suelen percibirse como «un SaaS más», en lugar de como infraestructura con acceso a recursos corporativos críticos.

El principio de mínimo privilegio (least privilege), la auditoría regular de accesos, el monitoreo de solicitudes anómalas y la segregación de entornos de prueba y producción no son conceptos nuevos. La seguridad de TI los aplica a CRM, ERP y bases de datos desde hace décadas. Según IBM, este paso se omite sistemáticamente al desplegar sistemas de AI.

Qué significa esto

La investigación de IBM traslada la conversación sobre seguridad de AI del ámbito de los riesgos algorítmicos al de la madurez organizacional. Los debates públicos sobre amenazas de AI suelen centrarse en las vulnerabilidades de los propios modelos: prompt injection, alucinaciones, comportamiento impredecible. Sin embargo, el panorama real de los incidentes, según IBM, es diferente: nueve de cada diez empresas que sufrieron una brecha de AI podrían haberla evitado con medidas que los profesionales de la seguridad de la información llevan décadas aplicando.

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