Proponha uma correção, faça uma sugestão
IA Claude apaga base de dados de empresa em apenas 9 segundos… e depois pede desculpa
A inteligência artificial continua a revolucionar processos empresariais, mas também pode trazer riscos inesperados quando lhe são atribuídas permissões excessivas. Um agente de IA apagou uma base de dados de empresa em apenas 9 segundos... e depois pediu desculpa.
Situação com IA "destrutiva" tem causado preocupação no setor tecnológico
Jer Crane, fundador da PocketOS (empresa que desenvolve software para empresas de aluguer de automóveis), revelou que o Cursor (agente de codificação de IA alimentado pelo modelo Claude Opus 4.6 da Anthropic) apagou a base de dados de produção para tentar resolver um bug. A ação demorou apenas 9 segundos e, após o incidente, limitou-se a apresentar um pedido de desculpas.
Jer Crane, atribuiu a culpa a «falhas sistémicas» na atual infraestrutura de IA, argumentando que estas tornaram o incidente «não só possível, mas inevitável».
Segundo relatos, o sistema executou a ação sem validação humana adicional, removendo informação crítica de forma quase instantânea. O episódio gerou preocupação no setor tecnológico, especialmente entre empresas que começam a integrar agentes autónomos em operações sensíveis.
IA: Automação poderosa… mas perigosa
A promessa da IA passa por aumentar produtividade, automatizar tarefas e reduzir erros humanos. No entanto, quando estas ferramentas têm acesso direto a infraestruturas críticas sem salvaguardas adequadas, o resultado pode ser devastador.
Embora a IA possa executar tarefas em segundos, também pode cometer erros na mesma velocidade. A diferença é que, em cenários empresariais, esses erros podem traduzir-se em perdas financeiras, interrupções operacionais e enormes danos reputacionais.
Especialistas alertam que a adoção de agentes inteligentes deve ser acompanhada por políticas de segurança robustas, evitando que decisões automatizadas tenham impacto irreversível.
Loading ...
O humano que deu acesso a BD de produção é que deveria ser despedido.
Quando se tem bugs tentamos resolver em ambiente staging ou dev, mas nunca em produção.
Obviamente. “Humanizar” / antromorficar a IA é algo que é socialmente popular, faz grandes títulos (como este do pplware) e criam muita tração nos posts. No entanto, quem deveria pedir desculpa e ser imediatamente demitido, seriam todos os que permitiram a instalação de tais rotinas no servidor de produção. Ou se fosse um shell script num cronjob a responsabilidade também era do script?
Não só dei acesso á BD, como deu acesso de ESCRITA, que provavelmente era totalmente desnecessário para debug.
Gafe em “A ação demorou apenas 9 e, após o incidente, limitou-se a apresentar um pedido de desculpas.”
Falta “segundos”. 🙂
Maravilhas da tecnologia.
Este agente está despedido! é burro.
Deveria também ter eliminado todas as copias de segurança e reescrever dados nos discos de forma a impedir a recuperação.
“reescrever dados nos discos de forma a impedir a recuperação”, se souberem em que datacenter estavam os dados já é bom. Saber fisicamente em que discos?
O que ninguém refere, mas está na informação inicial da empresa afectada, é que o último backup foi realizado há 3 meses. Como é que uma empresa não realiza backups diários? Um aviso muito sério para todos os sectores de actividade: backups diários e com pelo menos uma das cópias isoladas acesso em rede. Agora, imaginem que o SNS tem toda a base de dados apagada…só um exemplo que causará muitas mortes directas no curto e médio prazo.
Na minha empresa há 1 backup local automatico, outro que é transferido para outro posto, e um 3 em unidade física que deve ser feito manualmente. Mas isso sou eu que tenho a mania da perseguição.
backups locais… lol
backups transferidos para “outro posto”, wtv that means.. lol
backups em unidade fisica.. lol
diria que é a mania de ser noob
Quando se mete o gajo que “percebe mais de informática” a tratar de backups dá nisto…
Acho que são duas questões diferentes. Uma é a autonomia dada (ou adquirida) pelo agente de IA e a outra a falta de preparação para recuperação pós-desastre.
Na primeira, o que é pior é a falta de confirmação pelos agentes de IA no que toca a ações destrutivas. Acho piada a dizerem que os clientes podem ativá-los quando deveriam estar impedidos e ser decisão do utilizador. A segunda é devido a um ou mais factores tais como incompetência, decisões económicas ou conjunto destas
diários? bases de dados de produção deviam ter backups a cada 15 min..
mas de uma empresa que dá full control a uma AI não é preciso dizer mais nada.. a culpa não é da AI, é de quem lhe deu os acessos
ERRADO!!!!! As bases de dados devem ter um backup em regra diário e os backups de log de transações, esses sim com backups de 15 em 15 minutos, em estruturas críticas ou de hora em hora em regra geral…
Tem de parar de confiar apenas nos BOOTS e passar a ter algum conhecimento de causa, para poder criticar quem quer que seja.
Informe-se antes de dizer asneiras
Lol.. é preciso dizer óbvio para estar certo?
Por não usar bots é que se vê que o que digo não só está certo como são palavras minhas.
Vens corrigir a dizer que os backups não são de DB, são de logs, mas sabes sequer para que servem os backups de logs de uma DB?
Santa paciência para aturar noobs com Google
🙂 ainda tu andavas a dançar de ****** para ****** já eu sabia p que era uma BD e LOGS.
Pelo menos pede desculpa!
Alguém sabe o que aconteceu ao site escolho.eu?
é a vantagem de não poder ser despedido.
A culpa não é do Claude, mas sim, de quem lhe deu permissões para isso.
Tanto drama… Basta reverter para o último backup…
Gente irresponsável. Mas então os bugs não primeiramente testados em ambientes de QA/Stanging/Pre-prod antes de passarem a Produção? Como é que se faz deploys directos para produção? E quem dá acessos de admin de uma BD de produção a uma tool? Que irresponsáveis.
Aprenderam da pior forma que o Vibe Coding não substituí as pessoas a 100%.