137 000 personas, cero decisiones humanas: respuesta agéntica ante desastres con Elasticsearch

Agent Builder ya está disponible para el público en general. Inicia una prueba de Elastic Cloud y consulta la documentación de Agent Builder aquí.

Elastic acaba de coordinar la evacuación automatizada de 137 000 militares en siete instalaciones, sin intervención humana. Un huracán de categoría 4 azota la costa de Hampton Roads. El enriquecimiento geoespacial de Elasticsearch identifica cada instalación en la zona de impacto al momento de la indexación. Se activa una regla de detección de Kibana. Un flujo de trabajo inicia una conversación con un agente de AI. El agente analiza la capacidad, la distancia y la compatibilidad entre ramas de las fuerzas armadas, y luego envía 16 notificaciones de evacuación y recepción en una sola pasada. De un evento de GDACS sin procesar a una acción coordinada, automáticamente.

Cada año, los desastres naturales obligan a los gestores de emergencias, comandantes militares y oficiales de seguridad pública a tomar decisiones críticas en plazos ajustados. Estas decisiones suelen depender de cadenas de llamadas, hojas de cálculo y conocimiento institucional distribuido entre decenas de personas. La coordinación por sí sola consume un tiempo valioso.

Esta publicación demuestra cómo Elastic puede potenciar un sistema de coordinación agéntico con capacidad de respuesta ante desastres, que detecta amenazas, analiza la logística y actúa automáticamente. Para hacerlo concreto, creamos una simulación: un huracán ficticio de categoría 4 que amenaza la costa de Hampton Roads desencadena la reubicación automatizada de más de 137 000 personas en siete instalaciones militares.

Descargo de responsabilidad: Este es un escenario totalmente ficticio creado con fines de demostración. El huracán ELARA-26 no existe. Las ubicaciones de las instalaciones se basan en datos geográficos reales y disponibles públicamente (el set de datos Military Installations, Ranges, and Training Areas [MIRTA] del Departamento de Defensa de los EE. UU. [DoD]), pero todos los datos operativos, como el recuento de personal, la capacidad de alojamiento, los activos, los correos electrónicos de contacto y los perfiles de misión, son completamente ficticios. Nada en esta demostración refleja la preparación, la capacidad o los procedimientos operativos militares reales.

Por qué la respuesta automatizada ante desastres requiere coordinación geoespacial y agéntica

Cuando un desastre natural amenaza la infraestructura crítica, el desafío de coordinación es inmediato:

• ¿Qué instalaciones están en la zona de impacto?

• ¿Cuánto personal necesita trasladarse?

• ¿A dónde pueden ir? ¿Esas instalaciones tienen capacidad?

• ¿A quién se necesita notificar en este momento?

Estas preguntas no esperan. Tampoco deberían hacerlo las respuestas.

Despliega el pipeline: requisitos previos y configuración

Sigue las instrucciones aquí en el repositorio de ejemplo para desplegar un cluster local de Elastic con Elastic Inference Service (EIS) mediante Cloud Connect.

Cómo funciona el pipeline de respuesta ante desastres con agentes de Elasticsearch

El pipeline tiene siete capas que trabajan juntas de extremo a extremo:

1. Ingesta de datos: eventos de desastres del Sistema Mundial de Alerta y Coordinación de Desastres (GDACS) enviados a Elasticsearch

2. Pipeline de ingesta: GeoJSON se ingesta y normaliza a Elastic Common Schema (ECS).

3. Enriquecimiento geoespacial: el polígono del área afectada del evento se compara con los límites indexados de las instalaciones militares.

4. Alerting: una regla de detección de Kibana se activa cuando un desastre interseca cualquier instalación.

5. Automatización de flujos de trabajo: la alerta activa un flujo de trabajo de Kibana que inicia una conversación con un agente de AI.

6. Razonamiento de AI: el agente analiza las instalaciones afectadas, sus activos y las instalaciones de apoyo más cercanas para determinar cómo reubicar todos los activos y al personal.

7. Notificaciones por correo electrónico: el agente envía correos electrónicos a todos los destinatarios sobre la llegada y salida de personal o activos.

Revisemos cada capa.

Paso 1: indexar instalaciones militares con límites geográficos

La base es el set de datos MIRTA del DoD de source.coop/seerai/hifld. Este set de datos proporciona un geo_shape de tipo Point para cada instalación; coordenadas de centroide en lugar de polígonos de límites completos.

Cada documento de instalación en el índice mitra-facilities se enriquece con datos de perfil operativo (todos ficticios), más allá de lo que proporciona MIRTA:

{
  "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": [...] }
}

Este índice enriquecido es lo que le permite al agente de AI tomar decisiones inteligentes de asignación; no solo “aquí hay bases cercanas”, sino “aquí hay bases con capacidad de alojamiento disponible, tipos de misión compatibles y la logística para recibir activos entrantes”.

Paso 2: ingestar y normalizar eventos de GDACS

GDACS publica GeoJSON en tiempo real para terremotos, ciclones tropicales, inundaciones, incendios forestales, volcanes y sequías. Ingestamos este feed en un flujo de datos (logs-gdacs.events-*) mediante un pipeline de ingesta personalizado que normaliza el GeoJSON sin procesar a campos de ECS.

El pipeline de ingesta de GDACS hace varias cosas que vale la pena destacar:

Extracción de geometría: el centroide se almacena como geo_point para la visualización en mapas, y el polígono de impacto se almacena como geo_shape en gdacs.affected_area, que es el campo que se utiliza para búsquedas de intersección más adelante.

Normalización de la gravedad: cada tipo de desastre tiene una escala de gravedad diferente. Un ciclón tropical se mide en velocidad del viento en km/h; un terremoto, en magnitud de Richter. El pipeline los mapea a todos a una puntuación normalizada de 0–100:

// Painless snippet from the ingest pipeline
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));
}

Luego, la puntuación de gravedad normalizada se mapea a una etiqueta severity_level (low, medium, high, critical) utilizada para el mapeo de gravedad de las alertas en la regla de detección.

Alineación con ECS: event.kind: alert, event.category: threat, marcas de tiempo asignadas a event.start/event.end, y un _id estable basado en una huella digital para la deduplicación.

Paso 3: enriquecimiento geoespacial: búsqueda de instalaciones afectadas al momento de la indexación

La política de enriquecimiento geo_match de Elasticsearch compara el polígono del desastre con el límite de cada instalación al momento de la indexación, sin necesidad de una unión en tiempo de búsqueda. En lugar de consultar durante la búsqueda, usamos un procesador de enriquecimiento en el pipeline de ingesta para comparar el polígono de impacto del desastre con el límite de cada instalación a medida que se indexa el documento.

La política de enriquecimiento es una 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"
    ]
  }
}

El procesador se ejecuta al final del pipeline de ingesta:

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

INTERSECTS detecta cualquier instalación cuyo límite toque o se superponga con el polígono de desastre, incluidas las intersecciones parciales. El resultado es que cada documento de evento de GDACS se almacena con un arreglo anidado affected_facilities que nos indica exactamente qué instalaciones se encuentran en la zona de impacto. No se necesita una búsqueda de unión.

Paso 4: regla de detección: alertas sobre el impacto en las instalaciones

Una regla de detección de Kibana monitorea el flujo de datos logs-gdacs.events-* y se activa cuando un evento de GDACS se ha enriquecido con información sobre al menos una instalación afectada:

Búsqueda: affected_facilities: { entity_name: * }

La regla se ejecuta cada hora (cubre un intervalo de now-1h a now) y usa un mapeo dinámico de gravedad; el campo gdacs.severity_level calculado por el pipeline de ingesta determina automáticamente la gravedad de la alerta.

La gravedad de la alerta también determina la puntuación de riesgo mediante el mapeo de campos:

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

Cuando la regla se activa, envía todo el contexto de la alerta, incluido el arreglo enriquecido affected_facilities con los nombres, tipos y ubicaciones de las instalaciones, a un flujo de trabajo de Kibana para su procesamiento posterior.

Paso 5: automatización del flujo de trabajo: conectar la alerta con el agente

Los flujos de trabajo de Kibana gestionan la transferencia de la detección a la respuesta. El flujo de trabajo de respuesta ante desastres naturales se activa mediante la 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: "Nueva alerta de desastre natural: {{ event.alerts | json }}"

Toda la carga útil de la alerta (tipo de desastre, gravedad, área afectada y la lista de instalaciones afectadas) se reenvía al agente de AI como contexto inicial. El agente se encarga del resto.

Paso 6: el agente de AI: de los datos a la acción coordinada

El agente mitra.response toma la carga útil completa de la alerta y, en un único ciclo agéntico, evalúa el alcance, encuentra instalaciones receptoras, asigna personal y envía notificaciones de evacuación y recepción, todo sin intervención humana.

El agente tiene dos herramientas disponibles:

• mitra.nearest_facility realiza una búsqueda en el índice mitra-facilities mediante una búsqueda geo_shape, ordenada por distancia desde una coordenada dada, y devuelve hasta 50 instalaciones activas cercanas con capacidad disponible.

• mitra.send_email itera sobre una arreglo JSON de objetos de instalaciones y envía notificaciones de evacuación o recepción con formato.

El conjunto de instrucciones del agente define un flujo de trabajo claro:

1. Evalúa la situación. Parsea la alerta, identifica las instalaciones afectadas y determina el alcance del desastre.

2. Haz un inventario de lo que se debe mover. Recuentos de personal, activos críticos, requisitos de alojamiento por instalación.

3. Encuentra instalaciones de destino. Invoca a mitra.nearest_facility para cada instalación afectada, sin incluir las que aún están en la zona de peligro.

4. Toma decisiones de asignación. Analiza soluciones que involucren una o varias instalaciones, la compatibilidad entre ramas de las fuerzas armadas, la capacidad de alojamiento y el apoyo para los activos.

5. Envía correos electrónicos de coordinación. Envía órdenes de evacuación a las instalaciones de origen y notificaciones de recepción a las instalaciones receptoras.

6. Genera un reporte resumido. Genera un breve resumen de todas las instalaciones afectadas, el total de personal, los activos trasladados, las instalaciones de destino y cualquier inquietud en el chat para su revisión.

La lógica de asignación del agente sigue restricciones del mundo real: no exceder la capacidad de alojamiento, dar preferencia a las reubicaciones dentro de la misma rama de las fuerzas armadas cuando sea posible, usar bases conjuntas para alojar al personal de distintas ramas que exceda la capacidad de otras instalaciones y priorizar la distancia para minimizar el tiempo de traslado.

La herramienta de instalación más cercana

La búsqueda subyacente del flujo de trabajo usa geo_shape con un filtro de círculo y ordenamiento 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)"
    }
  }
}

La capacidad disponible se calcula en el momento de la búsqueda mediante un campo de script que calcula la capacidad de alojamiento menos el recuento de personal actual. El agente usa esto para asignar personal entre destinos sin exceder los límites.

Huracán ELARA-26: coordinación agéntica de 137 000 efectivos, de extremo a extremo

El huracán ELARA-26 es una tormenta de categoría 4 (vientos máximos de 213 km/h) que se prevé que toque tierra en el área de Hampton Roads de Virginia. Cuando se ingiere el evento de GDACS, el polígono del área afectada interseca siete instalaciones militares principales de la región. La regla de detección se activa. El flujo de trabajo inicia una conversación del agente.

Dentro de un solo ciclo agéntico, el agente:

• Identificó siete instalaciones en la zona de impacto, con un total combinado de 137 372 miembros del personal.

• Llamó a mitra.nearest_facility para encontrar instalaciones receptoras fuera de la trayectoria de la tormenta.

• Distribuyó al personal entre nueve instalaciones receptoras en función de la capacidad de alojamiento disponible y la distancia.

• Generó y despachó órdenes de evacuación a las siete instalaciones afectadas.

• Generó y despachó notificaciones de recepción a las nueve instalaciones receptoras.

• Generó un resumen completo de coordinación, similar al siguiente:

Instalaciones evacuadas:

Instalaciones receptoras:

Los activos reubicados incluyen vehículos de transporte, helicópteros, lanchas patrulleras, unidades médicas, vehículos de ingeniería, generadores, remolques de agua, kits de refugio y sistemas de comunicación.

Notificaciones por correo electrónico automatizadas

Una vez que el agente finalizó su plan de asignación, invocó a mitra.send_email y envió 16 correos electrónicos en una sola pasada; es decir, órdenes de evacuación a las siete instalaciones afectadas y notificaciones de recepción a las nueve instalaciones receptoras. Cada mensaje incluía la instalación de destino, el recuento de personal entrante, los activos por trasladar y un contacto de coordinación. Lo que habría requerido horas de cadenas de llamadas se completó automáticamente en cuanto el agente terminó de razonar.

Ampliación de la respuesta agéntica ante desastres con RAG y fundamentación en políticas

Esta demostración se basa exclusivamente en datos estructurados, como cifras de capacidad, distancias y estado operativo. Las funcionalidades de búsqueda semántica y Retrieval Augmented Generation (RAG) de Elastic pueden hacer que el agente sea significativamente más inteligente, con dos adiciones:

Recuperación de respuestas históricas: indexa reportes posteriores a la acción, resúmenes de incidentes de la Agencia Federal para el Manejo de Emergencias (FEMA) y registros de respuesta ante desastres anteriores como incrustaciones vectoriales. Cuando se activa un evento nuevo, el agente puede recuperar semánticamente cómo se gestionaron eventos similares, lo que fundamenta las decisiones de asignación con conocimiento institucional en lugar de basarse únicamente en cálculos de capacidad.

Fundamentación en políticas y doctrina: indexa las directivas de gestión de emergencias del DoD, los planes de continuidad de las operaciones de la instalación y las directrices del comandante. El agente puede recuperar y citar las políticas reales que rigen una respuesta, lo que garantiza que cada decisión esté fundamentada en la doctrina en lugar de en inferencias.

Ambos siguen el mismo enfoque nativo de Elastic: un pipeline de inferencia genera incrustaciones al momento de la indexación, y se expone una herramienta de búsqueda semántica al agente. El pipeline de coordinación permanece igual. El agente simplemente se vuelve más inteligente.

Por qué Elasticsearch es la plataforma adecuada para la respuesta agéntica del sector público

Esto no es un chatbot. No es un dashboard. Es un sistema de flujo de trabajo agéntico con capacidad de respuesta, uno que detectó una amenaza, razonó sobre un problema logístico complejo y coordinó la reubicación de 137 000 personas sin intervención humana. Ese tipo de resultado solo es posible porque cada funcionalidad de la que depende reside en una sola plataforma unificada.

El soporte geoespacial de Elasticsearch (geo_point, geo_shape, políticas de enriquecimiento y ordenación basada en la distancia) gestiona el razonamiento espacial que hace posible la detección de intersecciones y la búsqueda de instalaciones a escala. La búsqueda semántica y las incrustaciones vectoriales proporcionan a los agentes una base factual, lo que garantiza que el razonamiento de la AI se apoye en el contenido real de tus datos y no en suposiciones producto de alucinaciones. El motor de detección de Kibana, Workflows, Agent Builder y las herramientas de Agent Builder lo integran todo en un pipeline que va desde el evento sin procesar hasta la acción coordinada, sin necesidad de código de integración externo.

Ninguna otra plataforma reúne esto como lo hace Elastic. La combinación de indexación en tiempo real, precisión geoespacial, recuperación semántica y orquestación agéntica, todo en un solo stack, con seguridad y observabilidad de nivel empresarial integradas, es lo que diferencia a Elastic de las herramientas que hacen bien una de estas cosas pero requieren que unas el resto por tu cuenta.

Respuesta geoespacial agéntica para la gestión de emergencias, bomberos, fuerzas del orden y salud pública

La misma arquitectura se aplica dondequiera que se crucen personas, instalaciones y eventos en tiempo real. Los datos específicos cambian. El pipeline no.

Gestión de emergencias: FEMA y las oficinas estatales de gestión de emergencias pueden mapear las ubicaciones de los refugios, las áreas de preparación y las poblaciones vulnerables con respecto a los polígonos de fenómenos meteorológicos adversos entrantes del Servicio Meteorológico Nacional (NWS), lo que activa el posicionamiento previo automatizado de recursos antes de que una tormenta toque tierra.

Servicios de bomberos y emergencias médicas: los departamentos de bomberos pueden superponer las ubicaciones de las unidades y las zonas de respuesta sobre los perímetros de incendios forestales o las agrupaciones de incendios estructurales, y dirigir automáticamente las solicitudes de ayuda mutua a las unidades disponibles más cercanas que cuenten con el equipo adecuado.

Fuerzas del orden: las agencias pueden correlacionar las ubicaciones de incidentes activos con zonas escolares, infraestructura crítica y posiciones de los oficiales, lo cual activa notificaciones de confinamiento con reconocimiento geográfico o el despacho de recursos sin esperar la clasificación manual.

Seguridad en las escuelas públicas: los distritos escolares pueden monitorear datos de amenazas en tiempo real y compararlos con los límites de los recintos escolares. Cuando una amenaza cruza el perímetro de una escuela, un agente puede notificar de inmediato a la administración, iniciar las comunicaciones de cierre de emergencia y coordinar la respuesta de las fuerzas del orden, todo antes de que un despachador atienda el teléfono.

Salud pública: los departamentos de salud pueden cotejar datos de vigilancia de enfermedades o zonas de riesgo ambiental con ubicaciones de clínicas, capas de densidad poblacional e inventarios de depósitos de suministros para dirigir los recursos donde más se necesitan.

Los datos son diferentes en cada escenario. El patrón subyacente de ingestar, enriquecer en tiempo de indexación, detectar intersecciones, activar una respuesta agéntica y actuar es exactamente el mismo. Elastic brinda a las organizaciones del sector público la plataforma para crearlo una vez y adaptarlo en todas partes.

El lanzamiento de cualquiera de las características o funcionalidades descritas en esta publicación, así como su fecha, quedan a exclusivo criterio de Elastic. Es posible que algunas características o funcionalidades que no estén disponibles en este momento no se lancen a tiempo o no se lancen en absoluto.