Ein Repository ersetzt keine Verantwortung: Warum jedes produktive KI-System benannte Eigentümer braucht
Kurz gesagt
Vor dem Produktivstart eines KI-Systems müssen fachliche, technische, Sicherheits-, Datenschutz- und Betriebsverantwortung konkret einzelnen Personen oder Rollen zugeordnet sein – ein Code-Repository, ein Cloud-Konto oder ein API-Schlüssel ersetzt keine echte Eigentümerschaft. Ohne benannte Zuständigkeit für Alarmierung, Entscheidung, Kommunikation und Wiederherstellung im Störungsfall bleibt unklar, wer im Ernstfall überhaupt reagieren muss.
Warum "es läuft ja" keine Verantwortungsstruktur ist
Viele KI-Projekte im Mittelstand starten pragmatisch: Ein einzelner Mitarbeiter oder eine externe Person baut eine funktionierende Lösung, verbindet sie mit einem API-Schlüssel, und das System läuft. Das beantwortet aber nicht die entscheidenden Fragen für den echten Betrieb: Wer wird informiert, wenn das System nachts ausfällt? Wer entscheidet, ob eine fehlerhafte KI-Antwort ein Einzelfall oder ein systematisches Problem ist? Wer spricht mit betroffenen Kunden, wenn ein Fehler nach außen sichtbar wird? Ohne klare Antworten darauf ist ein System zwar aktiv, aber nicht wirklich verantwortet.
Fünf Verantwortungsbereiche, die konkret zugeordnet sein sollten
- Fachliche Verantwortung: Wer definiert Zweck, Nutzen und Erfolgskriterien des Systems, und wer entscheidet, ob es diesen Zweck weiterhin erfüllt?
- Technische Verantwortung: Wer verantwortet Code, Architektur und die technische Weiterentwicklung des Systems?
- Sicherheitsverantwortung: Wer prüft Zugriffsrechte, Abhängigkeiten und mögliche Angriffsflächen, und wer reagiert bei einem Sicherheitsvorfall?
- Datenschutzverantwortung: Wer stellt sicher, dass die Verarbeitung personenbezogener Daten im System weiterhin rechtmäßig bleibt, auch wenn sich das System oder seine Nutzung ändert?
- Betriebsverantwortung: Wer überwacht das laufende System, reagiert auf Störungen und verantwortet Wiederherstellung nach einem Ausfall?
Diese fünf Bereiche können in einem kleinen Unternehmen durchaus bei denselben ein oder zwei Personen liegen – entscheidend ist nicht die Anzahl der Köpfe, sondern dass für jeden Bereich tatsächlich klar ist, wer zuständig ist, statt dass die Frage im Ernstfall erst gestellt wird.
Was ohne benannte Eigentümerschaft konkret fehlt
Fehlt eine klare Zuordnung, entstehen typische Lücken: Eine Störung wird bemerkt, aber niemand fühlt sich zuständig, sie zu beheben. Eine sicherheitsrelevante Änderung an einem KI-Anbieter wird nicht rechtzeitig registriert, weil niemand die Beobachtung als eigene Aufgabe versteht. Ein Kunde beschwert sich über eine falsche KI-Antwort, und die Anfrage wird zwischen Support, IT und Geschäftsleitung hin- und hergereicht, statt zügig bearbeitet zu werden. Genau solche Situationen sind der Grund, warum Verfahren für Störungsreaktion und den zuverlässigen Betrieb komplexer Systeme (Incident Response und SRE-Praxis) voraussetzen, dass Alarmierung, Entscheidungsbefugnis, Kommunikation und Wiederherstellung von Anfang an klar zugewiesen sind – nicht erst während einer laufenden Störung improvisiert werden.
Der Zusammenhang mit Nutzen, Verantwortung und Betrieb
Eigentümerschaft ist nur einer von mehreren Mindestnachweisen, die ein produktives System braucht. Ebenso gehören dazu: dokumentierter Nutzer, dokumentierte Aufgabe, eine Baseline zum Vergleich und ein klares Abnahmekriterium für den fachlichen Nutzen; ein Repository, Review-Prozesse, eine kontinuierliche Integration und ein unveränderliches Release-Artefakt für kontrollierte technische Änderung; sowie aktive Servicelevel-Überwachung, Protokolle, Metriken und Runbooks für den laufenden Betrieb. Eigentümerschaft ist dabei die Voraussetzung, die all diese anderen Nachweise erst nutzbar macht – ohne benannte Verantwortung bleibt selbst die beste technische Dokumentation im Ernstfall wirkungslos, weil niemand sie anwendet.