81% das organizações relataram um ciberataque bem-sucedido à medida que a pressão da IA aumentava
O Google News destacou um número alarmante: cerca de 80% das organizações sofreram um ciberataque, enquanto a IA criou nova pressão sobre programas de segurança já sobrecarregados. O número soa como evidência de que a inteligência artificial subitamente comprometeu a segurança empresarial. A pesquisa subjacente sustenta uma conclusão mais complexa.
O dado verificado mais sólido vem do Relatório de Defesa contra Ciberameaças de 2026, promovido pelo Google Cloud e baseado em respostas de 1.200 profissionais de segurança. Ele constatou que 81% das organizações sofreram pelo menos um ciberataque bem-sucedido durante o ano anterior. Separadamente, 80% dos profissionais de segurança temiam que a IA pudesse afetar seus empregos.
Essas conclusões descrevem duas condições relacionadas, e não uma única categoria combinada de incidentes de IA. Os ciberataques continuam disseminados, enquanto a IA muda a forma como os atacantes operam, os defensores respondem e as empresas expõem dados. Tratar cada violação como um evento de IA ocultaria as falhas que continuam sendo mais importantes.
A Palo Alto Networks chegou a uma conclusão semelhante após responder a mais de 750 incidentes graves durante 2025. Seus pesquisadores constataram que lacunas evitáveis contribuíram materialmente para mais de 90% das violações investigadas. A IA acelerou partes do processo de ataque, mas visibilidade insuficiente, confiança excessiva e controles inconsistentes continuaram abrindo a porta.
O conflito real, portanto, é entre confiança e controle. As empresas estão implantando assistentes, agentes autônomos e ferramentas de desenvolvimento de IA mais rápido do que as equipes de segurança conseguem inventariá-los. Ao mesmo tempo, fragilidades conhecidas em identidade, correções, configuração de nuvem e resposta a incidentes permanecem sem solução.
O que a manchete do Google News realmente mede
O número de 80% sinaliza uma ampla taxa de falhas em cibersegurança, e não prova de que a IA causou quatro em cada cinco incidentes.
O benchmark de ciberameaças afirma que 81% das organizações sofreram um ciberataque bem-sucedido durante o ano anterior. A CyberEdge entrevistou 1.200 profissionais de segurança de TI em 17 países e 19 setores para o relatório.
A mesma pesquisa constatou que 67% esperavam um ataque bem-sucedido durante o ano seguinte. Também informou que 64% haviam enfrentado ransomware, enquanto 55% dos respondentes afetados pagaram. Entre os que pagaram, 39% ainda não conseguiram recuperar seus dados.
Esses números descrevem o ambiente geral de ameaças. Eles incluem ransomware, comprometimento de contas, roubo de dados, ataques à nuvem e outras classes estabelecidas de incidentes. O resumo não afirma que a IA causou 81% desses ataques bem-sucedidos.
Essa distinção importa porque a agregação pode condensar várias alegações separadas em uma única manchete dramática. Uma listagem do Google News pode colocar IA, cibersegurança e uma estatística de 80% lado a lado. Os leitores podem então inferir uma relação causal que a pesquisa de origem não estabeleceu.
A constatação da pesquisa sobre IA dizia respeito à força de trabalho de segurança. Oitenta por cento dos respondentes temiam que a IA pudesse afetar seus empregos, enquanto 97% dos gestores de contratação buscavam candidatos com habilidades em IA. Essa combinação sugere mudança de função e pressão por competências, em vez de simples substituição.
A IA ainda faz parte da história. Os atacantes a usam para acelerar pesquisas, criar iscas convincentes, solucionar problemas em código malicioso e operar contra mais alvos. Os defensores a usam para triar alertas, identificar comportamento suspeito e automatizar a contenção.
No entanto, uma campanha de phishing assistida por IA ainda pode ter sucesso porque um funcionário entregou credenciais. Uma violação em uma aplicação de IA pode começar com um plug-in vulnerável ou uma API exposta. Uma intrusão na nuvem pode se ampliar porque uma conta de serviço tem permissões excessivas.
Chamar todos esses eventos de “incidentes de IA” tornaria a estatística menos útil. Líderes de segurança precisam saber se a IA foi o alvo, a ferramenta de ataque, a aplicação vulnerável ou apenas parte do ambiente ao redor.
A categoria também afeta a responsabilização. Uma empresa pode culpar ameaças avançadas de IA enquanto ignora um sistema sem correção ou uma política permissiva de identidade. Essa explicação faz o incidente parecer inevitável, mesmo quando controles já estabelecidos poderiam ter reduzido os danos.
Leitores do Google News devem, portanto, interpretar a manchete como um alerta sobre riscos sobrepostos. Os incidentes cibernéticos já são comuns, e a IA está sendo adicionada a sistemas que têm dívida de segurança persistente.
O número de 81% continua alarmante sem exageros. Ele mostra que ataques bem-sucedidos se tornaram uma condição operacional normal para muitas organizações. Não estabelece que a IA causou esses ataques de forma independente.
Essa distinção fornece o teste central para cada nova alegação sobre segurança de IA. Pergunte o que a pesquisa mediu, quem a respondeu e como os pesquisadores definiram um incidente. Em seguida, pergunte se a IA causou a falha ou amplificou uma fragilidade existente.
A adoção de IA está avançando mais rápido do que a preparação em segurança
As empresas estão colocando IA em produção enquanto processos de visibilidade, responsabilidade e investigação permanecem incompletos.
O estudo AI and Human Risk Landscape de 2026, da Proofpoint, entrevistou mais de 1.400 profissionais de segurança em 12 países. Ele constatou que 87% das organizações haviam implantado assistentes de IA além da fase piloto. Outras 76% estavam testando ou implementando agentes autônomos.
Um agente autônomo é um software que pode perseguir um objetivo e tomar ações em sistemas conectados com orientação humana limitada. Essa capacidade diferencia os agentes de chatbots que apenas produzem texto. Ela também dá aos agentes acesso a credenciais, repositórios de dados, ferramentas de colaboração e fluxos de trabalho empresariais.
A pesquisa sobre riscos de IA constatou que 42% dos respondentes haviam vivenciado um incidente de IA suspeito ou confirmado. Apenas um terço disse estar totalmente preparado para investigar um incidente que abrange múltiplos sistemas e canais de comunicação.
A cobertura de segurança não garantiu confiança. Embora 63% tenham relatado possuir cobertura de segurança para IA, 52% não estavam totalmente confiantes de que esses controles detectariam um sistema de IA comprometido. Mais da metade das organizações com controles ainda relatou um incidente relacionado à IA.
A exposição foi além de produtos dedicados de IA. Os respondentes identificaram o e-mail como o vetor de ameaça mais comum, seguido por software de terceiros, aplicações em nuvem, plataformas sociais e sistemas de mensagens. Assistentes e agentes de IA acrescentaram outra superfície conectada.
Isso importa porque a IA empresarial raramente opera sozinha. Um assistente pode ler e-mails, pesquisar documentos, chamar um modelo externo e publicar uma resposta em um canal de colaboração. Cada conexão cria outro ponto em que permissões, monitoramento ou tratamento de dados podem falhar.
A Cloud Security Alliance identificou um problema de visibilidade ainda mais acentuado. Sua pesquisa de janeiro de 2026 abrangeu 418 profissionais de TI e segurança de organizações de diferentes tamanhos e localidades.
Segundo a pesquisa sobre segurança de agentes, 82% dos respondentes descobriram agentes de IA anteriormente desconhecidos durante o ano anterior. Quarenta e um por cento fizeram essa descoberta mais de uma vez.
Agentes desconhecidos apareceram com mais frequência em automação interna, ambientes de scripting, plataformas de modelos de linguagem, serviços de software com automação incorporada e fluxos de trabalho de desenvolvedores. Esses locais frequentemente ficam fora do processo de compra monitorado pelas equipes de segurança.
O mesmo estudo constatou que 65% haviam enfrentado pelo menos um incidente relacionado a agentes de IA. Entre as organizações afetadas, 61% relataram exposição de dados, 43% relataram interrupção operacional e 35% relataram consequências financeiras.
A pesquisa foi encomendada e financiada pela Token Security, fornecedora de segurança de identidade para IA. Essa relação não invalida os resultados, mas deve orientar a forma como os leitores os avaliam. Pesquisas patrocinadas por fornecedores frequentemente enfatizam problemas ligados ao mercado do patrocinador.
A metodologia também se baseia em relatos dos respondentes, e não em registros de incidentes verificados. Termos como “incidente relacionado à IA” podem abranger eventos com diferentes causas e gravidades. Um respondente pode contabilizar experimentação não autorizada, enquanto outro contabiliza roubo de dados confirmado.
Mesmo com essas ressalvas, estudos separados revelam um padrão consistente. A adoção de IA avançou além de testes isolados, mas muitas organizações não têm inventários completos nem procedimentos de investigação.
A pressão recai sobre diretores de segurança da informação, equipes de nuvem, desenvolvedores e gestores de negócios. Eles precisam apoiar uma implantação rápida enquanto determinam o que cada sistema de IA pode acessar e quem é responsável por seu comportamento.
Os trabalhadores do conhecimento também moldam esse risco. Funcionários podem colar material sensível em contas pessoais de IA ou conectar assistentes não aprovados a serviços da empresa. Uma base de conhecimento de IA clara pode reduzir a confusão sobre onde as informações aprovadas devem ficar, mas não pode substituir controles de acesso.
As equipes de segurança enfrentam, portanto, dois caminhos de adoção. O caminho oficial inclui ferramentas aprovadas, avaliações de risco e implantações monitoradas. O caminho paralelo começa quando as equipes criam agentes ou integrações sem revisão centralizada.
Ambos os caminhos podem gerar valor para o negócio. Apenas um fornece de forma confiável aos defensores o contexto necessário para investigar um incidente.
O conflito real é entre confiança e controle
Líderes de segurança frequentemente expressam confiança enquanto seus ambientes técnicos mostram vulnerabilidades sem solução, credenciais expostas e proteções insuficientes para agentes.
A Orca Security abordou o problema por meio de telemetria de nuvem, e não de uma pesquisa de opinião. Seu relatório State of AI Security de 2026 analisou dados do segundo trimestre de mais de 1.200 organizações em produção na Amazon Web Services, Microsoft Azure e Google Cloud.
A análise abrangeu pacotes de IA, endpoints de modelos, infraestrutura em nuvem, credenciais e implantações de agentes. Mais da metade das organizações observadas tinha IA em execução em produção.
A Orca constatou que 81% das organizações que executavam pacotes de software de IA tinham pelo menos uma vulnerabilidade conhecida. A pontuação média de gravidade entre os pacotes afetados chegou a 8,79 no Common Vulnerability Scoring System, de dez pontos.
Uma pontuação de vulnerabilidade estima a gravidade técnica de uma falha de software. Ela não prova exploração, mas uma pontuação maior geralmente indica maior impacto potencial ou abuso mais fácil.
As constatações de telemetria de nuvem também informaram que 50,1% dos alertas de vulnerabilidades de IA tinham um exploit público disponível. A Orca disse que o número correspondente era de 0,2% em seu relatório de 2024.
De forma mais marcante, 99,9% dos alertas de vulnerabilidades de IA com uma correção disponível permaneciam sem correção. Esse número descreve alertas observados pela plataforma da Orca, e não todos os sistemas de IA do mundo. Ainda assim, mostra a rapidez com que exposições identificáveis podem se acumular.
O relatório constatou que 29,5% dos adotantes de IA armazenavam pelo menos uma credencial de IA em um local inseguro. Também constatou que 56% haviam implantado frameworks de agentes em produção, frequentemente sem controles formais de segurança.
As credenciais são especialmente importantes porque os agentes precisam de autoridade para agir. Um agente pode ter uma chave de API, token de nuvem, senha de banco de dados ou autorização de software. Se invasores capturarem essa credencial, poderão herdar o acesso do agente.
A questão não é apenas se um modelo produz uma resposta insegura. O perigo maior começa quando o software consegue transformar uma resposta em uma ação externa. Um agente pode enviar uma mensagem, modificar um registro, recuperar dados confidenciais ou executar código.
Os sistemas tradicionais de identidade pressupõem que uma pessoa tenha uma função relativamente estável e necessidades de acesso previsíveis. Agentes podem ser criados rapidamente, duplicados em diferentes fluxos de trabalho e abandonados após um projeto. Suas permissões podem permanecer ativas depois que sua finalidade original desaparece.
A Cloud Security Alliance chama parte desse problema de “dívida de aposentadoria”. Apenas 21% dos participantes de seu estudo possuíam um processo formal para desativar agentes. Um agente abandonado pode reter credenciais e permissões muito tempo depois de deixar de ser monitorado ativamente.
É aqui que a confiança se separa do controle. Um líder de segurança pode acreditar que a organização tem políticas robustas de IA enquanto agentes desconhecidos continuam operando. Uma equipe pode instalar um produto de varredura e, ainda assim, deixar vulnerabilidades corrigíveis sem solução.
Portanto, o investimento em segurança não pode ser medido apenas pelo número de ferramentas implantadas. As perguntas mais relevantes dizem respeito à cobertura e aos resultados.
A organização consegue identificar todos os agentes em produção? Consegue atribuir um responsável a cada um? Consegue explicar quais fontes de dados o agente lê e quais ações ele pode executar?
Os defensores conseguem revogar o acesso do agente sem interromper sistemas não relacionados? Conseguem reconstruir suas ações após um incidente? Conseguem distinguir uma instrução maliciosa de uma tarefa comercial aprovada?
Se a resposta for não, a confiança se apoia em suposições. Essas suposições se tornam perigosas quando agentes operam em recursos de nuvem e documentos internos.
Uma base de conhecimento técnico pesquisável pode ajudar as equipes a preservar decisões de arquitetura, registros de responsabilidade e evidências de incidentes. Ainda assim, a documentação deve permanecer conectada aos dados ativos de identidade e monitoramento.
O principal equilíbrio não é entre inovação e segurança. É entre velocidade de implantação e controle verificável. As organizações podem avançar rapidamente, mas cada nova conexão precisa permanecer identificável e atribuível.
A IA Amplifica Falhas Antigas com Mais Frequência do que Cria Novas
As falhas de segurança de IA mais prejudiciais frequentemente começam com fragilidades conhecidas de identidade, configuração, aplicação de patches e confiança humana.
Os dados de resposta a incidentes da Unit 42, da Palo Alto Networks, oferecem um contraponto importante às manchetes de pesquisas. Seu relatório de 2026 se baseou em mais de 750 incidentes graves em mais de 50 países.
Os pesquisadores afirmaram que os invasores ainda estavam nos estágios iniciais da adoção de técnicas habilitadas por IA. A IA já reduziu o atrito em reconhecimento, engenharia social, criação de scripts, solução de problemas e extorsão. Ainda assim, as invasões normalmente seguiram caminhos conhecidos.
Segundo os dados de resposta a incidentes, lacunas evitáveis contribuíram de forma material para mais de 90% das violações investigadas. Essas lacunas incluíam telemetria incompleta, controles inconsistentes, confiança excessiva em identidades e conexões de terceiros não gerenciadas.
Essa evidência desafia a ideia de que os defensores precisam de uma arquitetura de segurança inteiramente nova para cada ameaça de IA. Alguns controles especializados são necessários, especialmente para prompts, modelos, agentes e identidades de máquina. O trabalho fundamental de segurança ainda determina o resultado.
A Gartner apresentou um ponto semelhante após pesquisar 302 líderes de cibersegurança na América do Norte, Europa, Oriente Médio, África e Ásia-Pacífico. A pesquisa foi realizada de março a maio de 2025.
Sessenta e dois por cento dos participantes haviam enfrentado um ataque de deepfake envolvendo engenharia social ou processos automatizados. Trinta e dois por cento relataram um ataque a uma aplicação de IA, enquanto 29% citaram um ataque à infraestrutura de IA generativa.
Deepfakes usam mídia gerada ou manipulada para imitar uma pessoa real. Eles podem tornar fraudes e falsificações de identidade mais convincentes, mas os invasores ainda precisam de um processo que aceite a identidade falsa.
A pesquisa sobre ataques com GenAI constatou que 67% dos líderes de cibersegurança esperavam que os riscos emergentes de IA exigissem mudanças significativas. A Gartner recomendou fortalecer os controles centrais enquanto se adicionam medidas direcionadas para novas categorias de risco.
Essa abordagem equilibrada evita dois erros caros. O primeiro é tratar a IA como software comum e ignorar sua capacidade de processar instruções ou agir de forma autônoma. O segundo é culpar a IA enquanto se negligencia a segurança fundamental.
Considere um funcionário que recebe uma ligação de voz gerada por IA de alguém se passando por um executivo. A síntese de voz aumenta a credibilidade da ligação. A perda ainda depende de os procedimentos financeiros permitirem que uma única solicitação por voz autorize uma transferência.
Considere um assistente de programação que introduz uma dependência vulnerável. A IA pode acelerar o erro, mas a análise de composição de software e a revisão de código ainda podem detectá-lo. O controle subjacente continua sendo conhecido.
Considere um agente com permissão para pesquisar arquivos internos e enviar os resultados por e-mail. A manipulação de prompts pode influenciar seu comportamento. O acesso excessivo determina quanta informação ele pode expor.
A pesquisa Cost of a Data Breach 2026, da IBM, acrescenta contexto financeiro. O relatório examinou violações sofridas por 602 organizações entre março de 2025 e fevereiro de 2026.
A IBM informou que uma em cada quatro violações maliciosas usou IA e teve um custo médio de US$ 6 milhões. A média global entre as violações foi de US$ 4,99 milhões. As violações habilitadas por IA incluíram falsificação de identidade por deepfake e malware assistido por IA.
Mais de 20% das organizações participantes relataram uma violação direcionada a modelos ou aplicações de IA. As causas mais comuns envolveram APIs, aplicações, plug-ins e configurações incorretas de nuvem comprometidos em torno de cargas de trabalho de IA.
O estudo sobre custo de violações também constatou que organizações que usam IA e automação em operações de segurança reduziram os custos de violações em quase US$ 2 milhões, em média.
Esse resultado mostra a IA operando nos dois lados da disputa. Os invasores podem reduzir o custo de atacar organizações. Os defensores podem reduzir o tempo de investigação e automatizar a contenção.
A pergunta importante não é se uma empresa usa IA. É se a organização aplica IA dentro de um sistema de segurança disciplinado.
A automação sem dados confiáveis pode acelerar decisões ruins. Uma resposta automatizada pode desativar um serviço legítimo ou deixar de detectar atividade ocorrendo fora dos canais monitorados. Um modelo treinado com alertas incompletos pode reproduzir os pontos cegos já presentes no programa de segurança.
Os estudos subjacentes também apresentam limitações. Pesquisas medem percepções e eventos autorrelatados. A telemetria de fornecedores cobre clientes e ambientes visíveis a uma plataforma específica. Relatórios de resposta a incidentes se concentram em organizações com problemas suficientemente graves para solicitar ajuda externa.
Essas amostras não devem ser combinadas em uma única taxa universal de incidentes. Elas medem populações, definições e períodos diferentes. Seu valor está na direção recorrente dos resultados.
Em todas as pesquisas, as organizações estão adotando IA rapidamente. A visibilidade e a governança frequentemente ficam para trás. Os invasores exploram tanto novas superfícies de IA quanto fraquezas conhecidas.
As evidências não sustentam a afirmação de que a IA causou todos os incidentes na manchete do Google News. Elas sustentam uma conclusão mais restrita e acionável: a IA aumenta a velocidade e a escala onde controles fracos já existem.
Três Sinais Mostrarão se a Lacuna Está Diminuindo
Cobertura de inventário, velocidade de correção e prontidão para investigação revelarão mais do que outra pesquisa de confiança.
O primeiro sinal é se as organizações conseguem produzir um inventário completo de sistemas e agentes de IA. Esse inventário deve incluir responsáveis, credenciais, dados conectados, ações aprovadas e datas de desativação.
Os números de descoberta devem inicialmente aumentar à medida que as empresas pesquisam com mais cuidado. Encontrar mais agentes ocultos pode indicar melhora na visibilidade, e não piora no comportamento. O teste mais forte é verificar se as implantações desconhecidas diminuem após esse primeiro ciclo de inventário.
Um programa confiável também deve distinguir experimentos de serviços em produção. Um protótipo temporário não apresenta o mesmo risco que um agente que processa registros de clientes. Ambos ainda precisam de um responsável e de uma política de expiração.
O segundo sinal é a velocidade de correção. A descoberta da Orca sobre alertas sem patches importa porque existia uma correção para as vulnerabilidades medidas. Relatórios futuros devem mostrar se as organizações reduzem o tempo entre divulgação, priorização e implantação.
Percentuais brutos de aplicação de patches podem induzir ao erro quando os alertas incluem software inacessível ou não utilizado. As equipes de segurança devem priorizar exposições conforme explorabilidade, acesso à internet, privilégio e proximidade de dados sensíveis. Também devem documentar por que qualquer correção é adiada.
Uma fila pendente em queda reforçaria a visão de que as operações de segurança estão alcançando o ritmo. Uma fila pendente em crescimento mostraria que o desenvolvimento de IA continua adicionando software mais rapidamente do que as equipes conseguem avaliá-lo.
O terceiro sinal é a prontidão para investigação. A Proofpoint constatou que apenas um terço dos participantes se sentia totalmente preparado para investigar um incidente de IA que abrangesse vários sistemas. Esse número deve melhorar à medida que as organizações unificam logs e estabelecem procedimentos de resposta.
Um exercício útil deve rastrear um agente em todo o seu fluxo de trabalho. Os investigadores precisam da instrução original, dos dados recuperados, da saída do modelo, das chamadas de ferramentas, das decisões de identidade e das ações resultantes.
Eles também precisam ter autoridade para conter o problema. Registrar uma ação insegura depois que ela ocorre não é o mesmo que evitá-la. Transações de alto risco devem exigir aprovação ou um limite de política aplicável.
Reguladores e organismos de padronização influenciarão esses sinais, mas as evidências internas devem chegar primeiro. Os conselhos não precisam esperar por uma nova exigência antes de perguntar se todo agente em produção tem um responsável definido.
Os compradores de segurança também devem resistir a promessas simplistas. Um produto que “protege a IA” pode cobrir modelos, código, identidades, prompts ou dados, mas raramente todos eles. Os compradores precisam mapear cada ferramenta a uma exposição verificada.
O Google News continuará produzindo manchetes alarmantes sobre segurança de IA porque as condições por trás delas permanecem reais. A melhor resposta não é outra declaração ampla de confiança.
Peça à sua organização três artefatos: um inventário atual de IA, um relatório de correção de exposições e os resultados de um exercício de incidente de IA. Se as equipes não conseguirem produzi-los, a lacuna de segurança continuará mensurável. Se conseguirem, compare esses registros novamente no próximo trimestre e procure menos agentes desconhecidos, correções mais rápidas e investigações mais completas.
