EmpCo Check: KI-Prüftool für Umweltaussagen

Der EmpCo Check prüft einzelne Aussagen, keine ganzen Texte. Im ersten Schritt löst er deshalb die Umweltaussagen aus dem Eingabematerial heraus. Das kann ein eingefügter Text sein, ein PDF oder eine ganze Website.

PDFs gehen direkt an das Modell. Umfangreiche Dokumente wie Nachhaltigkeitsberichte erschließt das System zunächst über ihre Gliederung, 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 und sieht daneben eine Kostenschätzung. 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 kommt über Realtime-Updates laufend in der Oberfläche an.

Das Tool klassifiziert jeden Claim, ordnet ihn einem Tatbestand der EmpCo-Richtlinie zu und begründet das. 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. Gibt die Datenlage kein belastbares Ergebnis her, sagt das System das und rät nicht. Fälle, die fachliches Urteilsvermögen brauchen, landen so sichtbar bei den Menschen, die es haben, und gehen nicht in einer grünen Ampel unter.

Das Tool ist in zwei Konstellationen im Einsatz: 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. Dazu gehören Tatbestand und Begründung, eine Farbe allein reicht nicht.

Zu jeder beanstandeten Aussage liefert das Tool außerdem einen konkreten Formulierungsvorschlag. Die Ergebnisse stehen im Dashboard oder als Excel-Export bereit, also dort, wo die fachliche Arbeit ohnehin stattfindet.

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

Welches Modell in welcher Phase der Pipeline arbeitet, konfiguriert FutureResponse selbst in den Einstellungen. Jeden Modellaufruf protokolliert das System mit Token- und Kostenaudit. Die Abwägung zwischen Kosten und Prüftiefe liegt damit beim Betreiber. Wir haben sie nicht einmalig in der Architektur festgeschrieben.

Was als Verstoß gilt und wie streng das Tool prüft, steht in versionierten Prompt-Dateien, die es zur Laufzeit lädt. Im Quelltext steht davon nichts. Eine Änderung an der Prüflogik braucht deshalb kein Deployment. Überprüfbar ist sie trotzdem: Die Prompts werden gegen Testfälle evaluiert wie Code gegen Unit-Tests.

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

In diesem Tool liegt ungeprüfte Außenkommunikation verschiedener Unternehmen nebeneinander. Die Mandantentrennung ist deshalb in der Datenbank verankert und nicht der Anwendung überlassen. Sie gilt auch dann, wenn ein Fehler in der Oberfläche etwas anderes anzeigen würde: Die Oberfläche blendet nur aus, die Datenbank lässt den Zugriff gar nicht erst zu. Die gesamte Anwendung liegt hinter einer Auth-Wall, die Daten liegen 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 erst 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 der einzige Weg, eine Fehlentwicklung zu bemerken, solange sie einen Tag alt ist.

Den Code hat Claude generiert, und zwar über den gesamten Weg und nicht nur als Vervollständigung an einzelnen Stellen. Dadurch ändert sich vor allem die Reihenfolge, weniger die Tippgeschwindigkeit. Früher entstand eine Spezifikation vor der Entwicklung und veraltete danach. Jetzt ist sie das Artefakt, aus dem die Umsetzung hervorgeht, und muss entsprechend präzise sein.

Der Aufwand verschiebt sich damit nach vorne und in die Prüfung. Deshalb reicht ein Entwickler: Es fällt nicht weniger Arbeit an, aber eine andere.

FutureResponse sollte das Tool selbst erweitern können: mit einem eigenen Entwickler, ohne Entwicklungsabteilung im klassischen Sinn. Deshalb haben wir keine Dokumentation hinterlassen, wir haben die Arbeitsweise selbst gebaut. Entstanden ist eine Harness, die den Entwicklungsprozess definiert, wo ein Dokument ihn nur beschreiben würde.

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. Wir haben diese Regel nicht aufgeschrieben und auf Sorgfalt gehofft. Drei unabhängige Prüfungen erzwingen sie: 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. Hat ein Kunde ein eigenes Entwicklungsteam, übergeben wir an Menschen. Gibt es keines, übergeben wir an ein System, das die Menschen führt.