Automação SOAR com revisão humana funciona quando a plataforma executa sozinha as etapas passivas da investigação e transfere para um analista apenas a decisão de agir. É o modelo human-in-the-loop: o playbook coleta contexto, enriquece indicadores e monta o caso; a ação de resposta — bloquear, isolar, desativar conta — espera uma aprovação explícita antes de rodar. O retorno é mensurável: no relatório Cost of a Data Breach 2025, organizações que usaram IA e automação de segurança de forma extensa economizaram em média US$ 1.9 milhão e reduziram o ciclo de vida das violações de dados em 80 dias, na comparação com quem não adotou essas tecnologias.
Por que automação total falha
Timidez e excesso de confiança travam projetos de SOAR da mesma forma. A prática consolidada de fornecedores que implantam a plataforma em escala mostra que a abordagem tudo-ou-nada costuma travar a adoção da plataforma: equipes que saltam de zero para fluxos complexos com triagem, investigação e resposta automáticas esbarram em bloqueios organizacionais imediatos e abandonam o esforço. O caminho comprovado é o oposto — pequenos passos que entregam valor visível ao SOC a cada ciclo, com revisão humana progressivamente reduzida conforme a confiança nos playbooks cresce.
O erro complementar é automatizar processo que não existe. Playbook é a codificação de um procedimento operacional: se o time não sabe descrever como decide um incidente de phishing, o playbook apenas automatiza a indecisão. Antes de desenhar automação, documente a decisão manual em casos reais recentes — por exemplo, como o time tratou o bypass de MFA pelo ransomware Gunra detectado no SOC — e só então converta as etapas repetitivas em blocos.
Como funciona a revisão humana
A mecânica do human-in-the-loop é simples de implementar e difícil de governar. A recomendação de boas práticas é executar etapas passivas primeiro e só então acionar um prompt humano para revisar e decidir os próximos passos: o playbook consulta fontes de reputação, correlaciona logs e apresenta um resumo ao analista, que aprova ou nega a ação subsequente. Esse prompt pode ser temporário, para depurar e ganhar confiança na automação em desenvolvimento, ou permanente, como etapa fixa de revisão antes de qualquer ação de resposta.
Três regras de governança evitam que a revisão vira gargalo ou fachada:
- Escopo por criticidade: aprovação obrigatória apenas para ações com efeito destrutivo ou difícil de reverter (bloqueio de IP em firewall de borda, isolamento de host, desativação de conta de serviço); ações somente-leitura rodam sem aprovação.
- SLA explícito: cada prompt tem prazo de resposta; ao expirar, o playbook segue caminho seguro pré-definido — normalmente escalar ou não agir, nunca agir sem decisão.
- Registro da decisão: quem aprovou, quando, com qual evidência à vista. Esse trilho é o que transforma aprovação em controle auditável.
Matriz de decisão: o que automatizar
| Ação | Modo recomendado | Revisão humana |
|---|---|---|
| Enriquecimento de IP, domínio e hash | Totalmente automático | Não |
| Fechamento de falso positivo recorrente | Automático com histórico | Não |
| Quarentena de e-mail de phishing confirmado | Automático após critérios | Amostragem semanal |
| Bloqueio de IP em firewall de produção | Semi-automático | Obrigatória, com SLA |
| Isolamento de host de executivo | Semi-automático | Obrigatória, dupla |
| Desativação de conta de serviço | Só sob demanda | Obrigatória, com avaliação de impacto |
A fronteira entre linha automática e revisada muda com a maturidade. Playbooks de contenção devem invocar o fluxo de aprovação antes de agir, mesmo quando a detecção é confiável — o padrão usado em playbooks de contenção de movimento lateral, como os que o time treina ao detectar pass-the-hash no SOC, onde bloquear credenciais legítimas comprometidas exige distinção fina entre atacante e usuário real.
Implantação em fases com aprovação
A progressão que sustenta automação com revisão humana tem cinco estágios, cada um liberando o seguinte somente com métricas de acerto estáveis:
- Instância isolada: familiarização com playbooks, containers e gestão de casos, sem integração com produção.
- Integração com o SIEM: playbooks que consultam dados existentes e devolvem enriquecimento ao analista.
- Ferramentas do SOC: integração com EDR, proxy e mensageria interna, ainda sem ações de resposta automáticas.
- Serviços externos: enriquecimento automático com fontes externas de reputação e ameaça.
- Sistemas corporativos: ações de resposta com aprovação humana em identidade, rede e endpoints de negócio.
Em cada estágio, meça taxa de falsos positivos do playbook, tempo médio de decisão humana e percentual de aprovações dentro do SLA. Só desça a exigência de revisão quando esses três números estiverem estáveis por algumas semanas — o critério que separa maturidade de sorte.
Erros comuns e como evitar
Quatro armadilhas concentram a maioria das falhas:
- Prompt vago: a mensagem de aprovação precisa trair o essencial — o que o playbook quer fazer, em qual ativo, com qual evidência e qual o efeito. Sem isso, o analista aprova no automático e a revisão vira rubber stamp.
- SLA inexistente: prompt sem prazo acumula na fila e atrasa resposta mais do que o processo manual que a automação substituiu.
- Aprovação única e permanente: mesma pessoa aprovando tudo cria ponto único de fadiga; alterne revisores por escalação e tipo de ação.
- Ignorar fadiga de aprovação: se mais de um terço das aprovações é rotineiramente concedida sem consulta à evidência, o sinal é que a ação deveria ser automática — ou o alerta, melhor calibrado.
Automação SOAR com revisão humana não é etapa de transição para o piloto automático completo: é o estado de operação que equilibra velocidade, risco e auditabilidade, mesmo em times maduros. A meta não é eliminar o analista da decisão, e sim garantir que cada intervenção humana ocorra no ponto da cadeia onde ela muda o resultado — e em nenhum outro.
