Não basta ligar a IA: por que defender com agentes é um problema de governança

A frase que resume tudo

O artigo do NCSC parte de uma máxima conhecida no meio, atribuída ao pesquisador Halvar Flake: todo problema ofensivo é técnico, e todo problema defensivo é político.

Parece exagero, mas veja o dia a dia de cada lado. O adversário pergunta: “Tenho um exploit para essa vulnerabilidade? Como evito ser detectado?”. O time de defesa pergunta: “Consigo orçamento para trocar esse sistema em fim de vida? A equipe de infraestrutura vai arrumar janela para o patch? Quem aprova essa mudança na regra do firewall?”.

Ou seja: quem ataca esbarra em obstáculos técnicos. Quem defende esbarra em processos, orçamento, prioridades e aprovações — em outras palavras, em governança.

Por que isso acontece

A explicação é simples. Para o criminoso, invadir é a atividade-fim — é de onde vem o dinheiro, seja por fraude, extorsão ou roubo de informação. Para a sua empresa, segurança não é a atividade-fim. Sua empresa existe para vender, atender pacientes, prestar serviços.

Segurança é um custo do negócio, disputando espaço com todas as outras prioridades. Por isso cada ação defensiva precisa ser pesada: aquele investimento não renderia mais em marketing? Esse patch vai derrubar a VPN? Essa regra de firewall vai quebrar algum processo que ninguém mapeou?

E há um detalhe que qualquer gestor reconhece. O NCSC observa, com humor britânico, que para parte da diretoria faz pouca diferença se a TI caiu por um ataque ou por uma ação mal calibrada do próprio time de segurança — só que, no segundo caso, dá para cobrar alguém pelo telefone.

Onde a IA entra nessa história

A IA é excelente em problemas técnicos com resultado claro e mensurável. O programa travou? O malware chamou o servidor de comando e controle? Sucesso, objetivo cumprido. Isso faz da IA uma aliada natural do lado ofensivo.

Já os problemas do blue team raramente têm um “resultado de sucesso” tão nítido — e quase nunca são só técnicos. Quando um agente de IA executa uma ação defensiva, alguém precisa responder por ela. É exatamente aí que a automação emperra.

A saída: começar pelo que é seguro automatizar

Em vez de tentar copiar o modo de operar do adversário (e correr o risco de quebrar a própria operação), o NCSC propõe que o time de defesa assuma explicitamente as suas restrições e automatize com critério. O ponto de partida são três princípios que já funcionam em áreas como varredura de vulnerabilidades e operação de SOC:

1. A tecnologia detecta, mas quem age são pessoas.
2. A detecção não pode prejudicar o negócio.
3. Quando há resposta automática, ela é rigidamente limitada — por exemplo, a uma única conta ou máquina, diante de um sinal claro de atividade maliciosa.

A partir disso, o NCSC sugere avaliar o grau de risco de cada ação automatizada em cinco dimensões. Em linguagem direta:

Quanto mais baixa a “nota” em cada dimensão, mais seguro é automatizar. O caminho mais fácil, segundo o NCSC, são tarefas de baixo poder de ação — recomendar a um humano em vez de mexer direto no ambiente. Resumir alertas, dar sentido ao volume de threat intel, priorizar o que o analista olha primeiro: aqui a IA já entrega valor real com risco baixo.

O artigo também sugere reduzir o risco de automações mais ousadas priorizando sistemas fáceis de recriar — a lógica de “gado, não bicho de estimação” — e usando a própria IA para modernizar sistemas legados, deixando-os mais simples de reimplantar.

E fecha com um alerta importante: não dá para esperar a defesa autônoma chegar e resolver tudo. Enquanto a pesquisa avança, as organizações precisam seguir fortalecendo a segurança pelo caminho tradicional.

O que isso significa para a sua empresa, na prática

Aqui está o ponto que o artigo do NCSC deixa nas entrelinhas — e que interessa a quem cuida de governança, risco e conformidade (GRC): se o gargalo da defesa é organizacional, a solução também é organizacional. Não adianta comprar o “SOC autônomo” mais moderno do mercado se a empresa não definiu quem responde pelas ações dele.

1. Responsabilidade precisa estar no papel antes da automação

Toda ação que um agente de IA executa em nome da empresa precisa ter dono definido. Quem aprovou a automação? Quem responde se ela derrubar um serviço? Quem tem autoridade para desligá-la? Sem isso, ou a ferramenta fica parada — ou opera sem ninguém responsável, o que é pior.

2. Sua gestão de mudanças precisa contemplar a IA

A ISO 27001 já exige controle sobre mudanças em sistemas. Uma automação que altera configuração ou permissão é uma mudança — só que em velocidade de máquina. Ela precisa entrar no processo de gestão de mudanças, com escopo aprovado, testes e plano de rollback.

3. Apetite a risco para automação é decisão da diretoria

As cinco dimensões do NCSC são, na prática, uma matriz de risco. E definir até onde a empresa aceita que uma IA aja sozinha não é decisão técnica: é decisão de negócio, que cabe à alta direção. A ISO 42001 exige exatamente isso — governança de IA com envolvimento da liderança, avaliação de riscos e supervisão humana onde o risco justifica.

4. Fornecedor de segurança com IA se avalia de outro jeito

Cada vez mais ferramentas vendem recursos “autônomos”. Antes de habilitar, pergunte: o que exatamente essa funcionalidade pode alterar? Em quais sistemas? Existe modo de auditoria, sem ação real? Dá para reverter? Os logs de cada ação ficam acessíveis? Se o fornecedor não sabe responder, você já tem a sua resposta.

5. A LGPD também está no jogo

Agentes de IA que coletam logs, cruzam comportamento de usuários ou bloqueiam contas tratam dados pessoais. Isso exige base legal, minimização, registro e segurança — e, se algo escapar do controle, pode virar incidente a comunicar à ANPD. Automação de segurança mal governada cria o próprio problema de conformidade que deveria evitar.

Por onde começar

1. Mapeie onde a IA já atua.Inclua o que vai atuar na sua operação de segurança — inclusive dentro de ferramentas já contratadas.
2. Classifique cada uso.Use as cinco dimensões: poder de ação, abrangência, criticidade, confiança prévia e reversibilidade.
3. Comece pelo baixo risco.IA que resume, organiza e recomenda — com humanos decidindo.
4. Formalize antes de liberar.Defina responsáveis, limites e plano de rollback antes de qualquer ação automática.
5. Leve a decisão à diretoria.Apetite a risco para automação é tema de governança, não de TI.

Conclusão

A mensagem do NCSC é, no fundo, uma boa notícia disfarçada. Se o que trava a defesa são problemas organizacionais, então governança bem feita vira vantagem competitiva. A empresa que decide antes — quem responde, até onde a IA pode ir, como reverter — é a que consegue de fato colocar a IA para trabalhar a seu favor, enquanto as outras ficam paralisadas entre o medo de agir e o risco de não agir.