Actualizado en septiembre de 2026: cambié la descripción de GEO_COPILOT que va al final. Decía cuatro agentes y mapas 3D con Cesium; hoy son seis agentes y el mapa es MapLibre. También corregí el pie de la Figura 1, sumé a la lista el agente que busca los datos y aclaré que el esquema del ejemplo es ilustrativo.
En los últimos meses he venido probando, rompiendo y volviendo a armar diferentes flujos de trabajo con agentes de IA aplicados a datos geoespaciales. Y mientras más avanzo, más claro tengo algo: los agentes cambian la forma de trabajar con un SIG.
Hoy ya no suena a locura abrir un proyecto y preguntar en lenguaje natural:
"¿Cuántos edificios hay en un radio de 500 metros del parque central?"
y recibir el número junto con un mapa, la intersección espacial bien hecha y una explicación que cualquier equipo puede entender.
Eso, hace muy poco tiempo, implicaba PostGIS, SQL espacial, manejo fino de proyecciones, buffers (zonas de influencia), joins (cruces de tablas), simbología… y horas de trabajo. Todo eso sigue siendo la base, pero la barrera de entrada está cambiando.
El problema de fondo es el acceso
Durante años el análisis espacial ha estado limitado a quien:
- domina herramientas como QGIS o ArcGIS,
- entiende bien los sistemas de referencia,
- sabe escribir consultas espaciales sin romper la base,
- y tiene el tiempo para repetir procesos una y otra vez.
Eso ha hecho que quien decide dependa de un analista incluso para preguntas relativamente simples. Ese es el hueco que un agente puede llenar.
Qué hace un agente geoespacial
Un agente orquesta: traduce una pregunta en tareas, llama a quien sabe hacer cada parte, valida, visualiza y comunica.
Figura 1: una versión anterior de GEO_COPILOT, el sistema del que hablo al final, mientras busca datos para una pregunta por las estaciones de bomberos de Bogotá.
Cuando uso frameworks como LangGraph y pongo a varios agentes a consultarse entre sí, lo que estoy construyendo es esto:
- Un agente que entiende la intención.
- Otro que busca los datos: lee el esquema de PostGIS y busca en servicios de datos abiertos.
- Otro que genera las consultas espaciales.
- Otro que ejecuta el análisis SIG (buffers, intersecciones, superposiciones).
- Otro que decide cómo se ve el resultado en un mapa.
- Y finalmente uno que te cuenta qué significa el resultado.
El analista SIG sigue siendo necesario: el agente puede dejarle responder más preguntas en el mismo tiempo.
Un ejemplo: escuelas y zonas inundables
Imagina esta pregunta:
"Muéstrame las zonas con mayor riesgo de inundación cerca de escuelas."
Antes: capas, reproyecciones, buffers, intersect, simbología, exportaciones, mapas.
Ahora: un flujo automático donde los agentes se reparten el trabajo, coordinan y entregan un resultado listo para análisis.
Usuario
"Muéstrame las áreas con mayor riesgo de inundación cerca de escuelas"
Agente Planner
Descompone en sub-tareas: obtener datos, análisis espacial, visualización
Agente Datos
Obtiene capas desde PostGIS: zonas_inundacion, escuelas
Agente GIS
Ejecuta operaciones: buffer 1km en escuelas, intersect con zonas inundación
Agente Simbolización
Define estilos: escuelas en rojo, zonas de riesgo en gradiente amarillo-rojo
Agente Visualizer
Genera mapa interactivo con capas y controles
Agente Reporter
Encontré 12 escuelas en zonas de alto riesgo de inundación…
Ese esquema es ilustrativo. Sus pasos no son los seis agentes de GEO_COPILOT, aunque Datos y GIS compartan nombre con dos de ellos. Las 12 escuelas son un número de ejemplo. Y el "A2A" del pie quiere decir agentes que se consultan dentro del mismo sistema: GEO_COPILOT no usa Agent2Agent, el protocolo abierto con ese nombre.
Un flujo así ya lo puedes armar con LangGraph y PostGIS. Todavía se equivoca. Por eso necesita a alguien que revise las consultas y el código antes de que corran. Es la primera de las cinco reglas que escribí para usar LLM en análisis geoespacial: nunca le des el volante.
Lo bueno, y lo que todavía falla
Los agentes abren posibilidades enormes para la planificación territorial, la gestión del riesgo, el monitoreo ambiental, la agricultura de precisión y el análisis urbano a escala.
Y los problemas siguen ahí:
- La precisión de las consultas que genera el modelo sigue siendo un reto.
- La escalabilidad sobre millones de geometrías también.
- El costo de los LLM no es trivial.
- Y la privacidad, especialmente en datos sensibles, no es negociable.
Por eso cada vez estoy más convencido de que el futuro realista pasa por modelos de código abierto, flujos híbridos y agentes corriendo cerca de los datos, en lugar de mandarlo todo a la nube por defecto.
Lo que viene
Creo que el futuro del SIG es que más personas puedan hacer mejores preguntas espaciales, sin quedar atrapadas en la complejidad técnica.
Voy a seguir probando estos flujos y contando aquí lo que falle.
GEO_COPILOT
Estoy desarrollando GEO_COPILOT, un sistema multiagente geoespacial que pone en práctica buena parte de lo que conté aquí: seis agentes especializados, orquestación con LangGraph, mapa con MapLibre, imágenes de Sentinel-2 y validación humana en el bucle. Nada de lo que escribe el modelo se ejecuta hasta que alguien lo aprueba. Hoy trabaja con modelos comerciales (OpenAI, Azure OpenAI y Anthropic), así que lo de correr modelos abiertos cerca de los datos aún no lo cumple. Todavía no está publicado: lo abro cuando alguien más pueda clonarlo y correrlo sin que yo esté al lado explicando.
Repositorio: saldrá en github.com/geoai-latam. Si quieres que te avise, suscríbete abajo.
Referencias:
