Ich kenne den Einwand schon, weil ich ihn mir selbst mache, jedes Mal, wenn ich das Wort Inventar höre. Noch ein Register. Noch ein Dokument, das jemand im Januar gewissenhaft ausfüllt und das im März schon Archäologie ist, weil das Team inzwischen zwei Abhängigkeiten ausgetauscht hat, ein Lieferant seine Vertragsbedingungen aktualisiert hat und jemand ein Modell in Produktion gebracht hat, das im Register nicht existiert. Wenn das das Versprechen ist, dann ist das Inventar nur die alte Bürokratie mit einem technischeren Namen, und wer es vorschlägt, verkauft das Problem, verkleidet als Lösung.
Der Einwand ist richtig. Und genau deshalb lohnt es sich, diesen Text zu schreiben, denn er beschreibt perfekt eine bestimmte Art, Inventar zu führen, die von Hand gepflegte, die von Anfang an tot ist. Aber diese Art mit der Idee des Inventars selbst zu verwechseln heißt, nicht zu sehen, was in der europäischen Regulierung geschieht, wo fünf verschiedene Rechtstexte, geschrieben von verschiedenen Generaldirektionen, für verschiedene Sektoren, auf dieselbe Forderung zulaufen, ohne sich abgesprochen zu haben.
Fünf Texte, ein einziger Satz
Der AI Act verlangt ein Register der Systeme, eine Klassifizierung des Risikos, eine Nachvollziehbarkeit der Trainingsdaten und der Entscheidungen. Der Cyber Resilience Act verlangt eine Stückliste der Software, die berühmte SBOM, und die Fähigkeit, schnell zu sagen, welche Produkte eine verwundbare Komponente enthalten. NIS2 verlangt, die eigene Lieferkette zu kennen und Vorfälle mit Meldefristen zu steuern, die voraussetzen, dass man schon weiß, wo man hinschauen muss. DORA, das zur Finanzwelt spricht, aber das Muster bestätigt, verlangt ein Register der Abhängigkeiten von kritischen ICT-Dienstleistern. Die Produkthaftungsrichtlinie verschiebt in ihrer neuen Fassung die Beweislast so, dass ein Hersteller, der nicht rekonstruieren kann, was zu einem bestimmten Datum in seiner Software steckte, schon als Verlierer antritt. Wie wir hierher gekommen sind, ausgehend von einer Flasche Ginger Beer aus dem Jahr 1932, habe ich in Die letzte Flasche von Mrs Donoghue erzählt.
Es sind verschiedene Sprachen. Register, SBOM, Kartierung, technische Dokumentation. Aber der Satz darunter ist ein einziger: Zeig, dass du weißt, was du im Haus hast. Welche Modelle, welche Komponenten, welche Lieferanten, welche Daten, welche Verantwortlichkeiten, welche Änderungen.
Nicht konform oder unregierbar
Und hier kommt der Punkt, der meiner Meinung nach systematisch missverstanden wird. Eine Organisation, die auf diese Fragen keine Antwort weiß, ist keine nicht konforme Organisation. Nicht konform ist, wer sein System kennt und sich entschieden hat, es nicht anzupassen, eine Position, die man verteidigen, verhandeln, heilen kann. Wer sein System nicht kennt, ist in einem anderen und schlimmeren Zustand: Er ist unregierbar. Er kann sich nicht einmal für die Konformität entscheiden, wenn er es wollte, weil er nicht weiß, worauf er die Entscheidung anwenden soll.
Die Strategie des Wartens
Unterdessen ist die verbreitetste Strategie, die mir begegnet, das Warten. Wir passen uns an, wenn die endgültige Leitlinie erscheint, wenn die nationale Behörde klärt, wenn der harmonisierte Standard kommt, wenn der Digital Omnibus den Kalender stabilisiert. Ich habe vor ein paar Wochen darüber geschrieben: Die Verschiebung der Fristen ist keine Amnestie, und wer sie so liest, verwechselt einen Aufschub mit einem Freispruch. Aber im Warten steckt ein tieferer Fehler, und das ist die Vorstellung, Konformität sei ein Inhalt, den uns früher oder später jemand diktieren wird, und unsere Aufgabe bestehe nur darin, ihn abzuschreiben. Die Leitlinien werden sagen, wie man das System beschreibt. Sie werden es nie an unserer Stelle beschreiben können. Und der schwierige Teil, der Monate braucht und die Grenzen zwischen den Teams durchquert, ist nicht das Abschreiben. Es ist zu wissen, was man schreiben soll.
Die Karte, die es nicht gibt
Ich sehe es in der täglichen Arbeit. Wenn wir in ein Projekt im Gesundheitswesen oder in der öffentlichen Verwaltung einsteigen, betrifft die erste Frage, die wir stellen, nie die Norm. Sie betrifft die Karte. Welche Anwendungen sind in Produktion, wer ist für sie verantwortlich, von welchen Bibliotheken hängen sie ab, wo liegen die Daten, welche Verarbeitungen wurden bewertet, welche Verträge decken welche Lieferanten ab, was hat sich in den letzten sechs Monaten geändert. Die ehrliche Antwort, fast überall, lautet: Die Karte existiert nicht. Es existieren Fragmente: eine Tabelle der IT, zuletzt vor einem Jahr aktualisiert, ein Verzeichnis der Verarbeitungstätigkeiten, eingefroren auf der Version, die dem Berater übergeben wurde, das Gedächtnis von zwei Personen, die, wenn sie morgen den Job wechseln, die Hälfte der Architektur mitnehmen. Keines dieser Fragmente spricht mit den anderen, und keines wird von den Ereignissen aktualisiert, die es speisen müssten.
Das tote Register und das lebende Inventar
Hier kehrt der Einwand vom Anfang zurück, und hier löst er sich auf. Das Register, das in einer Schublade altert, und die Karte, die die europäische Compliance braucht, sind nicht dieselbe Sache, mit mehr oder weniger Sorgfalt gemacht. Es sind zwei Objekte verschiedener Natur. Das erste ist ein Dokument, das zweite ist ein Nebenprodukt der Prozesse. Eine SBOM füllt man nicht aus: Sie wird von der Build-Pipeline erzeugt, bei jedem Build, und wenn die Pipeline sie nicht erzeugt, liegt das Problem in der Pipeline, nicht im Willen der Menschen. Ein Register der KI-Systeme wird nicht aus dem Gedächtnis aktualisiert: Es wird aktualisiert, weil der Weg eines Modells in die Produktion durch das Register führt, und ein Modell, das nicht im Register steht, kommt schlicht nicht in Produktion. Ein Change Log ist kein Ritual: Es ist die Spur, die es erlaubt, wenn die Meldung einer Schwachstelle oder die Anfrage einer Behörde eintrifft, zu rekonstruieren, was da war und wann. Das lebende Inventar verlangt von den Menschen nicht, ans Dokumentieren zu denken. Es verlangt von der Architektur der Prozesse, Dokumentation als Nebeneffekt der normalen Arbeit zu erzeugen. Das ist ein Unterschied der Ingenieurskunst, nicht der Disziplin, und es ist dieselbe Idee, die ich einmal Compliance als Architektur genannt habe.
Die Funktion, die keinen Namen hat
Es gibt allerdings ein Problem, das die Ingenieurskunst allein nicht löst, und das ist, dass diese Karte Territorien durchquert, die in Organisationen verschiedene Eigentümer haben. Die SBOM lebt bei denen, die DevOps machen. Das Verzeichnis der Verarbeitungstätigkeiten lebt beim Datenschutzbeauftragten. Die Verträge mit den Lieferanten leben beim Einkauf oder bei der Geschäftsführung. Die Vorfälle leben bei denen, die Sicherheit machen, wenn es jemanden gibt, der Sicherheit macht. Das KI-Register, wo es existiert, lebt bei dem, der das Pech hatte, im falschen Meeting die Hand zu heben. Jedes dieser Teile hat einen Eigentümer, aber die Kohärenz zwischen den Teilen hat keinen. Das ist keine Figur, die man einstellen muss, und ich misstraue jedem, der sie als die x-te Rolle mit Akronym fürs Organigramm präsentiert. Es ist eine Funktion, die heute keinen Namen hat und in die Lücken fällt zwischen dem Datenschutzbeauftragten, der auf die personenbezogenen Daten schaut, dem CISO, der auf die Bedrohungen schaut, und dem CTO, der auf das Produkt schaut. Jemand muss die Stückliste der Software, das Register der KI-Systeme, die Folgenabschätzungen, die Verträge, das Change Log und die Geschichte der Vorfälle zusammenhalten, nicht um sie auszufüllen, sondern um zu garantieren, dass sie dasselbe System erzählen. In kleinen Organisationen wird das ein weiterer Hut auf einem Kopf sein, der schon andere trägt. In großen wird es ein Beruf werden, dessen Aufstieg ich schon beschrieben habe. In beiden Fällen wird, wer es gut macht, etwas in der Hand halten, das mehr wert ist als die Konformität: die operative Beschreibung des Unternehmens.
Die Spezifikation der Organisation
Und hier schließe ich den Kreis mit etwas, das ich über Softwareentwicklung geschrieben habe. In der spezifikationsgetriebenen Entwicklung wird der Code zu einem Derivat und die Spezifikation zum Asset: Sie ist es, die gepflegt, versioniert, diskutiert wird, während der Code sich regenerieren lässt. Die europäische Regulierung sagt, ohne es zu wissen, dasselbe eine Ebene höher. Der Aktenordner ist das Derivat. Das lebende Inventar ist die Spezifikation der Organisation, die gepflegte und versionierte Beschreibung, aus der sich die Konformitätsdokumente jedes Mal neu erzeugen lassen, wenn eine Norm, eine Behörde oder ein Kunde sie in einem neuen Format verlangt. Wer die Spezifikation hat, produziert den Ordner in Tagen. Wer nur Ordner hat, schafft es nicht einmal, die Spezifikation zu produzieren, und häuft, ohne es zu sehen, Spezifikationsschulden im Maßstab des Unternehmens an.
Was 2026 belohnen wird
Deshalb glaube ich, dass 2026 nicht die belohnen wird, die am besten ausfüllen. Fristen verschieben sich, Leitlinien kommen zu spät, harmonisierte Standards stehen noch großteils auf dem Papier, und dieser ganze Kalenderlärm verdeckt die eigentliche Auslese, die im Gang ist. 2026 wird die belohnen, die ihr System besser beschreiben können, als die anderen ihres beschreiben: den Kunden, die es in den Lastenheften verlangen, den Behörden, die es in den Inspektionen verlangen werden, und vorher noch sich selbst, wenn schnell zu entscheiden ist, was zu ändern ist. Compliance ist nur der bürokratische Name dieser Fähigkeit. Das Inventar ist ihr Werkzeug. Und kein Aufschub hat je ein System regierbar gemacht, das sein Eigentümer nicht erzählen kann.
Was du mitnimmst
Fünf europäische Regelwerke, geschrieben von verschiedenen Generaldirektionen für verschiedene Sektoren, laufen auf dieselbe Forderung zu, ohne sich abgesprochen zu haben: AI Act, CRA, NIS2, DORA und PLD verlangen alle, mit verschiedenen Worten, den Nachweis, dass du weißt, was du im Haus hast.
Nicht konform ist, wer sein System kennt und sich entschieden hat, es nicht anzupassen: eine Position, die man verteidigen, verhandeln, heilen kann. Wer sein System nicht kennt, ist unregierbar, und das ist schlimmer: Er kann sich nicht einmal für die Konformität entscheiden, wenn er es wollte.
Auf Leitlinien und harmonisierte Standards zu warten heißt, die Konformität mit einem Inhalt zu verwechseln, den man abschreiben kann. Die Leitlinien werden sagen, wie man das System beschreibt, sie werden es nie an unserer Stelle beschreiben. Der schwierige Teil ist nicht das Abschreiben, sondern zu wissen, was man schreiben soll.
Das Register, das in einer Schublade altert, und das lebende Inventar sind Objekte verschiedener Natur: Das erste ist ein Dokument, das zweite ein Nebenprodukt der Prozesse. Eine SBOM füllt man nicht aus, sie wird bei jedem Build von der Pipeline erzeugt. Das ist ein Unterschied der Ingenieurskunst, nicht der Disziplin.
Die Kohärenz zwischen SBOM, KI-Register, Folgenabschätzungen, Verträgen und Change Log hat keinen Eigentümer: Sie fällt in die Lücken zwischen Datenschutzbeauftragtem, CISO und CTO. Wer diese Funktion übernimmt, hält etwas in der Hand, das mehr wert ist als die Konformität: die operative Beschreibung des Unternehmens.
Fragen & Antworten
Warum verlangt die europäische Compliance ein Inventar?
Weil fünf verschiedene Rechtstexte auf dieselbe Forderung zulaufen. Der AI Act verlangt ein Register der Systeme, eine Klassifizierung des Risikos und die Nachvollziehbarkeit der Trainingsdaten. Der Cyber Resilience Act verlangt die SBOM und die Fähigkeit, schnell zu sagen, welche Produkte eine verwundbare Komponente enthalten. NIS2 verlangt, die eigene Lieferkette zu kennen und Vorfälle in Fristen zu melden, die voraussetzen, dass man schon weiß, wo man hinschauen muss. DORA verlangt ein Register der Abhängigkeiten von kritischen ICT-Dienstleistern. Die revidierte PLD verschiebt die Beweislast so, dass ein Hersteller, der nicht rekonstruieren kann, was zu einem bestimmten Datum in seiner Software steckte, schon als Verlierer antritt. Es sind verschiedene Sprachen, aber der Satz darunter ist ein einziger: Zeig, dass du weißt, was du im Haus hast.
Was ist der Unterschied zwischen nicht konform und unregierbar?
Nicht konform ist die Organisation, die ihr System kennt und sich entschieden hat, es nicht anzupassen: eine Position, die man verteidigen, verhandeln, heilen kann. Die Organisation, die ihr System nicht kennt, ist in einem anderen und schlimmeren Zustand: Sie ist unregierbar. Sie kann sich nicht einmal für die Konformität entscheiden, wenn sie es wollte, weil sie nicht weiß, worauf sie die Entscheidung anwenden soll. Die Unterscheidung zählt, weil die meisten Organisationen, die sich bei der Compliance im Rückstand glauben, nicht mit einer Pflicht im Rückstand sind: Ihnen fehlt die Karte, auf die jede Pflicht anzuwenden wäre.
Was ist ein lebendes Inventar, und worin unterscheidet es sich von einem klassischen Register?
Es sind Objekte verschiedener Natur, nicht dasselbe Objekt mit mehr oder weniger Sorgfalt gemacht. Das klassische Register ist ein Dokument: Jemand füllt es aus, dann ändert sich das System und das Dokument altert. Das lebende Inventar ist ein Nebenprodukt der Prozesse: Die SBOM wird bei jedem Build von der Build-Pipeline erzeugt, das Register der KI-Systeme wird aktualisiert, weil der Weg eines Modells in die Produktion durch das Register führt, das Change Log ist die Spur, die es erlaubt zu rekonstruieren, was da war und wann. Es verlangt von den Menschen nicht, ans Dokumentieren zu denken: Es verlangt von der Architektur der Prozesse, Dokumentation als Nebeneffekt der normalen Arbeit zu erzeugen.
Wer sollte im Unternehmen für das Inventar verantwortlich sein?
Jedes Teil hat schon einen Eigentümer: Die SBOM lebt bei denen, die DevOps machen, das Verzeichnis der Verarbeitungstätigkeiten beim Datenschutzbeauftragten, die Verträge beim Einkauf, die Vorfälle bei denen, die Sicherheit machen. Was keinen Eigentümer hat, ist die Kohärenz zwischen den Teilen, also die Garantie, dass sie alle dasselbe System erzählen. Das ist nicht zwingend eine Stelle, die man besetzen muss: In kleinen Organisationen wird es ein weiterer Hut auf einem Kopf sein, der schon andere trägt, in großen wird es ein Beruf werden. Es ist eine Funktion, die heute in die Lücken fällt zwischen dem Datenschutzbeauftragten, der auf die personenbezogenen Daten schaut, dem CISO, der auf die Bedrohungen schaut, und dem CTO, der auf das Produkt schaut.
Lohnt es sich, mit der Anpassung auf die endgültigen Leitlinien zu warten?
Nein, aus zwei Gründen. Der erste: Die Verschiebung der Fristen ist keine Amnestie, der Digital Omnibus hat ein paar Daten verschoben und alles Übrige bestätigt. Der zweite ist tiefer: Warten setzt voraus, dass Konformität ein Inhalt sei, den uns früher oder später jemand diktieren wird, und dass unsere Aufgabe nur darin bestehe, ihn abzuschreiben. Die Leitlinien werden sagen, wie man das System beschreibt, sie werden es nie an unserer Stelle beschreiben. Der Teil, der Monate braucht und die Grenzen zwischen den Teams durchquert, ist nicht das Abschreiben: Es ist zu wissen, was man schreiben soll. Und dieser Teil hat keine Frist, wird nicht verschoben und wird mit der Zeit nicht leichter.
Der Autor
