137.000 pessoas, zero decisões humanas: resposta a desastres baseada em agentes com o Elasticsearch

O Agent Builder já está disponível na versão GA. Comece com um teste do Elastic Cloud e confira a documentação do Agent Builder aqui.

A Elastic acabou de coordenar a evacuação automatizada de 137.000 militares em sete instalações, sem nenhuma intervenção humana. Um furacão de categoria 4 atinge a costa de Hampton Roads. O enriquecimento geoespacial do Elasticsearch identifica todas as instalações na zona de impacto no momento da indexação. Uma regra de detecção do Kibana dispara. Um fluxo de trabalho inicia uma conversa com o agente de IA. O agente analisa a capacidade, a distância e a compatibilidade entre os ramos e, em seguida, envia 16 notificações de evacuação e recebimento em uma única etapa. Do evento bruto do GDACS à ação coordenada, automaticamente.

Todos os anos, os desastres naturais forçam gestores de emergência, comandantes militares e autoridades de segurança pública a tomar decisões de alto risco em prazos reduzidos. Essas decisões tradicionalmente dependem de árvores de chamadas, planilhas e conhecimento institucional distribuído entre dezenas de pessoas. A sobrecarga de coordenação por si só consome um tempo precioso.

Este post demonstra como a Elastic pode viabilizar um sistema de coordenação responsivo e baseado em agentes para resposta a desastres que detecta uma ameaça, avalia a logística e toma medidas automaticamente. Para tornar isso concreto, criamos uma simulação: um furacão fictício de Categoria 4 que ameaça a costa de Hampton Roads aciona o realojamento automatizado de mais de 137.000 pessoas em sete instalações militares.

Aviso: Este é um cenário totalmente fictício criado para fins de demonstração. O furacão ELARA-26 não existe. Os locais das instalações são baseados em dados geográficos reais e disponíveis publicamente (o conjunto de dados Military Installations, Ranges, and Training Areas [MIRTA] do Departamento de Defesa dos EUA [DoD]), mas todos os dados operacionais, como contagem de pessoal, capacidade de alojamento, ativos, e-mails de contato e perfis de missão, são totalmente fictícios. Nada nesta demonstração reflete prontidão militar, capacidade ou procedimentos operacionais reais.

Por que a resposta automatizada a desastres requer coordenação geoespacial e agêntica

Quando um desastre natural ameaça a infraestrutura crítica, o desafio de coordenação é imediato:

• Quais instalações estão na zona de impacto?

• Quantas pessoas precisam se deslocar?

• Para onde eles podem ir, e essas instalações têm capacidade?

• Quem precisa ser notificado agora?

Essas perguntas não esperam. Nem as respostas deveriam.

Implantar o pipeline: pré-requisitos e configuração

Siga as instruções aqui no repositório de exemplo para implantar um cluster local da Elastic com o Elastic Inference Service (EIS) via Cloud Connect.

Como funciona o pipeline agêntico de resposta a desastres do Elasticsearch

O pipeline tem sete camadas que trabalham juntas de ponta a ponta:

1. Ingestão de dados: eventos de desastre do Global Disaster Alert and Coordination System (GDACS) enviados para o Elasticsearch

2. Pipeline de ingestão: GeoJSON é ingerido e normalizado para o Elastic Common Schema (ECS).

3. Enriquecimento geoespacial: O polígono da área afetada pelo evento é comparado aos limites indexados de instalações militares.

4. Alerting: Uma regra de detecção do Kibana é acionada quando um desastre afeta qualquer instalação.

5. Automação de fluxo de trabalho: O alerta aciona um fluxo de trabalho do Kibana que inicia uma conversa com um agente de IA.

6. Raciocínio da IA: o agente analisa as instalações afetadas, seus ativos e as instalações de apoio mais próximas para determinar a realocação de todos os ativos e do pessoal.

7. Notificações por e-mail: o agente envia e-mails para todos os destinatários referentes à entrada e saída de pessoal e/ou ativos.

Vamos examinar cada camada.

Etapa 1: indexação de instalações militares com limites geográficos

A base é o conjunto de dados DoD MIRTA de source.coop/seerai/hifld. Este conjunto de dados fornece um geo_shape do tipo Point para cada instalação; coordenadas de centroide em vez de polígonos de limites completos.

Cada documento de instalação no índice mitra-facilities é enriquecido com dados de perfil operacional (todos fictícios), além do que o MIRTA fornece:

{
  "entity_name": "Naval Station Norfolk",
  "branch_of_service": "Navy",
  "mission_function_type": "fleet_support",
  "personnel_count": 50000,
  "housing_capacity": 55000,
  "temporary_housing_capacity": 10000,
  "logistics_capabilities": ["fuel", "airlift", "sealift", "medical"],
  "available_assets": [
    { "type": "helicopters", "count": 24 },
    { "type": "transport_vehicles", "count": 150 }
  ],
  "contact_email": "norfolk.ops@navy.mil.gov.fake",
  "operational_status": "act",
  "is_joint_base": false,
  "entity_geo_location": { "type": "polygon", "coordinates": [...] }
}

Esse índice rico é o que permite ao agente de IA tomar decisões inteligentes de alocação; não apenas "aqui estão as bases próximas," mas "aqui estão bases com capacidade de alojamento disponível, tipos de missão compatíveis e a logística para receber os ativos que chegam."

Etapa 2: ingerindo e normalizando eventos do GDACS

O GDACS publica GeoJSON em tempo real para terremotos, ciclones tropicais, inundações, incêndios florestais, vulcões e secas. Ingerimos esse feed em um fluxo de dados (logs-gdacs.events-*) usando um pipeline de ingestão personalizado que normaliza o GeoJSON bruto para campos do ECS.

O pipeline de ingestão do GDACS faz várias coisas que valem a pena notar:

Extração de geometria: O centróide é armazenado como um geo_point para exibição no mapa, e o polígono de impacto é armazenado como um geo_shape em gdacs.affected_area, que é o campo usado posteriormente para consultas de interseção.

Normalização da gravidade: cada tipo de desastre tem uma escala de gravidade diferente. Um ciclone tropical é medido pela velocidade do vento em km/h; um terremoto, pela magnitude Richter. O pipeline mapeia todos eles para uma pontuação normalizada de 0–100:

// Trecho de Painless do pipeline de ingestão
if (type == 'TC') {
  norm = Math.min(100.0, Math.max(0.0, (val - 40.0) / 2.6));
} else if (type == 'EQ') {
  norm = Math.min(100.0, Math.max(0.0, (val - 4.0) * 20.0));
}

A pontuação de gravidade normalizada é então mapeada para um rótulo severity_level (low, medium, high, critical) usado para o mapeamento de gravidade do alerta na regra de detecção.

Alinhamento ao ECS: event.kind: alert, event.category: threat, registros de data e hora mapeados para event.start/event.end, e um _id estável baseado em fingerprint para desduplicação.

Passo 3: enriquecimento geoespacial: encontrar instalações afetadas no momento da indexação

A política enrich geo_match do Elasticsearch compara o polígono do desastre com todos os limites de instalação no momento da indexação, sem a necessidade de uma junção no momento da consulta. Em vez de consultar no momento da busca, usamos um processador enrich no pipeline de ingestão para comparar o polígono de impacto do desastre com todos os limites de instalação à medida que o documento é indexado.

A política de enriquecimento é uma política geo_match:

{
  "geo_match": {
    "indices": "mitra-facilities",
    "match_field": "entity_geo_location",
    "enrich_fields": [
      "entity_name",
      "entity_type",
      "entity_station_number",
      "entity_geo_city_name",
      "entity_geo_region_name"
    ]
  }
}

O processador é executado no final do pipeline de ingestão:

{
  "enrich": {
    "policy_name": "facilities-geo",
    "field": "gdacs.affected_area",
    "target_field": "affected_facilities",
    "shape_relation": "INTERSECTS",
    "max_matches": 128
  }
}

O INTERSECTS captura qualquer instalação cujo limite toque ou sobreponha o polígono do desastre e até mesmo interseções parciais. O resultado é que cada documento de evento do GDACS é armazenado com um array aninhado affected_facilities que nos informa exatamente quais instalações estão na zona de impacto. Nenhuma consulta de junção é necessária.

Etapa 4: regra de detecção: alerta sobre impacto nas instalações

Uma regra de detecção do Kibana monitora o fluxo de dados logs-gdacs.events-* e é disparada quando um evento do GDACS tiver sido enriquecido com pelo menos uma instalação afetada:

Consulta: affected_facilities: { entity_name: * }

A regra é executada em uma programação de hora em hora (abrangendo uma janela de now-1h a now) e usa o mapeamento dinâmico de gravidade; o campo gdacs.severity_level calculado pelo pipeline de ingestão determina automaticamente a gravidade do alerta.

A gravidade do alerta também determina a pontuação de risco por meio do mapeamento de campos:

"risk_score_mapping": [
  {
    "field": "gdacs.normalized_severity",
    "operator": "equals",
    "value": ""
  }
]

Quando a regra dispara, ela passa todo o contexto do alerta, incluindo o array affected_facilities enriquecido com nomes, tipos e locais de instalação, para um fluxo de trabalho subsequente do Kibana.

Etapa 5: Automação do fluxo de trabalho: conectando o alerta ao agente

Os fluxos de trabalho do Kibana cuidam da transição da detecção para a resposta. O fluxo de trabalho de resposta a desastres naturais é acionado pelo alerta:

triggers:
  - type: alert
steps:
  - name: start_convo
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      body:
        agent_id: "mitra.response"
        input: "Novo alerta de desastre natural: {{ event.alerts | json }}"

Toda a carga útil do alerta (tipo de desastre, gravidade, área afetada e a lista de instalações impactadas) é encaminhada ao agente de IA como contexto inicial. O agente cuida do restante.

Etapa 6: o agente de IA: dos dados à ação coordenada

O agente mitra.response recebe o payload completo do alerta e, em um único loop agêntico, avalia o escopo, localiza instalações receptoras, aloca pessoal e envia notificações de evacuação e recebimento, tudo sem intervenção humana.

O agente tem duas ferramentas disponíveis:

• mitra.nearest_facility consulta o índice mitra-facilities usando uma consulta geo_shape, classificada por distância de uma determinada coordenada, retornando até 50 instalações ativas próximas com capacidade disponível.

• mitra.send_email itera sobre um array JSON de objetos de instalações e envia notificações formatadas de evacuação ou recebimento.

O conjunto de instruções do agente define um fluxo de trabalho claro:

1. Avalie a situação. Analise o alerta, identifique as instalações afetadas e determine a abrangência do desastre.

2. Faça um inventário do que precisa ser movido. Contagem de pessoal, ativos críticos, requisitos de alojamento por instalação.

3. Encontre as instalações de destino. Chame mitra.nearest_facility para cada instalação afetada, filtrando as instalações que ainda estão na zona de perigo.

4. Tome decisões de alocação. Analise soluções de instalação única em comparação com instalações múltiplas, compatibilidade entre ramos, capacidade de alojamento e suporte a ativos.

5. Envie e-mails de coordenação. Envie ordens de evacuação para as instalações de origem e notificações de recebimento para as instalações receptoras.

6. Gere um relatório de resumo. Gera um breve resumo de todas as instalações afetadas, do total de pessoas, dos ativos transferidos, das instalações de destino e de quaisquer preocupações para o chat para revisão.

A lógica de alocação do agente segue restrições do mundo real: não exceder a capacidade de alojamento, preferir relocações do mesmo ramo quando possível, usar bases conjuntas para o excedente de diferentes ramos e priorizar a distância para minimizar o tempo de deslocamento.

A ferramenta de instalação mais próxima

A consulta do fluxo de trabalho subjacente usa geo_shape com um filtro circle e classificação por _geo_distance:

"query": {
  "bool": {
    "filter": [
      {
        "geo_shape": {
          "entity_geo_location": {
            "shape": {
              "type": "circle",
              "coordinates": [{{ inputs.lon }}, {{ inputs.lat }}],
              "radius": "5000km"
            },
            "relation": "intersects"
          }
        }
      },
      { "term": { "operational_status.keyword": "act" } }
    ]
  }
},
"sort": [
  {
    "_geo_distance": {
      "entity_geo_point": { "lat": {{ inputs.lat }}, "lon": {{ inputs.lon }} },
      "order": "asc",
      "unit": "km"
    }
  }
],
"script_fields": {
  "available_capacity": {
    "script": {
      "source": "Math.max(0, doc['housing_capacity'].value - doc['personnel_count'].value)"
    }
  }
}

A capacidade disponível é calculada no momento da consulta por meio de um campo com script que calcula a capacidade de alojamento menos a contagem atual de pessoal. O agente usa isso para alocar pessoal entre os destinos sem exceder os limites.

Furacão ELARA-26: coordenação agêntica de 137.000 pessoas, de ponta a ponta

O furacão ELARA-26 é uma tempestade de categoria 4 (ventos máximos de 213 km/h) com previsão de atingir a costa na região de Hampton Roads, na Virgínia. Quando o evento do GDACS é ingerido, o polígono da área afetada intercepta sete grandes instalações militares na região. A regra de detecção dispara. O fluxo de trabalho inicia uma conversa com o agente.

Em um único loop agêntico, o agente:

• Identificou sete instalações na zona de impacto, com um total combinado de 137.372 pessoas.

• Chamou mitra.nearest_facility para encontrar instalações receptoras fora da trajetória da tempestade.

• Distribuiu o pessoal entre nove instalações receptoras com base na capacidade de alojamento disponível e na distância.

• Gerou e enviou ordens de evacuação para todas as sete instalações afetadas.

• Gerou e enviou notificações de recebimento para todas as nove instalações receptoras.

• Produziu um resumo completo de coordenação, semelhante ao mostrado abaixo:

Instalações evacuadas:

Instalações receptoras:

Os ativos realocados incluem veículos de transporte, helicópteros, barcos de patrulha, unidades médicas, veículos de engenharia, geradores, reboques de água, kits de abrigo e sistemas de comunicação.

Notificações automatizadas por e-mail

Depois que o agente finalizou seu plano de alocação, ele chamou mitra.send_email e enviou 16 e-mails de uma só vez; ou seja, ordens de evacuação para todas as sete instalações afetadas e notificações de recebimento para todas as nove instalações receptoras. Cada mensagem incluía a instalação de destino, a quantidade de pessoal que chegaria, os ativos a serem movidos e um contato de coordenação. O que teria levado horas de ligações em cadeia foi concluído automaticamente no momento em que o agente terminou de raciocinar.

Estendendo a resposta agêntica a desastres com RAG e fundamentação em políticas

Esta demo é puramente baseada em dados estruturados, como números de capacidade, distâncias e status operacional. Os recursos de busca semântica e retrieval augmented generation (RAG) da Elastic podem tornar o agente significativamente mais inteligente, com duas adições:

Recuperação de respostas históricas: indexe relatórios pós-ação anteriores, resumos de incidentes da Agência Federal de Gestão de Emergências (FEMA) e registros de resposta a desastres como embeddings vetoriais. Quando ocorre um novo evento, o agente pode recuperar semanticamente como eventos semelhantes foram tratados, embasando decisões de alocação com conhecimento institucional, em vez de se basear apenas em cálculos de capacidade.

Fundamentação em políticas e doutrinas: indexe diretrizes de gerenciamento de emergências do DoD, planos de continuidade de operações de instalações e orientações do comandante. O agente pode recuperar e citar as políticas reais que regem uma resposta, garantindo que cada decisão seja fundamentada em doutrina, em vez de inferência.

Ambos seguem a mesma abordagem nativa da Elastic:; um pipeline de inferência gera embeddings em tempo de indexação, e uma ferramenta de busca semântica é exposta ao agente. O pipeline de coordenação permanece o mesmo. O agente simplesmente fica mais inteligente.

Por que o Elasticsearch é a plataforma certa para a resposta agêntica no setor público

Este não é um chatbot. Não é um dashboard. É um sistema responsivo de fluxo de trabalho agêntico, que detectou uma ameaça, raciocinou sobre um problema logístico complexo e coordenou a realocação de 137.000 pessoas sem intervenção humana. Esse tipo de resultado só é possível porque todos os recursos dos quais ele depende estão em uma única plataforma unificada.

O suporte geoespacial do Elasticsearch (geo_point, geo_shape, políticas de enriquecimento e classificação baseada em distância) lida com o raciocínio espacial que torna a detecção de interseções e a consulta de instalações possíveis em escala. A busca semântica e os embeddings vetoriais ancoram os agentes na realidade, garantindo que o raciocínio da IA seja baseado no que realmente está em seus dados, em vez de suposições alucinadas. O mecanismo de detecção do Kibana, os fluxos de trabalho, o Agent Builder e as ferramentas do Agent Builder conectam tudo em um pipeline que vai do evento bruto à ação coordenada, sem a necessidade de nenhum código de integração externo.

Nenhuma outra plataforma reúne tudo isso como a Elastic. A combinação de indexação em tempo real, precisão geoespacial, recuperação semântica e orquestração por agentes, tudo em uma única pilha de tecnologia, com segurança e observabilidade de nível empresarial integradas, é o que diferencia a Elastic de ferramentas que fazem bem uma dessas coisas, mas exigem que você reúna o restante por conta própria.

Resposta geoespacial agêntica para gerenciamento de emergências, bombeiros, aplicação da lei e saúde pública

A mesma arquitetura se aplica onde quer que pessoas, instalações e eventos em tempo real se cruzem. Os dados específicos mudam. O pipeline não.

Gerenciamento de emergências: a FEMA e os órgãos estaduais de gerenciamento de emergências podem mapear locais de abrigo, áreas de mobilização e populações vulneráveis em relação aos polígonos de clima severo do National Weather Service (NWS), acionando o pré-posicionamento automatizado de recursos antes que uma tempestade atinja a costa.

Serviços de bombeiros e emergência médica: os corpos de bombeiros podem sobrepor localizações de unidades e zonas de resposta a perímetros de incêndios florestais ou clusters de incêndios estruturais, encaminhando automaticamente solicitações de ajuda mútua para as unidades disponíveis mais próximas com o equipamento adequado.

Aplicação da lei: as agências podem correlacionar locais de incidentes ativos com zonas escolares, infraestrutura crítica e posições de policiais, disparando notificações de bloqueio baseadas em localização geográfica ou despacho de recursos sem esperar pela triagem manual.

Segurança nas escolas públicas: os distritos escolares podem monitorar feeds de ameaças em tempo real em relação aos limites do campus. Quando uma ameaça cruza o perímetro de uma escola, um agente pode notificar imediatamente a administração, iniciar comunicações de confinamento e coordenar a resposta das forças policiais, tudo antes que um atendente pegue o telefone.

Saúde pública: os departamentos de saúde podem cruzar dados de vigilância de doenças ou zonas de risco ambiental com a localização de clínicas, camadas de densidade populacional e estoques de depósitos de suprimentos para direcionar recursos para onde são mais necessários.

Os dados são diferentes em cada cenário. O padrão subjacente de ingerir, enriquecer no momento da indexação, detectar interseção, acionar resposta agêntica e agir é o mesmo. A Elastic oferece às organizações do setor público a plataforma para criar uma vez e adaptar em qualquer lugar.

O lançamento e a disponibilização de quaisquer recursos ou funcionalidades descritos neste artigo ficam a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento podem não ser disponibilizados no prazo previsto ou nem chegar a ser disponibilizados.