Edge AI em câmaras municipais: o sistema de Dallas na prática

Câmaras com IA em camiões do lixo: o que está realmente a acontecer em Dallas

A cidade de Dallas instalou 100 câmaras de IA em 50 camiões de recolha de lixo volumoso para fotografar fachadas e atribuir um “blight score” (1 a 4) a cada propriedade. Segundo o Sapo.pt, o sistema começou a ser testado em abril e foi intensificado durante o verão. Parece simples, mas por trás há uma decisão arquitetural pesada: onde corre o modelo, como se processam as imagens, quem vê os dados e, mais importante, como se evita um escândalo de vigilância massiva disfarçada de serviço público.

Na minha experiência com pipelines de visão computacional em produção, este caso é um excelente exemplo de edge AI aplicada ao domínio público. Vou desconstruir o que provavelmente está debaixo do capô e o que devs e engenheiros precisam de considerar antes de aplaudirem ou criticarem a ideia.

O que o artigo do Sapo não diz: a stack provável

100 câmaras a 1920×1080, sem zoom, a fotografar fachadas em movimento a ~30 km/h. Cada camião gera entre 30 a 60 frames por segundo por câmara, ou seja, ~180 GB de dados brutos por dia por veículo antes de qualquer inferência. Ninguém armazena isso. Ou há inferência on-device (edge), ou os custos de cloud fariam o projeto morrer em três meses.

Aposto num dos dois cenários seguintes:

• Edge AI com TPU ou Jetson: um NVIDIA Jetson Orin Nano ou Google Coral por camião, a correr um modelo YOLOv8-nano ou EfficientDet-Lite quantizado para INT8. Resultado processado, lixo eliminado, apenas metadata enviada.
• Pipeline híbrido: deteção de movimento ou change-detection primeiro (modelo leve), e só as frames relevantes vão para um modelo maior, num servidor central.

Para um projeto municipal, a segunda opção faz mais sentido — centralizar treino, manter update OTA dos modelos, e reduzir custo de hardware por veículo.

Como funcionaria o “blight score” na prática

O número de 1 a 4 é, na verdade, a saída de um classificador ordinal — não é uma regressão contínua. Em termos de engenharia, isto resolve um problema clássico: como converter deteções brutas num índice acionável?

1. Deteção de objetos num crop da fachada: relva alta, lixo, entulho, fissuras visíveis.
2. Contagem e confiança por classe (ex.: 3 ocorrências de “erva” com confiança média 0.82).
3. Regras de negócio que mapeiam essa contagem para 1–4. Algo como: 0 ocorrências = 1, 1–2 ocorrências leves = 2, etc.
4. Filtro humano antes de gerar a multa ou notificação.

A peça mais sensível é a terceira. Num sistema deste tipo, deves sempre que possível manter as regras auditáveis, não escondidas dentro da rede neuronal. É mais fácil defender o sistema legalmente quando os pesos decisivos estão em código aberto dentro da própria equipa.

Na Prática: protótipo de deteção de “erva alta” com YOLOv8

Vou mostrar como reproduzir uma peça central deste sistema. Para devorar este exemplo precisas de: Python 3.10+, ultralytics, e uma GPU NVIDIA (ou sacrifica velocidade e corre em CPU).

# detector_fachada.py
# Pipeline mínimo: recebe uma imagem de fachada e devolve contagem de alvos.

from ultralytics import YOLO
from collections import Counter
import cv2
import numpy as np

# Modelo pré-treinado no COCO — serve como base para o exemplo.
# Em produção, faria fine-tune num dataset de fachadas urbanas.
model = YOLO("yolov8n.pt")

# Classes do dataset custom (em produção terias o teu)
CLASSES_ALVO = {
    "erva_alta": "erva",
    "lixo_acumulado": "lixo",
    "entulho": "entulho",
    "fachada_danificada": "estrutura",
}

def classificar_fachada(imagem_path: str) -> dict:
    """Devolve o blight score (1–4) baseado em contagem de anomalias."""
    img = cv2.imread(imagem_path)
    if img is None:
        raise FileNotFoundError(f"Falha a ler {imagem_path}")

    results = model.predict(img, conf=0.5, imgsz=1280, verbose=False)

    contagem = Counter()
    confiancas = []

    for r in results:
        for box in r.boxes:
            classe_id = int(box.cls.item())
            classe_nome = model.names[classe_id]
            conf = float(box.conf.item())
            confiancas.append(conf)

            # Mapeia classes do modelo para as categorias municipais
            for alvo in CLASSES_ALVO.values():
                if alvo in classe_nome.lower():
                    contagem[alvo] += 1

    # Regra de negócio: simples, auditável, defensável em tribunal.
    total_anomalias = sum(contagem.values())
    if total_anomalias == 0:
        score = 1
    elif total_anomalias <= 2:
        score = 2
    elif total_anomalias <= 5:
        score = 3
    else:
        score = 4

    return {
        "blight_score": score,
        "anomalias_detetadas": dict(contagem),
        "confianca_media": float(np.mean(confiancas)) if confiancas else 0.0,
        "recomenda_revisao_humana": score >= 3,
    }

if __name__ == "__main__":
    resultado = classificar_fachada("fachada_rua_42.jpg")
    print(resultado)

Algumas notas sérias sobre este snippet:

• Confiança > 0.5 é um limiar conservador. Em produção, eu começaria em 0.7 para evitar falsos positivos com consequências legais.
• Fine-tune é obrigatório. COCO tem classes tipo “potted plant” e “bench”, mas não “erva daninha urbana” nem “grafíte em fachada”. Sem dataset dedicado, a precisão despenca.
• Logs de todas as predições. Cada decisão tem de ficar registada para auditoria.

Comparação com alternativas reais

Há três caminhos viáveis para um projeto destes. Vou colocar lado a lado o trade-off honesto:

Em quase todos os cenários públicos, o híbrido vence. Porquê? Porque o problema não é técnico, é político-jurídico. Se a câmara gravar tudo e enviar tudo para um servidor municipal, isto rebenta numa semana por queixa de privacidade. Se nada sai do camião além de um JSON, o risco reduz drasticamente.

Erros Comuns que devs cometem neste tipo de projeto

Depois de implementar vários sistemas de visão em produção, vejo os mesmos tropeços uma e outra vez:

• Confundir accuracy com utilidade. Um modelo com 95% de accuracy num dataset balanceado pode falhar precisamente nas casas que precisam de atenção (as degradadas e visualmente “estranhas”). Mede precisão por classe, não global.
• Ignorar o bias do dataset. Se o modelo foi treinado maioritariamente em bairros ricos, vai errar mais nos bairros que o sistema supostamente quer proteger. Isto é um problema ético e legal.
• Esquecer a revisão humana no loop. Decisões administrativas automáticas (multas, notificações) sem salvaguarda humana são um convite a ações judiciais.
• Não tratar a geolocalização das câmaras. GPS drift de 10 metros pode atribuir a infração à propriedade errada. Calibra as coordenadas e reconcilia com o cadastro municipal.
• Subestimar a iluminação e oclusão. Camiões passam de manhã cedo, ao entardecer, à noite. Sem pré-processamento robusto e dados de treino diversificados, a performance varia brutalmente por hora do dia.
• Tratar o modelo como produto final. O modelo é o componente que precisa de mais monitorização contínua. Drift acontece — solstícios, estações do ano, obras. Alerta de drift deve ser tão importante quanto o modelo em si.

A pergunta que ninguém faz: e a falácia do “score 1”?

Um sistema que atribui “score 1” (sem infração) a uma propriedade fotografada de forma imperfeita, a 30 km/h, sem zoom, com oclusão possível de árvores e carros estacionados — não está realmente a avaliar a propriedade. Está a assumir “não detetei nada, logo está limpo”. Isto é uma falsa negativa perigosíssima.

Devs sérios têm de comunicar isto claramente aos decisores políticos. Um score “baixo” deve ser sempre “baixa confiança” ou “não avaliado”, não “aprovado”.

Implicações para quem está a construir sistemas parecidos

Se estás a considerar implementar algo assim em Portugal ou no Brasil, três recomendações práticas da minha experiência:

1. Alinhar com a CNPD ou ANPD antes do piloto. Em Portugal, a Comissão Nacional de Proteção de Dados já se manifestou sobre câmaras com IA; em Brasil, a ANPD exige DPIA. Fazer depois é tarde.
2. Publicar a metodologia e o dataset (ou as suas limitações). Transparência não é optativa — é a única defesa real contra a narrativa “Big Brother municipal”.
3. Construir a plataforma para falhar bem. Logs estruturados, rollback de modelo, feature flags, e um dashboard de drift aberto à cidade. Isto transforma um projeto “controverso” num projeto “exemplar”.

FAQ — perguntas que devs realmente fazem

Como reduzir o custo de inferência sem perder precisão?

Usa change detection para descartar frames sem alteração significativa, faz inferência só nessas, e aplica quantização INT8 com calibração adequada. Em hardware Jetson Orin, consegues 30+ FPS com YOLOv8-nano quantizado sem sacrificar precisão significativa.

Qual o modelo mais indicado para deteção de anomalias em fachadas?

Para uma baseline rápida, YOLOv8 ou RT-DETR pré-treinado no COCO funciona como ponto de partida, mas vais precisar de fine-tune num dataset de fachadas urbanas etiquetadas. Para problemas onde a “anomalia” é subtil, considera um autoencoder que aprenda o que é “normal” e sinalize desvios.

O que fazer com imagens onde aparece uma pessoa na fachada?

Bloqueia e desfoca automaticamente antes da inferência. Detecção de pessoas (classe “person”) numa camada pré-processamento é mandatória. Não guardes estas imagens, nem mesmo encriptadas.

Como evitar viés contra bairros mais degradados?

Estratifica o dataset de treino por zona socioeconómica, mede métricas por estrato, e audita as decisões automaticamente. Se o recall for menor num bairro específico, é sinal de problema de dados, não de modelo “burro”.

Vale a pena usar LLM multimodal (tipo GPT-4V) em vez de CNN clássica?

Não. Custo por inferência é 50–100x superior, latência é maior, e para tarefas objetivas de deteção um YOLO bem treinado vence. Reserva LLMs multimodais para tarefas de raciocínio sobre a imagem (ex.: gerar relatório textual para o munícipe).

Conclusão

O projeto de Dallas é tecnicamente interessante e eticamente delicado — a combinação clássica de qualquer sistema de visão computacional aplicado ao espaço público. Na minha leitura, a execução determinará se isto é um caso de sucesso ou um desastre de privacidade. E a execução depende quase inteiramente das escolhas técnicas que listei acima: onde corre a inferência, como se gere o dado, quem audita, e como se comunica a incerteza.

Se fosses contratado para um projeto destes, por onde começarias? Há uma camada que achas crítica e que não mencionei? Deixa nos comentários — adoro debater decisões arquiteturais destes sistemas.

🚀 Mais conteúdo técnico em yurideveloper.com.br

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