AI-Agents für GIS-Analysen: Erfahrungsbericht meiner Masterarbeit

Als ich meine Masterarbeit bei Esri begonnen habe, wurde mir schnell klar: Ich hatte mir ein Thema ausgesucht, bei dem ich einiges dazulernen würde. Aus meinem Geographiestudium brachte ich zwar Erfahrung mit GIS, räumlichen Analysen, Python und ersten AI-Methoden mit. Von Agent-Frameworks, MCP, Large Language Models und der Infrastruktur dahinter hatte ich zu Beginn jedoch kaum eine Ahnung.

In meiner Masterarbeit „Entwicklung und Evaluation digital souveräner AI-Agents für GIS-Analysen“ an der Universität Bonn untersuchte ich, wie sich digital souveräne AI-Agents für GIS-Analysen entwickeln und evaluieren lassen und wie technische Designentscheidungen ihre Analysefähigkeiten beeinflussen. Die Arbeit entstand in Zusammenarbeit mit Esri Deutschland GmbH.

Von der Geographie zu AI-Agents: Mein Sprung ins kalte Wasser

Genau das machte das Thema für mich aber auch so spannend. AI-Agents sind ein vergleichsweise neues Feld. Mich hat besonders interessiert, wie sich AI-Agents in klassische GIS-Analyseprozesse integrieren lassen und wie sich das unter den Bedingungen digitaler Souveränität umsetzen lässt.

Damit stellte sich für mich zunächst eine zentrale Frage:

Wie müssen LLM, Agent-Architektur und Tools zusammenspielen, damit aus einer natürlichsprachlichen Anfrage eine nachvollziehbare GIS-Analyse wird?

Dieser Frage bin ich in meiner Masterarbeit nachgegangen. Dafür entwickelte ich verschiedene Agent-Konfigurationen und untersuchte, wie gut sie sich für unterschiedliche GIS-Analysen eignen.

Vom klassischen GIS-Workflow zum AI-Agent

Wer schon einmal mit GIS gearbeitet hat, kennt den klassischen Ablauf: Daten recherchieren, Analysewerkzeug öffnen, Parameter setzen und anschließend die Ergebnisse interpretieren. Das funktioniert zuverlässig, setzt aber auch voraus, dass der Nutzer weiß, welche Daten und Tools benötigt werden und wie sie zu verwenden sind.

Die Idee eines AI-Agents setzt an einer anderen Stelle an: Statt sich durch große Mengen von Daten und Tools zu arbeiten, kann ich meine Anfrage einfach in natürlicher Sprache formulieren und der AI-Agent führt die Arbeitsschritte durch.

Wichtig ist: Der AI-Agent ersetzt nicht die GIS-Fachlogik. Er soll sie für den Nutzer über natürliche Sprache zugänglich machen.

Das klingt zunächst ziemlich praktisch. Aber gerade bei GIS-Analysen genügt nicht nur eine reine Textantwort. Und spätestens bei sensiblen Daten stellt sich die Frage: Wo werden diese Daten verarbeitet und wer hat die Kontrolle darüber?

Sensible Daten unter Kontrolle: Warum digitale Souveränität wichtig ist

Für meine Masterarbeit wollte ich deshalb nicht einfach eine Anfrage an einen externen AI-Dienst schicken und anschließend schauen, was dabei herauskommt. Die Rahmenbedingung war eine andere: Die gesamte technische Architektur, von den Daten über die LLMs bis zur Infrastruktur, sollte unter eigener Kontrolle bleiben.

Gerade im Umfeld kritischer Infrastrukturen können Geodaten Informationen enthalten, die nicht ohne Weiteres an externe Dienste übertragen werden sollten. Damit wurde die digitale Souveränität zu einem zentralen Bestandteil meiner Architektur.

Für meinen Ansatz bedeutete digitale Souveränität vor allem vier Dinge:

Kontrolle, Nachvollziehbarkeit, Austauschbarkeit und Datenhoheit.

Die Daten sollten innerhalb der eigenen Umgebung bleiben, die eingesetzten Komponenten möglichst transparent und kontrollierbar sein und einzelne Bausteine bei Bedarf ausgetauscht werden können.

Konkret setzte ich auf lokale Open-Source-LLMs, die ich mit Ollama ausführte. Die GIS-Grundlage meiner Architektur bildete ArcGIS Enterprise. Hier wurden die Geodaten und GIS-Dienste bereitgestellt, auf die meine AI-Agents für ihre Analysen zugreifen konnten. Damit konnte ich auf eine bestehende GIS-Umgebung von Esri aufbauen, anstatt eine separate GIS-Infrastruktur für die AI-Agents zu entwickeln.

Um diese GIS-Funktionalitäten für die AI-Agents nutzbar zu machen, entwickelte ich eigene Tools auf Basis der ArcGIS API for Python. Die API ermöglichte den programmatischen Zugriff auf Inhalte und Funktionen von ArcGIS Enterprise. So konnten die Tools die benötigten Geodaten abfragen und die vorgesehenen GIS-Analysen ausführen.

Die Verbindung zur Agent-Architektur stellte ich über FastMCP und das Model Context Protocol (MCP) her. Damit wurden die entwickelten Tools für die mit LangGraph aufgebauten AI-Agents verfügbar.

Dabei geht es nicht darum, dass Cloud-Dienste grundsätzlich schlechter sind. Entscheidend ist vielmehr die Frage: Wer besitzt die Kontrolle über die Daten, das LLM und die eingesetzte Infrastruktur?

Damit waren die technischen Rahmenbedingungen gesetzt. Jetzt fehlte nur noch der entscheidende Test: Wie schlägt sich dieser Ansatz in der Praxis?

Vom „Labor“ in die Praxis: Ein Use Case aus der kritischen Infrastrukturversorgung

Bis hierhin klingt das alles noch ziemlich abstrakt. Also mussten meine AI-Agents beweisen, was sie in der Praxis tatsächlich können. Dafür brauchte ich einen Anwendungsfall, bei dem echte Geodaten und konkrete Analyseaufgaben zum Einsatz kommen.

Als praktischen Use Case habe ich deshalb ein Szenario aus dem Umfeld der Bodensee-Wasserversorgung verwendet. Die Bodensee-Wasserversorgung ist eines der größten Wasserversorgungsunternehmen Deutschlands und damit Teil der kritischen Infrastruktur. Für meinen Anwendungsfall standen Geodaten zur Verfügung, anhand derer räumliche und attributive GIS-Analysen durchgeführt werden konnten.

Eine Anfrage konnte beispielsweise eine räumliche Analyse betreffen: Welche Objekte befinden sich innerhalb eines bestimmten Bereichs? Oder eine attributive Fragestellung: Welche Objekte besitzen bestimmte Eigenschaften?

Der AI-Agent musste dafür nicht nur die Anfrage verstehen, sondern diese auch an den zuständigen Subagenten leiten, das passende Tool auswählen und die benötigten Parameter bestimmen.

Anschließend konnte ich überprüfen, ob die AI-Agents tatsächlich das getan hatten, was ich von ihnen erwartet hatte: Wurde die Anfrage richtig verstanden? Wurde das passende Tool ausgewählt? Waren die Parameter korrekt? Und stimmte am Ende auch das GIS-Ergebnis?

Genau hier begann der eigentlich spannendste Teil meiner Masterarbeit: Nicht jede Konfiguration von AI-Agents kommt mit diesen Aufgaben gleich gut zurecht.

„Alles klar!“… und dann macht der AI-Agent etwas völlig anderes.

Meine anfängliche Vorstellung war vermutlich etwas zu gutmütig: Wenn die LLMs inzwischen so leistungsfähig sind, müsste ich ihnen doch einfach sagen, was sie tun sollen, und danach läuft es?

Spoiler: Nein.

Die Entwicklung meiner AI-Agents war deutlich weniger linear, als ich zunächst erwartet hatte. Denn auch wenn die einzelnen Komponenten grundsätzlich funktionieren, kann ihr Zusammenspiel völlig unerwartete Ergebnisse hervorbringen.

Manchmal wählte der AI-Agent trotz einer für mich eindeutigen Anfrage das falsche Tool. Manchmal interpretierte er einen Parameter anders als erwartet oder erzeugte unerwartete Input-Parameter. In anderen Fällen funktionierte ein Workflow grundsätzlich, aber ein Zwischenergebnis wurde nicht so weitergegeben, wie es für den nächsten Schritt benötigt wurde. Und dann gab es natürlich auch Unterschiede zwischen den verwendeten LLMs: Was mit Modell A zuverlässig funktionierte, hat mit Modell B plötzlich nicht mehr funktioniert.

Besonders spannend war dabei, dass eine vermeintliche „Optimierung“ nicht immer direkt Verbesserungen brachte. Eine kleine Änderung am System-Prompt konnte beispielsweise einen Konflikt beheben und gleichzeitig an anderer Stelle ein neues Problem auslösen.

Für mich bedeutete das vor allem eines: Sehr viel ausprobieren. Und manchmal war zunächst überhaupt nicht klar, warum die AI-Agents etwas Bestimmtes getan hatten. Also hieß es: Fehler eingrenzen, ausprobieren, anpassen, erneut testen. Und wieder von vorne anfangen.

Diese Momente waren manchmal frustrierend, aber gleichzeitig auch eine wichtige Erkenntnis. Ich habe dabei gemerkt, dass es bei der Entwicklung von AI-Agents weniger darum geht, ihnen einmalig eine Aufgabe zuzuweisen, als vielmehr darum, das Zusammenspiel aus LLM, Agents, Tools und GIS-Logik Schritt für Schritt zu entwickeln und zu testen.

Ein AI-Agent ist also kein fertiger „Mitarbeiter“, dem man eine Aufgabe gibt und der anschließend mit einem perfekten Ergebnis zurückkommt. AI nimmt einem nicht automatisch die gesamte Arbeit ab. Sie verändert eher die Art der Arbeit.

Nach vielen dieser kleinen „Warum macht er das jetzt?“-Momenten habe ich schließlich die entwickelten Konfigurationen systematisch miteinander verglichen.

Meine wichtigsten Erkenntnisse und ein Blick in die Zukunft

Nach all den Tests und Anpassungen wollte ich natürlich wissen:

Welche Konfiguration funktioniert am besten?

Die kurze Antwort: Es gibt nicht die eine perfekte Kombination aus LLM, Agent-Architektur und Tools. Schon die Wahl des LLMs kann beeinflussen, wie gut eine Anfrage verstanden, das passende Tool ausgewählt oder dessen Parameter gesetzt werden. Gleichzeitig können eine durchdachte Agent-Architektur und sinnvoll gestaltete Tools viele Fehler abfangen. Meine wichtigste Erkenntnis war deshalb:

Ein leistungsfähiges LLM allein macht noch keinen zuverlässigen AI-Agent. Entscheidend ist das Zusammenspiel aus LLM, Agents, Tools und der zugrundeliegenden GIS-Logik.

Für mich persönlich war die Masterarbeit aber auch eine Reise in ein Themenfeld, das weit außerhalb meines ursprünglichen GIS-Schwerpunkts lag. Als Geographin plötzlich mit LLMs, Agent-Frameworks, MCP und lokaler AI-Infrastruktur zu arbeiten, war definitiv eine Herausforderung. Gerade deshalb hat mir die Arbeit gezeigt, wie spannend die Verbindung von GIS und AI sein kann.

Auch die Zeit bei Esri war für mich eine besondere Erfahrung. Ich hatte die Möglichkeit, an einem sehr zukunftsorientierten Thema zu arbeiten und gleichzeitig die Sicht eines Unternehmens kennenzulernen, dessen GIS-Technologie ich zuvor vor allem aus der Anwenderperspektive kannte. Besonders interessant fand ich dabei, dass sich die Arbeit trotz der Größe des Unternehmens an vielen Stellen erstaunlich persönlich angefühlt hat.

Und wie geht es weiter mit AI-Agents?

Ich glaube, dass AI-Agents für GIS erst in den Kinderschuhen stecken. Statt eines einzelnen allwissenden AI-Agents könnten künftig spezialisierte Multi-Agent-Systeme unterschiedliche GIS-Aufgaben übernehmen, beispielsweise Datenabfragen, Monitoring oder die Aufbereitung von Ergebnissen. Genau hier sind modulare Architekturen interessant, bei denen einzelne Komponenten flexibel ausgetauscht und kombiniert werden können.

Trotz aller Möglichkeiten bleibt für mich aber ein Punkt besonders wichtig: AI-Agents sollten nicht gänzlich autonom Entscheidungen übernehmen, nur weil sie technisch dazu in der Lage sind. Gerade bei sensiblen Daten und kritischen Infrastrukturen müssen Ergebnisse von Menschen überprüft werden.

Meine Masterarbeit hat mir deshalb vor allem eines gezeigt: AI-Agents werden GIS nicht einfach ersetzen. Viel spannender ist die Frage, wie sie GIS zugänglicher und effizienter machen können und welche technischen Rahmenbedingungen dafür notwendig sind.

Und vielleicht ist genau das die spannendste Erkenntnis, die ich aus meiner Masterarbeit mitnehme: Ich bin mit einem GIS-Hintergrund in ein für mich neues Thema gestartet und habe dabei gelernt, dass man im Bereich AI nicht alles von Anfang an verstehen kann, viel auszuprobieren muss und gelegentlich auch mit einem „Warum macht der Agent das jetzt?“ vor dem Bildschirm sitzt.

Über die Autorin: Svenja Steffens

Ich bin Absolventin der Geographie an der Universität Bonn und interessiere mich besonders dafür, wie sich Agentic AI in klassische GIS-Analysen integrieren lässt.

Du beschäftigst dich ebenfalls mit AI-Agents, GIS oder digitaler Souveränität und hast konkrete Fragen zu meiner Arbeit? Dann melde dich gerne bei mir. Ich freue mich auf den Austausch!

E-Mail: Svenja.Steffens@gmx.de
LinkedIn: Svenja Steffens