IBM: 92% das empresas com incidentes de IA não tinham controle de acesso básico

A IBM investigou incidentes de segurança corporativos em sistemas de IA e identificou um padrão que muda as prioridades na proteção de IA: 92% das empresas que passaram por um incidente desse tipo não tinham controle de acesso básico às suas ferramentas de IA. Na maioria dos casos registrados, o modelo em si (sua arquitetura, seus pesos ou seu algoritmo) não foi a causa original do problema.

Onde a vulnerabilidade realmente surge

Esse é o número central do estudo da IBM: 92% das empresas com incidentes de IA não limitavam quem podia acessar seus sistemas de IA, nem com quais permissões. Controle de acesso, auditoria de permissões e monitoramento das chamadas ao modelo estavam ausentes justamente onde deveriam funcionar como a primeira barreira de proteção.

Os invasores, em geral, não atacaram o modelo diretamente. Eles exploraram vetores mais simples: comprometeram uma conta com permissões excessivas e obtiveram acesso à interface de IA. A partir daí, o próprio sistema entregava a eles as informações desejadas.

• 92% das empresas vítimas de incidentes de IA não tinham controle de acesso suficiente aos sistemas de IA
• O modelo de IA raramente foi a causa original da violação de segurança
• Os principais vetores de ataque: permissões excessivas de usuários e de contas de serviço
• A falta de monitoramento de requisições anômalas ao sistema de IA ampliou a escala dos incidentes

Controlar o acesso a um sistema de IA vai além de login e senha. No contexto corporativo, isso significa permissões granulares: quais dados e bases de conhecimento o modelo pode acessar, e quais funcionários e prestadores de serviço podem enviar requisições, e em que volume.

Por que os sistemas de IA se tornaram alvos atraentes

As ferramentas de IA corporativas recebem acesso cada vez mais amplo a dados críticos do negócio: bases de clientes, documentos financeiros, correspondência interna e materiais estratégicos. É isso que as torna um alvo valioso, não por vulnerabilidades do modelo em si, mas pelos dados que se podem alcançar por meio dele com requisições comuns.

Uma instalação corporativa típica de IA conecta o modelo a documentos, dados de CRM, chats de trabalho e bases de conhecimento. Se não há limites para o que o sistema pode "ver" e devolver em resposta às requisições, a escala do vazamento potencial depende apenas da amplitude do acesso a dados que a conta comprometida tinha.

"O modelo em si raramente é o problema", conclui o estudo da IBM, que

aponta fatores organizacionais e de configuração como a principal causa da maioria dos incidentes de IA registrados.

Por que as medidas básicas continuam sem implementação

A adoção acelerada de IA no ambiente corporativo criou uma situação em que os sistemas de IA são conectados a dados de produção antes de o perímetro de segurança necessário ser construído ao redor deles. Com frequência, as ferramentas são vistas como "mais um SaaS", e não como infraestrutura com acesso a recursos corporativos críticos.

O princípio do menor privilégio (least privilege), a auditoria regular de acessos, o monitoramento de requisições anômalas e a segregação entre ambientes de teste e de produção não são conceitos novos. A segurança da informação os aplica a CRM, ERP e bancos de dados há décadas. Segundo a IBM, esse passo é sistematicamente ignorado na implantação de sistemas de IA.

O que isso significa

O estudo da IBM desloca a conversa sobre segurança de IA do campo dos riscos algorítmicos para o da maturidade organizacional. O debate público sobre ameaças de IA costuma se concentrar em vulnerabilidades dos próprios modelos: prompt injection, alucinações, comportamento imprevisível. Mas o quadro real dos incidentes, segundo a IBM, é outro: nove em cada dez empresas que enfrentaram uma violação envolvendo IA poderiam tê-la evitado com medidas que os especialistas em segurança da informação aplicam há décadas. Para CISOs e equipes de TI, essa é a conclusão principal: antes de escalar a infraestrutura de IA, é preciso garantir que ela opere com os mesmos padrões de controle de acesso que valem para qualquer outra ferramenta corporativa crítica.