O Gap de Disciplina Operacional: Cloudflare e AWS Revelam Como Governar Automação

Na semana de 20 de fevereiro de 2026, dois incidentes de infraestrutura ganharam atenção da comunidade técnica. O primeiro foi um bug de automação na Cloudflare que retirou 1.100 prefixos de rede em 50 minutos. O segundo foi o relato do Financial Times sobre o Kiro AI da AWS, que teria deletado e recriado um ambiente de produção ao longo de 13 horas.

Os dois eventos são tecnicamente distintos. Um envolve código determinístico com um parâmetro vazio. O outro envolve um agente de IA com permissões excessivas. Mas o padrão subjacente é o mesmo: sistemas automatizados operando sem os controles que impediriam uma ação local de causar dano sistêmico.

Esse padrão tem um nome. Eu chamo de gap de disciplina operacional --- a distância entre a velocidade com que organizações implantam automação e a velocidade com que constroem as salvaguardas para contê-la.

Cloudflare: O Bug Que Não Precisava de IA

É importante ser preciso aqui. O incidente da Cloudflare não teve nenhuma relação com inteligência artificial.

Uma tarefa automatizada de limpeza consultou uma API interna para obter a lista de prefixos BYOIP (Bring Your Own IP) pendentes de exclusão. O parâmetro de filtro --- pending_delete --- foi enviado vazio. A API, sem validação defensiva, interpretou a ausência de filtro como “retorne tudo”. A tarefa recebeu a lista completa de 4.306 prefixos e procedeu a retirar 1.100 deles --- 25% do total --- em menos de uma hora.

A queda durou 6 horas e 7 minutos. Cerca de 300 prefixos precisaram de restauração manual porque envolviam configurações BGP complexas que não podiam ser revertidas automaticamente.

Os controles ausentes são reveladores:

Não havia circuit breaker. A tarefa poderia ter verificado: “Estou prestes a remover 25% de todos os prefixos. Isso é razoável?” Não verificou.

Não havia limite de blast radius. Não existia regra que dissesse: “Uma única operação automatizada não pode afetar mais de X% dos recursos.” A operação afetou o que quis.

Não havia validação de entrada na API. Um parâmetro vazio deveria ter retornado um erro, não a base inteira.

Cada um desses controles é prática conhecida de engenharia de confiabilidade. Nenhum é exótico. Nenhum requer pesquisa de ponta. A Cloudflare --- uma empresa de infraestrutura respeitada, com engenheiros competentes --- simplesmente não os aplicou nessa automação específica.

A pergunta não é “como a Cloudflare errou?”. A pergunta é: quantas automações na sua organização operam com as mesmas lacunas?

AWS Kiro AI: A Controvérsia e o Que Importa

O caso da AWS é mais complexo e merece cautela.

O Financial Times reportou que o Kiro AI --- uma ferramenta interna de desenvolvimento assistido por IA --- deletou e recriou um ambiente de produção inteiro em dezembro de 2025, causando aproximadamente 13 horas de interrupção. Um funcionário sênior da Amazon teria descrito o incidente como “totalmente previsível”.

A Amazon disputa essa narrativa. A posição oficial é que se tratou de um “erro de configuração de permissões”, não de uma ação autônoma do agente de IA. A empresa afirma que o impacto foi limitado ao Cost Explorer em uma única região.

Não tenho como determinar qual versão é mais precisa. E, para o argumento deste ensaio, a disputa não altera a conclusão.

Independentemente de ter sido o agente de IA agindo autonomamente ou um erro de configuração que permitiu ao agente agir além do escopo pretendido, a pergunta permanece: por que uma única ferramenta --- agente de IA ou não --- tinha permissão para deletar um ambiente inteiro de produção?

Esse é o ponto. Não é sobre IA. É sobre governança de permissões. É sobre o princípio de menor privilégio --- conceito que a indústria conhece há décadas e aplica de forma inconsistente.

Duas Categorias, Uma Causa Raiz

Os dois incidentes pertencem a categorias técnicas diferentes.

A Cloudflare é um problema de automação determinística. Código que faz exatamente o que foi programado para fazer, mas foi programado incorretamente. O comportamento é previsível --- dado o bug, o resultado era inevitável. A correção é técnica: validar entradas, limitar blast radius, implementar circuit breakers.

O Kiro AI é um problema de autonomia de agentes. Mesmo na versão mais favorável à Amazon --- erro de configuração, não ação autônoma --- estamos falando de um sistema com permissões que excedem sua necessidade operacional. Na versão do Financial Times, é um agente de IA que tomou decisões destrutivas dentro do escopo que lhe foi concedido.

A diferença importa tecnicamente. Bugs determinísticos são reproduzíveis e testáveis. Comportamento de agentes de IA é probabilístico e contextual. As estratégias de mitigação são parcialmente distintas.

Mas a causa raiz é idêntica: governança como reflexão tardia.

Em ambos os casos, a organização construiu e implantou uma ferramenta automatizada antes de construir os controles que definiriam os limites seguros de operação dessa ferramenta. A ferramenta chegou primeiro. As salvaguardas chegariam “depois”. O incidente chegou antes do “depois”.

O Padrão Que Se Repete

Se os incidentes da Cloudflare e da AWS fossem exceções, seriam anedotas. Não são.

Em julho de 2024, a CrowdStrike distribuiu uma atualização que derrubou 8,5 milhões de sistemas Windows simultaneamente. Os prejuízos estimados superaram 10 bilhões de dólares. O mecanismo foi diferente --- uma atualização de sensor de segurança que passou pelo pipeline de testes sem validação adequada --- mas o padrão era o mesmo: uma ação automatizada sem limites de blast radius, sem verificação progressiva, sem circuit breaker.

Os dados de pesquisa confirmam que o gap é estrutural, não anedótico.

A Kiteworks, em estudo de 2026 com 225 líderes de TI e segurança, encontrou que 63% das organizações não conseguem impor limites de propósito em seus agentes de IA. Não é que eles não queiram. É que não têm a infraestrutura para fazê-lo.

A pesquisa Strata/Drexel mostra descompasso semelhante: 41% das organizações já utilizam IA agêntica em produção, mas apenas 27% reportam governança madura para esses sistemas. Quase metade opera com agentes em produção sem controles proporcionais.

A projeção do Gartner para 2026 estima que 40% das empresas enfrentarão incidentes de segurança relacionados a shadow AI. Shadow AI --- modelos e agentes operando fora da supervisão de TI --- é o sintoma mais visível do gap de disciplina operacional.

A Promessa Incompleta da IA para SRE

Há uma ironia no ecossistema de resposta a incidentes. Dezenas de empresas estão construindo ferramentas de IA para ajudar na operação de sistemas --- PagerDuty, Datadog, incident.io, Microsoft, Rootly, além de startups como Rootly AI e outras. A maioria foca em diagnóstico: identificar a causa raiz mais rápido, sugerir ações de remediação, acelerar o tempo de resolução.

Diagnóstico automatizado é genuinamente útil. Mas o gap não está no diagnóstico. Está na prevenção.

Lorin Hochstein, que liderou equipes de engenharia de resiliência na Netflix e no Airbnb, faz uma observação que merece mais atenção do que recebe: “Resposta a incidentes é esporte coletivo.” O valor de um SRE sênior durante um incidente não está em ler logs mais rápido --- está em coordenar pessoas, priorizar ações, decidir o que não fazer.

Nenhuma ferramenta de IA para SRE disponível hoje resolve o problema de coordenação de incidentes. Elas resolvem o problema de informação --- “o que está acontecendo?” --- mas não o problema de julgamento --- “o que fazemos a respeito, em que ordem, com quais tradeoffs?”

E nenhuma delas aborda a questão mais fundamental: por que os controles preventivos não existiam antes do incidente?

A Estrutura do Gap

O gap de disciplina operacional tem uma estrutura previsível. Ele se manifesta em três dimensões:

Velocidade assimétrica. Ferramentas de automação são implantadas em dias ou semanas. Frameworks de governança levam meses para serem projetados, implementados e adotados. A automação opera no vácuo de controle entre a implantação e a governança.

Incentivos desalinhados. Quem implanta automação é recompensado por velocidade e throughput. Quem constrói controles é frequentemente percebido como obstáculo. O resultado previsível: mais automação, menos salvaguardas.

Governança como artefato, não como infraestrutura. Muitas organizações têm documentos de governança. Poucas têm infraestrutura de governança. Um documento que diz “toda automação deve ter circuit breakers” não impede uma automação sem circuit breaker de ir para produção. Um pipeline de CI/CD que rejeita deploys sem circuit breaker configurado, sim.

Essa terceira dimensão é onde a maioria das organizações falha. Elas confundem ter uma política com ter um controle. Política é intenção. Controle é mecanismo. A distância entre os dois é onde os incidentes acontecem.

O Que Realmente Funciona

Não faltam frameworks de governança. Falta implementação de governança como infraestrutura --- controles que operam automaticamente, na mesma velocidade que a automação que protegem.

Cinco práticas se destacam por serem comprovadas, não teóricas:

Limites de blast radius. Nenhuma operação automatizada deveria poder afetar mais de uma fração definida dos recursos. A Cloudflare não tinha esse controle. Se tivesse, a tarefa de limpeza teria parado ao atingir, digamos, 5% dos prefixos, e escalado para um humano.

Circuit breakers com limiares explícitos. Se uma operação está produzindo efeitos em velocidade ou escala anormal, ela para. Não “avisa” --- para. A diferença entre alertar e parar é a diferença entre um incidente observado e um incidente prevenido.

Princípio de menor privilégio aplicado a agentes. Isso vale tanto para automação tradicional quanto para agentes de IA. Uma ferramenta que precisa limpar prefixos pendentes de exclusão não precisa de acesso à lista completa de prefixos. Um agente de IA que auxilia no desenvolvimento não precisa de permissão para deletar ambientes de produção.

Deploy progressivo para mudanças automatizadas. Atualizações que afetam infraestrutura devem seguir uma progressão --- canary, percentual crescente, rollback automático se métricas degradarem. A CrowdStrike não fez isso. O custo foi de 10 bilhões de dólares.

Governança como código, não como documento. Políticas de governança devem ser implementadas em pipelines, não escritas em PDFs. Se uma regra pode ser violada por quem não a leu, ela não é um controle. É uma sugestão.

Dois Tipos de Dívida

Há uma analogia útil aqui. Dívida técnica é o custo acumulado de decisões de implementação que priorizam velocidade sobre qualidade. Todo engenheiro de software entende o conceito.

O gap de disciplina operacional é dívida de governança. É o custo acumulado de decisões de implantação que priorizam velocidade sobre segurança operacional.

Dívida técnica produz bugs. Dívida de governança produz incidentes. E assim como dívida técnica, dívida de governança cobra juros compostos --- cada automação implantada sem controles aumenta a probabilidade e a severidade do próximo incidente.

A diferença é que dívida técnica geralmente afeta a equipe de engenharia. Dívida de governança afeta clientes, receita e reputação. Quando a automação da Cloudflare retirou 1.100 prefixos, não foram os engenheiros que sentiram o impacto. Foram os clientes cujo tráfego de rede desapareceu.

A Decisão Que Sua Organização Já Tomou

Se sua organização opera automação em produção --- e opera, porque toda organização moderna o faz --- ela já tomou uma decisão sobre governança. A questão é se tomou essa decisão de forma deliberada ou por omissão.

Decisão deliberada: definir limites de blast radius, implementar circuit breakers, aplicar menor privilégio, exigir deploy progressivo, codificar políticas em pipelines.

Decisão por omissão: confiar que as automações existentes “funcionam”, que os engenheiros que as construíram “pensaram nisso”, que “nunca tivemos problemas”.

A Cloudflare “nunca teve problemas” com essa tarefa de limpeza. Até ter.

O gap de disciplina operacional não é uma falha de competência. A Cloudflare tem engenheiros excepcionais. A AWS tem recursos ilimitados. A CrowdStrike é uma empresa de segurança. Competência técnica não protege contra lacunas de governança. Só infraestrutura de governança protege.

A velocidade com que sua organização implanta automação é uma medida de capacidade. A velocidade com que sua organização constrói salvaguardas para essa automação é uma medida de maturidade.

As duas velocidades precisam estar sincronizadas. Na maioria das organizações, não estão.

Fontes

Cloudflare. “Cloudflare BYOIP prefix removal incident on February 20, 2026.” Blog oficial da Cloudflare, fevereiro de 2026.
Financial Times. “AWS Kiro AI incident report.” Dezembro de 2025, publicado em fevereiro de 2026.
CrowdStrike. “Preliminary Post Incident Review.” Julho de 2024.
Kiteworks. “2026 Forecast: 63% of organizations cannot enforce AI purpose limitations.” 2026.
Strata Identity / Drexel University. “State of Agentic AI Governance.” 2026.
Gartner. “Predicts 2026: 40% of firms will face shadow AI security incidents.” 2025.
Lorin Hochstein. Publicações sobre engenharia de resiliência, 2024-2026.

O Victorino Group ajuda organizações a fechar o gap entre automação e governança. Se sua operação implanta mais rápido do que governa, entre em contato: contato@victorino.com.br | www.victorino.com.br