Mit dem Software Carbon Intensity Standard (ISO/IEC 21031:2024) und dem Blauen Engel für Software (DE-UZ 215) existieren bereits zwei etablierte Ansätze, um Umweltwirkungen von Software sichtbar zu machen. NADIKI verfolgt ein anderes Ziel: eine kontinuierliche, infrastrukturnahe Zurechnung realer Umweltwirkungen — inklusive grauer Emissionen, Mehrfachindikatoren und produktiver versus nicht-produktiver Nutzung — bis hinunter auf die einzelne Workload oder das einzelne KI-Modell. Dieser Beitrag stellt die drei Ansätze gegenüber, zeigt die methodischen Lücken aller Beteiligten und skizziert, wie sich NADIKI, SCI und Blauer Engel sinnvoll ergänzen können.
Dieser Methodenvergleich ist Teil unserer Arbeit im NADIKI-Projekt.
Einleitung
Die Debatte um die Umweltwirkung von Software und KI hat in den vergangenen Jahren zwei wichtige Bezugspunkte hervorgebracht. Der Software Carbon Intensity Standard der Green Software Foundation, seit 2024 als ISO/IEC 21031:2024 international standardisiert, definiert eine einheitliche Kennzahl für die CO₂-Intensität von Software. Der Blaue Engel für Software (DE-UZ 215) wiederum ist das weltweit erste staatliche Umweltzeichen für Software-Produkte — vergeben durch das Umweltbundesamt und die RAL gGmbH auf Basis der Forschungsarbeit des Öko-Instituts.
Beide Ansätze sind wichtige Meilensteine. Sie unterscheiden sich jedoch in Zielsetzung, Methodik und Reichweite — und keiner von beiden adressiert vollständig das, was wir im NADIKI-Projekt zu beantworten versuchen: Wie groß ist die tatsächliche, kontinuierlich gemessene Umweltwirkung einer Software-Applikation oder eines KI-Dienstes — entlang der gesamten Wertschöpfungskette, vom Rechenzentrumsgetäude bis zur einzelnen Workload, und wie ordnet man diese Wirkung dem Verantwortlichen zu, der sie auch wirklich steuern kann?
Dieser Vergleich verfolgt deshalb zwei Ziele. Erstens soll er zeigen, wo NADIKI bestehende Standards methodisch erweitert. Zweitens soll er offenlegen, an welchen Stellen NADIKI selbst noch unvollständig ist und wo der Blaue Engel oder SCI nach wie vor stärker oder breiter aufgestellt sind. Das Ergebnis ist eine Einordnung der drei Ansätze, welche unterschiedliche Funktionen erfüllen.
Die drei Ansätze im Überblick
NADIKI ist eine infrastruktur- und workload-zentrierte Mess- und Bilanzierungsmethodik. Sie wurde im Rahmen des gleichnamigen Forschungsprojekts entwickelt und kombiniert eine Observer-Architektur in Rechenzentren mit einer offenen Datenpipeline, die reale Strom-, Hardware- und Gebäudedaten zu kumulativen Umweltwirkungskonten pro Entität verdichtet. Jede Entität in der Wertschöpfungskette — Rechenzentrumsgetäude, Rack, Server, digitale Ressource, Workload — führt ein eigenes Konto mit produktiven und nicht-produktiven Unterposten. Ziel ist nicht ein Label, sondern ein technisches Buchhaltungssystem für digitale Infrastruktur, das sich an Betreiber, Cloud-Anbieter, KI-Plattformen und Applikationsverantwortliche richtet.
Software Carbon Intensity (SCI) ist eine Kennzahl, kein vollständiges Bilanzierungssystem. SCI = (E × I) + M, pro funktionaler Einheit R. Dabei steht E für den Energieverbrauch einer Software-Instanz, I für die regionale CO₂-Intensität des verwendeten Stroms, M für die grauen Emissionen der Hardware (anteilig zugerechnet), und R für die „funktionale Einheit“ — also etwa eine API-Anfrage, ein verarbeitetes Bild oder einen Nutzer pro Monat. SCI ist seit 2024 als ISO/IEC 21031:2024 standardisiert und liefert einen vergleichbaren Pro-Einheit-Wert in gCO₂eq pro R.
Der Blaue Engel für Software (DE-UZ 215) ist ein Umweltzeichen für Software-Produkte. Vergeben wird er auf Basis dreier Kriterien: Ressourceneffizienz (gemessen über einen Referenzrechner und ein definiertes Nutzungsszenario), Nutzungsautonomie (Abwärtskompatibilität, Deinstallierbarkeit, Offlinefähigkeit, Werbefreiheit, Modularität) und Transparenz und Nutzerfreundlichkeit (offene Dokumentation, offene Datenformate, Energiebedarfsangabe). Der ursprüngliche Fokus auf „Software-Produkte für Desktop-Computer“ wurde in jüngeren Überarbeitungen schrittweise erweitert; mobile und serverseitige Software stehen in der Diskussion, sind aber methodisch noch nicht im selben Reifegrad abgedeckt.
Schon an dieser Kurzbeschreibung wird der grundlegende Unterschied deutlich: SCI ist eine Intensitätskennzahl, der Blaue Engel ist ein produktbezogenes Label, NADIKI ist ein infrastrukturnahes Bilanzierungssystem mit kumulativer Konten-Logik. Sie spielen also in verschiedenen Ligen, auch wenn sie demselben übergeordneten Ziel dienen.
Vergleichstabelle
Die folgende Übersicht stellt die drei Ansätze entlang elf methodischer Dimensionen gegenüber. Sie ist bewusst zugespitzt — wir zeigen, was jeder Ansatz im Kern leistet, nicht jede Randvariante.
Dimension | NADIKI | SCI (ISO/IEC 21031:2024) | Blauer Engel (DE-UZ 215) |
|---|---|---|---|
Zweck / Anwendungsfall | Kontinuierliche Bilanzierung von Infrastruktur- und Workload-Wirkungen; operative Optimierung | Vergleichbare Intensitätskennzahl pro funktionaler Einheit; Software-Vergleich | Kennzeichnung ressourceneffizienter Software-Produkte für Endkunden und Beschaffung |
Ausgabeformat | Kumulative Umweltwirkungskonten pro Entität (Facility, Rack, Server, Ressource, Workload); Mehrindikatoren-Vektor | Eine Zahl: gCO₂eq pro R (funktionale Einheit) | Ja/Nein-Zertifikat plus Begleitdokumentation |
Indikatoren (CO₂, Energie, Multi-Kriterien) | Mehrindikatoren: THG, abiotische Ressourcen, Wasser, Abfall (WEEE), Versäuerung, Eutrophierung u. a. | Ausschließlich CO₂-Äquivalente | Primär Energieverbrauch und Hardware-Anforderungen; CO₂ indirekt; weitere Kriterien (Autonomie, Transparenz) nicht-physisch |
Graue Emissionen (Embodied) | Explizit modelliert; LCA/EPD-basiert, mit Boavizta-API als Standardannahme; auf Workload zugerechnet | Im Wert M enthalten, Methodik der Zurechnung jedoch dem Anwender überlassen | Nicht direkt; nur indirekt über Hardware-Effizienzanforderung an den Referenzrechner |
Betriebsemissionen (Operational) | Reale stündliche Messung; Stromverbrauch mal echter regionaler CO₂-Intensität (Electricity Maps) | E × I; I kann regional sein oder Standardwert; E aus Messung oder Modell | Aus Strommessung im definierten Nutzungsszenario; Strommix als Durchschnittswert |
Zuordnungslogik (Allokation) | Anteilig pro digitalem Ressourcentyp (CPU 65 %, Memory 20 %, Storage 10 %, Network 5 % für Operational; eigene Schlüssel für Embodied); kumulative Konten; Reservierung vs. Nutzung | Nach SCI-Spezifikation: pro funktionaler Einheit; konkrete Aufteilung dem Anwender überlassen | Pro Software-Produkt im Referenzszenario, ohne Auflösung nach Workload oder Multi-Tenant |
Erneuerbare Energie | Nur physisch belegte Erzeugung (vor Ort oder ≤ 50 km PPA) wird mit reduziertem Faktor verbucht; Grünstromzertifikate werden bewusst nicht akzeptiert | „Marktbasiert“ zulässig — Zertifikate können I drücken; ortsbasiert ist Empfehlung, aber kein Muss | Strommix-Durchschnitt im Szenario; keine Anrechnung individueller Beschaffung |
KI und Cloud-native Anwendungen | Kernfokus: Workload-Ebene, Kubernetes-Pods, virtuelle Maschinen, Multi-Tenant; KI-Training und -Inferenz explizit adressiert | Im Prinzip anwendbar; konkrete Methodik für KI-Wertschöpfungsketten (Training, Fine-Tuning, Inferenz) noch im Entstehen | Bisher nicht abgedeckt; mobile und serverseitige Erweiterung in Vorbereitung |
Verifizierung / Prüfung | Datenpipeline open source; Prüfbarkeit basiert auf nachvollziehbaren Rohdaten und reproduzierbarem Berechnungsmodell; keine akkreditierte Drittprüfung etabliert | ISO-Standard, aber selbstgemeldete Werte; Auditierung nicht institutionalisiert | Akkreditierte Drittprüfung durch RAL gGmbH; klar geregelter Vergabeprozess |
Produktive vs. nicht-produktive Nutzung | Zentrale Unterscheidung: jedes Konto hat zwei Unterkonten; Leerlauf, Überreservierung und Verschwendung werden explizit sichtbar | Nicht vorgesehen; SCI ist ein Brutto-Intensitätsmaß | Nicht vorgesehen; Effizienz wird im definierten Szenario gemessen |
Vergleichbarkeit über Systeme hinweg | Hoch auf Infrastrukturebene; auf Applikationsebene anspruchsvoll, weil funktionale Einheit nicht fixiert | Hoch innerhalb derselben funktionalen Einheit; sehr eingeschränkt zwischen unterschiedlichen R | Hoch innerhalb derselben Produktkategorie; sonst nicht direkt vergleichbar |
Wo NADIKI weitergeht
Die offensichtlichste Erweiterung gegenüber SCI und Blauem Engel ist die vertikale Tiefe. NADIKI bilanziert nicht nur die Software, sondern explizit auch die darunterliegende Infrastruktur: das Gebäude mit seinem LCA, das Rack mit PDUs und USV, den Server mit grauen Emissionen aus der Herstellung, und die digitalen Ressourcen, die der Server in Form von Compute, Storage und Network bereitstellt. Erst aus diesen Konten leitet NADIKI die Wirkung einer Applikation oder eines KI-Modells ab. Damit lassen sich Fragen beantworten, die SCI und Blauer Engel methodisch nicht stellen: Wie groß ist der Anteil des Rechenzentrumsgetäudes an einem KI-Trainingslauf? Welcher Teil der Wirkung einer Inferenz-API entsteht durch ungenutzte Reservierungen?
Die zweite zentrale Erweiterung ist die Unterscheidung von produktiver und nicht-produktiver Wirkung. Diese Logik existiert in keinem der beiden anderen Ansätze. Sie ist betriebswirtschaftlich und ökologisch hochrelevant: Ein Server, der zu 80 % im Leerlauf läuft, verursacht — gemessen über kumulative Konten — bezogen auf seine produktive Leistung ein Vielfaches der Wirkung eines gut ausgelasteten Servers. SCI kann dies allenfalls indirekt sichtbar machen, indem die funktionale Einheit R groß genug skaliert wird. Der Blaue Engel adressiert es gar nicht.
Drittens nutzt NADIKI reale, ortsbasierte Strommix-Daten statt marktbasierter Instrumente. Wir lehnen Grünstromzertifikate als Bilanzierungsgrundlage bewusst ab, da sie für operative Entscheidungen — Lastverschiebung, Abschaltung, regionaler Workload-Shift — wertlos sind. Ein „100 % grünes“ Rechenzentrum, das im konkreten Moment Strom aus einem kohlelastigen Netz zieht, würde unter SCI bei marktbasierter Anwendung mit I = 0 in die Rechnung gehen. NADIKI lässt das nicht zu. Der Blaue Engel arbeitet mit Durchschnittswerten und vermeidet diese spezifische Falle ebenfalls — allerdings ohne den temporalen und regionalen Auflösungsgrad, den NADIKI über Electricity Maps liefert.
Viertens ist NADIKI ein Multi-Indikatoren-System. SCI ist auf CO₂-Äquivalente beschränkt, der Blaue Engel betrachtet Energie und Hardware-Anforderungen. NADIKI führt explizit weitere Wirkungsindikatoren mit: abiotischer Ressourcenverbrauch, Wasserverbrauch, Elektroschrott (WEEE), Versäuerungs- und Eutrophierungspotenzial. Gerade für KI-Infrastruktur — wo Wasserverbrauch zur Kühlung und seltene Erden in Beschleunigern relevant sind — ist die Engführung auf CO₂ eine substantielle methodische Schwäche, die NADIKI adressiert.
Fünftens ist NADIKI kontinuierlich und kumulativ. Die Methodik geht nicht von einem „Messlauf im Referenzszenario“ (Blauer Engel) oder einem „Wert pro funktionaler Einheit“ (SCI) aus, sondern führt fortlaufende Konten über den gesamten Lebenszyklus der Applikation. Wirkung ist nicht reversibel — verbrauchte Energie, emittiertes CO₂, verbauter Stahl bleiben verbucht. Diese Buchhaltungslogik macht Optimierungseffekte sichtbar als Veränderung der Kumulationsgeschwindigkeit, nicht als nachträgliche Korrektur einer Kennzahl.
Schließlich ist NADIKI explizit für Cloud-native und KI-Workloads konzipiert. Hypervisor, Container-Orchestrierung, Multi-Tenancy, verteilte Workloads über mehrere Rechenzentren — all das ist Teil des Modells, nicht ein nachträglicher Anbau. SCI lässt diese Ebene konzeptionell offen; der Blaue Engel hat sie bisher kaum erschlossen.
Stärken von SCI und Blauer Engel
Es wäre methodisch unredlich, hier zu suggerieren, NADIKI sei einfach „besser“. Beide Vergleichsansätze leisten Dinge, die NADIKI in dieser Form nicht leistet — und teilweise auch nicht leisten kann oder will.
SCI hat seinen großen Vorteil in der Einfachheit und Standardisierung. Eine einzelne Zahl pro funktionaler Einheit ist für Kommunikation, Vergleich und Reporting extrem nützlich. SCI lässt sich in CI/CD-Pipelines integrieren, als KPI im Engineering-Team führen und in Marketing-Materialien zitieren. Die ISO-Standardisierung gibt der Kennzahl internationale Legitimität und reduziert den Definitionsstreit. NADIKI hat dem nichts Vergleichbares entgegenzusetzen: Unsere Mehrindikatoren-Konten sind methodisch reicher, aber sie sind nicht in einer einzigen Zahl zusammenfassbar — und sollten es nach unserer Überzeugung auch nicht sein.
Der Blaue Engel wiederum hat zwei Stärken, die wir explizit anerkennen müssen. Erstens die akkreditierte Drittprüfung durch RAL gGmbH. Ein Blauer-Engel-Zertifikat ist nicht selbstgemeldet, sondern formal geprüft. Dieses Element der externen Verifikation fehlt sowohl bei SCI als auch bei NADIKI. Für regulatorische Anwendungen, öffentliche Beschaffung und Verbraucherschutz ist Drittprüfung unverzichtbar — und NADIKI hat hier methodisch noch keine institutionelle Antwort.
Zweitens betrachtet der Blaue Engel nicht nur physische Umweltwirkung, sondern auch Eigenschaften, die mittelbar die Nutzungsdauer und damit den ökologischen Fußabdruck beeinflussen: Abwärtskompatibilität mit älterer Hardware, Deinstallierbarkeit, Offline-Fähigkeit, Modularität, Werbefreiheit, offene Datenformate. Diese Kriterien sind ökologisch hochrelevant — denn die längste Nutzungsdauer von Endgeräten ist oft der wirksamste Hebel überhaupt. NADIKI hat hier eine echte Leerstelle. Wir messen, was an der Infrastruktur passiert, sagen aber nichts über die Software-Architektur selbst aus, die diese Infrastruktur in Anspruch nimmt.
Offene Fragen und Lücken in NADIKI
Im Geist einer ehrlichen Standortbestimmung wollen wir die methodischen Lücken in NADIKI klar benennen.
Erstens: Die funktionale Einheit fehlt. NADIKI liefert die Wirkung pro Applikation oder Workload über einen Zeitraum, aber nicht „pro Inferenz“, „pro generiertem Token“, „pro API-Aufruf“. Diese Aggregationsschicht ist genau das, was SCI leistet. Wer NADIKI-Daten für ein Pro-Anfrage-Reporting nutzen will, muss die Brücke zur funktionalen Einheit selbst schlagen — wir liefern die Rohdaten, nicht die Kennzahl. Eine SCI-Kompatibilitätsschicht über NADIKI-Konten ist denkbar und wäre ein logischer nächster Entwicklungsschritt.
Zweitens: Refurbished Hardware und Sekundärnutzung sind unzureichend modelliert. Unser Standardansatz verteilt graue Emissionen linear über eine angenommene Nutzungsdauer (Server fünf Jahre, Gebäude und Rack 15 Jahre). Wenn ein Server in einen zweiten Lebenszyklus geht oder Komponenten getauscht werden, ist die richtige Allokation methodisch offen. Der Blaue Engel ist hier mit seiner Hardware-Abwärtskompatibilitätsanforderung indirekt voraus.
Drittens: Keine institutionalisierte Drittprüfung. NADIKI ist als methodisches und technisches System offen — die Datenpipeline ist nachvollziehbar, die Berechnungen sind reproduzierbar, der Quellcode liegt offen. Aber wir haben keinen RAL-gGmbH-Äquivalent, der ein NADIKI-Reporting prüft und zertifiziert. Für die Skalierung in regulatorische Kontexte ist das eine echte Lücke, die nicht allein durch Open-Source-Code geschlossen werden kann.
Viertens: Netzwerkinfrastruktur ist bisher ausgeklammert. Netzwerkausrüstung außerhalb des einzelnen Servers (Switches, Router, Backbone-Infrastruktur, Internet-Übertragung) ist in unserem aktuellen Modell nicht erfasst. Für client-seitige Anwendungen — Streaming, Cloud-Gaming, mobile KI-Inferenz — ist das eine erhebliche Vereinfachung.
Fünftens: Der Anteil der Software-Architektur selbst. Wir messen, wie viel Infrastruktur eine Applikation in Anspruch nimmt, aber wir bewerten nicht, ob ein Algorithmus prinzipiell ressourceneffizient designt ist. Eine schlecht implementierte Suche, die zehnmal mehr CPU-Zeit verbraucht als nötig, schlägt in NADIKI als zehnfacher Verbrauch durch — wir sagen aber nicht, dass eine bessere Implementierung existiert. SCI macht diesen Vergleich über die funktionale Einheit zumindest sichtbar, der Blaue Engel über das Referenzrechner-Szenario.
Sechstens: Endgeräte und Client-seitige Wirkung sind unterentwickelt. NADIKI ist primär eine Methodik für die serverseitige und Rechenzentrumsseite. Die Wirkung auf Endgeräten — vom Smartphone-Akku, der bei einer ineffizienten App schneller leidet, bis zum Laptop, der wegen einer ressourcenhungrigen Anwendung früher ersetzt werden muss — ist genau das Feld, in dem der Blaue Engel ursprünglich entstanden ist.
Positionierung: Wie NADIKI, SCI und Blauer Engel zusammenpassen
Die ehrlichste Schlussfolgerung aus diesem Vergleich ist nicht, dass einer der drei Ansätze gewinnt, sondern dass sie unterschiedliche Schichten desselben Problems abdecken und sich produktiv ergänzen können.
NADIKI funktioniert am besten als Infrastruktur-Buchhaltungsschicht. Die Methodik liefert die Rohdaten und die kumulativen Konten, aus denen sich höherwertige Kennzahlen ableiten lassen — pro Workload, pro Container, pro KI-Modell, pro Cloud-Region. Sie ist die Schicht, auf der Betreiber, Cloud-Anbieter und Plattformverantwortliche operative Entscheidungen treffen: Welcher Workload läuft wo? Wann wird welche Hardware ausgetauscht? Wie groß ist die nicht-produktive Verschwendung in unserem Cluster?
SCI ist die natürliche Aggregationsschicht für Applikationsentwicklung und Software-Reporting. Wer eine API anbietet, ein SaaS-Produkt betreibt oder ein KI-Modell als Service vermarktet, will eine Zahl pro funktionaler Einheit. NADIKI-Konten lassen sich grundsätzlich zu SCI-konformen Werten verdichten — sofern die funktionale Einheit sauber definiert ist und die Allokation der nicht-produktiven Anteile transparent erfolgt. Eine NADIKI-zu-SCI-Brücke ist methodisch möglich und wäre ein sinnvoller Beitrag zur Standardlandschaft. Wir betrachten die ISO/IEC 21031-Kompatibilität deshalb als realistisches Zwischenziel — nicht als Konkurrenz, sondern als Schnittstelle.
Der Blaue Engel ist ideal als produktbezogenes Verbraucher- und Beschaffungslabel. Seine Stärke liegt im akkreditierten Vergabeverfahren und in der Berücksichtigung software-architektureller Eigenschaften, die NADIKI methodisch nicht abdeckt. Die spannende Frage ist, ob ein „Blauer Engel für cloud-native Software“ oder ein „Blauer Engel für KI-Dienste“ eine sinnvolle Weiterentwicklung wäre. Wir glauben: ja. Und wir glauben, dass NADIKI eine geeignete methodische Grundlage liefern könnte, um die infrastrukturseitige Effizienzmessung in einem solchen erweiterten Zeichen zu fundieren. Heute scheitert die Übertragung des Blauen Engels auf cloud-native Software an exakt der Stelle, an der NADIKI Antworten liefert: Wie misst man Ressourceneffizienz in einer Umgebung, in der die „Software“ über zehn Pods auf drei Servern in zwei Rechenzentren verteilt ist?
Eine plausible Arbeitsteilung könnte deshalb so aussehen:
NADIKI liefert die infrastrukturnahe, kontinuierliche Bilanzierung mit Multi-Indikator-Daten und der Trennung produktiv/nicht-produktiv. Adressaten sind Betreiber, Cloud-Anbieter, KI-Plattformen und Applikationsteams im operativen Betrieb.
SCI liefert die standardisierte Aggregation auf funktionale Einheiten für Software-Reporting, Vergleich zwischen Versionen und Engineering-KPIs. Adressaten sind Produktteams, Engineering, Sustainability-Reporting.
Blauer Engel liefert das geprüfte Endkunden- und Beschaffungslabel mit Berücksichtigung architektureller Nachhaltigkeitsmerkmale. Adressaten sind Verbraucherinnen und Verbraucher, öffentliche Beschaffung, Regulierung.
Was fehlt heute, sind die Brücken zwischen diesen Schichten — und genau hier sehen wir die nächste methodische Aufgabe. Eine NADIKI-zu-SCI-Schnittstelle, ein Blauer-Engel-Modul für serverseitige und cloud-native Software, eine institutionalisierte Prüfschicht für NADIKI-Reporting: Das sind die offenen Baustellen, an denen sich die Standardlandschaft in den kommenden Jahren bewähren muss.
Wir verstehen NADIKI deshalb nicht als Ersatz, sondern als das fehlende Stück Infrastruktur-Buchhaltung, das die beiden bestehenden Ansätze brauchen, um in der Welt der Cloud- und KI-Workloads voll wirksam zu werden. Und gleichzeitig erkennen wir an, dass NADIKI ohne Anschluss an SCI und ohne ein Pendant zur Drittprüfung des Blauen Engels nur die halbe Strecke geht. Die nächsten Schritte des Projekts werden genau diese Brücken adressieren.