KI-Governance mit Git erfüllen

KI-Governance mit Git erfüllen

0:00 In vielen Unternehmen entsteht gerade ein Dokument, das vor zwei Jahren noch niemand kannte: die KI-Richtlinie. Sie regelt, unter welchen Bedingungen generative Modelle eingesetzt werden dürfen. Und sie hat eine Eigenschaft, die sie von vielen anderen Richtlinien unterscheidet — sie muss nachweisbar sein. Es genügt nicht, dass man sich daran hält; man muss es zeigen können. Genau hier wird Git interessant, denn ein Repository ist ohnehin ein lückenloses Protokoll.

0:27 In diesem Modul sehen wir uns an, welche Teile einer solchen Richtlinie sich dort verankern lassen — und welcher Teil eben nicht.

Nachweisbar statt gut gemeint

0:35 Vier Themen liegen vor uns. Zuerst sortieren wir, woraus eine KI-Richtlinie typischerweise besteht. Dann geht es um Attribution — die Frage, welche Teile des Codes mit KI entstanden sind und wie belegbar die Antwort ist. Anschließend betrachten wir KI-gestützte Code Reviews, mit einem ehrlichen Blick auf ihre Grenzen. Und zum Schluss die Anweisungsdatei, die einem Agenten das mitgibt, was ein neuer Kollege in der ersten Woche erfährt.

1:00 Das ist der Baustein mit dem besten Verhältnis von Aufwand zu Wirkung. Vier Fähigkeiten. Sie kennen die Bausteine einer KI-Richtlinie und wissen, welche davon in Git verankert werden können. Sie beurteilen drei Wege der Attribution nach Aufwand und Durchsetzbarkeit — und wählen bewusst, statt den erstbesten zu nehmen. Sie setzen KI-Reviews dort ein, wo sie tatsächlich tragen, und ersparen sich die Stellen, an denen sie nur Rauschen erzeugen.

1:27 Und Sie schreiben eine Anweisungsdatei, die Agenten verlässlich leitet. Ein Hinweis vorweg: Dieses Modul enthält weniger Befehle als die vorigen. Es enthält dafür mehr Entscheidungen.

Anforderungen einer KI-Richtlinie

1:39 Beginnen wir mit dem Dokument selbst. Wie sieht eine schlanke KI-Richtlinie aus, was steht üblicherweise drin — und welcher Teil davon lässt sich technisch überhaupt nachweisen? Eine KI-Richtlinie beschreibt, unter welchen Bedingungen ein Unternehmen generative Modelle einsetzt. Die guten unter ihnen haben ein doppeltes Ziel: Sie sollen Tempo und Innovation erhalten und gleichzeitig das Risiko begrenzen.

2:03 Das klingt nach einem Widerspruch, ist aber keiner — es ist derselbe Gedanke wie bei einer Leitplanke. Sie bremst nicht, sie verhindert nur das Abkommen. Von den vier typischen Bausteinen lassen sich drei unmittelbar in Git abbilden. Der vierte ist der wichtigste und der einzige, für den Git nichts tun kann. Sehen wir uns die Verteilung an. Kennzeichnung, Review und Anweisungsdatei sind technische Fragen mit klaren Antworten im Repository.

2:30 Der erste Baustein ist von anderer Art: Ob Ihre Eingaben beim Anbieter zum Training verwendet werden, steht in einem Vertrag und in einer Kontoeinstellung — nicht in Git. Trotzdem steht er hier an erster Stelle, und das ist Absicht. Es ist das größte Risiko der ganzen Liste. Ein falsch konfigurierter Zugang kann Quellcode und Kundendaten aus dem Haus tragen, und keine Branch-Regel der Welt hilft dagegen.

2:54 Vier Kategorien, die niemand versehentlich in ein Modell geben will. Besonders geschützte Daten — Gesundheits- und Finanzinformationen etwa, bei denen schon die Weitergabe ein Verstoß ist. Personenbezogene Daten von Nutzern; die hat praktisch jedes Unternehmen, auch ohne besondere Branche. Das geistige Eigentum des Unternehmens, und dazu zählt der Quellcode selbst.

3:16 Und Kundendaten, deren Bekanntwerden Wettbewerbern nützt. Der unangenehme Teil daran: Diese Daten reisen selten absichtlich. Sie stecken in einem Testdatensatz, in einem Fehlerprotokoll, in einem Ausschnitt, den jemand schnell in den Chat kopiert hat. Fünf Schritte, und der letzte macht den Unterschied. Klären, was mit den Eingaben passiert. Einen Attributionsweg wählen und verbindlich machen.

3:41 Festlegen, wo das KI-Review stattfindet. Die Anweisungsdatei anlegen und committen. Und dann: für jeden Punkt festhalten, woran die Einhaltung erkennbar ist. Ohne diesen fünften Schritt haben Sie eine Absichtserklärung. Mit ihm haben Sie etwas, das einem Audit standhält. Und dieser Schritt ist auch derjenige, der die vorherigen diszipliniert — eine Regel, für die Ihnen kein Nachweis einfällt, ist meist keine gute Regel.

4:08 Nehmen Sie Ihre Richtlinie und gehen Sie sie Punkt für Punkt durch: Kann Git das tragen, und mit welchem Artefakt führen Sie den Nachweis? Ein Commit, eine Datei, eine Einstellung. Falls es noch keine Richtlinie gibt — und das ist derzeit eher die Regel als die Ausnahme — genügt der Entwurf von drei Regeln. Die Übung funktioniert in beide Richtungen: Sie zeigt nicht nur, was technisch machbar ist, sondern oft auch, welche Formulierungen in der Richtlinie zu vage sind, um überhaupt geprüft zu werden.

4:37 Vier Denkfehler. Annehmen, Git löse die Frage nach den Trainingsdaten — das tut es nicht, und dieser Irrtum ist bequem. Regeln formulieren, deren Einhaltung niemand prüfen kann; die kosten nichts und bewirken nichts. Die Richtlinie in einem Wiki ablegen, das Agenten nie erreichen — dann kennt sie zwar die Belegschaft, aber nicht das Werkzeug, um das es geht.

4:58 Und der vierte, der im Ernstfall teuer wird: Nachweise erst erzeugen, wenn die Prüfung schon läuft. Attribution funktioniert nur vorwärts. Was nicht gekennzeichnet wurde, lässt sich später nicht rekonstruieren.

KI-Commits attributieren

5:12 Kommen wir zur Kennzeichnung. Die Frage klingt zunächst einfach: Welcher Code kam von der KI? Interessant wird sie erst, wenn man dazu nimmt, wie belegbar die Antwort sein muss. Attribution heißt, im Repository festzuhalten, welche Anteile des Codes mit KI entstanden sind. Die Spannweite ist dabei beachtlich. Am einen Ende steht eine zusätzliche Zeile in der Commit-Nachricht — schnell eingerichtet, grob in der Auflösung.

5:38 Am anderen Ende steht zeilengenaue Herkunft samt aufbewahrtem Prompt. Denken Sie an den Unterschied zwischen einem Kassenbon und einer vollständigen Buchführung: Beides dokumentiert, aber sie beantworten verschiedene Fragen. Und genau darum geht es bei der Wahl — welche Frage wollen Sie später beantworten können? Vier Gründe, und sie sind unterschiedlich zwingend. Auswertung: zu wissen, welche Teams und Bereiche wie stark mit KI arbeiten — nützlich, aber selten dringend.

6:06 Technische Schulden: Wenn Sie an einer Stelle ein Anti-Pattern finden, können Sie gezielt dort suchen, wo derselbe Agent gearbeitet hat. Sicherheit, aus demselben Grund: Modelle machen wiederkehrende Fehler, und wer weiß, wo sie geschrieben haben, kann fokussiert prüfen. Und der vierte Grund ist juristisch: Für rein maschinell erzeugten Code ist der Urheberrechtsschutz umstritten.

6:29 Wer menschlichen Anteil belegen kann, steht in dieser Diskussion besser da. Diese Tabelle hat keine Gewinnerzeile, und das ist der Punkt. Die Co-Autor-Zeile ist in einer Minute eingerichtet und kostet danach nichts — dafür kann sie jeder abschalten, und niemand merkt es. Die PR-Vorlage bringt geteilte Verantwortung ins Spiel, weil mehrere Menschen beteiligt sind, verlangt aber bei jedem Pull Request Handarbeit.

6:53 Und der dritte Weg liefert die feinste Auflösung bei zentraler Steuerbarkeit, zum Preis einer aufwendigen Einführung. Entscheidend ist die Zeile Durchsetzbarkeit. Wenn Ihre Zahlen vollständig sein müssen, fällt die erste Spalte aus — so bequem sie ist. So sieht der einfachste Weg aus: eine zusätzliche Zeile im Fußbereich der Commit-Nachricht.

7:14 Worauf es ankommt, ist ihre Position — sie steht nach einer Leerzeile, wie jede Fußzeile, und wird von Plattformen entsprechend ausgewertet. Der Charme dieser Lösung liegt in ihrer Schlichtheit: Sie ist Teil des Commits und wandert mit ihm überallhin, auch beim Wechsel des Anbieters. Und die Grenze ist gleich mitgeliefert: Die Zeile sagt, dass ein Agent beteiligt war. Sie sagt nicht, in welchem Umfang.

7:38 Ob der Mensch drei Zeilen oder dreihundert beigesteuert hat, bleibt offen. Die Übung dreht die übliche Reihenfolge um. Formulieren Sie zuerst die Frage, die Sie später beantworten wollen — und wählen Sie dann den Weg, der sie beantwortet. "Wie viel Prozent unseres Codes ist KI-generiert?" verlangt etwas anderes als "Wurde dieses Modul mit KI gebaut?".

7:59 Zwei Kriterien aus der Tabelle sollen Ihre Wahl tragen, und ein Beispiel-Commit soll die Kennzeichnung schon zeigen. Wer die Reihenfolge umdreht und mit dem Werkzeug beginnt, sammelt am Ende Daten, die keine Frage beantworten. Vier Punkte, und der letzte ist der heikelste. Attribution einführen, ohne zu wissen, wer die Daten auswertet — dann pflegen Sie Metadaten für ein Publikum, das es nicht gibt.

8:23 Auf freiwillige Schalter setzen und die Zahlen für vollständig halten; sie sind es systematisch nicht. Attribution mit Verantwortung verwechseln — es zeichnet weiterhin ein Mensch für den Code, die Kennzeichnung ändert daran nichts. Und schließlich: Prompts mit sensiblen Inhalten dauerhaft im Repository ablegen. Wer Prompts aufbewahrt, bewahrt auch alles auf, was jemand hineinkopiert hat.

KI-gestütztes Code Review

8:47 Bisher haben wir KI Code schreiben lassen. Jetzt lassen wir sie welchen lesen. Das funktioniert erstaunlich gut — aber nur für einen bestimmten Ausschnitt der Fragen, die ein Review beantworten soll. Ein KI-Review ist ein erster Durchgang über die eigenen Änderungen, der offensichtliche Probleme findet, bevor ein Mensch liest.

9:06 Der Vergleich, der mir am besten gefällt, ist die Rechtschreibprüfung. Sie findet Tippfehler zuverlässig und spart dem Lektor Zeit — aber sie beurteilt nicht, ob der Text etwas taugt. Und wie die Rechtschreibprüfung braucht auch das KI-Review einen klaren Gegenstand. Der ist der Diff, also das, was sich geändert hat. Wer das gesamte Repository prüfen lässt, bekommt eine allgemeine Einschätzung, aber keine Aussage über die eigene Arbeit.

9:33 Die linke Spalte hat eine Gemeinsamkeit: Es sind Muster, die überall gleich aussehen. Bekannte Schwachstellen, versehentlich eingecheckte Geheimnisse, nicht behandelte Fehlerfälle, tote Codepfade — dafür braucht man kein Hauswissen. Die rechte Spalte hat ebenfalls eine Gemeinsamkeit: Alles dort verlangt Kontext, den das Modell nicht hat.

9:52 Ihre Geschäftslogik, Ihre Schwellenwerte, Ihre Architektur über das Repository hinaus, die Anforderung, die im Ticket steht. Und die letzte Zeile ist eine reine Kostenfrage: Stil und Testabdeckung messen wir seit zwanzig Jahren mit Werkzeugen, die das billiger und verlässlicher können. Fünf Schritte, und Schritt drei ist der, den fast alle überspringen. Das Review an den Diff binden — klar.

10:16 Kontext mitgeben, also zwei Sätze dazu, was gebaut wurde und warum — das hebt die Trefferquote spürbar. Aber dann kommt die Anweisungsdatei mit den Prüfschwerpunkten, und die ist der Unterschied zwischen Befunden und Ratschlägen. Ohne sie erhalten Sie allgemeine Software-Weisheiten. Mit ihr erhalten Sie Hinweise auf das, was in Ihrem Haus als Problem gilt. Danach bleiben nur noch zwei Entscheidungen: wo es läuft und ob es blockiert.

10:43 Fünf Kriterien, und die Antworten sind erfreulich klar verteilt. Wenn Sie Nachweisbarkeit brauchen, führt kein Weg an der entfernten Variante vorbei — lokale Prüfungen sind nicht manipulationssicher, und das ist keine Unterstellung, sondern eine Eigenschaft. Wenn Sie schnelle, private Rückmeldung wollen, bevor jemand Ihren Code sieht, gewinnt die lokale Variante. Beide Bedürfnisse sind legitim, und sie schließen sich nicht aus.

11:08 Die Fußzeile fasst deshalb zusammen, was in der Praxis funktioniert: lokal grob und früh, remote verbindlich und dokumentiert. Schneiden Sie eine KI-Prüfung so zu, dass sie Ihre Änderungen beurteilt — nicht Ihr Projekt. Der Erfolgstest hat zwei Teile, und beide sind wichtig. Erstens: mindestens ein konkreter Fundort mit Datei und Zeile. Ein Review, das nur allgemeine Hinweise gibt, hat den Diff nicht wirklich gelesen.

11:34 Zweitens: keine Wiederholung dessen, was Ihr Linter ohnehin meldet. Wenn das Modell Ihnen Einrückungen erklärt, haben Sie Geld für eine Rechtschreibprüfung ausgegeben, die Sie schon besitzen. Vier Fallen. Das gesamte Repository prüfen lassen und in Befunden ertrinken — nach dem dritten Review liest sie niemand mehr, und damit ist das Werkzeug tot.

11:56 Stil und Testabdeckung teuer per Modell messen. Befunde ungeprüft übernehmen: Auch das Review irrt, und es irrt selbstbewusst. Und der vierte, der eher eine Haltungsfrage ist: das KI-Review als Ersatz für den menschlichen Blick verkaufen. Es ist der erste Durchgang. Das Urteil bleibt bei jemandem, der die Fachlichkeit kennt und Verantwortung trägt.

Anweisungsdateien für Agenten

12:18 Zum Schluss dieses Moduls der Baustein, der am wenigsten kostet und am meisten bewirkt. Was macht man eigentlich, wenn ein neuer Kollege ins Team kommt? Man macht ein Onboarding. Genau das braucht ein Agent auch. Eine Anweisungsdatei ist eine Markdown-Datei im Repository, die einem Agenten Projektwissen mitgibt: Technologien mit Versionen, gebräuchliche Befehle, Stilregeln, Testerwartungen, Sicherheitsvorgaben.

12:44 Die naheliegende Frage lautet: Ist das nicht die Aufgabe der README? Nein — die beiden ergänzen sich. In die README gehört, was Menschen brauchen. In die Anweisungsdatei gehört, was für Menschen zweitrangig ist, für ein Werkzeug aber entscheidend. Der Nebeneffekt ist angenehm: Ihre README wird wieder kürzer und lesbarer, statt zur Sammelstelle für Details zu verkommen.

13:08 Vier Vorteile. Ein vorhersagbarer Ort, an dem jeder Agent seine Regeln findet — das ist der eigentliche Trick, denn Agenten suchen dort automatisch. Gleiche Ergebnisse, unabhängig davon, wie jemand seinen Prompt formuliert; das nimmt eine erhebliche Streuung aus dem Team. Entlastung der README. Und für große Repositories der praktischste Punkt: Sie können je Teilprojekt eine eigene Datei hinterlegen.

13:32 Der Agent nimmt die nächstgelegene — er läuft im Verzeichnisbaum nach oben, bis er eine findet. In einem Monorepo ist das der Unterschied zwischen brauchbaren und generischen Vorgaben. Eine Abwägung, die sich an einer einfachen Frage entscheidet: Wie viele Modelle sind bei Ihnen im Einsatz? Bei ein bis zwei ist der modellspezifische Weg bequem — die Namenskonventionen greifen von selbst, und Sie können besondere Fähigkeiten nutzen, etwa rollenbezogene Dateien für Tests oder Dokumentation.

14:01 Sobald es mehr werden oder Sie an einem offenen Projekt arbeiten, kippt die Rechnung: Dann pflegen Sie dieselbe Information mehrfach, und die Fassungen laufen auseinander. Die universelle Datei kostet eine einmalige Konfiguration und spart danach dauerhaft Pflege. Fünf Abschnitte, und der erste ist der, bei dem es meistens hakt. Ein Projektüberblick mit konkreten Versionen — nicht "Node und TypeScript", sondern die Hauptversionen.

14:26 Erst damit weiß das Modell, welche Sprachmittel überhaupt zur Verfügung stehen. Dann die Befehle, die es häufig braucht. Dann Stilregeln, dann Testerwartungen und Sicherheitsvorgaben. Und zum Schluss alles, was Sie einem neuen Kollegen auch sagen würden. Die Fußzeile nennt die praktische Grenze: unter hundert Zeilen bleiben, üblich sind vierzig bis achtzig.

14:48 Was zu lang ist, wird nicht vollständig behalten — und wirkt dann auch nicht. Ein kurzer Ausschnitt, der das Prinzip zeigt. Worauf es ankommt, ist die Konkretheit. "Testabdeckung hundert Prozent" ist eine Vorgabe, an der man scheitern kann. "Abdeckung gesund halten" ist eine Floskel und wird entsprechend behandelt. Dasselbe gilt für die Versionen und für die Regel zu den Beispieldaten.

15:12 Je präziser eine Zeile ist, desto zuverlässiger richtet sich ein Modell danach — und desto eher merken Sie im Ergebnis, ob die Datei überhaupt gelesen wurde. Vage Regeln sind nicht nur wirkungslos; sie sind auch nicht überprüfbar. Vier Punkte. Die Datei so lang schreiben, dass sie nicht vollständig behalten wird — mehr ist hier nicht besser. Vage Vorgaben statt konkreter Zahlen, wie eben besprochen.

15:37 Änderungen an der Datei ungeprüft übernehmen: Das ist der wichtigste Punkt in dieser Liste, denn diese Datei steuert Verhalten. Behandeln Sie sie sicherheitstechnisch wie eine Pipeline-Konfiguration — wer sie ändert, ändert, was Agenten in Ihrem Projekt tun. Und der letzte: die Datei einmal schreiben und nie wieder anfassen. Sie ist ein lebendes Dokument, so wie die Konventionen des Teams auch.

16:01 Verdichten Sie Ihr Projektwissen so, dass ein Agent ohne Rückfragen im Stil des Hauses arbeitet. Unter hundert Zeilen, versioniert im Repository. Der Test dafür steht im Hinweis und ist der schönste dieses Moduls: Lassen Sie eine kleine Erweiterung generieren und sehen Sie nach, ob Validierung und Tests von selbst entstehen — ohne dass Sie im Prompt danach gefragt haben.

16:23 Wenn ja, wirkt die Datei. Wenn nein, ist sie entweder zu lang, zu vage oder liegt am falschen Ort. Alle drei Fälle sind schnell behoben.

Modul 5 geschafft

16:31 Halten wir fest: Drei der vier Richtlinien-Bausteine lassen sich in Git verankern — Attribution, Review und Anweisungsdatei. Der vierte, die Frage nach den Trainingsdaten, bleibt eine Sache von Vertrag und Konfiguration, und er ist deshalb nicht weniger wichtig. Den Attributionsweg wählt man nach dem Zweck der Auswertung, nicht nach dem geringsten Aufwand. Und KI-Reviews gehören an den Diff, mit klaren Prüfschwerpunkten.

16:56 Im letzten Modul verlassen wir den eigenen Rechner endgültig und sehen uns an, welche Grenzen sich auf dem Server ziehen lassen — dort, wo sie verbindlich sind.