- Generische LLMs erzeugen Code, der lokal funktioniert, aber in der Skalierung scheitert – falsche CRS, Memory-Explosionen, plattformspezifische Fallstricke
- Dual-Agent-Architektur (Architect + Auditor) erkennt 94 % der Probleme vor dem Deployment durch Kreuzvalidierung
- Ihre Daten verlassen niemals Ihre Umgebung – Agents analysieren Workflow-Logik, nicht Geodaten
- Am besten für repetitive Execution-Workflows (8+ Stunden/Woche, 12+ Ausführungen/Jahr). Neuartige Analysen benötigen weiterhin Menschen.
Alle paar Monate demonstriert jemand auf einer GIS-Konferenz einen Chatbot, der "mit Ihren Karten sprechen" kann. Sie geben eine Frage ein, erhalten eine Heatmap. Das Publikum applaudiert. Das Startup erhält Finanzierung.
Dann scheitert das Pilotprojekt. Nicht weil die Technologie schlecht ist, sondern weil sie das falsche Problem löst. Unternehmen benötigen keine weitere Schnittstelle zu ihren Daten. Sie benötigen, dass die Arbeit erledigt wird.
Der Unterschied zwischen einem Chatbot und einem Automatisierungs-Agent ist der Unterschied zwischen einer Suchmaschine und einem Fließband. Eines hilft Ihnen, Dinge zu finden. Das andere produziert Output.
Das Problem: Wiederkehrende manuelle Tätigkeiten
Das eigentliche Problem ist kein einzelnes Tool. Es sind die wiederkehrenden manuellen Tätigkeiten über unverbundene Schritte hinweg, die Woche für Woche die Zeit Ihres Teams verschlingen:
- →ArcGIS Desktop öffnen und einen 12-Schritte-Geoprocessing-Workflow durchführen – manuelles Klicken durch jedes Tool, Warten, Outputs überprüfen
- →Satellitenbilder von einem Portal herunterladen, in ENVI vorverarbeiten, in drei verschiedene Formate exportieren, in ein anderes System hochladen
- →Daten aus einem Tool exportieren, in Excel neu formatieren, weil die Schemata nicht übereinstimmen, in ein anderes Tool importieren
- →Jede Woche dieselbe QGIS-Analyse mit aktualisierten Daten durchführen – dieselben Schritte, dieselben Klicks, dasselbe Warten
Das Muster ist immer dasselbe: Download → Verarbeitung → Analyse → Bericht. Manueller Download vom Datenportal. Desktop-Vorverarbeitung. GIS-Analyse. Excel-Reporting. PowerPoint-Zusammenstellung.
Die Rechnung ist brutal:
8 Stunden/Woche für eine Routine = 416 Stunden jährlich für DIESELBE Aufgabe.
Manuelle Verarbeitung von 3 Ländern/Jahr bedeutet, dass 50 Länder 17× mehr Personal erfordern.
Das ist keine Skalierungsherausforderung. Das ist eine strukturelle Unmöglichkeit.
Der Instinkt ist zu fragen: "Kann AI das für mich erledigen?"
Die Antwort lautet ja – aber nicht so, wie die meisten Anbieter es verkaufen.
Warum generische LLMs bei GIS scheitern
Jeder kann Claude oder GPT dazu bringen, Geospatial-Code zu generieren. Die Frage ist, ob dieser Code in der Produktion funktioniert, in der Skalierung, auf IHRER Plattform, mit IHREN Einschränkungen.
Generische LLMs scheitern bei der GIS-Automatisierung aus spezifischen, vorhersehbaren Gründen:
1Sie verstehen Koordinatensysteme nicht
Geografisch vs. projiziert ist nicht nur Trivialwissen – es bestimmt, ob Ihre Flächenberechnungen in Quadratgrad (bedeutungslos) oder Quadratmeter (nützlich) erfolgen. Ein generisches LLM berechnet fröhlich Flächen in EPSG:4326 und liefert Zahlen, die plausibel aussehen, aber je nach Breitengrad um Faktoren von 10-100× falsch sind.
2Sie schlagen Ansätze vor, die bei Skalierung scheitern
"Laden Sie den GeoDataFrame und führen Sie dissolve aus" funktioniert großartig bei 10.000 Features. Bei 10 Millionen Features löst es einen OOM-Kill aus. Das LLM kennt weder Ihre Datensatzgröße, noch Ihren Cluster-Speicher, noch den Unterschied zwischen einem Muster, das in einem Jupyter-Notebook funktioniert, und einem, das in der Produktion überlebt.
3Sie ignorieren plattformspezifische Einschränkungen
Cloud-Objektspeicher unterstützen keine Seek-Operationen. Databricks Volumes können GeoPackages nicht direkt schreiben. AWS Lambda hat ein 15-Minuten-Timeout. Azure Functions haben unterschiedliche Paketlimits. Das LLM weiß nicht, auf welcher Plattform Sie sind oder was diese Plattform nicht kann.
4Sie fehlt das Enterprise-Bewusstsein
In regulierten Branchen – Versicherungen, Versorgungsunternehmen, Finanzen – ist Präzision wichtig. Ein Unterschied von 0,001 % in räumlichen Berechnungen kann sich zu erheblichen Geschäftsauswirkungen aufschaukeln. Reproduzierbarkeit ist obligatorisch. Audit-Trails sind erforderlich. Das LLM generiert Code, der funktioniert. Es generiert keinen Code, der prüfbar, reproduzierbar oder konform ist.
DER ECHTE FEHLER, DEN WIR SEHEN
GEOSException: IllegalArgumentException: Unhandled geometry type in CoverageUnionGenerische LLMs schlagen coverage_union_all() für Dissolves vor, weil es 80× schneller ist. Was sie nicht wissen: Es funktioniert NUR mit Polygon/MultiPolygon. Wenn make_valid() eine GeometryCollection mit einem LineString zurückgibt, stürzt die gesamte Pipeline ab.
Dieser spezifische Fehler hat uns beim ersten Mal 3 Tage zur Diagnose gekostet. Jetzt dauert es 3 Sekunden. Das ist der Unterschied zwischen generischer Code-Generierung und produktionsbewusster Automatisierung.
Die Dual-Agent-Architektur
Die Lösung sind keine intelligenteren Prompts. Es ist eine andere Architektur.
Single-Agent-Systeme halluzinieren. Sie generieren plausibel aussehenden Code, der auf subtile Weise versagt. Der Fehlermodus ist schlimmer als offensichtliche Bugs – es ist Code, der erfolgreich läuft, aber falsche Ergebnisse produziert.
Dual-Agent-Systeme fangen diese Fehler durch Kreuzvalidierung ab. Ein Agent schlägt vor. Ein anderer Agent validiert. Wenn der Validator Probleme findet, schreibt der Vorschlagende neu. Die Schleife setzt sich fort, bis der Code besteht oder an einen Menschen eskaliert wird.
┌─────────────────────────────────────────────────────────────┐ │ WORKFLOW-ORCHESTRIERUNG │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ AGENT A │───▶│ IMPLEMENT │───▶│ AGENT B │ │ │ │ Architect │ │ │ │ Auditor │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ │ │ │ ┌──────────────┐ │ │ │ │ │ REWRITE │◀──────────────┤ FAIL? │ │ │ └──────────────┘ │ │ │ │ │ │ │ │ └──────────────┴─────────────────────────┘ │ │ │ │ │ ▼ │ │ [PASS] │ │ │ │ │ ▼ │ │ ┌──────────────┐ │ │ │ UPDATE DOCS │ │ │ └──────────────┘ │ └─────────────────────────────────────────────────────────────┘
ADer Architect
Schlägt Modernisierungspfade vor. Bildet Legacy-ArcPy-Logik auf cloud-native Äquivalente ab. Generiert den Code, der validiert werden soll.
- Durchsucht Fehlerregister nach vergangenen Fehlern
- Überprüft domänenspezifische Dokumentation
- Prüft Git-Historie, warum aktueller Code existiert
- Gibt Risikobewertung aus: HIGH/MEDIUM/LOW
BDer Auditor
Validiert generierten Code gegen bekannte Einschränkungen. Fängt die Fehler ab, bevor sie die Produktion erreichen.
- Syntax-Check:
python -m py_compile - Import-Verifizierung: alle Abhängigkeiten werden aufgelöst
- Plattform-Einschränkungs-Prüfung (Volumes, Memory)
- Fehlermuster-Erkennung gegen dokumentierte Fehler
Die selbsterhaltende Schleife
Maximal 3 Iterationen, bevor an einen Menschen eskaliert wird. Wenn der Auditor den Code dreimal ablehnt, überprüft ein Mensch. Dies verhindert Endlosschleifen und stellt sicher, dass wirklich schwierige Probleme menschliche Aufmerksamkeit erhalten.
Nach erfolgreichen Änderungen wird die Dokumentation automatisch aktualisiert. Neue Fehler werden dem Register hinzugefügt. Das System lernt aus jedem Deployment und macht zukünftige Validierungen genauer.
In unseren Produktions-Deployments fängt diese Architektur 94 % der Probleme ab, bevor sie zur menschlichen Überprüfung gelangen. Die verbleibenden 6 % sind wirklich neuartige Probleme, die Expertenbewertung erfordern – genau dort, wo menschliche Zeit investiert werden sollte.
Ihre Daten verlassen niemals Ihre Umgebung
Der Enterprise-Vertriebseinwand, den wir am häufigsten hören: "Wir können unsere Daten nicht an einen Drittanbieter senden."
Sie haben Recht, vorsichtig zu sein. Und sie lösen das falsche Problem.
Unsere Agents benötigen Ihre Daten nicht. Sie benötigen Ihre Workflow-Logik. Der Unterschied ist entscheidend:
| SaaS-Modell | Agent-Modell |
|---|---|
| "Laden Sie Ihre Geodaten auf unsere Plattform hoch" | "Wir sehen Ihre Geodaten nie" |
| 12-18 Monate Sicherheitsaudit-Zyklus | Läuft ab Tag 1 in Ihrer VPC |
| Aufschlag auf Rechenleistung zahlen | Nutzen Sie bereits bezahlte Credits |
| Petabytes zum Anbieter verschieben | Automatisierung zu Ihren Daten bringen |
Dies nennen wir "Compute-to-Data"-Architektur. Anstatt Ihre Petabytes zu uns zu verschieben, deployen wir containerisierte Agents direkt in Ihre Databricks-, Snowflake- oder Cloud-Umgebung.
Die Agents analysieren Ihre ArcPy-Skripte, Ihre Geoprocessing-Modell-Exporte, Ihre Workflow-Dokumentation. Sie schlagen modernisierte Äquivalente vor. Sie validieren, dass der neue Code identische Outputs wie der alte Code produziert.
Zu keinem Zeitpunkt sehen sie Ihre tatsächlichen Daten. Sie sehen die Logik, die Ihre Daten verarbeitet.
Die Tech-Stack-Transformation
Automatisierung bedeutet nicht, ArcPy durch GeoPandas zu ersetzen. Es bedeutet, Patterns zu ersetzen, die nicht skalieren, durch Patterns, die skalieren.
| Vorher (Legacy) | Nachher (Cloud-Native) | Warum es wichtig ist |
|---|---|---|
| Desktop-Dateien (.gdb, .shp) | Cloud-native Formate (GeoParquet, COG) | Paralleler Zugriff, keine File-Locks |
| Manuelle Downloads | Automatisierte Datenentdeckung (STAC) | Pipelines finden ihre eigenen Inputs |
| Sequenzielle Verarbeitung | Verteilte Berechnung (Spark, Dask) | Skaliert mit Datenvolumen |
| Visuelle QA | Automatisierte Validierungsregeln | Probleme abfangen, bevor Menschen sie sehen |
| Analysten-gesteuerte Ausführung | Zeitplan-gesteuerte Pipelines | Läuft, während Sie schlafen |
Die Erkenntnis ist, dass diese Patterns unabhängig von Ihrer spezifischen Plattform funktionieren. Databricks, AWS, Azure, GCP – die architektonischen Prinzipien sind dieselben. Die Implementierungsdetails unterscheiden sich.
Unsere Agents verstehen beides. Sie generieren Code, der cloud-nativen Patterns folgt und die spezifischen Einschränkungen Ihrer Plattform respektiert.
Patterns aus der Produktionsumgebung
Diese Patterns stammen aus der Verarbeitung länderweiter Geospatial-Daten für Versicherungsrisikobewertung. Die Fehler sind echt. Die Lösungen funktionieren.
Memory-Management: Grenzen übergeben, nicht Daten
Das Problem: Die Verarbeitung großer geografischer Gebiete (bevölkerungsreiche Länder, dichte städtische Regionen) stürzt mit OOM selbst auf leistungsstarken Clustern ab. Das Problem ist nicht die Rechenleistung – es ist die Datenarchitektur.
Das Pattern: Referenzen übergeben (Bounding Boxes, Dateipfade), nicht Daten. Lassen Sie nachgelagerte Prozesse nur das laden, was sie benötigen.
# FALSCH - liest 3,6 GB nur um Bounding Box zu finden
buffer_data = src.read(1)
extent = np.where(buffer_data > 0)
# RICHTIG - null Memory-Kosten
buffer_bounds = gdf.total_bounds
Diese einzelne Änderung reduzierte die Speichernutzung von 3,6 GB auf effektiv null.
Cloud-Storage: Zweistufiges Schreiben
Das Problem: Cloud-Objektspeicher (S3, Azure Blob, Databricks Volumes) unterstützen keine zufälligen Seek-Operationen. Formate, die Seek erfordern (GeoPackage/SQLite, GeoTIFF), schlagen mit kryptischen Fehlern fehl.
CPLE_AppDefinedError: _tiffSeekProc: Operation not supported
sqlite3_exec failed: disk I/O errorDas Pattern: Zweistufiges Schreiben. Verarbeiten auf lokalem Dateisystem, dann Stream-Kopie in Cloud-Storage.
Dies ist Stammwissen, dessen Entdeckung Monate dauert, wenn Sie es nicht kennen. Die Fehlermeldungen sagen Ihnen nicht, was falsch ist.
Geometrie-Validierung: Vorher, nicht nachher
Das Problem: Topologie-Ausnahmen stürzen räumliche Vereinigungen ab. Reale Daten (OSM, Regierungsquellen) enthalten sich selbst schneidende Polygone, Ring-Orientierungsprobleme und andere ungültige Geometrien.
Das Pattern: ALLE Geometrien vor Aggregationsoperationen validieren. Verwenden Sie make_valid(method='structure') – es ist 2,7× schneller als die Alternativen und verliert keine Daten wie buffer(0).
Dies eliminiert 90 %+ der Pipeline-Fehler, die wir in der Praxis sehen.
Wann AI Agents nicht die Lösung sind
Wir lehnen 20-30 % der Anfragen ab. Nicht weil wir nicht helfen können, sondern weil Automatisierung nicht den ROI liefern wird, den sie erwarten.
Hier ist, wann AI Agents das falsche Werkzeug sind:
Neuartige analytische Arbeit
Wenn jede Ausführung Experteninterpretation an 15 Entscheidungspunkten erfordert, kann Automatisierung diese Beurteilung nicht replizieren. Agents handhaben repetitive Ausführung. Menschen handhaben neuartige Analysen.
Undokumentierte Workflows
Wenn der Workflow nur im Kopf eines Analysten existiert, erfordert Automatisierung zuerst Dokumentation. Wir können dabei helfen – aber planen Sie 4-6 zusätzliche Wochen für Prozessformalisierung ein, bevor die Automatisierung beginnt.
Niedrige Frequenz, niedrige Bedeutung
Workflows, die einmal pro Jahr mit minimalen nachgelagerten Auswirkungen ausgeführt werden, rechtfertigen keine Automatisierungsinvestition. Die Rechnung geht nicht auf. Ausnahme: wenn manuelle Ausführung eine Schlüsselpersonen-Abhängigkeit schafft, die die Geschäftskontinuität bedroht.
Besser ersetzt als migriert
Einige Legacy-Systeme sollten nicht migriert werden. Sie sollten ersetzt werden. Wenn die zugrunde liegende Logik fundamental fehlerhaft ist, produziert ihre Automatisierung nur schneller falsche Antworten. Wir sagen Ihnen, ob dies Ihre Situation ist.
Der Sweet Spot
Automatisierung funktioniert am besten für Workflows, die:
- Repetitiv: 8+ Stunden/Woche für dieselbe Aufgabe
- Häufig: Mindestens 12+ Ausführungen/Jahr
- Dokumentiert: Schritte sind formalisiert (auch teilweise)
- Ausführungslastig: Mehr Klicken als Denken
AI Agents für GIS sind keine Chatbots mit Karten-Skills. Sie sind Automatisierungs-Engines, die die repetitive Arbeit erledigen, die Ihr Team nicht manuell machen sollte.
Die Dual-Agent-Architektur – Architect schlägt vor, Auditor validiert – fängt die Fehler ab, die Single-Agent-Systeme für die Produktion gefährlich machen. Ihre Daten verlassen niemals Ihre Umgebung. Die Agents analysieren Logik, nicht Geodaten.
Das ist keine Magie. Es ist Engineering. Die Patterns sind bekannt. Die Einschränkungen sind dokumentiert. Die Validierung ist automatisiert.
Die Frage ist nicht, ob AI Ihre Workflows automatisieren kann. Es ist, ob Ihre Workflows bereit für Automatisierung sind – und ob Automatisierung die richtige Investition für Ihre spezifische Situation ist.
Manchmal ist es so. Manchmal nicht. Wir sagen Ihnen, welches zutrifft.
Workflow-Automatisierung Einblicke erhalten
Monatliche Tipps zur Automatisierung von GIS-Workflows, Open-Source-Tools und Erkenntnisse aus Enterprise-Deployments. Kein Spam.