IA autônoma em drones: a ética da camada de decisão para devs

Quando o código que você escreve vira munição: IA autônoma, drones e a linha que separou software de arma letal

Três nomes. Tetiana Bubynets, 19 anos. Oleksiy Svirin, 41. Roman Karpiy, 48. Três civis mortos no começo de julho em Zaporizhzhia por um ataque de drone, conforme reportagem do Olhar Digital baseada em apurações sobre a guerra na Ucrânia. Outras milhares de pessoas morreram em bombardeios desde o início do conflito. Não é um assunto “de outro mundo”. É um assunto de quem escreve software que processa imagens, treina modelos de detecção e toma decisões em milissegundos. E é por isso que eu, como dev, preciso falar sobre isso.

O que antes parecia ficção — drones autônomos selecionando alvos sozinhos — já é rotina operacional. E a fronteira entre “ferramenta de defesa” e “arma que mata civis” não é uma decisão de hardware. É uma decisão de modelo, de threshold, de quem assina o PR no repositório. Se você trabalha com visão computacional, sistemas autônomos ou pipelines de ML em produção, isso diz respeito direto a você.

A diferença técnica entre “drone teleguiado” e “drone autônomo”

Muita gente ainda pensa em drone como aquele brinquedo controlado por joystick. Na guerra moderna, existem pelo menos três níveis de autonomia que importam:

• Remotamente pilotado (RPAS): um humano controla tudo em tempo real. O drone é só um transmissor de vídeo armado. Não é autonomia — é teleoperação.
• Human-on-the-loop: o drone voa sozinho, identifica alvos por visão computacional e propõe engajamentos. O humano aprova ou aborta em segundos.
• Human-out-of-the-loop: o sistema detecta, classifica, prioriza e ataca sem intervenção humana. O humano só lê o relatório depois.

O salto entre o segundo e o terceiro nível é onde a maioria dos engenheiros de software passa batido. Parece “só mais um pipeline”. Mas é literalmente a diferença entre um sistema que pode matar e um sistema que vai matar sem ninguém apertar botão nenhum. Em organizações como a Stop Killer Robots, esse terceiro nível é exatamente o que está sendo discutido em termos de proibição internacional.

O pipeline real por trás de um “engajamento” autônomo

Quando eu montei pipelines de visão computacional para projetos menos sensíveis (controle de qualidade em linha de produção, por exemplo), a arquitetura era basicamente a mesma usada em drones militares. A diferença estava no output: no meu caso, era “peça defeituosa” em vez de “alvo confirmado”. Isso me fez perceber quão tênue é a fronteira técnica.

Um pipeline típico tem estas etapas:

1. Aquisição: frame de câmera infravermelha ou RGB.
2. Detecção: modelo tipo YOLO, Faster R-CNN ou DETR encontra objetos na cena.
3. Classificação: rede separada (ou cabeça do mesmo modelo) diz se aquilo é civil, militar, veículo, criança, animal.
4. Tracking: Kalman filter ou ByteTrack mantém a identidade entre frames.
5. Decisão: threshold de confiança + regras de engajamento decidem se o alvo é “válido”.
6. Execução: sinal para o atuador (no caso de drone, o detonador).

Exemplo simplificado da camada de decisão

Vou mostrar um trecho conceitual em Python do que é a camada de decisão — a parte que decide “engaja ou não engaja”. É aqui que mora a ética do sistema, e é onde o dev tem responsabilidade direta.

# decision_layer.py
# Camada de decisão de um sistema autônomo. Conceitual/educacional.

from dataclasses import dataclass
from enum import Enum

class EngagementDecision(Enum):
    HOLD = "hold"
    REQUEST_HUMAN_APPROVAL = "request_human"
    ENGAGE = "engage"
    ABORT = "abort"

@dataclass
class Target:
    classification: str          # ex: "civil_vehicle", "soldier", "child"
    confidence: float            # 0.0 a 1.0
    distance_m: float
    is_near_civilian_infra: bool
    last_seen_seconds: float

ENGAGEMENT_RULES = {
    # Apenas alvos militares podem ser engajados autonomamente
    "military_vehicle": 0.85,
    "soldier":          0.90,
    # CIVIS NUNCA são engajados, independentemente da confiança
    "civilian_vehicle": 1.01,
    "child":            1.01,
    "unknown":          1.01,
}

def decide(target: Target) -> EngagementDecision:
    threshold = ENGAGEMENT_RULES.get(target.classification, 1.01)

    # Regra 1: nenhuma confiança acima do threshold? segura.
    if target.confidence < threshold:
        return EngagementDecision.HOLD

    # Regra 2: perto de infraestrutura civil? aborta sempre.
    if target.is_near_civilian_infra:
        return EngagementDecision.ABORT

    # Regra 3: tracking instável (alvo sumiu) segura.
    if target.last_seen_seconds > 2.0:
        return EngagementDecision.HOLD

    return EngagementDecision.REQUEST_HUMAN_APPROVAL

Esse código é didático, mas representa exatamente o tipo de lógica que define se um drone autônomo mata um tanque ou uma criança. Um threshold mal calibrado, uma classe faltando no dicionário, um bug no filtro de Kalman — qualquer um desses vira corpo no noticiário.

Na Prática: por que o modelo erra (e sempre vai errar)

Na minha experiência deployando modelos em produção, três classes de erro são recorrentes — e todas elas aparecem em sistemas de targeting:

1. Dataset enviesado

Se o modelo foi treinado majoritariamente com imagens de soldados masculinos adultos em uniformes, ele vai ter recall baixíssimo para combatentes em roupas civis, mulheres armadas ou crianças portando artefatos. Em fábrica isso vira "peça OK classificada como defeituosa". Em campo vira "alvo legítimo solto" ou pior, "civil atacado".

2. Distribuição adversária (dataset shift)

Modelos de detecção funcionam bem no domínio onde foram treinados. Quando o drone voa sobre uma cidade que nunca esteve no dataset, a acurácia despenca. Solução comum? Reduzir o threshold de confiança para não perder alvos militares. Esse é o momento exato onde o sistema começa a aceitar falsos positivos como positivos.

3. Sensores ruins em ambientes degradados

Fumaça, chuva, neblina, contraluz. Câmeras térmicas saturam em incêndios. Em cenários reais de guerra urbana, esses são a norma — não a exceção. Modelos confiáveis em laboratório viramloteria em campo.

Erros comuns que devs cometem quando constroem sistemas autônomos

• Confundir acurácia com segurança. 95% de acurácia em um dataset limpo significa que 5 em cada 100 alvos estão errados. Em detecção de spam tudo bem. Em targeting, esses 5 são pessoas.
• Métricas agregadas escondem o pior caso. Média de acurácia mascara os outliers. O dev precisa olhar worst-class accuracy e taxa de falso positivo por classe.
• Achar que "human-on-the-loop" resolve o problema ético. Estudos mostram que humanos aprovam 90%+ das sugestões de IA em segundos, sem realmente revisar (o famoso automation bias). Não é supervisão, é teatro de supervisão.
• Não versionar o dataset e o threshold juntos. Quando alguém muda o threshold de 0.85 para 0.80 em produção para "pegar mais alvos", ninguém rastreia. É um merge silencioso que mata.
• Tratar "alvo" como abstração técnica. No commit message vai estar fix: lower threshold for class 'vehicle'. No mundo real, isso muda quem sobrevive à noite.

O que isso significa para quem trabalha com IA hoje

Eu não estou dizendo que todo dev de visão computacional vai acabar escrevendo código de drone militar. Mas existe uma cadeia de suprimentos de software séria: contractors terceirizados, datasets públicos, modelos pré-treinados em Hugging Face que podem ser fine-tuned para finalidades letais, datasets abertos como o ImageNet que alimentam tanto um classificador de produtos quanto um sistema de targeting.

Quando você assina um PR, três perguntas merecem ser feitas:

1. Quem é o usuário final deste modelo?
2. O sistema tem human-in-the-loop real, ou só humano-para-responder-ao-relatório?
3. Qual é a taxa de falso positivo por classe minoritária?

Se a resposta para a segunda pergunta for "human-on-the-loop com janela de 3 segundos", você está olhando para um sistema que decide sozinho na prática. E aí a responsabilidade ética, na minha leitura, volta para quem escreveu o código da camada de decisão.

Comparação honesta: drones autônomos vs. carros autônomos

Sempre que o tema aparece, alguém compara drones militares com Tesla FSD ou Waymo. A comparação é útil porque revela uma assimetria reveladora:

O setor civil passou anos debatendo se um carro autônomo deveria ser permitido a 50 km/h em área urbana com 1% de chance de erro. O setor militar debate se um drone pode decidir matar alguém sem supervisão humana. A incoerência é gritante — e a diferença, no fim, é apenas quem está em risco quando o modelo erra.

FAQ — Perguntas que devs reais fazem

1. Existem modelos de código aberto que já foram usados em drones autônomos?

Modelos como YOLOv8 e frameworks como ROS têm uso dual claro. Não há confirmação pública de uso militar direto dessas ferramentas específicas, mas arquiteturas de detecção em tempo real baseadas nelas já são padrão em pesquisas acadêmicas militares. O ecossistema open source não é neutro — ele habilita tanto um app de contagem de pessoas quanto um sistema de targeting.

2. Como funciona o "human-on-the-loop" na prática em sistemas militares?

O operador recebe uma sugestão de alvo com vídeo anexo. Tem alguns segundos (geralmente entre 5 e 30) para aprovar ou abortar antes do engajamento automático. Estudos da RAND e da própria indústria indicam que a taxa de aprovação humana fica acima de 90%, mesmo quando o tempo de revisão é insuficiente. É, na prática, uma assinatura em branco.

3. Tem como um dev recusar esse tipo de projeto eticamente?

Sim, e cada vez mais empresas sérias permitem. O ACM Code of Ethics, cláusula 1.2, fala explicitamente em "evitar causar dano". Na prática, vale documentar a recusa por escrito e acionar canais internos antes de qualquer ação pública.

4. A detecção de civis em tempo real é tecnicamente viável hoje?

Em condições controladas, sim. Em ambientes urbanos de guerra real (fumaça, oclusão, roupas civis similares a uniformes), a taxa de erro é alta o suficiente para tornar qualquer sistema baseado apenas em visão computacional não-confiável para decisões letais autônomas.

5. O que posso fazer como dev sem estar em projeto militar?

Apoiar publicamente regulamentação de armas autônomas, exigir cláusulas de uso ético em modelos open source que você contribui, e pressionar seu empregador a ter comitês de ética para projetos com potencial dual-use. Não é panaceia, mas é começo.

O ponto que eu quero deixar — e isso é o que mais me pesa como dev — é que Tetiana, Oleksiy e Roman não morreram por causa de uma bala perdida nem de um piloto deliberado. Eles morreram por causa de uma cadeia de decisão que alguém escreveu, alguém fez deploy e alguém nunca questionou. Sistemas letais autônomos não são "o próximo passo natural da tecnologia". São uma escolha. E toda escolha técnica é também uma escolha ética.

Quando você projeta a próxima camada de decisão do seu próximo modelo, lembra: a única coisa que separa um sistema de targeting de um classificador de imagens é o dataset, o threshold e o contrato social por trás dele. Não subestime o seu papel nisso.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.