Die meisten Entwicklungsteams arbeiten längst mit KI-Tools. Deutlich weniger haben festgehalten, was erlaubt ist, was nicht und wer entscheidet. Genau in dieser Lücke sitzt das Risiko.
Wenn man uns holt, damit ein Team KI in den Griff bekommt, fragen wir als Erstes nach der Richtlinie. In aller Regel trifft eines von zwei Dingen zu. Entweder gibt es gar keine, und jeder Entwickler entscheidet von Fall zu Fall auf eigene Faust, mit Firmencode und Kundendaten. Oder es gibt eine, aber sie kommt aus der Rechtsabteilung, umfasst vier Seiten „Der Mitarbeiter hat zu …“ und kein Entwickler ist je über den ersten Absatz hinausgekommen.
Beides lässt Sie ungeschützt. Eine gute KI-Nutzungsrichtlinie ist kein juristischer Schutzschild. Sie ist ein Arbeitsdokument, das dem Entwickler genau dann, wenn er zum Tool greift, sagt, was er ohne Rückfrage tun darf und was er vorher abklären muss.
Was eine brauchbare Richtlinie wirklich klärt
Eine Richtlinie, der Entwickler folgen, beantwortet die konkreten Fragen, die im Arbeitsalltag tatsächlich aufkommen. Keine Prinzipien, sondern Entscheidungen. Fünf davon sind entscheidend.
| Entscheidung | Welche Frage sie beantwortet | Was Sie „ungeklärt“ kostet |
|---|---|---|
| Freigegebene Tools | Welche KI-Tools darf ich für die Arbeit einsetzen? | Shadow AI: Jeder wählt selbst, ohne dass jemand AGB oder Datenverarbeitung geprüft hat |
| Datengrenzen | Was darf in einen Prompt, und was darf das Haus nie verlassen? | Secrets, Kundendaten oder proprietärer Code landen bei einem ungeprüften Anbieter |
| Review-Pflichten | Was muss ich prüfen, bevor KI-Ausgaben ausgeliefert werden? | Ungeprüfter KI-Code in Produktion, für den sich niemand verantwortlich fühlt |
| Verantwortung | Wer haftet, wenn KI-gestützter Code versagt? | Verantwortung verläuft sich; „das Modell hat es geschrieben“ wird zur Ausrede |
| Eskalation | Wenn etwas unklar ist: wen frage ich? | Entwickler raten oder tun das Riskante still und leise |
Lässt Ihre Richtlinie auch nur einen dieser Punkte offen, steuert sie nicht das Verhalten, das das Risiko erzeugt. Dann beschreibt sie bloß einen Wunschzustand.
Setzen Sie bei freigegebenen Tools an, nicht bei verbotenen
Der erste Reflex ist eine Verbotsliste. Das geht nicht auf, denn neue Tools tauchen schneller auf, als Sie sie verbieten können, und eine Liste des Verbotenen sagt dem Entwickler nichts darüber, was sicher ist.
Drehen Sie es um. Benennen Sie die Tools, die für die Arbeit freigegeben sind, für welche Datenstufe das jeweils gilt und auf welchem Weg ein neues hinzukommt. Eine Positivliste mit schnellem Aufnahmeverfahren schlägt eine Sperrliste, die permanent veraltet ist.
Eine praxistaugliche Struktur:
- Freigegeben für alle Firmendaten, einschließlich proprietären Codes: Tools, mit denen Sie einen Auftragsverarbeitungsvertrag haben und die Sie geprüft haben.
- Nur für unkritische Nutzung freigegeben: Tools, die für öffentliche Informationen, Codegerüste oder zum Lernen in Ordnung sind, aber nie für Kundendaten oder Secrets.
- Nicht freigegeben, Prüfung anfragen: alles andere, mit benanntem Verantwortlichen und einer zugesagten Bearbeitungszeit, damit die Antwort nicht reflexhaft „nein“ lautet, sondern „noch nicht“.
Das schnelle Aufnahmeverfahren zählt mehr als die Liste selbst. Dauert eine Freigabe drei Wochen, gehen die Entwickler an Ihnen vorbei, und Sie sind zurück bei Shadow AI.
Machen Sie die Datenregeln greifbar
„Teilen Sie keine vertraulichen Informationen mit KI-Tools“ ist keine Regel, mit der ein Entwickler etwas anfangen kann. Er wird, in bestem Glauben, anders beurteilen als Sie, was darunter fällt.
Ersetzen Sie das durch Stufen und Beispiele, die sich in Sekunden zuordnen lassen.
| Datenstufe | Beispiele | Regel |
|---|---|---|
| Öffentlich | Open-Source-Code, öffentliche Doku, allgemeine Fragen | Jedes freigegebene Tool |
| Intern | Interner Code, Architektur, nicht personenbezogene Config | Nur freigegebene Tools mit Datenvereinbarung |
| Eingeschränkt | Secrets, Zugangsdaten, Schlüssel, Kunden-PII, regulierte Daten | Nie in einen Prompt, ohne Ausnahme |
Die Zeile „Eingeschränkt“ ist die, die den einen Vorfall verhindert, der sonst im Post-mortem landet. Formulieren Sie sie unmissverständlich und stützen Sie sie mit Technik ab, etwa Secret-Scanning bei Commits und maskierte Logs, damit nicht die Regel allein zwischen einem übermüdeten Entwickler und einem geleakten Schlüssel steht.
Hängen Sie die Richtlinie an den Workflow, nicht an eine Schulungsfolie
Eine Richtlinie, die einmal beim Onboarding gelesen und danach nie wieder angefasst wird, ist keine Kontrolle. Die Teams, bei denen es dauerhaft hält, verankern die Richtlinie an den Stellen, an denen die Entscheidung wirklich fällt.
- Die Liste der freigegebenen Tools steht dort, wo Entwickler ihre Tools konfigurieren, nicht in einem Wiki, das keiner öffnet.
- Die Review-Pflicht steckt im Pull-Request-Template, sodass „Hat ein Mensch diese Änderung verantwortet?“ eine Checkbox ist und keine Gedächtnisübung.
- Die Datenstufen tauchen im Secret-Scanning und in den Pre-Commit-Tools auf, sodass sich die Richtlinie dort selbst durchsetzt, wo sie kann.
Das ist dasselbe Prinzip, das wir auf freigegebene KI-Workflows anwenden: Governance, die direkt neben der Arbeit sitzt, wird befolgt; Governance, die in einem Dokument lebt, wird vergessen.
Benennen Sie die Verantwortung ausdrücklich
Der wichtigste Satz der ganzen Richtlinie ist der über die Verantwortung. KI-Unterstützung verschiebt keine Verantwortung. Wer die Änderung einreicht, verantwortet sie, genauso, als hätte er jedes Zeichen selbst getippt. „Das Modell hat es vorgeschlagen“ ist keine Ausrede, und die Richtlinie sollte das in klaren Worten festhalten.
Es geht nicht um Schuld. Es geht darum, die eine Annahme zu erhalten, ohne die Review und Qualität überhaupt nicht funktionieren: dass ein namentlich Verantwortlicher jede Änderung versteht und für sie geradesteht. In dem Moment, in dem diese Annahme aufweicht, wird jede nachgelagerte Kontrolle mit ihr schwächer.
Halten Sie sie kurz genug, dass man sie liest
Eine Richtlinie, der Entwickler folgen, passt auf ein bis zwei Seiten, ist in ihrer Sprache geschrieben und nutzt Beispiele aus ihrer echten Arbeit. Liest sie sich wie ein Vertrag, wird sie auch wie einer behandelt: unterschrieben, abgeheftet, ignoriert.
Schreiben Sie sie für den Entwickler an der Tastatur, nicht für den Prüfer im Meeting. Den Prüfer überzeugt eine kurze, klare, durchgesetzte Richtlinie ohnehin weit eher als eine lange, der keiner folgt.
Unsere Sicht
Eine KI-Nutzungsrichtlinie ist kein Papier, das Sie produzieren, um geordnet zu wirken. Sie ist das Bündel an Entscheidungen, das Entwicklern erlaubt, schnell und sicher zu handeln, ohne für jede Routineentscheidung um Erlaubnis zu fragen, und das ihnen klar sagt, wann sie eben doch fragen müssen.
Teams, die das richtig machen, schreiben weniger, nicht mehr. Sie entscheiden die fünf Dinge, auf die es ankommt, nämlich freigegebene Tools, Datengrenzen, Review, Verantwortung und Eskalation, und bringen diese Entscheidungen dorthin, wo gearbeitet wird, und halten das Dokument kurz genug, dass es tatsächlich gelesen wird. Alles Weitere ist Detail, das Sie ergänzen können, sobald der Kern sitzt.
Eine Richtlinie, die keiner liest, steuert nichts. Setzen Sie bei dem an, was ein Entwickler in dem Moment wissen muss, in dem er zum Tool greift. Dann schreiben Sie eine, die genau das tut.
Quellen
- EU-Verordnung über Künstliche Intelligenz, Artikel 4, zu den Pflichten zur KI-Kompetenz, abgerufen am 2026-06-10
- OWASP,
OWASP Top 10 for Large Language Model Applications, abgerufen am 2026-06-10 - NIST,
AI Risk Management Framework (AI RMF 1.0), abgerufen am 2026-06-10
Häufige Fragen
- Welche fünf Entscheidungen muss eine KI-Nutzungsrichtlinie für Entwicklungsteams verbindlich treffen?
- Eine Richtlinie, der Entwickler tatsächlich folgen, muss fünf konkrete Fragen beantworten: Welche Tools sind für die Arbeit freigegeben? Was darf in einen Prompt, was darf das Haus nie verlassen? Was muss vor dem Ausliefern von KI-Ausgaben geprüft werden? Wer haftet, wenn KI-gestützter Code versagt? Und wen fragt man, wenn etwas unklar ist? Bleibt auch nur einer dieser Punkte offen, steuert die Richtlinie nicht das Verhalten, das das Risiko erzeugt.
- Warum sollte eine KI-Richtlinie mit einer Positivliste freigegebener Tools arbeiten statt mit Verboten?
- Neue Tools erscheinen schneller, als eine Verbotsliste nachgezogen werden kann, und eine Liste des Untersagten sagt dem Entwickler nicht, was sicher ist. Eine Positivliste benennt die freigegebenen Tools, die jeweils erlaubte Datenstufe und den Weg, ein neues Tool aufnehmen zu lassen. Entscheidend ist dabei die Geschwindigkeit des Aufnahmeverfahrens: Dauert eine Freigabe drei Wochen, gehen Entwickler daran vorbei, und Shadow AI kehrt zurück.
- Wie sollten Datenstufen in einer KI-Richtlinie definiert sein, damit Entwickler sie im Arbeitsalltag sicher anwenden können?
- Vage Regeln wie "Teilen Sie keine vertraulichen Informationen" sind nicht anwendbar, weil jeder in gutem Glauben anders urteilt, was darunter fällt. Ersetzen Sie sie durch drei Stufen mit konkreten Beispielen: Öffentliche Daten dürfen in jedes freigegebene Tool. Interne Daten wie Code, Architektur oder Config nur in Tools mit Datenverarbeitungsvereinbarung. Eingeschränkte Daten, also Secrets, Zugangsdaten, Kunden-PII und regulierte Daten, gehören nie in einen Prompt, ohne Ausnahme. Flankieren Sie die Regel mit Secret-Scanning bei Commits und maskierten Logs, damit sie sich dort selbst durchsetzt, wo sie kann.
- Wer trägt die Verantwortung, wenn KI-gestützter Code fehlerhaft ist oder einen Produktionsausfall verursacht?
- Die Verantwortung liegt bei dem Entwickler, der die Änderung einreicht, genauso als hätte er jedes Zeichen selbst getippt. KI-Unterstützung verschiebt keine Verantwortung, und "das Modell hat es vorgeschlagen" ist keine gültige Ausrede. Die Richtlinie muss das in klaren Worten festhalten, denn sobald diese Annahme aufweicht, verliert jede nachgelagerte Kontrolle, einschließlich Code-Review und Qualitätssicherung, an Wirkung.
