Die Antwort zuerst: Ein KI-Pilot braucht mehr als einen Modellnamen
Stadtwerke testen KI zunehmend in Wissenssuche, Dokumentenklassifikation, Kundenservice, Datenprüfung oder interner Assistenz. In Projektübersichten steht dann häufig nur der Name eines Modells oder Dienstes. Das reicht für einen prüfbaren Betrieb nicht aus. Eine KI-Anwendung besteht aus mehreren Komponenten: Modell und Version, Systemanweisung, Datenquellen, Suchindex, Werkzeuge, Schnittstellen, Laufzeitumgebung, Filter, Protokollierung und menschliche Freigabepunkte. Ein AI-SBOM, also ein Komponentenverzeichnis für KI, macht diese Abhängigkeiten sichtbar.
Eine gemeinsame G7-Handreichung unter Beteiligung des Bundesamts für Sicherheit in der Informationstechnik beschreibt Mindestelemente einer Software Bill of Materials für KI. Das Dokument versteht sich als praktische Empfehlung und nicht als neue verbindliche Vorgabe. Für Stadtwerke ist gerade dieser Charakter nützlich: Die Elemente können als Ausgangspunkt für eine schlanke Inventarroutine dienen, bevor ein Pilot in einen regulären Fachprozess hineinwächst.
KI ist eine Lieferkette, kein einzelnes Werkzeug
Bei klassischer Software ist die Idee eines Komponentenverzeichnisses etabliert: Wer Abhängigkeiten kennt, kann Versionen, Schwachstellen und Änderungen besser bewerten. KI erweitert diese Sicht. Ein Modell kann über eine Programmierschnittstelle bezogen, mit einer bestimmten Systemanweisung gesteuert, durch Dokumente angereichert und mit Werkzeugen verbunden werden. Das sichtbare Ergebnis entsteht aus dem Zusammenspiel dieser Teile.
Daraus folgt eine einfache Regel: Der Modellname allein erklärt weder Herkunft noch Verhalten des Gesamtsystems. Zwei Anwendungen mit demselben Basismodell können wegen anderer Datenquellen, Prompts, Werkzeuge oder Filter völlig unterschiedliche Risiken und Ergebnisse haben. Umgekehrt kann ein Modellwechsel unkritisch sein, wenn die Aufgabe eng begrenzt, der Prüfpfad stabil und die Ausgabe nur ein unverbindlicher Vorschlag bleibt. Das Komponentenverzeichnis schafft die Grundlage für diese Unterscheidung.
Acht Felder reichen für eine erste Version
Ein Stadtwerk kann mit acht Feldern beginnen. Erstens: eindeutiger Name und Zweck der KI-Anwendung. Zweitens: verantwortliche Fachrolle und technische Betriebsrolle. Drittens: verwendetes Modell, Anbieter und Version, soweit verfügbar. Viertens: Herkunft und Freigabestatus der Datenquellen. Fünftens: verbundene Werkzeuge und Schnittstellen. Sechstens: Regeln für Eingaben, Ausgaben und Protokollierung. Siebtens: menschliche Prüf- und Freigabepunkte. Achtens: Stand, Änderungsdatum und nächster Review.
Diese Felder beschreiben noch keine vollständige Sicherheitsarchitektur. Sie beantworten jedoch die wichtigsten Betriebsfragen: Was ist im Einsatz? Wofür? Mit welchen Daten? Wer ist verantwortlich? Welche Aktion darf das System auslösen? Wann wurde die Zusammensetzung zuletzt geprüft? Fehlt eine Antwort, ist das kein Grund, das Feld mit einer Vermutung zu füllen. Unbekannt ist ein valider Status und zugleich ein klarer Arbeitsauftrag.
Datenquellen brauchen Herkunft und Gültigkeitsgrenze
Bei wissensgestützten KI-Anwendungen entscheidet die Datenbasis oft stärker über die Qualität als das Basismodell. Deshalb sollte jede Quelle mit Herkunft, Aktualisierungsrhythmus, Schutzklasse und fachlicher Gültigkeitsgrenze erfasst werden. Eine öffentliche FAQ kann für allgemeine Erklärungen geeignet sein, aber nicht automatisch für eine individuelle Prozessentscheidung. Ein internes Handbuch kann fachlich hochwertig und dennoch veraltet sein. Ein Ticketarchiv kann reale Fehlerbilder enthalten, aber auch personenbezogene oder vertrauliche Angaben.
Das Verzeichnis sollte deshalb nicht nur Links sammeln. Es muss sichtbar machen, wer eine Quelle kuratiert, wann sie zuletzt geprüft wurde und welche Aussagen daraus nicht abgeleitet werden dürfen. Diese Negativgrenze ist für Stadtwerke besonders wichtig. Eine KI kann Informationen zusammenfassen oder Prüffragen vorschlagen, ohne damit eine rechtliche, regulatorische oder betriebliche Freigabe zu erteilen.
Werkzeuge verändern die Risikoklasse
Ein Chat, der ausschließlich auf freigegebene Dokumente verweist, hat einen anderen Wirkungsradius als ein Agent, der E-Mails versendet, Daten ändert oder technische Systeme ansteuert. Im AI-SBOM müssen Werkzeuge deshalb als eigene Komponenten erscheinen. Für jedes Werkzeug gehören erlaubte Aktionen, benötigte Berechtigungen, Freigabepunkt und Rückfallweg dokumentiert.
Die wichtigste Grenze lautet: Lesen, vorschlagen und ausführen sind unterschiedliche Betriebsarten. Ein Pilot kann mit lesendem Zugriff beginnen und strukturierte Vorschläge erzeugen. Externe Kommunikation, Stammdatenänderungen oder produktive Schaltungen brauchen eigene Kontrollen und eindeutige Autorisierung. Das Komponentenverzeichnis macht sichtbar, wenn ein zunächst harmloser Assistent durch ein neues Werkzeug plötzlich eine andere Wirkungsklasse erreicht.
Versionen machen Änderungen prüfbar
Die G7-Handreichung betont unter anderem Versionierung und Zeitstempel. Für den Stadtwerke-Alltag bedeutet das: Jede wesentliche Änderung an Modell, Prompt, Datenquelle, Werkzeug oder Prüfregel braucht einen neuen dokumentierten Stand. Nur so lässt sich später erklären, welche Zusammensetzung ein bestimmtes Ergebnis erzeugt hat.
Das heißt nicht, jede Textkorrektur wie eine große Softwarefreigabe zu behandeln. Sinnvoll ist eine abgestufte Änderungslogik. Redaktionelle Klarstellungen können als kleine Änderung gelten. Eine neue Datenquelle, ein anderes Modell oder ein zusätzliches Werkzeug verlangt eine fachliche Prüfung. Eine Erweiterung um externe oder produktive Aktionen braucht einen gesonderten Freigabepfad. Wichtig ist, dass diese Klassen vorab definiert sind und nicht erst nach einem Fehler diskutiert werden.
Das Verzeichnis unterstützt Einkauf und Betrieb zugleich
Ein AI-SBOM ist nicht nur ein Dokument für IT-Sicherheit. Der Einkauf erkennt, welche externen Dienste und Unterauftragnehmer für einen Prozess relevant sind. Datenschutz und Informationssicherheit sehen Datenwege und Speicherorte. Der Fachbereich erkennt Quellen und Nicht-Ziele. Der Betrieb erhält Ansprechpartner, Versionen und Rückfallwege. Die Geschäftsführung kann sehen, welche Piloten tatsächlich in kritische Prozesse hineinreichen.
Damit wird das Verzeichnis zu einer gemeinsamen Sprache. Es verhindert nicht jedes Risiko und ersetzt keine Fachprüfung. Es reduziert aber die Abhängigkeit von Einzelwissen. Wenn eine verantwortliche Person ausfällt oder ein Anbieter eine Komponente ändert, bleibt sichtbar, welche Prozesse betroffen sind und wer die Auswirkung bewerten muss.
Ein 30-Tage-Einstieg für bestehende Piloten
In der ersten Woche werden alle aktiven KI-Piloten mit Zweck und Verantwortlichen erfasst. In der zweiten Woche ergänzt jedes Team Modell, Datenquellen und Werkzeuge. In der dritten Woche werden menschliche Freigaben, Protokollierung und Nicht-Ziele geprüft. In der vierten Woche folgt ein gemeinsamer Review: Welche Einträge sind vollständig, welche Komponenten unbekannt, welche Piloten haben inzwischen einen größeren Wirkungsradius als ursprünglich angenommen?
Das Ergebnis sollte anfangs bewusst kompakt bleiben. Eine Tabelle oder strukturierte Datei kann genügen, wenn Versionierung, Eigentümerschaft und Reviewtermin verlässlich sind. Automatisierung ist erst der zweite Schritt. Zuerst muss das Stadtwerk wissen, welche Komponenten fachlich relevant sind.
KI-Governance wird oft als Sammlung abstrakter Prinzipien diskutiert. Ein AI-SBOM übersetzt einen Teil davon in eine konkrete Betriebsfrage: Woraus besteht unser System heute? Wer diese Frage jederzeit beantworten kann, schafft eine belastbare Grundlage für sichere und nachvollziehbare Automatisierung.