Governance für kleine Teams: eine Seite pro KI-Einsatz statt Konzernformalismus

Eine kleine Organisation muss sich zwischen zwei schlechten Bildern nicht entscheiden. Das erste Bild lautet: Erst ein großes Governance-Programm mit Gremium, Richtlinienhandbuch und Spezialsoftware macht den Einsatz generativer KI verantwortbar. Das zweite lautet: Ein Textgenerator sei bloß ein Schreibwerkzeug; wer ihn benutzt, brauche deshalb keine besondere Entscheidung. Beide Bilder verfehlen den Arbeitsalltag. Ein fünfköpfiger Betrieb kann kein Konzernformalismus nachbauen. Er kann aber sehr wohl entscheiden, wofür ein bestimmter Dienst verwendet wird, welche Informationen hineindürfen, wer einen Entwurf prüft, wer Einwände vorbringen kann und wann der Versuch endet.

Dieser Artikel schlägt dafür eine kleine, sichtbare Form vor: eine Use-Case-Card pro KI-Einsatz. Sie ist keine allgemeine Erlaubnis für ein Tool und kein Etikett für „ethische KI“. Sie ist eine kurze Arbeitsvereinbarung für eine genau abgegrenzte Tätigkeit. Im Mittelpunkt steht ein vollständig fiktiver Fall: Ein kleiner Gebäudeservice erwägt, generative KI für erste Entwürfe interner Arbeitsberichte zu nutzen. Als Eingabe sind nur allgemeine, nicht personenbezogene Arbeitsnotizen vorgesehen. Bevor ein Bericht in die betriebliche Dokumentation gelangt, prüft und bearbeitet ihn eine verantwortliche Person. Die KI verschickt nichts, entscheidet nichts über Personen und wird nicht als Quelle für Tatsachen behandelt.

Der Fall ist absichtlich unspektakulär. Gerade dort, wo die Tätigkeit als geringfügig erscheint, entstehen Gewohnheiten: eine Notiz wird zu breit kopiert, der Entwurf wird zu schnell übernommen, eine Überprüfung wird aus Zeitdruck übersprungen. Gute Governance verhindert nicht jede Fehlentscheidung. Sie macht die Entscheidung, die Kontrolle und den Abbruch so konkret, dass ein kleines Team sie im Alltag tatsächlich ausführen kann.

Ausgangspunkt: keine Erlaubnis für ein Tool, sondern eine Frage zu einer Handlung

Die Frage lautet nicht: „Dürfen wir dieses KI-Tool einsetzen?“ Ein Dienst kann für eine harmlose Schreibskizze geeignet und für die Verarbeitung eines Kundenprotokolls ungeeignet sein. Deshalb beginnt die Karte mit einem Satz im Format: „Für [klar beschriebene Aufgabe] darf [klar beschriebene Rolle] [klar beschriebene Datenzone] nutzen, sofern [Prüfung und Grenzen] erfüllt sind.“

Für den fiktiven Gebäudeservice könnte dieser Satz lauten:

Für den ersten Entwurf eines internen Arbeitsberichts darf die Einsatzleitung ein freigegebenes generatives Textsystem mit allgemeinen, nicht personenbezogenen Arbeitsnotizen nutzen, sofern eine fachkundige Person jeden Entwurf prüft, berichtigt und freigibt, bevor er als Arbeitsbericht abgelegt wird.

Schon dieser Satz lässt wichtige Fragen offen: Was zählt als „allgemein“? Wer ist fachkundig? Was passiert bei widersprüchlichen Notizen? Diese Offenheit ist kein Mangel. Die Karte muss nicht alle denkbaren Risiken erraten. Sie muss die Stellen markieren, an denen das Team entscheidet oder stoppt.

Eine nicht KI-gestützte Arbeitsweise gehört deshalb auf dieselbe Karte. Im Beispiel schreibt die Einsatzleitung den Bericht aus einer Standardvorlage selbst oder lässt ihn durch eine Kollegin gegenlesen. Dieser Vergleich ist keine symbolische Pflicht. Ohne realistische Alternative wird „Zeitersparnis“ schnell zur bloßen Behauptung. Das Team sollte vor dem Pilot festhalten, welche Arbeit tatsächlich wegfällt und welche Arbeit hinzukommt: Notizen bereinigen, Ausgabe prüfen, Fehler berichtigen, Fassung ablegen. Wenn die Prüfung mehr Zeit braucht als eine gute Vorlage, ist Verzicht ein sinnvolles Ergebnis.

Der fiktive Fall: Entwürfe, keine automatischen Akten

Der fiktive Gebäudeservice unterhält kleinere Gewerbeobjekte. Nach einem Einsatz notiert die verantwortliche Fachkraft etwa: „Filter gewechselt; Sichtprüfung abgeschlossen; Materialbestand kontrollieren; nächster Termin nach Plan.“ Aus diesen Stichpunkten soll ein interner Bericht entstehen, der Arbeitsschritte und offene Punkte übersichtlich festhält.

Nicht eingegeben werden sollen Namen, Kontaktdaten, Zugangscodes, genaue Objektadressen, Fotos, freie Kundennachrichten, Angaben zu Beschäftigten, Gesundheitsdaten, Streitfälle oder Vertragsunterlagen. Ebenso wenig soll das System neue Tatsachen erfinden, Fristen auslegen, Leistungen abrechnen oder einen Bericht selbst in ein Kundenportal einstellen. Diese Grenzen ergeben sich hier nicht aus einer Behauptung, der Dienst sei „sicher“. Sie folgen aus einer gewählten Aufgabenbegrenzung: Für einen generischen Entwurf reichen generische Notizen.

Ein plausibler Ablauf sieht so aus:

1. Die Einsatzleitung überführt die zulässigen Notizen in eine festgelegte Eingabemaske. 2. Das System erstellt einen Entwurf nach einer internen Struktur: durchgeführte Arbeit, offene Punkte, ungeklärte Angaben. 3. Eine benannte prüfende Fachkraft vergleicht jede Aussage mit den Notizen und streicht oder ergänzt sie. 4. Erst die geprüfte Fassung wird als interner Bericht abgelegt. Die Entwurfsfassung bleibt nicht versehentlich als maßgebliche Akte bestehen. 5. Bei einer Unklarheit wird nicht „nachgepromptet“, bis etwas Plausibles erscheint. Die Fachkraft klärt den Sachverhalt über die zuständige Person oder dokumentiert ihn als offen.

Der Ablauf nimmt der KI keine Verantwortung weg; sie hatte nie eine. Er ordnet Verantwortung Menschen und Rollen zu. Die Person, die die Notiz erstellt, verantwortet ihre fachliche Grundlage. Die prüfende Person verantwortet die Freigabe des Berichts. Die Betriebsleitung verantwortet, ob der begrenzte Einsatz überhaupt fortgesetzt wird. Die Person, die einen Fehler bemerkt, braucht einen Weg, ihn zu melden, ohne zunächst beweisen zu müssen, dass ein Algorithmus die Ursache war.

Datenzonen: klein halten, sichtbar machen

„Keine sensiblen Daten“ ist für den Alltag zu ungenau. Kleine Teams arbeiten besser mit wenigen Datenzonen und klaren Beispielen. Für den Fall reichen vier Zonen:

Die Zonen ersetzen keine Datenschutzanalyse und keine vertragliche Prüfung. Sie sind eine praktische Vorsortierung. Ihre Stärke liegt darin, dass sie vor der Eingabe greift: Eine Person kann „rot“ sehen, bevor ein Text kopiert wird. Ihre Grenze liegt ebenso offen: Ein scheinbar allgemeiner Satz kann im Kontext identifizierbar sein. Darum bleibt die Regel „bei Zweifel nicht eingeben, erst klären“ wichtiger als die Illusion einer vollständigen Liste.

Die Karte sollte außerdem festhalten, was mit Entwürfen geschieht. Wird der Prompt protokolliert? Werden Textausgaben beim Anbieter gespeichert? Gibt es Administrations- oder Trainingseinstellungen? Welche Aufbewahrungsfrist gilt intern? Diese Fragen ändern sich mit Vertrag, Konfiguration und Anbieter. Eine Karte darf daher nicht den Stand eines Tages in eine ewige Freigabe verwandeln.

Philosophische Linse: Verantwortung ist geteilt, aber nicht verdünnt

Iris Marion Young beschreibt in Responsibility for Justice ein Modell sozialer Verbindung. Es lenkt den Blick auf strukturelle Zusammenhänge: Schäden und unfaire Folgen entstehen oft durch viele gewöhnliche Handlungen, Regeln und Arbeitsteilungen; Verantwortung erschöpft sich dann nicht darin, rückwärts eine einzelne schuldige Person zu suchen. Als Linse für den fiktiven KI-Einsatz hilft das, die Frage anders zu stellen. Nicht: „Wer ist schuld, wenn der Textgenerator einen Fehler macht?“ Sondern: „Welche Rollen, Anreize und Routinen verbinden uns mit der Möglichkeit dieses Fehlers, und was können wir an ihnen ändern?“

Das ist keine Validierung des hier vorgeschlagenen Modells durch Young. Ihre Theorie liefert weder eine Use-Case-Card noch eine Freigabeformel. Sie schützt aber vor zwei Ausweichbewegungen. Die erste lautet: Die KI habe gehandelt, also trage niemand Verantwortung. Die zweite lautet: Nur die letzte prüfende Person sei verantwortlich, obwohl andere Personen Datenregeln, Zeitvorgaben, Beschaffung und Ablageform gesetzt haben. Der soziale Zusammenhang verteilt Pflichten nach Rolle und Einfluss, ohne sie ins Ungefähre aufzulösen.

Für den fiktiven Betrieb bedeutet das: Die Leitung darf eine Prüfung nicht verlangen und gleichzeitig dafür keine Zeit vorsehen. Die Einsatzleitung darf nicht mit einer vagen Datenregel allein gelassen werden. Die prüfende Fachkraft darf eine kritische Rückfrage stellen können, ohne als Bremse zu gelten. Und eine betroffene Person oder Kollegin muss Fehler und Einwände melden können. Gemeinsame Verantwortung heißt hier: Jede Rolle hat eine konkrete, erfüllbare Aufgabe; keine Rolle kann die Aufgabe mit dem Hinweis auf das Tool abschieben.

Diese Linse macht auch einen Zielkonflikt sichtbar. Schnellere Berichte können die interne Übersicht verbessern und Freiraum für fachliche Arbeit schaffen. Mehr Prüfung kostet Zeit, und ein kleiner Betrieb hat davon wenig. Doch Zeitdruck ist kein neutraler Umstand, wenn er dazu führt, dass der wirtschaftliche Nutzen bei der Leitung liegt, während die Risiken falscher Dokumentation bei Kundschaft, Beschäftigten oder einzelnen Prüferinnen hängen bleiben. Ein begrenzter Pilot mit nachvollziehbarer Abbruchregel ist daher keine bürokratische Verzierung. Er ist eine Art, diese Verteilung sichtbar zu machen und veränderbar zu halten.

K als Kern: vier Schritte, die eine Karte tragen

K ist in diesem Artikel das zentrale, nutzerentwickelte Konsultations- und Governance-Modell. Sein Grundzyklus hat vier Schritte: Exploration → Reflexion/Analyse → Entscheidung/Empfehlung → Feedback/Evaluation. Er ist weder ein zertifiziertes Kontrollsystem noch ein Nachweis, dass eine Entscheidung ethisch oder rechtlich richtig ist. Er schafft eine wiederholbare Gesprächs- und Entscheidungsform.

In der Exploration sollte das Team Begriffe entzaubern. „Arbeitsbericht“ kann ein reiner interner Merker sein oder eine Grundlage für Rechnungen, Haftungsfragen und Kundenkommunikation. Die Kartenfrage muss den tatsächlichen Verwendungsweg nennen. Für den fiktiven Pilot wird ausdrücklich nur der interne Entwurf erlaubt. Soll ein Bericht später für eine Rechnung, einen Vertrag oder eine Streitklärung verwendet werden, beginnt eine neue Bewertung; die alte Karte reicht nicht weiter.

Die Reflexion/Analyse enthält keine Rechenformel, die Werte gegeneinander aufwiegt. Sie zwingt aber dazu, die stärkste Gegenposition fair zu formulieren: Kleine Teams können sich lange Debatten und doppelte Dokumentation kaum leisten. Wer jede Schreibhilfe mit umfassenden Akten versieht, begünstigt entweder den Verzicht oder die heimliche Schattennutzung. Diese Kritik trifft einen realen Punkt. Eine Karte, die niemand liest und nur für die Außenwirkung existiert, verschlechtert die Praxis.

Die Antwort kann nicht sein, Prüfungen wegzulassen. Sie lautet: Dokumentation muss einer Entscheidung dienen, die im Arbeitsablauf vorkommt. Eine Seite pro Einsatz enthält nur Angaben, die eine Rolle braucht, um zu handeln. Sie ersetzt kein Gremium durch eine Scheinminiatur. Sie benennt in einem kleinen Team oft dieselben Personen in mehreren Rollen. Wichtig ist nicht eine imposante Organisationsgrafik, sondern dass etwa „Tool beschaffen“, „Eingabe freigeben“, „Ausgabe prüfen“, „bei Konflikt stoppen“ nicht unsichtbar zusammenfallen.

Die Entscheidung/Empfehlung im Fall ist nicht „KI erlaubt“. Sie könnte lauten: sechs Wochen Pilot, höchstens zehn Berichts-Entwürfe pro Woche, nur Grün-Daten, keine Außenkommunikation, immer fachliche Prüfung, wöchentliche Kurzbesprechung. Die Leitung stellt für die Prüfung Zeit bereit. Die Einsatzleitung darf bei Unsicherheit stoppen. Die prüfende Fachkraft darf einen Entwurf zurückweisen. Eine benannte Kontaktrolle sammelt Einwände von Beschäftigten. Diese Regeln sind überprüfbar, weil sie konkret sind.

Feedback/Evaluation fragt nach der Nutzung, nicht nach einer abstrakten „KI-Qualität“. Wurden die Datenzonen eingehalten? Wie viele Aussagen mussten korrigiert werden, und welche Art von Fehlern waren es? Haben Prüferinnen den Entwurf tatsächlich gelesen oder nur bestätigt? Wurde eine Regel umgangen, weil sie unpraktisch war? Hat die Zeitersparnis die zusätzliche Prüfung plausibel aufgewogen? Ein kleiner Fehlerzähler allein beantwortet das nicht; er kann aber Anlass für eine fachliche Rückschau sein. Das Team dokumentiert auch Gegenbeispiele und Beschwerden, nicht nur gelungene Entwürfe.

Separat: die fünfstufige K-Fallszenario-Erweiterung

Für eine ausführlichere Fallarbeit hat K eine fünfstufige Szenario-Erweiterung: Exploration, Reflexion, Entscheidung, Implementierung/Pilot, Abschlussbewertung/Optimierung. Sie ist nicht der vierstufige Kern. Ihre zusätzliche Stärke liegt darin, dass der Start eines Versuchs und die abschließende Auswertung eigene Arbeitsabschnitte erhalten.

Im Gebäudeservice trennt die Erweiterung die Entscheidung vom Pilot: Erst legt das Team Datenzonen, Prüfschritte, Zugriff und Stoppregeln fest; danach probiert es den Workflow unter diesen Bedingungen aus. Die Abschlussbewertung entscheidet dann, ob die Karte geändert, der Pilot verlängert oder der Einsatz beendet wird. Die Trennung verhindert, dass „wir testen es mal“ als stille Dauerfreigabe weiterläuft.

Die Use-Case-Card: eine Seite, die im Alltag benutzt wird

Die folgende Struktur passt auf eine Seite. Sie ist bewusst keine Vorlage für jede Organisation und keine vollständige Checkliste für jeden Rechtsraum. Sie ist ein Arbeitsobjekt für eine begrenzte Entscheidung.

Use-Case-Card UCC-01: Interne Berichts-Entwürfe (fiktives Beispiel)

Die Karte muss zugänglich sein: dort, wo die Eingabe vorbereitet wird, und in einer Version, die Beschäftigte verstehen. Eine Person darf sie ändern, aber Änderungen brauchen Datum, Grund und erneute Freigabe. Sonst wird nach einem Anbieterupdate oder einer stillen Prozessänderung eine alte Karte zum falschen Beruhigungsmittel.

Das Protokoll ist absichtlich schmal. Es soll erklären können, welcher Workflow in welcher Version lief und was mit dem Entwurf geschah. Es soll kein Schattenarchiv von Prompts, Personalverhalten oder Kundendaten erzeugen. Die Frage „Was müssen wir wissen, um einen Fehler zu verstehen?“ ist besser als „Was können wir alles aufzeichnen?“

Einspruch, Rückmeldung und Entscheidungsmacht

Ein Einspruchskanal muss für kleine Teams nicht anonym und technisch aufwendig sein; er muss erreichbar und folgenlos nutzbar sein. Im fiktiven Betrieb kann jede beschäftigte Person einen Fehler oder eine Sorge der Einsatzleitung, der prüfenden Fachkraft oder einer dafür benannten Kontaktrolle melden. Die Meldung erhält Datum, kurze Beschreibung und eine Entscheidung: sofort pausieren, beim nächsten Review behandeln oder als Fachfrage weitergeben. Wer den Workflow verantwortet, darf die eigene Entscheidung nicht allein als erledigt erklären, wenn die Meldung gerade die Qualität seiner Prüfung betrifft. Die Leitung entscheidet über Fortsetzung und Ressourcen, jedoch nicht über die fachliche Richtigkeit eines einzelnen Berichts.

Auch externe Betroffene brauchen keinen Zugang zum Tool, um gehört zu werden. Stellt eine Kundin oder ein Kunde später einen Fehler in einem abgelegten Bericht fest, wird der Bericht als Arbeitsprodukt korrigiert, die Ursache geprüft und die Pilotkarte gegebenenfalls neu bewertet. Das Verfahren verspricht keine konfliktfreie Lösung; es verhindert, dass eine Rückmeldung zwischen „Technikproblem“ und „menschlichem Fehler“ verloren geht. Ein Team sollte außerdem festhalten, welche Rückmeldung zu einer sofortigen Korrektur führt, welche eine Musterprüfung auslöst und wer über eine Beendigung des Pilots entscheidet. Damit wird das Recht auf Widerspruch zu einer betrieblichen Aufgabe statt zu einer freundlichen Fußnote.