KI-Coding-Governance

Erlaubt ein Team KI-gestützte Änderungen, braucht es eine explizite Antwort auf die Engineering-Lead-Frage „wie kontrollieren wir diese Änderung?“: deklarierte Regel, Kontrollen, Belege und benannter Entscheidungsinhaber.

Diese Werte wurden am 17. Juli 2026 gegen Sonars Umfragematerial geprüft. Sie beschreiben dessen Stichprobe und sind weder universelle Adoptionstelemetrie noch Audit-Ergebnis oder Wirksamkeitsnachweis. Separat definiert der EU AI Act Pflichten nach Akteur, System und Nutzung; Artikel 4 behandelt KI-Kompetenz bei Anbietern und Betreibern. Welche Pflichten greifen, ist juristisch zu bewerten. Ein Workflow-Beleg kann diese Bewertung informieren, ist aber keine Compliance-Feststellung.

Ein brauchbares Governance-Modell trennt sechs Dinge:

• Policy - welche Tools sind freigegeben, für welchen Code, mit welchen Daten. Sie benennt die Regel; sie setzt sie nicht selbst durch.
• Entscheidungsrecht - wer eine technische Änderung, Ausnahme oder Veröffentlichung freigeben darf und wo geschäftliche oder rechtliche Freigabe getrennt bleibt.
• Kontrolle - ein Mechanismus wie Auftragsgrenze, Branch-Regel, Pflichtcheck oder menschliches Gate, der einen Teil der Policy anwendet. Wie so ein Gate aussieht, wenn es gebaut statt nur aufgeschrieben ist, steht unter geschützte Dateien und veraltete Freigaben.
• Verifikation pro Änderung - der Verifikations-Loop: ein begrenzter Vergleich mit dem deklarierten Auftrag plus ausgewählte Checks. Ein Pass sagt, was diese Checks beobachteten; er beweist weder Korrektheit noch Sicherheit oder Freigabe für jeden Zweck.
• Belegartefakt - Prüfberichte, die Eingaben, Kommandos, Ergebnisse, Lücken und Entscheidungen festhalten. Eine prüfbare Aufzeichnung ist keine Garantie über ihren Gegenstand.
• Datenkontrolle - wissen, was die eigene Umgebung verlässt, pro Tool. Local-first-Setups können Governance-Zustand und konfigurierte Datenpfade leichter prüfbar machen. Tool-, Modell-, Netzwerk- und Laufzeitverhalten muss das Team trotzdem verifizieren.

„Eine Seite, nicht vierzig“ ist wörtlich gemeint - eine funktionierende Policy passt auf einen Bildschirm:

Tools:        Claude Code, Cursor (freigegeben) · andere: erst fragen
Scope:        alle Repositories außer infra/secrets/*
Daten:        Modell-APIs nur unter Firmenverträgen ·
              keine Quellcode-Uploads an nicht freigegebene Dienste

Pro Auftrag:  Ziel + Grenzen schriftlich VOR dem Run
Pro Änderung: Validierung, die das Modell nicht verfasst hat
              (Tests/Typen/Build)
Pro Run:      Prüfbericht beim Code gespeichert

Gate:         benannter Code-Owner übernimmt oder verwirft technisch
              · geschäftliche/rechtliche Freigaben bleiben getrennt
              · kein Auto-Commit
Review:       Policy wird quartalsweise geprüft · Owner: Eng Lead

1. Mit einem Team, einem Workflow starten. Schriftliche Aufträge und ein benannter technischer Entscheidungsinhaber machen Regel und Entscheidungsrecht sichtbar; sie garantieren keine Entscheidungsqualität.
2. Belege automatisch machen. Kommandos, Ergebnisse und Entscheidungen im Workflow erfassen und dann auf Vollständigkeit und Relevanz prüfen. Automation macht ein Artefakt nicht von selbst richtig.
3. Den Nachweis monatlich lesen. Übersprungene Validierungen, Grenzbefunde, Ausnahmen und Review-Entscheidungen sind Inputs für die Policy-Prüfung, kein Wirksamkeitsbeweis.
4. Über Adoption skalieren, nicht per Dekret. Erst erweitern, nachdem Workflow-Kosten, Belegqualität, übersehene Fälle und Entscheidungsklarheit im ersten Team beobachtet wurden.

Reality Graph ist dafür ausgelegt, Auftragsgrenzen, Validierungsergebnisse und prüfbare Belege mit einem expliziten menschlichen Gate festzuhalten. Seine Aufzeichnungen unterstützen eine Entscheidung; sie treffen sie nicht und beweisen weder Korrektheit, Sicherheit, Compliance noch Freigabequalität. Aktuell in privater Beta; sprecht mit dem Gründer oder fragt Early Access an.