Kiteworks alerta que 80% das organizações enfrentaram incidentes de segurança ou IA enquanto a governança ficava para trás

A Kiteworks chegou ao Google News com uma afirmação contundente: 80% das organizações sofreram um incidente de segurança ou de IA, enquanto a preparação em governança permanecia criticamente baixa. O número chama atenção, mas o conflito mais profundo está entre políticas escritas e controles que funcionam durante o uso real de IA.

A manchete, publicada pela Cybersecurity Insiders, surge no momento em que empresas concedem a sistemas de IA acesso a documentos privados, aplicações de negócios e fluxos de trabalho internos. Essas conexões ampliam as consequências de permissões fracas, registros incompletos e movimentação desconhecida de dados.

A Kiteworks tem interesse comercial nessa discussão porque vende tecnologia de segurança e governança de dados privados. Portanto, suas conclusões merecem escrutínio, não aceitação automática. Ainda assim, diversos números de apoio revelam um problema de governança que vai além da narrativa de um único fornecedor.

O que o relatório da Kiteworks realmente muda

O relatório transforma a governança de IA de um debate sobre políticas em um problema de resposta a incidentes.

A matéria no Google News apresenta o índice de 80% como a principal conclusão. No entanto, a manchete por si só não explica se essa porcentagem combina violações confirmadas, eventos suspeitos, violações de políticas ou falhas específicas de IA.

Essa distinção importa. Uma violação convencional de dados, um funcionário que envia texto confidencial a um chatbot não aprovado e um agente autônomo que toma uma ação não intencional são eventos diferentes. Eles exigem controles distintos e geram diferentes níveis de dano.

Por isso, os leitores devem tratar a porcentagem da manchete como um resultado de pesquisa relatado pelo fornecedor. Ela não é uma medida de violações verificadas de forma independente em toda a economia. Materiais públicos da Kiteworks sustentam a preocupação mais ampla com governança, mas não tornam todas as categorias de incidentes equivalentes.

Uma pesquisa global anterior da Kiteworks consultou 461 organizações na América do Norte, Europa, Ásia-Pacífico e Oriente Médio. A cobertura dessa pesquisa constatou que apenas 17% haviam implementado integralmente estruturas técnicas de governança de IA.

Essa é a referência mais útil. Governança técnica de IA significa controles aplicáveis que abrangem acesso a dados, uso de modelos, monitoramento, retenção e tratamento de incidentes. Um documento de política sem esses controles não consegue impedir que um funcionário, uma aplicação ou um agente exponha informações protegidas.

A mesma pesquisa associou visibilidade limitada a resultados mais fracos. Segundo um relatório independente, 46% das organizações que não sabiam quantos terceiros possuíam também não conseguiam identificar sua frequência de violações.

Entre as organizações incertas sobre violações, 42% também tinham incerteza sobre os tempos de detecção. Outras 48% não conseguiam quantificar os custos de litígios, segundo a cobertura.

Essas relações não estabelecem que a baixa visibilidade causou todas as violações. Elas mostram que organizações incapazes de inventariar sistemas e parceiros também têm dificuldade para medir as consequências.

A análise da Kiteworks sobre o setor de tecnologia em 2026 oferece outra perspectiva. Ela consultou 225 líderes de segurança, TI, conformidade e risco em 10 setores e oito regiões. Trinta e dois respondentes representavam organizações de tecnologia, enquanto 97% de todos os participantes trabalhavam em organizações com pelo menos 1.000 funcionários.

Essa amostra é relevante para o risco em grandes empresas, mas não representa todos os negócios. O subconjunto de tecnologia é particularmente pequeno. Diferenças percentuais dentro dessas 32 respostas devem ser interpretadas como conclusões direcionais, não como estimativas precisas do setor.

Mesmo com essas limitações, o relatório identifica um problema consistente. As organizações investiram em práticas de governança visíveis, mas os controles fundamentais permanecem incompletos.

Isso é o que mudou. Incidentes de segurança de IA já não são casos extremos hipotéticos ligados a futuros sistemas autônomos. Empresas estão relatando incidentes enquanto capacidades essenciais de inventário, proveniência e aplicação de controles continuam inacabadas.

Por que o Google News está destacando agora a lacuna de governança

A adoção de IA passou de sessões isoladas de chat para sistemas capazes de recuperar dados, chamar ferramentas e agir em processos de negócios.

Um chatbot que responde a uma pergunta geral tem acesso limitado. Um agente de IA conectado a e-mail, armazenamento em nuvem, registros de clientes, código-fonte ou sistemas financeiros opera em uma superfície de ataque muito maior.

IA agêntica refere-se a software capaz de planejar e executar múltiplas ações em direção a um objetivo. Seu risco depende menos da fluência conversacional e mais de identidade, permissões, ferramentas disponíveis e dos dados que consegue alcançar.

Isso cria várias rotas para um incidente. Um agente pode receber privilégios excessivos, seguir instruções maliciosas incorporadas em um documento, divulgar informações recuperadas ou disparar uma ação fora de sua finalidade pretendida.

Os funcionários também criam exposição por meio da IA sombra, ou seja, ferramentas de IA usadas sem aprovação ou monitoramento formal. O risco aumenta quando essas ferramentas retêm prompts, treinam com conteúdo enviado ou se conectam a contas organizacionais.

Programas de segurança tradicionais já gerenciam identidade, endpoints, aplicações e tráfego de rede. A IA adiciona uma camada de raciocínio que pode combinar informações e iniciar ações na velocidade das máquinas.

Isso não torna todos os sistemas de IA imprevisíveis. Significa, porém, que uma aprovação estática durante a implantação não pode substituir a observação contínua após a implantação.

O momento também reflete pressão regulatória. A Lei de IA da União Europeia entrou em vigor em 2024, e suas obrigações seguem um cronograma escalonado. Os requisitos de governança para modelos de IA de propósito geral começaram a ser aplicados em agosto de 2025.

O cronograma de implementação da Comissão Europeia mostra que diferentes disposições e prazos transitórios se aplicam em momentos distintos. As organizações precisam identificar quais sistemas, funções de fornecedor e casos de uso se enquadram em cada obrigação.

Esse cronograma em evolução complica o planejamento de conformidade, mas não elimina a necessidade de um inventário. Uma empresa não consegue classificar um sistema de IA, documentar seus riscos ou aplicar os controles corretos se ninguém souber que ele existe.

A regulamentação é apenas uma fonte de pressão. Clientes perguntam cada vez mais aos fornecedores como a IA processa informações confidenciais. Seguradoras, auditores, conselhos e equipes de compras também querem evidências de que os controles operam conforme descrito.

A exigência de evidências muda o significado de preparação. Uma empresa não está preparada porque seus executivos aprovaram uma política de IA. Ela está preparada quando as equipes conseguem mostrar quem acessou os dados, qual modelo os recebeu, o que o sistema fez e como a organização respondeu.

É por isso que as conclusões da Kiteworks sobre governança de IA repercutem além da base de clientes do fornecedor. Elas descrevem uma lacuna operacional já visível em análises de segurança e compras corporativas.

O Google News está amplificando a estatística de incidentes em um momento em que executivos reconhecem o problema, mas não têm provas consistentes. A manchete chama atenção porque a adoção superou os sistemas necessários para observá-la.

As promessas de governança estão superando o controle técnico

O conflito principal não é adoção de IA versus cautela; é governança prometida no papel versus governança aplicada em produção.

O relatório da Kiteworks para o setor de tecnologia ilustra essa divisão. As organizações de tecnologia lideraram a amostra global em diversas capacidades formais de governança.

O setor relatou técnicas de preservação da privacidade em 56%, em comparação com 33% no resultado global. Taxonomias de incidentes de IA e manuais de resposta chegaram a 50%, contra 27% globalmente.

Os respondentes do setor de tecnologia também relataram avaliações de impacto de IA em 53%, auditorias de viés em 47% e documentação de explicabilidade de modelos em 41%. Cada resultado superou o número global correspondente.

São investimentos significativos. Avaliações de impacto podem identificar grupos afetados e danos previsíveis. Manuais de resposta a incidentes dão às equipes responsabilidades predefinidas quando um modelo se comporta de forma inesperada.

No entanto, o mesmo relatório do setor de tecnologia encontrou resultados mais fracos em infraestrutura menos visível.

Apenas 22% dos respondentes de tecnologia relataram ambientes de treinamento isolados, contra 26% globalmente. O isolamento separa recursos de desenvolvimento, treinamento e produção para que os dados não possam circular entre eles sem controle.

Apenas 19% relataram capacidades de proveniência e linhagem, em comparação com 23% globalmente. A proveniência de dados registra de onde a informação se originou, como ela mudou e quais modelos ou processos a utilizaram.

Isso cria uma contradição prática. Uma empresa pode detectar comportamento incomum e possuir um documento de resposta, mas ainda assim não conseguir rastrear a saída afetada até seus dados de origem.

Ela também pode manter controles de acesso em produção enquanto deixa ambientes de desenvolvimento de modelos conectados de forma excessivamente ampla. Essa lacuna aumenta o risco de acesso não autorizado, material de treinamento contaminado ou movimentação não intencional de dados.

Os respondentes de tecnologia tiveram melhor desempenho em trilhas de auditoria imutáveis, monitoramento de desvio e manuais de resposta a incidentes. Esses controles ajudam as equipes a perceber que algo mudou.

Uma linhagem fraca dificulta explicar por que isso mudou. Ela pode atrasar a análise de causa raiz e tornar mais difícil prevenir recorrências.

O relatório também constatou que 53% dos respondentes de tecnologia disseram que os conselhos priorizavam a governança de IA. Ainda assim, apenas 47% relataram atenção do conselho à postura geral de risco cibernético, sete pontos percentuais abaixo do número global.

Esse resultado não prova que os conselhos abandonaram a cibersegurança. Ele sugere que a atenção da liderança pode se deslocar para iniciativas de IA mais visíveis, enquanto a segurança fundamental disputa o mesmo tempo e orçamento.

A governança de IA não pode ficar ao lado da cibersegurança como um projeto isolado de conformidade. Ela depende de gestão de identidade, criptografia, classificação de dados, segurança de software, supervisão de terceiros e resposta a incidentes.

O Instituto Nacional de Padrões e Tecnologia dos EUA reflete essa abordagem de ciclo de vida. Sua estrutura voluntária de risco de IA organiza o trabalho em torno de quatro funções: Governar, Mapear, Medir e Gerenciar.

A governança estabelece responsabilidades e políticas. O mapeamento identifica o contexto e as partes afetadas. A medição avalia o risco, enquanto a gestão o prioriza e trata.

Uma empresa que para na governança concluiu apenas parte desse ciclo. As políticas precisam estar conectadas a observações técnicas, resultados de testes e decisões de resposta.

Essa é a inversão central por trás da manchete. As organizações podem parecer preparadas porque têm comitês, padrões e ferramentas aprovadas. Incidentes de segurança de IA revelam se esses preparativos alcançam os sistemas que lidam com dados reais.

Incidentes de segurança de IA expõem o problema de inventário

As organizações não conseguem controlar fluxos de dados de IA que não conseguem identificar, classificar e reconstruir.

O inventário parece básico, mas a IA o torna difícil. Um único processo de negócios pode envolver um funcionário, um aplicativo de software, um provedor externo de modelos, infraestrutura de recuperação e vários repositórios de dados.

A empresa pode possuir apenas parte dessa cadeia. Uma plataforma de atendimento ao cliente pode adicionar recursos generativos por meio de um modelo de terceiros. Um desenvolvedor pode conectar um assistente de programação a repositórios privados.

Outra equipe pode criar um agente interno que recupera documentos de armazenamento compartilhado. Cada implantação pode criar condições distintas de retenção, permissões e registro de logs.

Portanto, um inventário útil deve registrar mais do que nomes de produtos. Ele deve identificar proprietários de sistemas, finalidades pretendidas, provedores de modelos, dados conectados, ferramentas disponíveis, grupos de usuários e locais geográficos de processamento.

Também deve registrar se o sistema pode executar ações. Um assistente que redige um e-mail cria um nível de risco. Um agente autorizado a enviar esse e-mail ou modificar uma conta cria outro.

As conclusões da Kiteworks sobre a visibilidade de terceiros se encaixam nesse problema. Fornecedores e integrações desconhecidos podem ocultar caminhos pelos quais dados privados circulam.

A organização pode ter aprovado o aplicativo visível, mas não compreender todos os processadores que operam por trás dele. Isso se torna importante quando um provedor de modelos, plug-in ou serviço de dados muda.

A mesma questão aparece na soberania de dados. A pesquisa de 2026 da Kiteworks constatou que cerca de quatro em cada cinco respondentes se consideravam bem informados sobre os requisitos de soberania. Ainda assim, aproximadamente um terço relatou um incidente relacionado à soberania no ano anterior.

A soberania de dados diz respeito ao controle jurídico e operacional sobre onde as informações residem e qual jurisdição as rege. A IA complica isso quando prompts, embeddings, logs e saídas de modelos atravessam fronteiras regionais.

O relatório sobre soberania enquadra a lacuna como uma diferença entre conscientização e controle comprovável. As organizações podem entender as regras, mas não dispor de aplicação automatizada ou evidências prontas para auditoria.

Esse contraste é mais defensável do que tratar cada evento relatado como o mesmo tipo de incidente de IA. Ele também aponta para um teste concreto.

Após um evento relacionado à IA, a organização consegue identificar os dados afetados, o modelo envolvido, a identidade que iniciou o processo, as ações executadas e os destinatários subsequentes? Se não, a governança continua incompleta, independentemente da qualidade das políticas.

Os trabalhadores do conhecimento têm um papel nesse sistema. Eles decidem quais arquivos entram nos prompts, quais respostas geradas são confiáveis e quais ferramentas de IA passam a fazer parte do trabalho diário.

As organizações podem reduzir a exposição acidental oferecendo aos funcionários formas aprovadas de pesquisar e sintetizar suas próprias informações. Uma base de conhecimento de IA privada pode limitar cópias desnecessárias entre serviços não relacionados quando seus limites são claramente definidos.

Essa abordagem ainda exige governança. O armazenamento local ou privado não resolve automaticamente acessos excessivos, resultados imprecisos, autenticação fraca ou obrigações de retenção.

O objetivo não é proibir fluxos de trabalho úteis. É oferecer aos usuários um caminho aprovado cujo movimento de dados possa ser compreendido e analisado.

O inventário também precisa de gestão de mudanças. Um aplicativo que começou como assistente de escrita pode ganhar recursos de recuperação, automação ou agentes por meio de uma atualização.

As equipes de segurança devem avaliar novos recursos de acordo com acessos e ações alterados, e não apenas pelo nome familiar do produto. Uma ferramenta antes de baixo risco pode se tornar materialmente diferente após receber novas permissões.

É aqui que os incidentes de segurança de IA se tornam sinais valiosos. Cada evento deve atualizar o inventário, o modelo de ameaças, o desenho dos controles e as orientações aos funcionários.

Uma contagem de incidentes, por si só, não mostra se as organizações aprenderam com esses eventos. A qualidade do processo corretivo importa mais do que o número em destaque.

O Que o Número de 80% Não Prova

A manchete indica ampla exposição, mas não estabelece uma taxa universal de violação nem prova que a IA tenha causado todos os incidentes relatados.

Pesquisas de fornecedores podem revelar padrões úteis, especialmente quando publicam tamanhos de amostra e metodologia. Elas também carregam limitações inevitáveis.

Os respondentes podem interpretar “incidente” de maneiras diferentes. Líderes de segurança podem incluir ataques tentados, violações confirmadas, descumprimentos de políticas, eventos de privacidade e falhas operacionais sob o mesmo rótulo.

Resultados autodeclarados também dependem de visibilidade. Uma organização madura, com monitoramento abrangente, pode relatar mais incidentes porque detecta mais eventos.

Uma organização menos preparada pode parecer mais segura simplesmente porque não consegue enxergar as falhas. A própria pesquisa da Kiteworks alerta para esse efeito de visibilidade.

As populações das pesquisas também importam. O resumo de tecnologia da Kiteworks representa majoritariamente grandes organizações, com 97% dos respondentes trabalhando em empresas com pelo menos 1.000 funcionários.

Grandes empresas têm mais sistemas, usuários, fornecedores e obrigações regulatórias. Sua experiência não deve ser projetada diretamente sobre pequenas empresas.

A análise de tecnologia incluiu apenas 32 respondentes do setor. Uma diferença de várias respostas pode alterar materialmente uma porcentagem nesse subgrupo.

Portanto, a afirmação de 80% precisa de detalhes de apoio antes que os leitores possam compará-la com outro estudo de incidentes. Os detalhes necessários incluem a redação da pergunta, as opções de resposta, o período de observação e o tratamento de eventos suspeitos.

Também ajudaria separar incidentes cibernéticos tradicionais de eventos originados por IA. Um invasor que usa IA para aprimorar phishing é diferente de um modelo corporativo que vaza dados recuperados.

Uma terceira categoria envolve ataques convencionais contra infraestrutura de IA, como roubo de credenciais ou software vulnerável. Chamar os três de “incidentes de IA” obscurece quem controlava o sistema que falhou.

A Kiteworks também vende produtos projetados para tratar da governança de dados privados. Essa posição comercial não invalida seus dados, mas cria um incentivo para enfatizar os riscos que sua plataforma aborda.

A reprodução independente fortaleceria a afirmação da manchete. O mesmo ocorreria com a publicação de detalhamentos anonimizados por tipo de incidente, tamanho da organização, região e maturidade de governança.

A lição mais confiável do relatório não exige aceitar uma taxa universal de 80%. Vários estudos da Kiteworks mostram que a preparação formal e a aplicação operacional frequentemente divergem.

O resumo de tecnologia identifica lacunas no isolamento de treinamento e na proveniência. A pesquisa anterior constatou implementação limitada de governança técnica. A pesquisa sobre soberania mostra alta conscientização ao lado de incidentes contínuos.

Em conjunto, essas conclusões sustentam uma conclusão mais restrita. Muitas grandes organizações iniciaram a governança de IA, mas relativamente poucas conseguem demonstrar controle técnico abrangente em todo o ciclo de vida dos dados.

Isso é sério sem ser sensacionalista. Também oferece aos compradores uma estrutura melhor para avaliar produtos de governança.

Um fornecedor deve explicar quais fluxos de dados observa, quais políticas aplica e quais ações pode bloquear. Também deve divulgar limitações e dependências de integração.

Os compradores devem ter cautela quando um produto trata a governança apenas como um painel. A visibilidade é necessária, mas aplicação, testes, resposta e recuperação completam o ciclo operacional.

Eles também devem evitar presumir que um único gateway controla todos os caminhos. Funcionários, recursos de IA incorporados, interfaces diretas de programação de aplicativos e agentes autônomos podem criar rotas separadas.

A manchete do Google News merece atenção porque o risco subjacente é real. Sua porcentagem exata deve continuar atribuída ao relatório até que a metodologia completa esclareça o que o número inclui.

Três Sinais Que Testarão o Alerta da Kiteworks

As próximas evidências devem mostrar se as empresas estão construindo governança aplicável ou apenas adicionando outra camada de documentação.

O primeiro sinal é uma divulgação melhor de incidentes. Pesquisas futuras devem separar violações confirmadas, eventos suspeitos, violações de políticas e ações não intencionais de IA.

Elas também devem distinguir incidentes causados por IA de ataques direcionados a sistemas de IA. Essa taxonomia tornaria comparações anuais mais significativas.

Uma divulgação detalhada poderia fortalecer o alerta da Kiteworks se taxas elevadas persistirem em categorias claramente definidas. Poderia enfraquecer a manchete se o número de 80% combinar muitos eventos de baixa gravidade ou vagamente relacionados.

O segundo sinal é o progresso mensurável em controles técnicos. O resumo de tecnologia de 2026 fornece referências para ambientes de treinamento isolados, proveniência, manuais de resposta a incidentes e supervisão do conselho.

Uma pesquisa de acompanhamento deve usar as mesmas perguntas e a mesma abordagem de amostragem. O aumento na adoção de rastreabilidade e isolamento de ambientes mostraria que as organizações estão fechando a lacuna de aplicação.

Resultados estáveis ou em queda sustentariam a preocupação central do relatório. Eles indicariam que os investimentos continuam concentrados em avaliações e políticas, em vez de controles fundamentais.

O terceiro sinal são evidências regulatórias. A aplicação das normas europeias, auditorias e orientações de implementação devem revelar quais falhas de governança criam a maior exposição prática.

Observe casos que envolvam documentação ausente, monitoramento inadequado, interação com IA não divulgada ou movimentação de dados mal controlada. Esses exemplos ajudarão as organizações a priorizar investimentos.

Ação regulatória poderia fortalecer a tese do relatório se as autoridades encontrarem repetidamente lacunas entre políticas declaradas e o comportamento dos sistemas. Conformidade clara, com poucas falhas operacionais, reduziria sua urgência.

Compradores empresariais não precisam esperar por esses sinais antes de agir. Eles podem testar a preparação com um exercício direto baseado em um fluxo de trabalho de IA em produção.

Comece com um sistema que acesse informações sensíveis. Peça ao responsável que identifique cada fonte de dados, provedor de modelos, ferramenta conectada, permissão, regra de retenção e tomador de decisão responsável.

Em seguida, simule uma conta comprometida, um documento malicioso ou uma ação não intencional. Determine se a organização consegue interromper o sistema, rastrear sua atividade, identificar informações expostas e preservar evidências.

O exercício deve incluir as áreas jurídica, de segurança, privacidade, TI e a equipe de negócios que usa o sistema. A governança de IA falha quando a responsabilidade desaparece entre esses grupos.

As equipes devem preservar decisões e lições de incidentes em um sistema pesquisável, em vez de dispersá-las entre reuniões e documentos. Um fluxo de trabalho de conhecimento estruturado pode ajudar os responsáveis a manter evidências à medida que os sistemas mudam.

A documentação ainda não pode substituir a aplicação. Seu valor está em conectar responsáveis nomeados, comportamento observado, exceções aprovadas e ações corretivas.

O número de 80% de incidentes relatado pela Kiteworks deve ser lido como um alerta que merece verificação. A pesquisa mais ampla da empresa já mostra evidências suficientes de visibilidade fraca, governança técnica limitada e proveniência incompleta.

A verdadeira questão já não é se uma organização tem uma política de IA. É se essa organização consegue reconstruir as ações de um sistema de IA depois que algo dá errado.

O Google News pode amplificar uma porcentagem dramática, mas os líderes de segurança precisam dos controles que a sustentem. Eles devem inventariar um fluxo de trabalho de IA ativo, testar seu caminho de falha e documentar o que permanece invisível.