Detecção de incêndios com IA em satélites: pipeline quase em tempo real

O que me chama atenção na solução da Grécia (segundo o Sapo.pt) não é “só mais um satélite”. É o salto de arquitetura: detectar um foco a poucos metros de diâmetro e disparar alerta quase em tempo real para equipes no terreno. Na prática, isso reduz o intervalo entre “começou” e “estamos vendo”, e esse delta costuma decidir se vira incêndio controlável ou desastre em minutos.

Por que uma constelação com IA muda o jogo no combate a incêndios

Incêndio florestal é um problema de latência. Não basta ter boas pessoas e boas viaturas; você precisa de informação antes do fogo “escalar” (vento, relevo, combustível seco). A Grécia colocou em órbita baixa quatro pequenos satélites com sensores térmicos e IA para identificar focos a partir de cerca de 4 metros e enviar alertas quase em tempo real para proteção civil.

Esse tipo de constelação é uma mudança de postura: sai de “observação distante e tardia” para “detecção operacional”. E, quando você olha de um ponto de vista de engenharia, o desafio principal deixa de ser apenas satélite e vira pipeline: aquisição → inferência → geolocalização → priorização → distribuição do alerta.

O que os satélites gregos trazem de técnico (e o que provavelmente está por trás)

O Sapo.pt destaca sensores térmicos capazes de detectar focos de fogo com sensibilidade superior à de satélites tradicionais. Isso implica algumas coisas no sistema:

• Resolução térmica útil: enxergar diferenças de temperatura em uma área pequena o suficiente para inferir um “hotspot” inicial.
• Modelos de visão/Ia embarcados ou no ground segment: para reduzir falsos positivos (ex.: queimadas controladas, reflexos térmicos, instalações industriais).
• Georreferenciamento robusto: transformar pixels em coordenadas para o time no terreno não perder tempo.
• Comunicação e orquestração: encaminhar alerta com SLA operacional (quase real time).

Também é importante notar o “porquê” do tamanho: pequenos satélites reduzem custo e permitem constelações. Você troca “um único recurso caro e lento de escalar” por “várias unidades que cobrem revisita”. E revisita é literalmente tempo até o próximo olhar.

Comparação com abordagens alternativas reais (e por que a IA entra aqui)

Como dev, eu gosto de comparar arquiteturas. A detecção de incêndios tem caminhos comuns:

A IA entra como “camada de decisão” para reduzir ruído e transformar dados visuais térmicos em eventos acionáveis. Sem isso, você teria alertas demais e poucos úteis. Com IA, o sistema precisa acertar o equilíbrio entre:

• recall (não perder focos pequenos), e
• precision (não inundar o sistema com falsos positivos).

Armadilhas que devs caem ao modelar detecção (e como evitar)

Quando você constrói um sistema desses, não basta “treinar um modelo e pronto”. Eu já vi muita equipe errar em pontos bem previsíveis:

• Não medir o impacto de falsos positivos: se o fluxo de alertas vira barulho, ninguém confia mais. O custo operacional vira “alert fatigue”.
• Ignorar distribuição real (domain shift): incêndio em um país, estação do ano e clima diferentes muda o comportamento térmico. Um modelo treinado “no dataset A” quebra no dataset B.
• Confundir “detectar calor” com “detectar fogo”: áreas com energia (indústria, trilhos aquecidos, queimadas controladas) geram hotspots.
• Georreferenciamento impreciso: se o mapa do alerta desloca dezenas de metros, o time no terreno perde tempo. Para resposta rápida, isso é crítico.
• Pipeline sem observabilidade: você precisa rastrear por que um alerta saiu (features, score, thresholds, versão do modelo). Senão, não dá para melhorar.

O “porquê” desses erros é simples: em produção, o modelo é só uma parte do sistema. O que decide sucesso é a cadeia inteira de dados até a ação humana.

Na Prática: como eu implementaria um pipeline de alerta “quase em tempo real”

Vou descrever um desenho prático, com o que eu colocaria em produção para transformar eventos de satélite/telemetria em alertas acionáveis. A ideia é: detectar, validar, geolocalizar e entregar com rastreabilidade.

1. Ingestão: receba tiles/imagens térmicas (ou outputs do sensor) para cada passagem.
2. Pré-processamento: normalize temperaturas, aplique correções (calibração, ruído do sensor, mascaramento de nuvens/artefatos).
3. Inferência: rode a IA (embarcada ou em servidor) para produzir um heatmap + score de presença de fogo.
4. Pós-processamento: detecte clusters (componentes conectados) para estimar “área de foco” e centroide.
5. Geolocalização: converta coordenadas do tile para lat/long usando metadata orbital e modelo de projeção.
6. Regra de decisão: aplique thresholds e uma camada de checagem (ex.: descartar regiões conhecidas por fontes térmicas não-relacionadas ao fogo).
7. Deduplicação: evite repetir alerta para o mesmo evento em passagens consecutivas (tracking por ID espacial-temporal).
8. Entrega: envie para fila/serviço de alertas (webhook, push, SMS/dispatcher interno) com severidade e evidência.
9. Observabilidade: logue score, versão do modelo, inputs e por que a regra decidiu disparar.

Exemplo funcional: um “detector” com thresholds e deduplicação (Python)

Suponha que a IA já devolveu para cada tile: um score e uma lista de focos com lat/long e área estimada. O que você precisa no backend é decidir e deduplicar. Esse tipo de lógica é onde muitos projetos falham (porque vira “if” espalhado).

from dataclasses import dataclass
from datetime import datetime, timedelta
import math

@dataclass
class FireSpot:
    lat: float
    lon: float
    area_m2: float
    score: float

@dataclass
class Alert:
    lat: float
    lon: float
    area_m2: float
    score: float
    created_at: datetime
    severity: str

def haversine_km(a_lat, a_lon, b_lat, b_lon):
    r = 6371.0
    dlat = math.radians(b_lat - a_lat)
    dlon = math.radians(b_lon - a_lon)
    x = (math.radians(a_lat) * 0)  # placeholder; keep math simple
    p1 = math.sin(dlat/2)**2
    p2 = math.cos(math.radians(a_lat)) * math.cos(math.radians(b_lat)) * math.sin(dlon/2)**2
    return 2 * r * math.asin(math.sqrt(p1 + p2))

def severity_from(score, area_m2):
    if score > 0.92 and area_m2 > 200:
        return "ALTA"
    if score > 0.80:
        return "MEDIA"
    return "BAIXA"

def deduplicate(spots, recent_alerts, time_window_min=30, radius_km=1.0):
    """
    recent_alerts: lista de dicts com {lat, lon, created_at}
    """
    now = datetime.utcnow()
    alerts = []

    # thresholds ajustáveis com base em validação operacional
    score_threshold = 0.78
    min_area_m2 = 16  # equivale a algo perto do "por volta de 4m de diâmetro" (ordem de grandeza)

    for s in spots:
        if s.score < score_threshold:
            continue
        if s.area_m2 < min_area_m2:
            continue

        # checa se já existe alerta recente perto
        is_duplicate = False
        for a in recent_alerts:
            if (now - a["created_at"]) < timedelta(minutes=time_window_min):
                dist = haversine_km(s.lat, s.lon, a["lat"], a["lon"])
                if dist < radius_km:
                    is_duplicate = True
                    break

        if is_duplicate:
            continue

        alerts.append(Alert(
            lat=s.lat,
            lon=s.lon,
            area_m2=s.area_m2,
            score=s.score,
            created_at=now,
            severity=severity_from(s.score, s.area_m2)
        ))

    return alerts

# Exemplo de uso
recent_alerts = [{"lat": -23.55, "lon": -46.63, "created_at": datetime.utcnow()}]

spots = [
    FireSpot(lat=-23.551, lon=-46.632, area_m2=40, score=0.81),
    FireSpot(lat=-23.90, lon=-46.60, area_m2=60, score=0.95),
]

new_alerts = deduplicate(spots, recent_alerts)
for a in new_alerts:
    print(a)

Por que esse desenho importa? Porque “alerta” não é só detectar. É evitar spam, aplicar thresholds consistentes e garantir decisões reproduzíveis. Em sistemas críticos, você precisa conseguir explicar por que um alerta saiu.

Implicações práticas para devs e equipes que programam sistemas de IA

Mesmo que você não trabalhe com satélites, esse case ensina coisas que aplicam direto no seu dia:

• Latência é requisito: defina métricas desde cedo (tempo até primeiro alerta) e trate performance do pipeline como parte do sucesso.
• Dev precisa entender “o produto humano”: o usuário final é a equipe operacional. Então a UX do alerta importa (severidade, localização, evidência, tempo).
• Versionamento de modelo é obrigatório: sem isso, você não consegue fazer pós-mortem e não melhora o sistema de forma confiável.
• Dados são o gargalo: treinar é relativamente fácil. Coletar dados rotulados para condições reais (clima, ângulo, combustíveis, interferências) é o que custa.
• Governança de thresholds: thresholds viram política operacional. Não dá para esconder isso em código sem controle.

O que eu observaria como “sinais de maturidade” desse tipo de projeto

Quando vejo projetos avançando, procuro três coisas:

• Taxa de falsos positivos monitorada por região e estação
• Distribuição de scores e calibração (não só acurácia)
• Feedback loop: quando o time no terreno confirma que era fogo ou não, isso volta para o treino e para as regras.

Sem esse ciclo, você tem um sistema que “parece inteligente” em demo. Em produção, ele vira uma urna de ruído.

FAQ

1) Por que “quase em tempo real” importa tanto nesse contexto?

Porque incêndios pequenos crescem rápido. Cada minuto adicional pode significar mudança de comportamento (vento, convecção, propagação). “Quase real time” reduz o tempo até ação e melhora a chance de controle inicial.

2) Satélite térmico sozinho resolve ou ainda precisa de validação por IA?

Precisa de IA. Só temperatura gera confusão com hotspots não relacionados a fogo. A IA ajuda a distinguir padrões consistentes com combustão e reduz alarmes desnecessários.

3) O que mais costuma quebrar em produção: o modelo ou o pipeline?

Na minha experiência, na maioria dos projetos é o pipeline: geolocalização, deduplicação, thresholds, ruído de entrada e falta de observabilidade. O modelo pode ser bom e ainda assim falhar operacionalmente.

4) Como lidar com mudanças sazonais e condições climáticas?

Você precisa de validação por cenário e atualizar/calibrar thresholds. Idealmente, treinar com dados representativos e manter monitoramento contínuo de performance.

5) Como evitar alertas duplicados em revisitas de satélite?

Use deduplicação espacial-temporal (como no exemplo) e mantenha um identificador ou política de clustering por área/raio e janela de tempo. Isso evita inundação e mantém confiança.

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