KI-Inventar erstellen: Vom Systemverzeichnis zum belastbaren Audit-Trail

Warum eine Liste allein nicht genügt

Viele KI-Inventare beginnen als Tabelle mit Produktname, Anbieter und Abteilung. Das ist ein sinnvoller Start, aber noch keine belastbare Arbeitsgrundlage. Die Liste sagt nicht, welchen Prozess das System unterstützt, welche Daten hineingehen, wer fachlich verantwortlich ist oder wie eine Änderung geprüft wird. Sobald ein Modell aktualisiert, eine neue Datenquelle verbunden oder ein Pilot in den Regelbetrieb überführt wird, verliert die Momentaufnahme an Aussagekraft.

Ein brauchbares Inventar verbindet deshalb drei Ebenen. Erstens die Identität des Systems: Was ist es und wo läuft es? Zweitens den betrieblichen Kontext: Wofür wird es eingesetzt, wer nutzt es und welche Verantwortung hängt daran? Drittens die Kontrollspur: Welche relevanten Ereignisse haben den aktuellen Zustand hervorgebracht?

Der Audit-Trail ist dabei kein Protokoll jeder technischen Kleinigkeit. Er dokumentiert Ereignisse, die für Zweck, Daten, Verantwortung, Risiko, Freigabe oder Status bedeutsam sind. Dadurch bleibt das Register lesbar und die Historie erklärt trotzdem, warum ein Eintrag heute so aussieht.

Zuerst den Gegenstand sauber abgrenzen

Bevor Felder definiert werden, muss klar sein, was im Unternehmen als inventarisierter Gegenstand gilt. Ein öffentliches Chatwerkzeug, eine integrierte Textfunktion im CRM, ein selbst betriebenes Modell und eine Automatisierung mit mehreren KI-Schritten können jeweils einen eigenen Eintrag benötigen. Entscheidend ist nicht der Markenname, sondern ob Nutzung, Datenfluss, Verantwortung oder Kontrolle eigenständig beurteilt werden müssen.

Auch Schattennutzung gehört in die Erhebung. Das Ziel ist nicht, Mitarbeitende mit einer Verbotsliste zu überraschen, sondern reale Nutzung sichtbar zu machen. Ein kurzer Erhebungsweg über Fachbereiche, Einkauf, IT, Datenschutz, Informationssicherheit und vorhandene SaaS-Listen liefert meist mehr als die Bitte, nur „KI-Tools“ zu melden. Fragen Sie nach Funktionen: Wo werden Texte generiert, Entscheidungen vorbereitet, Inhalte klassifiziert, Gespräche zusammengefasst oder Daten angereichert?

Mehrfachnennungen sind zunächst unproblematisch. Sie lassen sich später über Anbieter, Instanz, Prozess und Owner zusammenführen. Gefährlicher ist eine zu enge Definition, bei der eingebettete Funktionen oder selbst gebaute Automationen unsichtbar bleiben.

Ein Ereignis braucht mehr als einen Zeitstempel

Ein Audit-Trail wird erst verständlich, wenn jedes relevante Ereignis dieselbe kleine Beweisstruktur trägt. Dazu gehören der betroffene Eintrag, die Art der Änderung, alter und neuer Zustand, Anlass, handelnde oder freigebende Rolle, Zeitpunkt, Status und ein Verweis auf den Beleg. Der Beleg kann ein Testprotokoll, eine Freigabenotiz, ein Ticket, eine aktualisierte Arbeitsanweisung oder eine dokumentierte Entscheidung sein.

Der Trail sollte Tatsachen und Bewertung trennen. „Datenquelle CRM ergänzt“ ist eine Änderung. „Risiko akzeptabel“ ist eine Bewertung, die eine verantwortliche Rolle, Kriterien und einen Beleg braucht. Werden beide Ebenen in einem unstrukturierten Kommentarfeld vermischt, lässt sich später weder die technische Änderung noch die Entscheidung sauber nachvollziehen.

Korrekturen sollten frühere Einträge nicht unsichtbar überschreiben. Stattdessen erhält das Ereignis einen neuen Status oder einen verknüpften Korrektureintrag. So bleibt erkennbar, dass eine Information zunächst falsch oder unvollständig war und wie sie berichtigt wurde. Das stärkt die Verlässlichkeit mehr als eine scheinbar makellose Historie.

Verantwortung so modellieren, dass Arbeit möglich wird

„Die IT“ oder „das Fachteam“ sind selten ausreichende Besitzer. Für jeden Eintrag sollte mindestens klar sein, wer den geschäftlichen Zweck verantwortet, wer technische Änderungen betreut und wer definierte Freigaben erteilt. Je nach Einsatz können Datenschutz, Informationssicherheit, Einkauf, Betriebsrat oder weitere Funktionen beteiligt sein. Nicht jede Rolle muss jedes Ereignis freigeben.

Hilfreich ist eine einfache Zuordnung nach Ereignistyp. Ein Modell- oder Anbieterwechsel kann technische und fachliche Prüfung auslösen. Eine neue Datenquelle braucht möglicherweise zusätzliche Datenschutz- und Sicherheitsklärung. Eine Änderung des Einsatzzwecks gehört zum Business Owner und kann eine erneute Gesamteinordnung erfordern. Ein Vorfall braucht einen klaren Eskalationsweg.

Vertretung und Fristen gehören ebenfalls zur Betriebsfähigkeit. Ein Inventar, das nur von einer Person gepflegt werden kann, wird bei Urlaub oder Rollenwechsel schnell unzuverlässig. Die Verantwortung sollte deshalb an Rollen und nachvollziehbare Übergaben gebunden sein, nicht ausschließlich an individuelles Gedächtnis.

Eine Einführung in vier kontrollierbaren Schritten

1. Scope und Sprache festlegen. Bestimmen Sie, welche Organisationseinheiten und Nutzungstypen in der ersten Runde betrachtet werden. Definieren Sie Begriffe wie System, Instanz, Anwendungsfall, Owner und Freigabe so, dass Fachbereich und Technik dasselbe meinen. Diese kurze Taxonomie verhindert, dass ein Team jede Funktion einzeln zählt und ein anderes nur große Plattformen meldet.

2. Bestand erheben und normalisieren. Sammeln Sie Meldungen aus Interviews, Einkauf, IT-Verzeichnissen, Prozessdokumentation und vorhandenen Freigabewegen. Führen Sie Dubletten erst zusammen, wenn Nutzung, Instanz und Verantwortung geklärt sind. Markieren Sie unsichere Angaben als offen, statt sie durch Annahmen zu vervollständigen. Ein sichtbarer offener Punkt ist belastbarer als ein scheinbar vollständiges, aber erfundenes Feld.

3. Kritische Einträge priorisieren. Nicht jeder Eintrag braucht sofort dieselbe Tiefe. Starten Sie dort, wo KI regelmäßig genutzt wird, sensible oder geschäftskritische Prozesse berührt, Entscheidungen vorbereitet oder viele Personen erreicht. Priorisierung bedeutet nicht, andere Systeme dauerhaft auszublenden. Sie macht die erste Prüfung arbeitsfähig und schafft ein Muster für die weitere Erhebung.

4. Fortschreibung an echte Ereignisse binden. Verknüpfen Sie Beschaffung, technische Changes, neue Datenquellen, Freigaben, Vorfälle und Stilllegung mit dem Inventar. Die Pflege darf nicht nur von einer jährlichen Erinnerung abhängen. Gleichzeitig ist eine periodische Bestätigung sinnvoll, weil nicht jede Nutzungsänderung automatisch an einer zentralen Stelle sichtbar wird.

Qualität prüfen, ohne einen Scheinscore zu erzeugen

Ein pauschaler Reifegrad kann nützlich wirken, verdeckt aber schnell unterschiedliche Probleme. Prüfen Sie stattdessen konkrete Eigenschaften: Hat jeder produktive Eintrag einen erreichbaren Business Owner? Sind Zweck und tatsächliche Nutzung vereinbar? Lassen sich relevante Datenquellen benennen? Ist die letzte wesentliche Änderung mit Entscheidung und Beleg dokumentiert? Sind offene Maßnahmen von bestätigten Kontrollen unterscheidbar?

Auch Aktualität ist mehr als ein Datum. Ein Eintrag kann gestern bestätigt worden sein und trotzdem auf einer unklaren Quelle beruhen. Halten Sie deshalb fest, wer welche Information bestätigt hat und worauf diese Bestätigung basiert. Bei importierten Daten sollte sichtbar bleiben, aus welchem System und von welchem Zeitpunkt sie stammen.

Die beste Qualitätsprobe ist eine Übergabe. Geben Sie einen Eintrag an eine sachkundige Person, die bisher nicht beteiligt war. Kann sie den Zweck erklären, Verantwortliche finden, den aktuellen Status nachvollziehen und die letzte wesentliche Entscheidung samt Beleg öffnen? Wenn dafür zusätzliche mündliche Erläuterungen nötig sind, zeigt die Lücke genau, welche Struktur im Inventar oder Trail noch fehlt.

Vom Tabellenprojekt zum belastbaren Betriebsprozess

Die erste Version darf klein sein. Wählen Sie einen begrenzten Bereich, identifizieren Sie reale Systeme und testen Sie die Felder an tatsächlichen Entscheidungen. Wenn ein Feld keine spätere Handlung unterstützt, sollte seine Notwendigkeit geprüft werden. Wenn eine häufige Entscheidung nirgends dokumentiert werden kann, fehlt wahrscheinlich ein Feld oder Ereignistyp.

Nach der Erstaufnahme folgt die wichtigste Probe: Lässt sich der heutige Zustand aus den dokumentierten Ereignissen erklären? Kann eine neue verantwortliche Person erkennen, warum ein System produktiv ist, welche Daten es nutzt und welche Kontrolle bei der letzten Änderung stattgefunden hat? Sind offene Punkte von abgeschlossenen Freigaben unterscheidbar? Wenn nicht, ist das Register zwar gefüllt, aber noch nicht übergabefähig.

Ein Audit-Trail verspricht keine automatische Compliance und ersetzt weder fachliche noch rechtliche Bewertung. Er schafft die operative Voraussetzung, Fragen anhand eines konsistenten Bestands und sichtbarer Entscheidungen zu beantworten. Genau diese Nachvollziehbarkeit macht aus einer Liste ein steuerbares Inventar.