Problemstellung

Im Kurs Interface Design war meine Endabgabe die Gestaltung einer KI-Software zum Thema „ESG Compliance & Regulation Auditor“. Die Kurzbeschreibung lautete:

Der oder die Studierende gestaltet ein Tool für Nachhaltigkeitsberichte. Ziel ist es, die Verbindung zwischen Finanzdaten und Umweltzielen (CO2-Ausstoß) grafisch aufzubereiten und für externe Prüfer lückenlos nachvollziehbar zu machen.

Mit der CSRD müssen Unternehmen einen Nachhaltigkeitsbericht abgeben, der ähnlich streng geprüft wird wie der Finanzbericht. Das eigentliche Problem dahinter: Die zugrunde liegenden Daten – etwa CO2-Werte – liegen verstreut in Stromrechnungen, Excel-Listen, Umfragen oder Lieferantendaten. Eine KI kann beim Zusammentragen helfen, aber jeder von ihr erzeugte Wert muss für einen externen Prüfer (Auditor) nachvollziehbar bleiben: Woher kommt diese Zahl, wie wurde sie berechnet, und wie sicher kann man sich sein?

Lösung

ESG Auditor löst das über zwei zentrale Mechanismen:

Den Audit Trail als Visual Mapping. Statt nur den fertigen CO2-Wert zu zeigen, macht das Tool die gesamte Kette sichtbar – vom Finanzbeleg (z.B. einer Stromrechnung) über die KI-Extraktion bis zur fertigen Emissionszahl. Bei komplexeren Werten (z.B. Scope-3-Schätzungen wie Mitarbeiterpendeln) verzweigt sich diese Kette zu mehreren zusammenfließenden Quellen, statt eine starre lineare Abfolge vorzutäuschen.

Ein zweiachsiges Vertrauenssystem. Jeder Datenpunkt wird entlang zweier unabhängiger Dimensionen markiert: Urheber (KI-generiert oder manuell) und Status (verifizierbar oder geschätzt). Je nach Kombination ändert sich die Unsicherheitsanzeige – ein verifizierbarer KI-Wert bekommt einen Confidence-Score, ein geschätzter Wert (egal ob von KI oder Mensch) bekommt stattdessen eine Bandbreite (Min–Wahrscheinlich–Max), angelehnt an die Drei-Punkt-Schätzung, wie sie auch in der IPCC-Methodik für Treibhausgas-Inventare verwendet wird.

Umsetzung

Domain Research

Ich habe mich zunächst in die fachliche Domäne eingearbeitet: CSRD-Berichtspflicht, die zehn ESRS-Themenstandards (E1–G1), die GHG-Protocol-Scopes (1/2/3) sowie die Praxis, wie Unternehmen aktuell mit Datenlücken umgehen – insbesondere die offizielle EFRAG-Datenpunkte-Liste, gegen die sich Vollständigkeit überhaupt erst messen lässt, und die übliche Praxis, fehlende Primärdaten über ausgabenbasierte Schätzungen oder Branchendurchschnittswerte zu überbrücken. Das hat mir geholfen, mein Vertrauenssystem nicht aus der Luft zu greifen, sondern an realer Berichtspraxis auszurichten.

Personas

Auf Basis der Domain Research habe ich drei Silicon Personas entwickelt, die unterschiedliche Anforderungen an Transparenz stellen:

Thomas (Skeptiker) – will maximale Kontrolle und Detailtiefe, misstraut KI-Outputs ohne Beleg

Jana (tech-affin) – vertraut KI-Ergebnissen schnell, ist aber bei regulatorischen Feinheiten unsicher

Michael (CFO) – will nur den groben Status, keine Details, muss aber freigeben können

Diese drei Profile haben direkt zur Informationsarchitektur geführt: Statt für jede Persona eine eigene Ansicht zu bauen, habe ich mich für Progressive Disclosure entschieden – eine einzige Anwendung mit gestufter Detailtiefe, durch die jede Person so weit klickt, wie sie es braucht.

Informationsarchitektur

Die Anwendung gliedert sich in vier Detailebenen über drei Screens:

[hier 1–2 Screenshots der Sitemap/des Klickflows einfügen]

Berichte – Jahresauswahl, vergangene (archivierte) und aktueller Bericht

Bericht-Übersicht (Ebene 0) – Gesamtfortschritt, Anteil geprüfter Werte, ein aggregierter Sicherheitskoeffizient sowie eine Prognose für den noch laufenden Berichtszeitraum

Dashboard (Ebene 1+2) – ein Kategorie-Grid der sechs ESRS-Bereiche; per Klick klappt darunter die Liste der einzelnen Datenpunkte auf, ohne Screen-Wechsel

Audit-Trail-Kette (Ebene 3) – die volle Herkunftskette eines einzelnen Werts, in zwei Varianten (linear bei einfachen Quellen, verzweigt bei mehreren zusammenfließenden Schätz-Quellen)

Designentscheidungen entlang der HAX/PAIR-Kriterien

Trust Calibration: Statt einer einzelnen „Confidence“-Zahl für alles trennt das System bewusst zwei Achsen (Urheber × Status) und wählt je nach Fall zwischen Prozentwert und Bandbreite. Auf der übergeordneten CO2-Treiber-Ansicht wird zusätzlich farblich kodiert, wie CO2-intensiv ein Posten pro investiertem Euro ist – das verbindet die in der Aufgabenstellung geforderte Finanz-CO2-Verbindung direkt mit der Vertrauensfrage.

Explainability: Jeder KI-generierte Wert in der Audit-Trail-Kette trägt einen kurzen, für Menschen lesbaren Begründungstext (z.B. „Feld 'Jahresverbrauch' auf allen 12 Rechnungen eindeutig erkannt“), der nach einem festen Schema aufgebaut ist: Ergebnis – Grundlage – Begründung der Unsicherheit.

Error & Hallucination Handling: Jeder Endwert in der Kette bietet die Optionen „Bestätigen“ oder „Korrigieren“. Zusätzlich prüft die KI bei manuell geschätzten Werten gegen, ob diese innerhalb einer plausiblen Bandbreite liegen, und markiert Abweichungen sichtbar. Auch unvollständige Quellenlagen (z.B. ein fehlender Standort in den HR-Daten) werden direkt im Kettenknoten als Hinweis ausgewiesen, statt den Wert unkommentiert als vollständig erscheinen zu lassen.

User Agency & Control: Über „Quelle öffnen“ kann jeder Beleg in einer Vorschau mit markierter Fundstelle eingesehen und heruntergeladen werden – Nutzer müssen der KI nicht blind vertrauen, sondern können jede Aussage an der Originalquelle prüfen. Fehlende Werte oder Quellen lassen sich direkt im Interface nachtragen.

Visuelles System

[Hier kurz beschreiben, welche bestehende Design Library als Basis diente, ergänzt um die Custom-Komponenten: Status-Dot (Ampel), zweiachsige Trust-Chips, Range-Slider, Audit-Trail-Knoten, Treemap.]

Ich habe zwei farblich strikt getrennte Systeme verwendet, um Verwechslungen zu vermeiden: ein Ampelsystem für den Compliance-Status (grün/gelb/rot) und ein unabhängiges System für die Datenherkunft, damit „kritisch im Bericht“ nie mit „kritisch bei der Datenqualität“ verwechselt wird.

Fazit

Im Verlauf des Projekts haben sich mehrere Annahmen als zu kompliziert oder unpassend herausgestellt:

Ursprünglich hatte ich einen expliziten Umschalter zwischen „Einfacher“ und „Experten“-Ansicht geplant, um den unterschiedlichen Bedürfnissen meiner Personas gerecht zu werden. Bei genauerer Prüfung wurde klar, dass reines Progressive Disclosure dieselbe Anforderung bereits ohne zusätzliches UI-Element erfüllt – der Umschalter wäre nur kosmetisch gewesen und ist daher wieder rausgeflogen.

Auch die Begrifflichkeit musste ich nachschärfen: „Geprüft“ hatte ich anfangs sowohl für „ein Wert ist überhaupt vorhanden“ als auch für „ein Wert ist durch einen Beleg bestätigt“ verwendet – zwei verschiedene Bedeutungen für ein Wort, die ich erst bei genauerer fachlicher Reflexion sauber in „erfasst“ (Vollständigkeit) und „verifiziert“ (Qualität) getrennt habe.

Eine ursprüngliche Idee, ein CO2-Reduktionsziel direkt auf der obersten Berichtsebene zu zeigen, habe ich verworfen, nachdem mir aufgefallen ist, dass das Tool den gesamten ESG-Bericht abbilden soll, nicht nur den CO2-Aspekt – die Zielgrafik gehört fachlich und gestalterisch nur in den E1-Bereich, nicht auf die neutrale Gesamt-Übersicht.