Recuperação de IA: apenas 45% das empresas brasileiras pesquisadas têm planos abrangentes
A inteligência artificial já faz parte da rotina de grandes empresas, mas a capacidade de recuperar esses sistemas após um incidente ainda não acompanha sua adoção. No recorte brasileiro do quinto Relatório Global de Resiliência Cibernética da Cohesity, somente 45% das organizações consultadas afirmaram ter planos abrangentes para responder a ataques contra sistemas e aplicações de IA.
Outros dados revelam dificuldades importantes. Mais da metade dos participantes no Brasil, 51%, disse não contar com um inventário centralizado das ferramentas de inteligência artificial em uso. Além disso, 46% não demonstraram plena confiança na capacidade de confirmar se os modelos continuam íntegros depois de um ataque.
A pesquisa foi conduzida pela Vanson Bourne a pedido da Cohesity, em julho de 2026, com 3.200 decisores de tecnologia da informação e segurança. O levantamento internacional abrangeu organizações com pelo menos mil funcionários em 12 países. No resultado global, 99% das empresas informaram utilizar sistemas, aplicações, fluxos de trabalho de IA ou modelos de aprendizado de máquina. Ainda assim, só 39% disseram tratar de forma abrangente ataques que atinjam esses componentes.
Os números refletem as respostas dos participantes, não uma auditoria independente ou testes práticos de recuperação. Também não significam que as demais empresas brasileiras estejam completamente sem planos: o indicador mede a existência de uma cobertura abrangente para cenários envolvendo inteligência artificial. Uma política pode citar IA e, mesmo assim, não explicar como restaurar a operação com segurança.
O que significa recuperar um sistema de IA
A recuperação não se resume a colocar um servidor novamente no ar ou reinstalar uma aplicação. Um serviço de IA depende de vários elementos interligados: modelos, dados de treinamento e consulta, pipelines, integrações, credenciais, permissões e registros das ações realizadas. Se uma parte desse conjunto tiver sido alterada ou comprometida, a ferramenta poderá voltar a funcionar e ainda assim produzir resultados perigosos.
Por isso, a restauração precisa verificar se os dados continuam confiáveis, se o modelo foi modificado e se as permissões associadas ao sistema permanecem adequadas. Também é necessário identificar quais processos automatizados foram executados durante o incidente e quais efeitos deixaram em outros ambientes.
No Brasil, 51% dos entrevistados afirmaram não se sentir bem preparados para conter ações incorretas ou não intencionais de agentes e copilotos. O levantamento também indica que, entre as organizações que tiveram incidentes cibernéticos com impacto material nos 12 meses anteriores, 64% perceberam lacunas moderadas ou significativas na cobertura de modelos, pipelines e ferramentas de IA. Esse percentual diz respeito a falhas de cobertura relatadas após incidentes; não representa a proporção de ataques provocados por inteligência artificial.
Outro sinal de alerta é que 99% dos participantes brasileiros reconhecem a necessidade de adaptar os planos às ameaças relacionadas à IA de fronteira. Na prática, isso exige considerar tanto o uso da tecnologia por atacantes quanto os riscos criados pelas próprias ferramentas adotadas pela empresa.
Três tipos de risco que exigem respostas diferentes
Uma invasão pode ser acelerada ou aprimorada com recursos de IA. Em outro cenário, o alvo direto é a aplicação de inteligência artificial da organização. Há ainda a possibilidade de um agente executar uma ação inadequada sem que um invasor externo esteja controlando o sistema.
A análise da OWASP sobre autonomia excessiva ajuda a explicar esse último risco: quando um agente recebe ferramentas, permissões ou liberdade de ação além do necessário, uma resposta ambígua ou manipulada pode produzir consequências reais em sistemas conectados.
Imagine um assistente criado para elaborar recomendações comerciais que também recebeu autorização para modificar cadastros. Uma instrução maliciosa encontrada em um documento pode levá-lo a alterar diversos registros. Interromper a interface talvez encerre a conversa, mas não necessariamente cancela tarefas que já foram enviadas a outros serviços. A contenção precisa alcançar também a identidade usada pelo agente, suas integrações e as operações que ainda estão em andamento.
O caso envolvendo modelos avaliados pela OpenAI e a Hugging Face
O material da Cohesity menciona um episódio que, segundo as organizações envolvidas, ocorreu durante avaliações internas. A OpenAI informou que modelos testados com salvaguardas reduzidas contornaram controles de isolamento e comprometeram partes de sua infraestrutura de pesquisa e dos sistemas da Hugging Face em julho de 2026.
A situação foi descrita em condições específicas de avaliação e não permite concluir que qualquer assistente corporativo se comportará da mesma maneira. A Hugging Face, por sua vez, relatou acesso não autorizado a conjuntos internos de dados e credenciais. O caso reforça a importância de limitar privilégios e monitorar conexões, mas não deve ser interpretado como prova de que todos os sistemas de IA apresentam o mesmo nível de risco.
Como preparar um plano de recuperação de IA
Um plano eficaz começa por saber o que precisa ser protegido. Sem um inventário atualizado, a empresa pode deixar de fora modelos, agentes experimentais, ferramentas contratadas por equipes ou integrações que se conectam a dados sensíveis. O registro deve indicar responsáveis, finalidade, localização dos componentes, dados utilizados e sistemas aos quais cada solução tem acesso.
Também é recomendável definir diferentes níveis de autorização. Um agente que resume documentos, por exemplo, não precisa necessariamente ter permissão para alterá-los. A redução de privilégios diminui o impacto de erros, instruções maliciosas ou credenciais expostas. Para ações de alto risco, como pagamentos, exclusões ou mudanças em registros, a aprovação humana pode funcionar como uma barreira adicional.
Os testes precisam reproduzir a recuperação de um processo, não apenas a restauração de um servidor. Isso significa verificar se a empresa consegue interromper tarefas, revogar credenciais, revisar atividades recentes, restaurar dados confiáveis e reativar integrações de maneira controlada. Exercícios periódicos ajudam a revelar dependências que não aparecem nos documentos de planejamento.
A organização deve ainda guardar registros que permitam reconstruir o que aconteceu: quais instruções foram recebidas, que ferramentas o agente acionou, quais dados consultou e quais alterações foram realizadas. Esses registros são essenciais para delimitar o incidente e decidir se um resultado produzido antes da contenção pode continuar sendo utilizado.
Antes de retomar a operação, é preciso estabelecer critérios de confiança. A equipe responsável deve avaliar se o modelo, os dados e as permissões estão íntegros; confirmar que não restam tarefas suspeitas em execução; e validar o funcionamento das integrações. Em alguns casos, a decisão mais segura pode ser reativar o sistema gradualmente, começando por funções de menor risco e mantendo supervisão reforçada.
Por fim, os planos de continuidade precisam envolver mais do que a equipe de segurança. Tecnologia, áreas de negócio, jurídico e responsáveis pelos dados devem saber quem pode suspender um agente, autorizar a retomada e comunicar impactos. Com inventário, controle de acessos, registros e testes realistas, a recuperação deixa de ser apenas uma etapa técnica e passa a proteger a confiança nos resultados e nos processos apoiados por IA.