AI Coding Governance: Wie Teams KI kontrolliert in der Entwicklung einsetzen

Die meisten Organisationen stehen bei KI in der Entwicklung vor derselben unangenehmen Wahl: ein Verbot, das faktisch nicht durchsetzbar ist, oder ein Laisser-faire, bei dem niemand mehr sagen kann, welche Werkzeuge auf welche Daten zugreifen. Beides sind keine Entscheidungen, sondern deren Aufschub.

1. Verbot oder Wildwuchs – beides kostet

Ein Verbot scheitert an der Verfügbarkeit: KI-Funktionen stecken in Editoren, Terminals, Browsern und Ticketsystemen. Was übrig bleibt, ist Nutzung ohne Aufzeichnung – privat installiert, privat bezahlt, ohne Datenschutzprüfung und ohne Spur im Prozess. Das ist die schlechteste aller Varianten, weil sie das Risiko behält und die Kontrolle abgibt.

Der ungeregelte Gegenpol ist nicht besser. Ohne Vorgaben entstehen pro Team eigene Werkzeugketten, eigene Datenflüsse und eigene Vorstellungen davon, was geprüft werden muss. Spätestens bei der ersten Kundenfrage – „Wurde in unserem Projekt KI eingesetzt, und wie stellen Sie Qualität sicher?“ – fehlt eine belastbare Antwort.

2. Was Governance in diesem Zusammenhang heißt

Governance klingt nach Gremium und Formular, ist hier aber schlicht ein Satz Entscheidungen, die einmal getroffen und danach durchgesetzt werden. Der Umfang ist überschaubar: In vielen Organisationen passt die Regelung auf zwei Seiten, wenn sie sich auf das Wesentliche beschränkt.

Drei Eigenschaften machen den Unterschied zwischen Regelung und Papier:

• Entscheidbar. Jede Regel beantwortet eine Frage, die im Alltag auftritt – nicht eine, die theoretisch auftreten könnte.
• Prüfbar. Es lässt sich feststellen, ob sie eingehalten wurde.
• Durchgesetzt. Wo möglich technisch, nicht durch Appell.

3. Die vier Regelungsfelder

Praktisch reduziert sich AI Coding Governance auf vier Felder. Alles Weitere folgt daraus:

1. Werkzeuge und Betriebsmodell. Welche Werkzeuge sind zugelassen, in welcher Betriebsform – öffentlicher Dienst, dedizierte Umgebung, eigener Betrieb? Eine kurze Positivliste ist wirksamer als ein langer Kriterienkatalog.
2. Daten. Welche Inhalte dürfen in welches Werkzeug? Das ist die Kernfrage und wird in Abschnitt 4 aufgelöst.
3. Prüfpflichten. Was muss geschehen, bevor generierter Code produktiv geht? Idealerweise exakt dasselbe wie bei handgeschriebenem Code – plus die Punkte, die bei generiertem Code häufiger auffallen.
4. Dokumentation und Verantwortung. Was wird festgehalten, und wer trägt die Verantwortung für das Ergebnis? Die Antwort auf die zweite Frage ist immer eine Person, nie ein Werkzeug.

4. Datenklassen als Ankerpunkt

Die häufigste Fehlkonstruktion ist eine Regel pro Werkzeug. Werkzeuge wechseln schneller als Richtlinien. Stabiler ist die umgekehrte Verankerung: Regeln pro Datenklasse, Werkzeuge werden diesen Klassen zugeordnet.

Die Tabelle ist ein Muster, keine Vorgabe. Welche Klassen und Zusicherungen für Ihr Haus gelten, hängt von Verträgen, Branche und Datenschutzbewertung ab.

Der praktische Vorteil: Ein neues Werkzeug muss nicht neu diskutiert werden. Es wird geprüft, einer Klasse zugeordnet – fertig. Und Entwicklerinnen und Entwickler haben eine Regel, die sie sich merken können.

5. Technische Durchsetzung: was in der Pipeline steht, gilt

Der wirksamste Teil einer KI-Richtlinie steht nicht in der Richtlinie. Er steht in der Pipeline und in den Repository-Einstellungen:

• Quality Gates als Merge-Voraussetzung: Build, Tests, Contract-Tests, Lint, SAST, Dependency- und Secret-Scan. Details im Pillar KI in der Softwareentwicklung.
• Abhängigkeitsrichtlinie: nur Pakete aus kuratierten Quellen, Lizenzprüfung automatisiert, neue Abhängigkeiten sichtbar im Review.
• Verpflichtendes Review durch eine zweite Person, gesteuert über Zuständigkeiten am Verzeichnisbaum.
• Begrenzte Agent-Rechte, wenn Werkzeuge auf Systeme zugreifen – siehe MCP und Berechtigungsgrenzen.
• Keine Produktionszugänge in Entwicklungsumgebungen, in denen Agents laufen.

Diese Maßnahmen sind bemerkenswert unspektakulär: Fast alle gehören ohnehin zu einem soliden Entwicklungsprozess. KI macht sie nicht neu, sondern nur unverzichtbar.

6. Kennzeichnung und Verantwortung

Ob wesentlicher KI-Einsatz gekennzeichnet wird, ist eine bewusste Entscheidung. Für regulierte und kundennahe Projekte spricht viel dafür – nicht als Misstrauensvotum, sondern weil sich später die Prüftiefe bewerten lässt. Eine leichtgewichtige Form genügt:

# Pull request template (excerpt)

## Requirement
Requirement: REQ-____

## AI assistance
- [ ] No AI assistance
- [ ] AI-assisted (single files / small changes)
- [ ] Substantially AI-generated (reviewed and adjusted manually)

## Verification
- [ ] Tests derived from the requirement, not from the implementation
- [ ] Error and permission paths covered
- [ ] New dependencies reviewed

Wichtig ist die Trennung, die dahintersteht: Das Werkzeug erzeugt einen Vorschlag, die Person übernimmt ihn. Wer einen Änderungssatz einreicht, verantwortet ihn vollständig – unabhängig davon, wie viel davon getippt wurde. Diese Formulierung gehört in die Richtlinie, weil sie jede Diskussion über „Schuld des Modells“ beendet.

7. Herkunft und Lizenzen

Die rechtliche Bewertung generierter Codeanteile ist je nach Rechtsraum und Vertragslage unterschiedlich und entwickelt sich weiter. Unabhängig davon lassen sich drei praktische Vorkehrungen treffen, die in jeder Konstellation helfen:

• Lizenzscanning für Abhängigkeiten automatisieren und eine Positivliste erlaubter Lizenzen führen.
• Auffällig lange, ungewöhnlich spezifische Codeblöcke im Review hinterfragen, statt sie ungeprüft zu übernehmen.
• Vertragliche Zusicherungen der Anbieter dokumentieren – was mit Eingaben passiert, ob sie zum Training verwendet werden, welche Freistellungen zugesagt sind.

Für Kundenprojekte empfiehlt sich außerdem eine klare Position im Angebot: ob KI eingesetzt wird, in welcher Form und mit welchen Prüfungen. Das erspart die unangenehmere Variante, die Frage erst im Projekt zu klären.

8. Wer entscheidet was

• Geschäftsführung / CTO: gibt die Richtlinie frei und entscheidet über zugelassene Betriebsmodelle.
• Security / Datenschutz: bewertet Werkzeuge und ordnet sie Datenklassen zu.
• Engineering: setzt Prüfpflichten technisch um und pflegt die Gates.
• Projekt- oder Teamleitung: entscheidet den Einsatz im konkreten Projekt im Rahmen der Richtlinie – und klärt Kundenzustimmung, wo nötig.
• Jede einreichende Person: verantwortet den eingereichten Änderungssatz.

Für Organisationen mit Managementsystem lässt sich das andocken, statt eine Parallelstruktur aufzubauen: ISO 9001 für die Prozessseite, ISO/IEC 27001 für Informationssicherheit, ISO/IEC 42001 als Managementsystem für KI. Diese Normen zertifizieren Organisationen und Prozesse – nicht ein Werkzeug und nicht das entstehende Softwareprodukt.

9. Was Sie beobachten sollten

Zahlen zur Produktivität sind in diesem Feld notorisch unzuverlässig, und zugekaufte Kennzahlen helfen nicht weiter. Aussagekräftig sind Größen, die Sie ohnehin erheben – im Vorher-Nachher-Vergleich im eigenen Haus:

• Änderungsvolumen pro Review – steigt es, sinkt die reale Prüftiefe.
• Durchlaufzeit von Review und Merge – zeigt, ob der Engpass sich verschoben hat.
• Ausfälle an den Gates nach Kategorie – wo entstehen Fehler wirklich?
• Fehler nach Auslieferung, bezogen auf den Änderungsumfang.
• Nacharbeitsanteil: Wie viel des generierten Codes wurde im Review substanziell geändert?

Diese Größen gehören intern ausgewertet und nicht nach außen kommuniziert, solange sie nicht belastbar sind. Erfundene Prozentwerte sind in Angeboten ein Risiko, kein Argument.

10. Einführung in drei Stufen

Typische Fehler

• Pauschales Verbot – erzeugt Nutzung ohne Aufzeichnung.
• Regeln pro Werkzeug statt pro Datenklasse; veraltet binnen Monaten.
• Richtlinie ohne technische Durchsetzung – unter Termindruck wirkungslos.
• Sonderprozess für KI-Code, der die regulären Prüfungen aufweicht statt sie zu nutzen.
• Produktivitätsversprechen nach außen, bevor eigene Zahlen vorliegen.
• Kundenzustimmung erst im Projekt klären, statt im Angebot.

Checkliste: AI Coding Governance

Fazit

Gute AI Coding Governance ist unspektakulär. Sie besteht aus einer kurzen Richtlinie, einer Handvoll Datenklassen, den ohnehin sinnvollen Quality Gates und einer klaren Zuordnung von Verantwortung. Was sie wirksam macht, ist nicht ihr Umfang, sondern dass sie an den Stellen greift, an denen Arbeit tatsächlich stattfindet – im Repository, in der Pipeline, im Review.

Der Nebeneffekt ist der eigentliche Gewinn: Ein Team mit klaren Regeln kann KI deutlich offensiver einsetzen als eines, das jeden Einzelfall diskutiert. Kontrolle ist hier keine Bremse, sondern die Voraussetzung dafür, Tempo überhaupt zulassen zu können.