GitHub Copilot Code Review geht einen Schritt weiter: Jede Review enthält nun eine Einschätzung, ob ein Pull Request aus Sicht von Copilot freigabebereit ist. Zusätzlich können Administratoren Copilot in einer öffentlichen Vorschau erlauben, eine formale Genehmigung abzugeben, die für die erforderlichen Pull-Request-Freigaben eines Repositorys zählt. Damit wird aus einer Empfehlung potenziell ein wirksames Element der Merge-Governance.
Für Unternehmen ist die entscheidende Frage nicht, ob Copilot gute Hinweise liefert. Sie lautet: Unter welchen Bedingungen darf ein KI-System einen organisatorisch relevanten Kontrollpunkt erfüllen? Die Funktion ist standardmäßig deaktiviert und lässt sich auf Enterprise-, Organisations- und Repository-Ebene sowie nach Dateipfaden steuern. Genau diese Granularität sollte der Ausgangspunkt eines begrenzten Piloten sein.
Assessment und formale Freigabe sind nicht dasselbe
GitHub unterscheidet zwei Ebenen. Das Approval Assessment erscheint im Übersichtskommentar jeder Copilot-Code-Review und signalisiert lediglich Copilots Einschätzung. Es zählt nicht für Merge-Anforderungen. Erst wenn Administratoren die Approval-Funktion aktivieren, kann Copilot eine Genehmigung einreichen, die eine Required-Approvals-Regel erfüllt.
Bestätigt ist außerdem: Wird nach Copilots Genehmigung ein neuer Commit gepusht, verfällt die Approval wie bei einem menschlichen Reviewer. Eine neue Copilot-Review kann anschließend angefordert werden. Das schützt vor einer Freigabe, die trotz nachträglicher Codeänderung bestehen bleibt. Es sagt jedoch nichts darüber aus, ob fachliche Anforderungen, Architekturfolgen oder betriebliche Risiken vollständig erkannt wurden.
Welche Dateipfade Copilot freigeben darf
Die folgende Einordnung ist ein GNS-Entscheidungsrahmen, keine von GitHub veröffentlichte Risikoklassifizierung. Je höher der mögliche Schaden einer Änderung und je mehr Kontext außerhalb des Diffs benötigt wird, desto weniger sollte eine Copilot-Approval eine menschliche Freigabe ersetzen.
- Geeignet für einen frühen Pilot: Dokumentation, interne Beispiele, isolierte Testdaten und automatisch erzeugte Dateien mit deterministischer Validierung.
- Nur ergänzend freigeben: Anwendungscode mit guter Testabdeckung, klaren Modulgrenzen und verpflichtendem zweiten Review bei risikoreichen Änderungen.
- Vom KI-Approval ausnehmen: Authentifizierung, Autorisierung, Zahlungslogik, Datenmigrationen, Infrastruktur, Secrets, Abhängigkeitspolitik und Sicherheitskontrollen.
- Immer separat behandeln: Änderungen, die Datenschutz, regulatorische Pflichten, Produktionszugriffe oder irreversible Geschäftsprozesse betreffen.
- Nicht nur per Endung filtern: Pfadregeln sollten Repository-Struktur und Eigentümerschaft abbilden; sicherheitskritische Konfiguration liegt nicht immer in offensichtlich benannten Dateien.
Die Pfadgrenze ist damit kein Komfortmerkmal, sondern das wichtigste technische Mittel zur Begrenzung des Entscheidungsraums. Unternehmen sollten die erlaubten Pfade positiv definieren. Eine kurze Allowlist für unkritische Bereiche ist leichter zu prüfen als eine lange Ausschlussliste, bei der neue Verzeichnisse unbeabsichtigt freigegeben werden können.
Pilotplan ohne Aufweichung des Vier-Augen-Prinzips
- Baseline erfassen: Für ausgewählte Repositorys Review-Dauer, nachträgliche Korrekturen, zurückgezogene Approvals und produktionsrelevante Fehler dokumentieren.
- Scope festlegen: Ein Repository, wenige risikoarme Pfade und einen eindeutigen technischen Eigentümer wählen; Enterprise- und Organisationsvorgaben zentral dokumentieren.
- Shadow-Phase starten: Copilots Assessment und mögliche Approval auswerten, ohne dass sie zunächst den letzten menschlichen Pflichtreview ersetzt.
- Negativfälle testen: Unzureichende Tests, riskante Konfigurationsänderungen, versteckte Berechtigungsfolgen und neue Commits nach einer Approval gezielt prüfen.
- Begrenzt aktivieren: Erst nach bestandener Shadow-Phase die zählende Approval für die freigegebenen Pfade zulassen und einen zusätzlichen menschlichen Review für Hochrisikoklassen erzwingen.
- Regelmäßig neu bewerten: Pfade, Fehlentscheidungen und Umgehungsmöglichkeiten nach Strukturänderungen am Repository erneut prüfen.
Der wirtschaftliche Nutzen sollte gegen zusätzliche Kontrollkosten gemessen werden. Eine schnellere Merge-Zeit ist nur dann wertvoll, wenn Rework, Rückrollungen und Sicherheitsbefunde nicht steigen. Deshalb gehören neben Durchlaufzeit auch die Präzision relevanter Findings, übersehene Fehler, menschliche Korrekturen nach Copilot-Approval und die Zahl später verworfener Freigaben in die Pilotmessung.
Klare Abbruchkriterien vor der Aktivierung festlegen
Ein Pilot braucht vorab definierte Stoppsignale. Dazu zählen eine Copilot-Approval trotz fehlgeschlagener Pflichtchecks, wiederholt übersehene sicherheitsrelevante Änderungen, unklare Pfadzuordnung oder fehlende Auditierbarkeit der administrativen Konfiguration. Auch ein starker Zeitgewinn rechtfertigt keine Ausweitung, wenn Teams die Verantwortung für eine gemergte Änderung nicht eindeutig zuordnen können.
Organisatorisch sollte die KI-Freigabe einem benannten Policy Owner gehören, nicht dem einzelnen Entwickler. Enterprise-Administratoren entscheiden, ob Organisationen die Funktion überhaupt nutzen dürfen. Organisationen legen fest, welche Repositorys teilnehmen. Repository-Verantwortliche definieren die Pfade. Diese Ebenen sollten sich ergänzen, ohne dass eine lokale Einstellung zentrale Sicherheitsvorgaben umgehen kann.
GitHubs neue Funktion kann Review-Wartezeiten reduzieren und Routineänderungen schneller durch den Prozess bringen. Ihr Wert entsteht aber erst durch eine kontrollierte Zuständigkeit: Copilot darf nur in einem begrenzten, messbaren Bereich formal zustimmen; Tests und Schutzregeln bleiben unabhängig; kritische Änderungen erhalten weiterhin menschliche Verantwortung. So wird die Approval zu einem gezielten Automationsbaustein statt zu einem pauschalen Ersatz für Software-Governance.