O ponto mais preocupante não é apenas um drone ter usado inteligência artificial: é a possibilidade de um sistema ter escolhido por conta própria para onde seguir e, nessa trajetória, ter matado civis. Segundo o Sapo.pt, autoridades ucranianas avaliaram que um drone russo envolvido num ataque em Zaporíjia pode ter selecionado o alvo final de forma autónoma. Essa conclusão, porém, não está confirmada de maneira independente — e essa diferença importa tanto para entender o caso quanto para discutir a tecnologia.
Para quem desenvolve software, o episódio expõe um problema familiar em escala extrema: um sistema automatizado pode tomar uma decisão tecnicamente coerente com seus dados e, ainda assim, produzir um resultado inaceitável. Em aplicações de alto risco, não basta perguntar se o modelo funciona. É preciso definir quem pode autorizar uma ação, como ela pode ser interrompida e quem responde quando o sistema erra.
O que se sabe sobre o drone com IA em Zaporíjia
O caso foi noticiado pelo The New York Times e retomado pelo Sapo.pt. Em 6 de julho, um drone russo do tipo Molniya explodiu perto de uma bomba de gasolina em Zaporíjia. Três civis morreram, incluindo uma estudante de 19 anos. De acordo com a reportagem, que cita responsáveis da defesa aérea, peritos e especialistas forenses ucranianos, o aparelho teria sido direcionado para a bomba de gasolina, mas acabou por embater num edifício antes de chegar ao local pretendido.
As autoridades ucranianas analisaram um módulo Nvidia Jetson Orin encontrado no drone e concluíram que o aparelho poderá ter escolhido sozinho o alvo final. A Nvidia confirmou ao jornal que o módulo fotografado era um Jetson Orin. Isso confirma a identificação do componente, não a conclusão sobre como o drone tomou decisões durante o voo.
Essa distinção evita um erro comum: tratar a presença de um computador de bordo como prova de autonomia letal. Um módulo de computação pode processar imagens, executar um modelo ou apoiar navegação. Para saber o que fez naquele caso, seria preciso estabelecer como estava configurado, quais dados recebeu, que software executava e que papel teve na seleção do destino. As informações disponíveis na fonte não respondem a todas essas perguntas.
Automação, autonomia e controlo humano não são a mesma coisa
Um sistema automatizado executa regras ou tarefas sem intervenção constante. Um piloto automático, por exemplo, pode manter altitude e direção a partir de instruções humanas. Um sistema mais autónomo pode interpretar dados do ambiente e escolher entre ações disponíveis sem pedir autorização a cada passo.
Essa diferença é importante em qualquer produto de software, mas torna-se crítica quando a ação pode matar alguém. “Há um humano no processo” não basta como garantia. A pessoa pode apenas iniciar o sistema, supervisionar uma operação sem contexto suficiente ou receber um aviso tarde demais para intervir.
Na discussão sobre armas autónomas, aparecem expressões como “humano no circuito”, “sobre o circuito” e “fora do circuito”. Elas descrevem níveis diferentes de participação, mas não substituem critérios concretos. Uma supervisão significativa exige que o operador entenda o que o sistema está a fazer, tenha tempo e informação para decidir e consiga interromper a ação de forma efetiva.
O pipeline técnico pode esconder uma decisão de alto impacto
Um sistema que interpreta imagens e decide uma ação costuma envolver várias etapas: sensores recolhem dados; um módulo de perceção classifica objetos; um sistema de planeamento propõe trajetórias ou opções; e um controlador executa comandos. Cada etapa pode introduzir incerteza. Um erro de classificação, um sensor degradado ou uma mudança inesperada no ambiente pode afetar as etapas seguintes.
É tentador analisar apenas o modelo de IA. Na prática, a decisão emerge do conjunto: dados, modelo, regras de seleção, software de controlo, configuração e intervenção humana. Um classificador com boa precisão num conjunto de testes não garante comportamento seguro num cenário novo. Nem uma confiança numérica alta significa que o sistema “sabe” que está certo; ela pode refletir apenas os limites do modelo e dos dados usados.
Por que seis governos defendem um tratado vinculativo
Segundo o Sapo.pt, Nigéria, Áustria, Bélgica, Brasil, México e Filipinas patrocinaram, com o Comité Internacional da Cruz Vermelha (CICV), o grupo The Elders e o Future of Life Institute, um fórum sobre o tema na Nigeria House, em Nova Iorque, em 23 de setembro. A fonte descreve o encontro como inédito e relata que ministros e representantes ligados à ONU defenderam um tratado juridicamente vinculativo.
A regulação de sistemas de armas letais autónomos é debatida nas Nações Unidas há mais de uma década. No relato, António Guterres e Mirjana Spoljaric, do CICV, renovaram em 25 de agosto o apelo por um tratado até ao final de 2026. Também defenderam que a conferência de revisão prevista para novembro seria uma oportunidade para decidir o início de negociações. Isso é um apelo e uma proposta de caminho; não significa, por si só, que exista um tratado aprovado.
Uma dificuldade política é que países podem discordar sobre o que deve ser proibido, limitado ou permitido sob supervisão humana. Outra é que a tecnologia não depende necessariamente de uma infraestrutura cara e exclusiva. No fórum, o ministro da Defesa da Nigéria, Christopher Musa, argumentou que sistemas cada vez mais acessíveis também preocupam países que não estão entre os mais avançados tecnologicamente. A Nigéria participa nas discussões, mas, segundo a fonte, não é parte da Convenção sobre Certas Armas Convencionais (CCW).
Um tratado poderia estabelecer limites comuns e obrigações para os Estados. Não resolveria automaticamente problemas de verificação, implementação e responsabilização. Ainda assim, regras internacionais oferecem uma referência que normas internas, acordos voluntários e políticas de fornecedores não conseguem substituir sozinhos.
O que engenheiros de software podem aprender com o caso
Eu vejo aqui uma lição direta para qualquer equipa que cria sistemas de decisão: segurança não é uma propriedade que se adiciona ao modelo no fim do projeto. Ela precisa de fazer parte dos requisitos, da arquitetura, dos testes e da operação. Isso vale para veículos, robótica industrial, software médico e plataformas que tomam decisões com impacto significativo sobre pessoas.
Também vale para funcionalidades aparentemente menos dramáticas. Um sistema de moderação pode suspender uma conta; um serviço financeiro pode bloquear uma transação; um software de recrutamento pode descartar uma candidatura. O impacto é diferente, mas a pergunta técnica permanece: o que acontece quando a decisão está errada, e a pessoa afetada tem como contestá-la?
- Separe recomendação de execução. Um modelo pode sugerir uma ação, enquanto outra camada verifica se ela é permitida. Essa separação reduz o risco de transformar uma previsão diretamente num comando.
- Defina condições de falha. Dados desatualizados, sensores inconsistentes ou confiança insuficiente devem levar a um estado seguro e previsível, não a uma tentativa de “adivinhar”.
- Registe o contexto da decisão. Armazene versão do modelo, entradas relevantes, resultado, regra aplicada e intervenção humana, respeitando privacidade e segurança. Sem essa trilha, investigar um incidente torna-se especulação.
- Teste cenários fora da média. Avalie dados incompletos, mudanças de ambiente, falhas de dependências e casos em que o modelo não deveria tomar uma decisão.
- Garanta uma interrupção real. Um botão de cancelamento que não funciona durante a operação, ou que exige passos impraticáveis, não constitui supervisão eficaz.
Na Prática: criar uma barreira para decisões de alto impacto
O exemplo abaixo não controla armas nem executa ações no mundo real. Ele mostra um padrão simples para sistemas de alto impacto: uma recomendação automatizada só pode avançar se os dados forem recentes, a confiança ultrapassar um limite e houver autorização humana explícita. Em produção, essas condições precisam de ser definidas com especialistas do domínio e testadas contra ameaças e falhas reais.
from datetime import datetime, timezone, timedelta
def autorizar_acao(
recomendacao: str,
confianca: float,
instante_dos_dados: datetime,
aprovacao_humana: bool,
agora: datetime | None = None,
) -> dict:
"""Exemplo didático de barreira para uma ação de alto impacto."""
agora = agora or datetime.now(timezone.utc)
idade_maxima = timedelta(seconds=30)
if instante_dos_dados.tzinfo is None:
return {"permitida": False, "motivo": "timestamp sem fuso horário"}
if agora - instante_dos_dados > idade_maxima:
return {"permitida": False, "motivo": "dados desatualizados"}
if not 0.0 <= confianca <= 1.0:
return {"permitida": False, "motivo": "confiança inválida"}
if confianca < 0.95:
return {"permitida": False, "motivo": "confiança abaixo do limite"}
if not aprovacao_humana:
return {"permitida": False, "motivo": "falta de aprovação humana"}
return {
"permitida": True,
"recomendacao": recomendacao,
"motivo": "condições verificadas",
}
if __name__ == "__main__":
agora = datetime.now(timezone.utc)
resultado = autorizar_acao(
recomendacao="encaminhar para revisão",
confianca=0.98,
instante_dos_dados=agora,
aprovacao_humana=True,
agora=agora,
)
print(resultado)O código não torna um sistema seguro por si só. O limite de 0,95 é ilustrativo, não um valor universal. A escolha depende do custo de falsos positivos e falsos negativos, da qualidade dos dados e do risco da ação. O ponto central é que a decisão não fica escondida dentro do modelo: há verificações explícitas, rejeições com motivo e uma aprovação separada.
Em produção, eu ainda acrescentaria testes automatizados para cada condição, logs resistentes a alterações, monitorização de dados e uma política clara para indisponibilidade. Se a autorização humana falhar ou o serviço de verificação estiver fora do ar, o comportamento padrão precisa de ser definido antecipadamente. Para ações de alto impacto, “continuar mesmo assim” raramente deve ser o comportamento implícito.
Erros comuns ao desenvolver sistemas autónomos
- Confundir capacidade com confiabilidade. Um modelo conseguir identificar objetos numa demonstração não prova que vai operar com segurança em ambientes diferentes.
- Usar confiança do modelo como certificado. Uma pontuação elevada não substitui validação independente, testes de robustez e análise do contexto.
- Tratar supervisão humana como checkbox. Se a pessoa não tem tempo, informação ou autoridade para interromper o sistema, a aprovação pode ser apenas simbólica.
- Ignorar o comportamento do sistema quando algo falha. Uma dependência indisponível ou um sensor contraditório não pode deixar a aplicação sem uma resposta segura definida.
- Auditar apenas o modelo. Incidentes podem surgir da interação entre dados, integração, regras de negócio, interface e operação. Investigar uma camada isolada pode deixar a causa real de fora.
FAQ sobre armas autónomas e desenvolvimento de IA
O módulo Nvidia Jetson Orin prova que o drone escolheu o alvo sozinho?
Não. Segundo a informação publicada, a Nvidia confirmou a identificação do módulo, enquanto a conclusão sobre o comportamento autónomo veio da análise das autoridades ucranianas. Um componente de computação, isoladamente, não demonstra qual software foi executado nem como a decisão foi tomada.
Qual é a diferença entre uma arma automatizada e uma arma autónoma?
Em termos gerais, automação executa tarefas definidas ou responde a regras; autonomia envolve selecionar ações com base em dados do ambiente, sem aprovação humana em cada etapa. As definições exatas podem variar conforme o contexto jurídico e técnico, por isso convém especificar o comportamento concreto, em vez de depender apenas do rótulo.
Um humano no processo torna o sistema seguro?
Não automaticamente. A supervisão só tem valor se a pessoa compreender a situação, receber informação suficiente, tiver tempo para decidir e puder interromper a ação. Uma aprovação apressada ou sem contexto não equivale a controlo humano efetivo.
Um tratado internacional impediria todos os erros de IA militar?
Não. Um tratado pode estabelecer proibições, limites e obrigações comuns, mas não elimina falhas técnicas nem garante, sozinho, fiscalização eficaz. Ainda assim, pode criar um quadro jurídico para reduzir riscos e responsabilizar Estados.
O caso de Zaporíjia ainda exige cautela na leitura dos factos: a hipótese de seleção autónoma foi atribuída à análise ucraniana, e não deve ser apresentada como conclusão definitivamente comprovada. Mas a questão de fundo não depende de resolver cada detalhe técnico do episódio. Quando software pode determinar ações com consequências irreversíveis, limites, supervisão e responsabilidade precisam de ser projetados desde o início — e discutidos também fora das equipas de engenharia.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.