EmpCo Check

Geprüft wird nicht ein Text, sondern eine Aussage. Der erste Schritt ist deshalb, aus dem Eingabematerial die einzelnen Umweltaussagen herauszulösen - aus einem eingefügten Text, einem PDF oder einer ganzen Website.

PDFs gehen dabei direkt an das Modell. Umfangreiche Dokumente wie Nachhaltigkeitsberichte werden nicht am Stück verarbeitet, sondern zunächst über ihre Gliederung erschlossen: Das System wählt die relevanten Abschnitte aus und prüft nur diese. Bei Websites ermittelt Firecrawl zuerst die Struktur des Auftritts. Bevor ein Lauf startet, bestätigt die Nutzerin die Auswahl der Seiten - mit einer Kostenschätzung daneben. Niemand soll versehentlich einen Konzernauftritt komplett durchprüfen lassen.

Der Lauf selbst arbeitet asynchron über eine Job-Verarbeitung mit Lease- und Retry-Mechanik, angetrieben von einem minütlichen Cron. Der Fortschritt läuft über Realtime-Updates zurück in die Oberfläche, statt in einem Ladebalken zu verschwinden.

Jeder Claim wird klassifiziert und einem Tatbestand der EmpCo-Richtlinie zugeordnet - mit Begründung. Das Urteil kennt vier Ausprägungen: Konform, kritisch, nicht konform - und Enthaltung.

Die vierte ist die wichtigste. Ein Prüfwerkzeug, das zu jeder Aussage ein Urteil fällt, erzeugt genau dort Scheinsicherheit, wo es darauf ankommt. Wo die Datenlage kein belastbares Ergebnis hergibt, sagt das System das, statt zu raten. Die Fälle, die fachliches Urteilsvermögen brauchen, landen damit sichtbar bei denen, die es haben - und werden nicht in einer grünen Ampel begraben.

Das Tool wird in beiden Konstellationen eingesetzt: Kunden prüfen ihre Kommunikation selbst, und die Berater:innen von FutureResponse arbeiten mit denselben Ergebnissen. Ein Befund muss deshalb für sich stehen können - mit Tatbestand und Begründung, nicht mit einer Farbe.

Zu jeder beanstandeten Aussage liefert das Tool zusätzlich einen konkreten Formulierungsvorschlag. Ergebnisse landen im Dashboard oder als Excel-Export - dort, wo die fachliche Arbeit ohnehin stattfindet.

Eine Website kann Hunderte Kandidaten für Umweltaussagen enthalten, von denen die meisten keine sind. Jede davon durch ein großes Modell zu schicken, wäre langsam und teuer. Ein günstiger Vorfilter sortiert deshalb vor, bevor die eigentliche Klassifikation läuft.

Welches Modell in welcher Phase der Pipeline arbeitet, konfiguriert FutureResponse selbst in den Einstellungen. Jeder Modellaufruf wird mit Token- und Kostenaudit protokolliert. Damit bleibt die Abwägung zwischen Kosten und Prüftiefe dort, wo sie hingehört: Beim Betreiber, nicht in einer Architekturentscheidung, die wir einmal getroffen haben.

Was als Verstoß gilt und wie streng geprüft wird, steht nicht im Quelltext, sondern in versionierten Prompt-Dateien, die zur Laufzeit geladen werden. Eine Änderung an der Prüflogik braucht damit kein Deployment - und sie ist überprüfbar: Die Prompts werden gegen Testfälle evaluiert wie Code gegen Unit-Tests.

Für eine Beratung ist das der eigentliche Hebel. Die Richtlinie wird sich in der Auslegung bewegen, Behörden und Gerichte werden Maßstäbe setzen, und die Fachleute, die das mitbekommen, sitzen bei FutureResponse - nicht bei uns.

In diesem Tool liegt ungeprüfte Außenkommunikation verschiedener Unternehmen nebeneinander. Die Trennung ist deshalb nicht Sache der Anwendung: Sie ist in der Datenbank verankert und gilt auch dann, wenn ein Fehler in der Oberfläche etwas anderes anzeigen würde. Die Oberfläche blendet aus - die Datenbank lässt gar nicht erst zu. Die gesamte Anwendung liegt hinter einer Auth-Wall, die Daten in der EU.

Vier Wochen funktionieren nur, wenn niemand Zeit damit verbringt, die Zuständigkeit des anderen zu erraten. Die Fachspezifikation kam vollständig von FutureResponse - die Beratung weiß, wie eine EmpCo-Prüfung fachlich abläuft, und musste dieses Wissen nicht durch uns hindurch übersetzen. Von uns kam die technische Spezifikation: Architektur, CI, Sicherheit, Performance, Monitoring und die Harness selbst.

Startpunkt waren die Workflow-Idee des Kunden und erste Mockups. Von dort lief die Entwicklung iterativ, mit nahezu täglichem Abgleich. Bei vier Wochen Laufzeit ist das keine Zeremonie, sondern der einzige Weg, eine Fehlentwicklung zu bemerken, solange sie einen Tag alt ist.

Den Code hat Claude generiert - über den gesamten Weg, nicht als Vervollständigung an einzelnen Stellen. Was sich dadurch ändert, ist weniger die Tippgeschwindigkeit als die Reihenfolge. Eine Spezifikation ist nicht mehr ein Dokument, das vor der Entwicklung entsteht und danach veraltet, sondern das Artefakt, aus dem die Umsetzung hervorgeht - und das entsprechend präzise sein muss.

Der Aufwand verschiebt sich damit nach vorne und in die Prüfung. Genau deshalb reicht ein Entwickler: Nicht, weil weniger Arbeit anfällt, sondern weil es eine andere ist.

FutureResponse sollte das Tool selbst erweitern können - mit einem eigenen Entwickler, ohne Entwicklungsabteilung im klassischen Sinn. Statt Dokumentation zu hinterlassen, haben wir deshalb die Arbeitsweise selbst gebaut: Eine Harness, die den Entwicklungsprozess definiert, statt ihn zu beschreiben.

Sie besteht aus einem verbindlichen Regelwerk, aus Testpflichten und aus Gates in der Pipeline, die beides durchsetzen. Ein Beispiel: Die Trennung zwischen Server- und Client-Code entscheidet in dieser Anwendung darüber, ob Zugangsdaten im Browser landen. Statt diese Regel aufzuschreiben und auf Sorgfalt zu hoffen, wird sie von drei unabhängigen Prüfungen erzwungen - eine Abhängigkeitsanalyse, ein eigener Prüfschritt und ein Security-Scanner. Wer die Regel verletzt, kommt nicht durch die Pipeline.

Das ist derselbe Grundsatz, nach dem wir Teams befähigen, nur mit anderen Mitteln. Wo ein Kunde ein eigenes Entwicklungsteam hat, übergibt man an Menschen. Wo keines existiert, übergibt man an ein System, das die Menschen führt.