Ein Satellit meldete ein Depot unter Wasser. Es war der Schatten einer Wolke – und der parametrische Trigger stand kurz davor, 1,2 Mio. $ automatisch auszuzahlen.
Ein Satellit erfasste das Mesa Junction Depot, sah eine dunkle Fläche, wo trockener Boden sein sollte, und markierte den Standort als überflutet. Eine parametrische Flutpolice las diesen Trigger als Tatsache und bereitete eine automatische Auszahlung von 1,2 Mio. $ vor – kein Schadenregulierer, kein Telefonanruf, keine zweite Prüfung. Die dunkle Fläche war der Schatten einer Wolke. Sechs Tage später war er aus den Aufnahmen verschwunden, und der Boden darunter war nie nass gewesen.
Ich habe genau diesen Fall ganz bewusst konstruiert, weil es derjenige ist, den ein einzelnes Satellitenbild niemals erfassen kann. Ich bin Ashutosh und leite Veriprajna. TriggerProof ist eine Demo, die ich gebaut habe, um eine bestimmte These zu belegen: Der gefährliche Moment in der parametrischen Flutversicherung ist nicht die Erkennung, sondern die Entscheidung zur Auszahlung. Jeder Standort, jede Kachel, jeder Pegelmesser und jeder Feldbericht darin sind synthetische, physikgetreue Stellvertreter, die ich geschrieben habe, um die Fehlermodi sauber zu inszenieren. Sie können die Demo öffnen und das Ganze selbst ausprobieren unter veriprajna.com/de/demos/satellitengestutzte-hochwasser-intelligence-bewertung-des-parametrischen-triggers-vor-der-auszahlung. Das Mesa Junction Depot ist der Ort, an dem ich beginnen möchte, denn dieser Fall hat mir vor Augen geführt, was ich da eigentlich baute.
Vier verschiedene Ursachen verdunkeln dieselben Pixel
Ich hatte das eigentliche Problem noch gar nicht voll erfasst, bis ich mich daranmachte, die synthetischen Bilder zu erzeugen, und vier Phänomene auf einem einzigen Bild identisch aussehen lassen musste. Die parametrische Flutversicherung hat den Schadenregulierer durch einen Trigger ersetzt: Ein Satellit meldet, ein Standort stehe unter Wasser, und schon fließt Geld. Das Problem ist: Auf einer einzelnen optischen Aufnahme oder einem einzigen Radardurchlauf verdunkeln sich echtes Flutwasser, ein Wolkenschatten, ein Radar- oder Geländeschatten und ein dauerhaftes Wasserreservoir auf exakt dieselbe Weise. Ein einzelnes Bild kann sie nicht voneinander trennen, weil die Information, die sie unterscheidet, nicht in einem einzelnen Bild existiert.
Das hat die gesamte Demo für mich neu definiert. Der katastrophale Fehler in diesem Geschäft ist nicht die Überschwemmung, die der Trigger übersieht. Es ist die Überschwemmung, die der Trigger erfindet, eine selbstsichere Auszahlung von 2 Mio. $ auf einen Schatten, ohne jeden Nachweispfad, um die Entscheidung zu verteidigen, wenn ein Rückversicherer ein Jahr später danach fragt. TriggerProof erkennt keine Überschwemmungen und erzeugt keine Satellitendaten. Es nimmt einen Trigger, der bereits ausgelöst wurde, und beurteilt, ob tatsächlich ausgezahlt werden sollte.
Ein Bild meldete Flut; das nächste zeigte, dass der Boden nie nass war
Ich erinnere mich noch gut daran, wie ich den Mesa-Junction-Filmstreifen zum ersten Mal durchging, als er korrekt gerendert wurde. Über die Benutzeroberfläche kann man einen markierten Standort öffnen und die Aufnahmebilder Bild für Bild durchgehen – optisch oben, Radar unten. Im Trigger-Bild ist der dunkle Fleck direkt zu sehen, wassersignalgrün, genau das, was den Alarm auslöste. Geht man zur nächsten Aufnahme, ist er verschwunden. Geht man zurück, zeigt die Radar-Rückstreuung unter demselben Fleck in jedem einzelnen Bild Normalwerte an, weil das Radar die ganze Zeit über direkt durch die Wolke hindurch trockenen Boden sah.
Der Schatten zog weiter; das Wasser wäre geblieben. Das erkennt man nur über die Zeit und über mehrere Sensoren hinweg – niemals auf dem einzelnen Bild, das den Trigger ausgelöst hat.
Die Physik ist eindeutig, sobald man die Bilder nebeneinanderlegt. Ein Wolkenschatten ist flüchtig und bewegt sich mit Wolkengeschwindigkeit; er ist also auf einer Aufnahme dunkel und auf der nächsten schon verschwunden. Echtes Flutwasser bleibt über mehrere Aufnahmen hinweg bestehen und erscheint gleichzeitig im optischen Bild dunkel und im Radar niedrig. Zwei Regeln bilden genau das ab: zeitliche Persistenz und Radar-Optik-Übereinstimmung. Bei Mesa Junction liefern beide das Ergebnis FAIL, und der Klassifikator stuft das Ereignis mit einem Konfidenzwert von 1,00 als Wolkenschatten ein. Die 1,2 Mio. $ hätten niemals zur Auszahlung vorgemerkt werden dürfen.
Die fünf Regeln entscheiden, nicht das Sprachmodell
Ich habe anfangs versucht, das Sprachmodell diese Entscheidung treffen zu lassen, und ich bin froh darüber, denn es scheiterte auf die lehrreichste denkbare Weise. Ich ließ einen Agenten dieselben Belege auswerten und fragte ihn im Grunde, ob der Standort wirklich überflutet sei. Bei einem uneindeutigen Fall schrieb er mir einen flüssigen, selbstsicheren Absatz mit Argumenten für eine Flut – und lag falsch, ohne dass auch nur der geringste Hinweis in seinem Tonfall darauf hindeutete. Dieser Nachmittag besiegelte eine Architekturentscheidung, die ich seither nicht wieder infrage gestellt habe.
Die Entscheidung liegt daher in reinem Python, in fünf einsehbaren Diskriminatoren – ganz ohne KI-Modell im Pfad, der Gelder bewegt. Zeitliche Persistenz (R1) unterscheidet eine Flut von einem flüchtigen Wolkenschatten. Radar-Optik-Übereinstimmung (R2) unterscheidet eine Flut sowohl von einem Wolkenschatten als auch von einem Radarschatten. DEM-Hangneigung (R3) schließt Wasser aus, das sich an steilem Gelände stauen müsste. Eine Dauergewässermaske (R4) schließt bekannte Wasserreservoirs aus. Die hydrologische Anbindung (R5) prüft, ob die nasse Fläche tatsächlich mit dem Entwässerungsnetz verbunden ist. Der Verifizierer entscheidet; das Sprachmodell berät nur. Der beratende Agent basiert auf Pydantic AI, unterstützt austauschbare Modelle mit dem Standard claude-opus-4-8, gleicht das physikalische Urteil mit unabhängigen Bodensignalen ab und gibt corroborates, contradicts oder inconclusive zurück. Er kann überstimmt werden, und wenn ich den API-Schlüssel entferne, läuft die Demo vollständig offline auf einem deterministischen Fallback – denn der Teil, dem ich eine Auszahlung anvertraue, darf nicht derjenige sein, der in selbstsicheren Absätzen formuliert.
Wenn die Physik selbst unsicher ist, eskaliert das System, statt zu raten
Der Fall, in dem das System „Ich weiß es nicht“ sagt, ist mir wichtiger als jeder eindeutige Treffer. Canal Street Hub ist genau so ein Fall. Die optischen und Radar-Signaturen sind grenzwertig, das Flutsignal hält über zwei von drei Bildern an, und der unabhängige Flusspegel hat nie den bordvollen Wasserstand überschritten. Die Belege widersprechen sich tatsächlich. Der Konfidenzwert liegt bei 0,151 – weit unter der Automatisierungsschwelle von 0,65, die ich auf dem gelabelten Datensatz kalibriert habe –, und der Boden-Agent widerspricht der Satellitenklassifizierung direkt.
Das Policy-Gate übergibt diese 0,8 Mio. $ mit allen beigefügten Belegen und dem Vermerk „needs proof“ an einen Menschen, statt eine Münze zu werfen und das Ganze Automatisierung zu nennen. Ein Flut-Trigger, der wirklich zweifelhafte Fälle eskaliert, wirkt auf manche Einkäufer wie das schwächere Produkt. Ich sehe das genau umgekehrt. Es ist die einzige Version, die ich unbeaufsichtigt laufen lassen würde, weil die Alternative zur Eskalation hier ein schnelles Raten um echtes Geld ist, getarnt als Entscheidung.
Die Portfolio-Kennzahl, zu der ich immer wieder zurückkehre
Ich rufe dieses Portfolio aus acht Standorten immer wieder auf, weil es die Tragweite auf eine Weise verdeutlicht, wie es kein Einzelfall vermag. Ein Unwetter zieht über ein Portfolio aus acht Gebieten hinweg. Der herkömmliche Einzelbild-Trigger schlägt bei sechs davon an und reiht 8,0 Mio. $ für automatische Auszahlungen ein. TriggerProof beurteilt das Portfolio: Zwei echte Überschwemmungen werden bestätigt und mit 4,0 Mio. $ ausgezahlt, drei Fehlalarme werden unterdrückt (ein Wolkenschatten über 1,2 Mio. $, ein Radarschatten über 1,0 Mio. $, ein Dauerreservoir über 1,0 Mio. $), wodurch 3,2 Mio. $ einbehalten werden, und der eine zweifelhafte Fall über 0,8 Mio. $ wird eskaliert.
Die Hälfte dessen, was der herkömmliche Trigger ausgezahlt hätte – 4,0 Mio. $ von 8,0 Mio. $ –, wird entweder gestoppt oder zur Nachprüfung einbehalten. Das ist die Zahl, und ich möchte ihren Rahmen präzise abstecken: Dies ist das synthetische Portfolio der Demo – acht Fälle, die ich physikalisch getreu modelliert habe, kein Bestand realer Schadensfälle. Der Mechanismus ist echt und überprüfbar. Die Schadensfälle sind inszeniert, damit man die Funktionsweise des Mechanismus beobachten kann.
Null unsichere Entscheidungen und der Vorbehalt, auf den ich keinesfalls verzichte
Ich habe einen fundierten Benchmark durchgeführt, denn ein Portfolio aus acht Fällen ist eine Geschichte, kein Beweis. Die Testumgebung bewertet 60 gelabelte Fälle von eindeutigen Signaturen bis hin zu grenzwertigem Rauschen. Die wichtigste Kennzahl ist keine Genauigkeitsquote, sondern ein Sicherheitswert: null unsichere automatisierte Entscheidungen gegenüber 48 bei einer Einzelbild-Baseline, die jeden markierten Fall auszahlt. Achtzig Prozent der Fälle werden automatisch gelöst, und die unsicheren 20 % werden eskaliert. Unter den automatisch gelösten Fällen beträgt die Falsch-Positiv-Unterdrückung 36 von 36 und der Flut-Recall 12 von 12, und jeder einzelne der 12 tatsächlich uneindeutigen Fälle wird eskaliert, statt automatisch entschieden zu werden.
Es ging nie um ein perfektes Ergebnis auf meinem eigenen Testdatensatz. Der entscheidende Punkt ist, dass das System niemals eine unsichere automatisierte Entscheidung trifft. Wenn es sich nicht sicher ist, eskaliert es.
Dieser Vorbehalt gehört untrennbar zu jeder einzelnen dieser Zahlen, und ich lasse ihn nicht unter den Tisch fallen. Sie wurden auf einem festen, gelabelten Datensatz aus 60 synthetischen, physikgetreuen Fällen gemessen – sie sind weder eine Open-World-Garantie noch ein Praxisergebnis aus dem Feld. Der ehrliche nächste Schritt ist kein noch größerer Anspruch, sondern die Validierung anhand realer Archive wie Sen1Floods11 und aktueller Sentinel-Szenen. Genau das wäre das Erste, was ein echtes Kundenprojekt liefern würde, und nicht etwas, was diese Demo bereits geleistet hat. Das offen auszusprechen, erlaubt es mir, voll hinter den restlichen Zahlen zu stehen.
Eine Auszahlung, die man später nicht verteidigen kann, ist ein Haftungsrisiko – selbst wenn sie berechtigt war
Ich hatte ursprünglich nicht vor, den Nachweispfad zum Herzstück zu machen, aber am Ende war es genau der Teil, bei dem ich mir am sichersten war, dass ein Versicherer wirklich dahinterstehen kann. Eine berechtigte Auszahlung, die man später nicht rekonstruieren kann, bleibt ein Haftungsrisiko, denn „der Satellit hat es so gemeldet“ ist keine Begründung, die ein Rückversicherer oder Wirtschaftsprüfer akzeptiert. Deshalb erzeugt jede Entscheidung – ob Auszahlung oder Unterdrückung – ein forensisches Dossier: die Datenherkunft jedes Bildes, die Belege pro Regel mit den Messwerten jedes Diskriminators, das Protokoll zur Eliminierung von Falsch-Positiven, den unabhängigen Abgleich mit Bodendaten und einen SHA-256-Herkunftshash der Entscheidung.
Ich möchte genau differenzieren, was dieser Hash ist und was nicht. Es handelt sich um einen Inhalts-Hash, der den Datensatz manipulationssicher macht, sodass jeder ihn neu berechnen und überprüfen kann, ob die Entscheidung nachträglich verändert wurde. Es ist keine digitale PKI-Signatur, und der Satellitenabruf, die SAR-Auftragsvergabe, die Boden-Feeds sowie die Integration in Schadensplattformen sind in dieser Demo lediglich gemockt – simuliert, damit das Ganze auf meinem Laptop läuft. Was real ist, ist die Struktur des Datensatzes: für jede automatisierte Auszahlungsentscheidung genau festzuhalten, welche physikalische Regel was ausgesagt hat, mit welcher Konfidenz und abgeglichen mit welchem unabhängigen Signal.
Die parametrische Versicherung ist einen echten Kompromiss eingegangen: Sie verzichtet auf den Schadenregulierer, um Auszahlungen sofort und streitfrei zu ermöglichen. Was sie sich damit eingehandelt hat, ist ein physikalisches Problem, das sie auf einem einzelnen Bild nicht durchschauen kann – und das Fehlerrisiko, dem dieser Kompromiss einen aussetzt, ist eine schnelle, selbstsichere Auszahlung für einen Schatten. Die dauerhafte Lösung liegt außerhalb des Modells: deterministische Regeln, die täuschend ähnliche Phänomene über Zeit und Sensoren hinweg trennen, ein Gate, das zweifelhafte Fälle an einen Menschen eskaliert, und ein Datensatz, der jede Entscheidung verteidigbar macht. Ein schärferer Satellit löst kein Beurteilungsproblem – und genau darum handelt es sich hier.
Und wenn Sie das Ganze lieber in Aktion sehen möchten, als meine Beschreibung zu lesen: Hier läuft der gesamte Ablauf von Anfang bis Ende.
Mesa Junction ist der Fall, zu dem ich immer wieder zurückkomme. Erst die zweite Aufnahme kannte den Unterschied zwischen dem Schatten und der Flut – und der Trigger hatte bereits ausgelöst, bevor sie eintraf. Sie können diesen Filmstreifen selbst durchgehen und die Auszahlung nachvollziehen, die vermeintlich hätte erfolgen sollen, unter veriprajna.com/de/demos/satellitengestutzte-hochwasser-intelligence-bewertung-des-parametrischen-triggers-vor-der-auszahlung. Die Frage, die ich jedem stellen würde, der ein Portfolio automatisierter Flutversicherungen betreibt, ist präzise und beantwortbar: Wie viele der Trigger, die Sie in der letzten Saison automatisch ausgezahlt haben, könnten Sie heute noch als echtes Wasser und nicht als Schatten belegen?
