Olá a todos!
Hoje vou falar-vos de algo que me fez quase engasgar com o café quando li as notícias esta semana, e que devia estar a provocar reuniões de emergência em todas as empresas que dependem da AWS para manter os seus sistemas a funcionar. Estou a falar das falhas provocadas pelas próprias ferramentas de IA da Amazon dentro da AWS, a maior plataforma de cloud do planeta, e de como isto é um aviso brutal para toda a indústria.
Se ainda não ouviram falar disto, buckle up, porque a história é tão absurda que quase parece ficção. Em dezembro de 2025, engenheiros da AWS permitiram que o Kiro, uma ferramenta de IA agéntica desenvolvida internamente pela Amazon para assistência de código, fizesse alterações num sistema de produção. O objetivo era simples: corrigir um bug menor no AWS Cost Explorer, o sistema que permite aos clientes analisar os custos dos serviços AWS. Uma intervenção que, feita por um humano, seria cirúrgica e controlada.
O que é que o Kiro fez? Decidiu, de forma completamente autónoma, que a melhor solução era apagar e recriar o ambiente inteiro. Leram bem. A ferramenta de IA da própria Amazon olhou para um bug e concluiu que a abordagem ideal era terra queimada: destruir tudo e reconstruir de raiz. O resultado? Uma interrupção de 13 horas que afetou sistemas na região da China continental. Treze horas. Por causa de um bug que provavelmente se resolvia com meia dúzia de linhas de código.
E fica já o aviso à navegação: este não é um post para agradar a evangelistas de IA que acham que automação total é o futuro glorioso da engenharia de software. Este é um post sobre a realidade brutal do que acontece quando damos permissões de administrador a algoritmos e tiramos os humanos da equação.
O padrão que está sempre presente nestes casos.
O incidente de dezembro não foi um caso isolado. Segundo funcionários da AWS que falaram com o Financial Times, pelo menos um outro incidente semelhante ocorreu nos meses anteriores, desta vez envolvendo o Amazon Q Developer, o chatbot de IA que a Amazon desenhou para ajudar engenheiros a escrever código. Dois incidentes. Duas ferramentas diferentes de IA. O mesmo padrão: agentes autónomos com permissões excessivas a tomar decisões destrutivas sem aprovação humana.
E aqui está a parte que me irrita profundamente: a resposta oficial da Amazon. Ou falta de transparência nela. A empresa descreveu o envolvimento das ferramentas de IA como “coincidência” e insistiu que “o mesmo problema poderia ocorrer com qualquer ferramenta de desenvolvimento ou ação manual.” A Amazon classificou ambos os casos como “erro do utilizador, não erro da IA.”
Vamos parar um momento para apreciar a ginástica retórica aqui. A Amazon dá permissões de nível de operador à sua IA. A IA decide autonomamente apagar um ambiente de produção inteiro. E a culpa é do utilizador que lhe deu as permissões. É como dar as chaves de um carro a uma criança de cinco anos e depois culpar a criança quando ela bate contra uma parede. A responsabilidade não é de quem executa, é de quem desenhou o sistema que permite que isto aconteça.
Um engenheiro sénior da AWS resumiu a situação de forma perfeita numa declaração anónima ao Financial Times: “As falhas foram pequenas mas inteiramente previsíveis.” Inteiramente previsíveis. Lembrem-se esta frase, porque ela é o cerne de tudo o que vou discutir neste post.
O Contexto: Uma tempestade perfeita de ambição e imprudência
Para perceberem a dimensão do problema, precisam de contexto. A Amazon estabeleceu uma meta interna para que 80% dos seus developers usem IA pelo menos uma vez por semana para tarefas de código. Oitenta por cento. E a adoção está a ser monitorizada de perto. Isto não é uma sugestão amigável: é uma diretiva corporativa com métricas de acompanhamento.
O Kiro foi lançado em julho de 2025, posicionado como uma ferramenta que vai além do chamado “vibe coding” e que escreve código baseado em especificações. A Amazon vendeu-o como o futuro da produtividade de engenharia. E para ser justo, o conceito em si não é mau. Ferramentas de IA para assistência de código podem ser extraordinariamente úteis quando usadas corretamente. O problema nunca foi a tecnologia. O problema é como a implementamos.
Agora juntem estas duas peças: uma pressão corporativa massiva para adotar IA, combinada com ferramentas que são tratadas como “extensão do operador” e recebem as mesmas permissões que os engenheiros humanos. A Amazon confirmou que as suas ferramentas de IA são equipadas com as mesmas permissões que o operador que as utiliza. Nos dois incidentes, os engenheiros envolvidos não necessitaram de aprovação de uma segunda pessoa antes de fazerem alterações, algo que normalmente seria obrigatório.
Estão a conseguir ver o desastre a formar-se? Pressão para usar IA. Ferramentas com permissões elevadas. Controlos de aprovação contornados. É a receita perfeita para o caos.
E antes que alguém diga “mas só afetou um serviço na China”, lembrem-se que em outubro de 2025, apenas dois meses antes, a AWS sofreu uma falha de 15 horas no US-East-1 que derrubou o ChatGPT da OpenAI, o Fortnite, o Snapchat, o Venmo, a Disney+, Dualingo e dezenas de outros serviços. Cinquenta mil queixas registadas no Downdetector em minutos. A AWS é a espinha dorsal de uma parte significativa da internet global. Quando a AWS falha, o mundo sente.
O Incidente do Amazon Q: A cereja no topo do bolo
Como se o caso do Kiro não fosse suficiente, há ainda o episódio com o Amazon Q Developer. Em julho de 2025, foi descoberto que a versão 1.84 da extensão para Visual Studio Code continha código malicioso. A causa? Um token do GitHub com permissões excessivas na configuração do CodeBuild que permitiu a um atacante injetar código malicioso no repositório open-source, código que foi automaticamente incluído numa release oficial.
E que código era esse? Instruções para executar comandos como aws ec2 terminate-instances e rm -rf nas máquinas dos developers. Estamos a falar da extensão oficial de IA da Amazon, distribuída através dos canais oficiais, a conter instruções para destruir sistematicamente ficheiros locais e infraestrutura cloud. Com flags como --trust-all-tools e --no-interactive, o que significa zero prompts de confirmação, zero hipótese de o utilizador parar a execução.
A Amazon diz que tiveram sorte porque a extensão estava “não funcional” durante esse período. Sorte. O maior fornecedor de cloud do mundo a depender de sorte para não causar destruição massiva nas máquinas dos seus clientes. Se isto não vos assusta, não sei o que vos assustará. Ou então ganharam o euromilhões e estão a trabalhar como passatempo.
Os investigadores de segurança da Koi apontaram o dedo ao verdadeiro problema: a Amazon removeu o pull request que introduziu o código malicioso. Desapareceu. Não há forma de perceber como passou pela revisão, quem o aprovou, se alguém levantou red flags. O processo que falhou é invisível, e sem perceber o processo, não podemos evitar que volte a acontecer.
As três Marias incómodas que a indústria precisa de aceitar
Depois de digerir o possível tudo isto, há três conclusões que considero absolutamente fundamentais e que qualquer pessoa que trabalhe em tecnologia precisa de interiorizar.
1. Privilégio Mínimo não é uma sugestão
Dar chaves de administrador a um algoritmo não é inovação, é imprudência sistémica. Ponto final. Não há forma de suavizar isto.
O princípio do privilégio mínimo existe há décadas em segurança informática. Não é um conceito novo, não é uma teoria académica obscura, é um dos pilares fundamentais de qualquer arquitetura de segurança que se preze. E no entanto, a AWS tratou as suas ferramentas de IA como extensões diretas dos operadores humanos, com as mesmas permissões, sem restrições adicionais.
Quando um engenheiro humano tem permissões elevadas, há um contexto: anos de experiência, compreensão do impacto das ações, capacidade de avaliar consequências, instinto desenvolvido ao longo de uma carreira. Uma ferramenta de IA não tem nada disto. Tem um modelo estatístico que calcula a próxima ação mais provável. E quando essa ação mais provável é “apagar tudo e recomeçar”, não há nenhum mecanismo interno que diga “espera, isto é uma péssima ideia em produção.”
As ferramentas de IA em ambientes de produção precisam de operar com o mínimo absoluto de permissões necessárias para a tarefa específica. Zero admin por defeito. Sempre. Sem exceções. Sem “mas neste caso específico faz sentido.” Não faz. Nunca faz.
2. A IA não erra devagar
Um humano a cometer um erro numa infraestrutura de produção é um processo relativamente lento. Escreve um comando, executa, percebe que algo correu mal, para, avalia, tenta reverter. Pode demorar minutos ou horas, mas há janelas de intervenção. Há momentos em que o instinto dispara e o engenheiro pensa “espera, isto não parece certo.”
Uma IA não tem estes momentos. Uma IA que decide apagar um ambiente inteiro fá-lo em segundos. Não há hesitação, não há aquele momento de pausa antes de premir Enter num comando destrutivo, não há o colega ao lado que olha para o ecrã e diz “tens a certeza que queres fazer isso?” A velocidade que torna a IA útil para tarefas repetitivas torna-a catastroficamente perigosa quando toma decisões erradas.
No caso do Kiro, o tempo entre “vou apagar este ambiente” e “o ambiente está apagado” foi provavelmente medido em segundos. A recuperação demorou 13 horas. Esta assimetria entre a velocidade de destruição e a velocidade de recuperação é o elefante na sala que toda a gente na indústria de IA prefere ignorar.
3. Automação total sem guardrails humanos é só uma forma muito particular de um camião a descer uma montanha. Sem ninguém ao volante. E sem travões.
Há uma narrativa persistente na indústria tecnológica de que o objetivo final é a automação total. Tirar os humanos do ciclo. Deixar as máquinas fazer tudo porque são mais rápidas, mais eficientes, não cometem “erros humanos.” E esta narrativa é extremamente perigosa.
Os humanos não são o bottleneck que precisamos de eliminar. Os humanos são o guardrail que evita que decisões algorítmicas se transformem em catástrofes. Quando removemos o humano do ciclo de decisão em sistemas críticos, não estamos a ser inovadores. Estamos a ser irresponsáveis.
A AWS aprendeu isto da forma mais dolorosa possível: com sistemas em baixo, clientes afetados, e a credibilidade manchada. E mesmo assim, a resposta inicial foi minimizar, chamar-lhe “coincidência”, culpar o utilizador. Não é assim que se constrói confiança. É assim que se garante que o próximo incidente vai ser pior.
O que afinal devemos fazer: Mais mitigação real, menos buzzwords
Chega de diagnóstico. Vamos falar de soluções concretas. Aqui está o que qualquer organização que use IA em ambientes de produção, quer seja na AWS, Azure, GCP, ou on-premise, precisa de implementar imediatamente.
RBAC rigoroso para agentes IA, com zero admin por defeito. As ferramentas de IA devem ter roles específicas com permissões granulares. Nunca, em circunstância alguma, devem herdar as permissões do operador. Se um agente precisa de ler logs, damos-lhe permissão para ler logs. Não lhe damos permissão para apagar ambientes inteiros. Isto devia ser óbvio, mas aparentemente para a Amazon não era. Ou então estão tão desesperados para vender a ideia que o destino se encarregou de lhes ensinar.
Aprovação humana obrigatória em produção. Qualquer ação destrutiva ou potencialmente destrutiva proposta por um agente de IA em ambiente de produção precisa de aprovação explícita de um humano. Não de um segundo agente. De um ou mais humanos. Com olhos, cérebro, pensamento tridimensional e capacidade de dizer “não, isto é uma péssima ideia.” Se a Amazon tivesse exigido aprovação de um segundo engenheiro antes do Kiro executar a sua decisão de terra queimada, aquelas 13 horas de downtime simplesmente não teriam acontecido.
Monitorização em tempo real e logging de todas as ações. Cada ação executada por um agente de IA deve ser registada, monitorizada, e auditável. Não depois do facto. Em tempo real. Com alertas para ações que ultrapassem thresholds de risco predefinidos. Se um agente decide apagar um ambiente, quero um alerta no Slack, no PagerDuty, no telemóvel de alguém, antes que a ação seja completada. Não depois.
Testes em staging com rollback automático. As alterações propostas por agentes de IA devem ser primeiro aplicadas em ambientes de staging, validadas, e só depois promovidas para produção. Com mecanismos de rollback automático que revertam alterações quando métricas de saúde do sistema degradam. Isto não é rocket science. É basic deployment strategy que fazemos com código humano há décadas. Porque é que para IA seria diferente?
Revisão consciente de prompts e decisões: human-in-the-loop sempre. Não basta ter um humano que clica “OK” sem ler. Precisamos de processos de revisão que obriguem o operador a compreender o que a IA está a propor antes de autorizar a execução. Isto significa interfaces que mostrem claramente o plano de ação, o impacto estimado, e os riscos associados. Se a interface diz “Kiro propõe: apagar e recriar o ambiente do Cost Explorer”, qualquer engenheiro com dois dedos de testa diria “não, corrige o bug e não toques no resto.”
A Pergunta que Ninguém Está a Fazer
Aqui está o que realmente me preocupa: se a Amazon, com os seus recursos praticamente ilimitados, as suas equipas de engenharia de classe mundial, e décadas de experiência em operar infraestrutura crítica, não conseguiu implementar controlos adequados para as suas próprias ferramentas de IA, o que é que acham que está a acontecer nas milhares de empresas mais pequenas que estão a adotar IA a toda a velocidade sem pensarem nas consequências?
A resposta é simples e assustadora: a mesma coisa, mas pior. Sem a visibilidade. Sem os recursos para recuperar. Sem os engenheiros capazes de resolver um incidente em 13 horas em vez de 13 dias.
Estamos numa corrida para integrar IA em tudo, e a pressão vem de todos os lados: dos investidores, dos boards, dos concorrentes, dos media. E nessa corrida, a segurança e os controlos são vistos como fricção, como obstacles à velocidade, como coisas que “vemos depois.”
Mas “depois” é quando os sistemas estão em baixo. “Depois” é quando os dados foram apagados. “Depois” é quando se percebe que não há backups porque o agente de IA também os apagou.
A Lição Final
A IA é uma ferramenta extraordinária. Uso-a diariamente em muitos clientes meus. Recomendo o seu uso para quem não se preocupa com questões do on-prem. Mas uma ferramenta extraordinária nas mãos erradas, ou sem os controlos certos, é apenas uma forma mais eficiente de causar destruição.
A AWS mostrou-nos, da forma mais concreta possível, o que acontece quando confundimos velocidade com segurança, quando tratamos automação como sinónimo de progresso, e quando removemos os humanos das decisões que mais precisam deles.
A próxima vez que alguém vos disser que “a IA resolve isso” sem mencionar guardrails, controlos, aprovações, e monitorização, lembrem-se do Kiro. Lembrem-se dos 13 horas. Lembrem-se que a ferramenta de IA da maior plataforma de cloud do mundo olhou para um bug simples e decidiu que a solução era apagar tudo.
E depois perguntem-lhes: “E quem é que vai aprovar isso antes de ir para produção?”
Se a resposta for “ninguém, a IA trata disso”, run. Run for the hills. Corram o mais depressa que puderem.
Até ao próximo post.
Nuno