Ein Team wollte etwas ausprobieren. Einen Chatbot für Kundenfragen, ein Skript, das Berichte zusammenfasst, eine Kopplung mit einem Sprachmodell, um E-Mails zu sortieren. Dafür war kein großer Beschluss nötig: Jemand hatte einen Account, einen API-Schlüssel oder eine kostenlose Testphase, und innerhalb eines Nachmittags lief etwas. Der Pilot funktionierte, oder funktionierte ausreichend, und niemand hatte noch einen Grund, ihn abzuschalten.
Das ist keine Ausnahme. Es ist der gewöhnliche Weg, wie KI in eine Organisation gelangt. Nicht über eine Ausschreibung oder ein genehmigtes Budget, sondern über einen Testaufbau, der seinen eigenen Teststatus überlebt. Die Testphase wurde nie formell abgeschlossen, weil es auch nie einen formellen Anfang gab, den man hätte abschließen können.
Ein Pilot, der funktioniert, wird genutzt. Und was genutzt wird, wird zur Abhängigkeit. Das Team, das den Berichts-Zusammenfasser gebaut hat, ist vielleicht gegangen, aber die Zusammenfassung kommt noch jede Woche an. Niemand hat den Auftrag, es abzuschalten, und niemand will das Risiko eingehen, dass etwas aufhört zu funktionieren, ohne zu wissen, was an dessen Stelle tritt.
Hinzu kommt, dass ein Testaufbau meist keinen Eigentümer hat in dem Sinne, den eine Governance-Struktur erwartet. Es wurde keine Risikoklassifizierung erstellt, keine Datenanalyse durchgeführt, keine Entscheidung darüber getroffen, wer verantwortlich ist, wenn etwas schiefgeht. Der Pilot existiert in einem Zwischenraum: zu genutzt, um ihn zu ignorieren, zu informell, um ihn zu verwalten. Das ist genau das Muster, das dazu führt, dass Mitarbeiter ein Tool nutzen, das niemand genehmigt hat — nur eben auf Teamebene statt individuell.
Der Reflex bei der Entdeckung eines nicht genehmigten Testaufbaus lautet oft: Wer hat das erlaubt, und warum wussten wir davon nichts. Diese Frage ist verständlich, wirkt aber kontraproduktiv. Wer beim ersten Gespräch bereits spürt, dass eine Schuldfrage bevorsteht, erzählt beim nächsten Mal nichts mehr. Und der nächste Testaufbau — der zweifellos kommen wird — verschwindet dann genauso aus dem Blickfeld wie dieser.
Eine auf Vertrauen aufgebaute Bestandsaufnahme bringt mehr als ein auf Kontrolle aufgebautes Audit. Nicht weil Menschen nichts zu verbergen haben wollen, sondern weil die gesuchte Information beim Nutzer liegt, und dieser Nutzer nur spricht, wenn er nicht für das zur Rechenschaft gezogen wird, was er berichtet.
Sobald ein Testaufbau sichtbar wird, ist die erste Frage nicht, ob er bestehen bleiben darf, sondern was er genau tut. Welche Daten fließen hinein, wer nutzt das Ergebnis, und was passiert, wenn das Ergebnis falsch ist. Das sind dieselben Fragen, die für jede andere KI-Anwendung gelten, und die Antwort bestimmt, ob etwas ein informelles Hilfsmittel ist oder ein Risiko, das Aufmerksamkeit verdient.
Danach folgt die Klassifizierung: Passt die Anwendung in eine bereits bestehende Risikokategorie, oder erfordert sie eine neue Abwägung. Anschließend: Was muss festgehalten werden, um nachweisbar zu machen, dass die Organisation weiß, was läuft und warum. Genau darauf geht was Sie pro Anwendung festhalten müssen ein — nicht als zusätzliche Bürokratie, sondern als die minimale Dokumentation, die nötig ist, um einen Pilot von einem Risiko zu unterscheiden.
Ein Testaufbau, der diese Prüfung besteht, kann weiterbestehen, nun mit einem Eigentümer und einer Klassifizierung. Ein Testaufbau, der die Prüfung nicht besteht, muss abgebaut werden — aber das ist ein kontrollierter Prozess, keine Entlassung der Person, die ihn einst gestartet hat.
Der Testaufbau, der nie abgeschaltet wurde, ist eine Form eines breiteren Musters. Denken Sie an die Browsererweiterung mit Zugriff auf Ihre E-Mail, die jemand einst installierte, um Zeit zu sparen, oder an Unternehmensdaten, die in einem kostenlosen Chatfenster landen, weil das schneller ging als das offizielle Tool. All diese Situationen teilen ein Merkmal: Sie sind aus einem praktischen Bedürfnis entstanden, nicht aus einer Grundsatzentscheidung, und sie bleiben bestehen, solange niemand danach fragt.
Die IT-Liste mit genehmigter Software ist daher nicht der Ausgangspunkt einer Bestandsaufnahme — sie ist der Ausgangspunkt einer Suche nach dem, was außerhalb dieser Liste liegt. Wer wissen möchte, wie diese Suche aussieht, findet einen Ansatz in wie Sie eine KI-Bestandsaufnahme aufbauen.
Ein Testaufbau, der ans Licht kommt, wirft meist eine Anschlussfrage auf, die über Governance hinausgeht: Warum funktionierte das eigentlich so gut, dass niemand es zu stoppen wagte? Das ist eine Frage über die Arbeit selbst, nicht nur über das Risiko. Der Werkscan von FTE TO AI berechnet pro Aufgabe, welcher Teil der Arbeit von KI übernommen werden kann, und macht damit sichtbar, was ein Testaufbau implizit bereits zeigte: dass ein Teil der Arbeit anders organisiert werden kann. Während der Responsible AI Scan abbildet, was läuft und unter welchem Risiko, zeigt der Werkscan, woher diese Nutzung stammt und was sie strukturell für die Aufgabenverteilung bedeutet.
Der Responsible AI Scan, mit der Bestandsaufnahme, Klassifizierung und dem Governance-Set, die oben beschrieben wurden, befindet sich in der Entwicklung. Wer hiermit bereits jetzt zu tun hat und informiert werden möchte, sobald das Instrument verfügbar ist, kann sich für die Warteliste anmelden.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.