Governance und AI Act — Sicherheit, Nachweise und Verantwortlichkeiten

Governance scheitert selten an fehlendem Willen und fast immer an fehlenden Nachweisen. Ein Unternehmen weiß meist ungefähr, welche KI-Systeme im Haus laufen, wer sie eingeführt hat und wofür sie genutzt werden — aber es kann es nicht belegen, wenn ein Kunde, ein Auditor oder eine Aufsichtsbehörde danach fragt. Diese Seite behandelt vier Aufgaben, die diesen Abstand schließen: den eigenen Bestand kennen, das Risiko einordnen, Verantwortlichkeiten benennen und Nachweise so führen, dass sie im Ernstfall vorliegen statt rekonstruiert werden zu müssen.

Das ist eine Einordnung aus der Umsetzungspraxis, keine Rechtsberatung. Wo es um die rechtliche Bewertung eines einzelnen Systems geht, gehört juristischer Rat dazu.

Zuerst den Bestand kennen

Fast jedes Governance-Projekt beginnt mit einer unangenehmen Entdeckung: Es laufen mehr KI-gestützte Systeme im Unternehmen, als die Liste hergibt. Eingekaufte Software hat ein Assistenzfeature bekommen, ein Team nutzt einen Dienst über die Fachabteilung statt über die IT, ein Skript ruft seit Monaten eine Modell-API auf. Ohne belastbaren Bestand ist jede weitere Bewertung eine Aussage über einen Ausschnitt:

• Eingekauft ebenso wie selbst gebaut. Ein Assistenzfeature in einer Standardsoftware wirft dieselben Fragen auf wie ein eigenes Modell — der Unterschied liegt darin, wer die Antworten liefern muss, nicht darin, ob sie nötig sind.
• Zweck statt Produktname. Was ein System im Alltag tatsächlich entscheidet oder vorbereitet, ist die relevante Angabe. Der Produktname sagt darüber wenig aus, und er ändert sich mit dem nächsten Release.
• Datenarten, die hineinfließen. Personenbezogene Daten, Geschäftsgeheimnisse, Kundendaten aus Drittverträgen: Die Datenart bestimmt, welche Pflichten überhaupt greifen.
• Wer es eingeführt hat und wer es heute betreibt. Das sind in der Praxis oft zwei verschiedene Parteien, und die zweite weiß häufig nicht, welche Zusagen die erste gemacht hat.

Dieser Bestand ist kein einmaliges Dokument. Er ist nur dann nützlich, wenn es einen festen Anlass gibt, zu dem er aktualisiert wird — etwa bei jeder Beschaffung und bei jedem größeren Release.

Risiko einordnen, statt alles gleich zu behandeln

Der AI Act ist risikobasiert aufgebaut: Wenige Praktiken sind untersagt, eine begrenzte Gruppe von Anwendungen gilt als hochriskant und trägt substanzielle Pflichten, für weitere Systeme gelten vor allem Transparenzanforderungen, und ein großer Teil des betrieblichen Alltags fällt in keine dieser Kategorien. Diese Abstufung ist die eigentliche Arbeitserleichterung — vorausgesetzt, sie wird genutzt:

• Einstufung pro Anwendung, nicht pro Anbieter. Dasselbe Modell kann in einer Anwendung unkritisch und in einer anderen hochriskant sein. Maßgeblich ist der Einsatzzweck, nicht die Technologie darunter.
• Die eigene Rolle klären. Ob ein Unternehmen ein System anbietet oder es lediglich betreibt, verschiebt die Pflichten erheblich. Wer ein eingekauftes System unter eigenem Namen weitergibt oder es wesentlich verändert, kann in eine andere Rolle rutschen, als der Einkauf angenommen hat.
• Transparenzpflichten nicht unterschätzen. Dass Menschen erkennen können, wann sie mit einem KI-System interagieren oder synthetische Inhalte vor sich haben, betrifft viele Anwendungen, die sonst als unkritisch gelten.
• Die Einstufung begründen und festhalten. Eine Einordnung, deren Begründung niemand mehr kennt, ist bei der nächsten Prüfung wertlos. Der Satz, warum ein System nicht hochriskant ist, ist genauso wichtig wie die Einstufung selbst.

Die Pflichten des AI Act greifen gestaffelt über mehrere Jahre. Praktisch heißt das: Die Einstufung sollte stehen, damit der Aufwand dort landet, wo er hingehört, statt gleichmäßig über alles verteilt zu werden.

Verantwortlichkeiten benennen, bevor ein Vorfall es erzwingt

Der häufigste Governance-Mangel ist keine fehlende Richtlinie, sondern eine Richtlinie ohne benannte Person. Solange Zuständigkeit implizit bleibt, übernimmt sie im Zweifel niemand:

• Freigabe. Wer entscheidet, dass ein System in Betrieb gehen darf — und auf welcher Grundlage? Eine Freigabe ohne dokumentierte Entscheidungsgrundlage ist eine Unterschrift, keine Kontrolle.
• Betrieb. Wer beobachtet das System im laufenden Einsatz und bemerkt, wenn sich sein Verhalten verändert, etwa nach einem Modellwechsel beim Anbieter?
• Abschaltung. Wer darf ein System anhalten, ohne vorher eine Genehmigungskette zu durchlaufen? Diese Befugnis ist im Vorfall die wichtigste und im Normalbetrieb die am seltensten geklärte.
• Auskunft. Wer beantwortet die Frage eines Kunden, einer Aufsicht oder eines Betriebsrats — und hat diese Person Zugriff auf die Unterlagen, die sie dafür braucht?

Vier benannte Rollen sind wenig Aufwand. Ihr Fehlen wird erst im ersten Vorfall sichtbar, und dann ist es teuer.

Nachweise führen, die im Ernstfall vorliegen

Die Pflichten laufen praktisch alle auf dieselbe Frage hinaus: Können Sie belegen, was Sie behaupten? Nachweise, die erst bei Bedarf zusammengesucht werden, sind in dem Moment am schwächsten, in dem sie gebraucht werden:

• Entscheidungen zum Zeitpunkt festhalten. Warum dieses System, warum diese Einstufung, warum diese Freigabestufe — notiert, als die Entscheidung fiel, nicht rekonstruiert, nachdem gefragt wurde.
• Protokolle, die eine Rückverfolgung erlauben. Für Systeme mit Handlungsspielraum muss sich später nachvollziehen lassen, was das System getan hat und auf welcher Grundlage.
• Änderungen als Ereignis behandeln. Ein Anbieter tauscht ein Modell aus, ein Prompt wird angepasst, eine neue Datenquelle kommt hinzu: Jede dieser Änderungen kann die Einstufung berühren und gehört datiert festgehalten.
• Menschliche Aufsicht belegbar machen. "Ein Mensch prüft das" ist erst dann eine Kontrolle, wenn erkennbar ist, wer wann was geprüft hat und was bei einer Ablehnung passiert.

Cybersicherheit gehört in denselben Nachweisrahmen. Ein KI-System erweitert die Angriffsfläche um Eingaben aus unzuverlässigen Quellen, um Werkzeuge, die es aufrufen darf, und um Daten, die es ausgeben kann. Zugriffsrechte, Protokollierung und mögliche Datenabflusswege gehören für diese Systeme genauso dokumentiert wie für jedes andere produktive System.

Wo das in der Praxis schiefgeht

Das typische Muster ist ein Governance-Projekt, das mit dem Dokument beginnt statt mit dem Bestand. Eine Richtlinie wird geschrieben, freigegeben und abgelegt — und beschreibt einen Zustand, den niemand überprüft hat. Sechs Monate später stellt sich bei der ersten Kundenanfrage heraus, dass mehrere produktive Systeme in der Richtlinie gar nicht vorkommen, dass für zwei davon niemand die Freigabe erteilt hat und dass die Person, die das dritte eingeführt hat, nicht mehr im Unternehmen ist. Der Aufwand, der durch die Richtlinie vermieden werden sollte, fällt dann vollständig an — nur unter Zeitdruck und mit einem Kunden, der auf eine Antwort wartet.

Der zweite wiederkehrende Fehler ist die Gleichbehandlung: Jedes System wird durch dasselbe schwere Verfahren geschickt, weil keine Einstufung vorliegt. Das Ergebnis ist ein Prozess, den die Teams umgehen, weil er für den unkritischen Fall unverhältnismäßig ist — und damit greift er auch dort nicht mehr, wo er nötig wäre.

Nächster Schritt

Wer wissen will, welche Systeme im eigenen Haus überhaupt betroffen sind, wie die Einstufung für einen konkreten Anwendungsfall ausfällt oder welche Nachweise für eine anstehende Kunden- oder Auditanfrage fehlen, kann direkt Kontakt aufnehmen. Eine kurze Beschreibung der eingesetzten Systeme und des konkreten Anlasses reicht als Ausgangspunkt.