Code-Review ist seit Jahrzehnten eine der wirksamsten Methoden der Qualitätssicherung in der Softwareentwicklung. Eine zweite Person liest die Änderung, stellt Fragen, entdeckt Denkfehler und verbreitet ganz nebenbei Wissen im Team. In der Praxis hat das Verfahren aber bekannte Schwächen: Reviews warten tagelang auf Freigabe, große Änderungen werden nur überflogen, und die Gründlichkeit hängt stark von Tagesform und Zeitdruck der Reviewer ab. Hinzu kommt, dass in kleinen Teams oft nur zwei oder drei Personen das System so gut kennen, dass ihr Urteil wirklich zählt.
Mit dem breiten Einsatz von Coding-Assistenten hat sich dieses Problem verschärft. Autovervollständigung, Chat im Editor und autonome Agenten erzeugen Code in einem Tempo, mit dem die menschliche Prüfung nicht mithält. Agenten liefern komplette Pull Requests, die formal sauber aussehen, aber subtile Fehler, unnötige Komplexität oder Sicherheitslücken enthalten können. KI-Code-Review ist die naheliegende Antwort: Wenn Maschinen beim Schreiben helfen, sollen sie auch beim Prüfen helfen. Drei Eigenschaften unterscheiden ein KI-Review von klassischen Prüfwerkzeugen:
Das klassische Review kennt zwei Rollen: die Person, die den Code geschrieben hat, und die Person, die ihn prüft. Mit KI-Review kommt eine dritte Rolle hinzu, die man am besten als unermüdliche, aber nicht immer treffsichere Vorprüferin beschreibt. Sie liest jede Zeile, kennt viele typische Fehlermuster und verfügt über breites Wissen zu Bibliotheken und Sprachen. Ihr fehlt aber das Wissen um Fachlogik, Kundenanforderungen, historische Entscheidungen und informelle Absprachen, die in keinem Dokument stehen.
In ausgereiften Teams entsteht daraus eine Arbeitsteilung: Die KI prüft zuerst und kümmert sich um Lesbarkeit, offensichtliche Fehler, fehlende Fehlerbehandlung, unsichere Muster und Konventionen. Die Autorin räumt diese Punkte selbst ab, bevor sie einen Menschen um Freigabe bittet. Der menschliche Reviewer sieht dann einen bereits bereinigten Pull Request und kann sich auf Architektur, Fachlichkeit und Seiteneffekte konzentrieren. Das Vier-Augen-Prinzip bleibt erhalten, wird aber um ein drittes, maschinelles Augenpaar ergänzt.
Sprachmodelle sind gut darin, lokale Probleme in einem überschaubaren Codeausschnitt zu erkennen: vergessene Nullprüfungen, falsche Vergleichsoperatoren, ungeschlossene Ressourcen, inkonsistente Benennung, fehlende Tests für neue Verzweigungen oder Abfragen, die anfällig für Injection sind. Ebenso hilfreich sind die automatischen Zusammenfassungen, die erklären, was eine Änderung tut, und damit gerade bei großen Pull Requests die Einarbeitung beschleunigen.
Schwächer ist KI-Review bei allem, was Wissen außerhalb des Codes voraussetzt. Ob eine Rabattberechnung den Vertragsbedingungen eines Großkunden entspricht, ob eine Änderung zur langfristigen Architektur passt oder ob ein Feld aus regulatorischen Gründen nicht gelöscht werden darf, kann ein Modell nur erraten. Hinzu kommen Fehlalarme, also Kommentare zu Problemen, die gar keine sind, und gelegentlich halluzinierte Behauptungen über Funktionen oder Bibliotheken. Ein KI-Review ist deshalb eine Liste von Hinweisen, die geprüft werden muss, und kein Urteil.
Drei Entwicklungen machen KI-Review für mittelständische Unternehmen gerade jetzt relevant. Erstens wächst durch Coding-Assistenten die Menge an Änderungen, während die Zahl erfahrener Reviewer gleich bleibt. Zweitens steigen die Anforderungen an nachweisbare Qualitätsprozesse, etwa durch Lieferantenaudits, Branchenstandards oder den Cyber Resilience Act, der Herstellern von Produkten mit digitalen Elementen Pflichten zur Schwachstellenbehandlung auferlegt. Drittens ist der Fachkräftemangel in der Softwareentwicklung für viele Unternehmen im DACH-Raum der eigentliche Engpass. Jede Stunde, die eine Senior-Entwicklerin nicht mit Routineprüfungen verbringt, steht für anspruchsvollere Arbeit zur Verfügung.
Wer bereits einen Coding-Assistenten im Unternehmen lizenziert hat, findet die Review-Funktion häufig schon im Vertrag. Bei GitHub lässt sich Copilot inzwischen als Reviewer zu einem Pull Request hinzufügen, GitLab bietet im Rahmen von Duo eine Review-Funktion für Merge Requests, und auch die großen Cloud-Anbieter haben Review-Funktionen in ihre Entwickler-Assistenten integriert. Der Vorteil liegt auf der Hand: kein neuer Anbieter, kein neuer Vertrag, kein neuer Eintrag im Verzeichnis von Verarbeitungstätigkeiten. Der Nachteil ist, dass diese Funktionen meist nur auf der eigenen Plattform laufen und weniger Feinsteuerung bieten.
Spezialisierte Dienste wie CodeRabbit oder Qodo Merge leben davon, beim Review gründlicher und konfigurierbarer zu sein. Typische Zusatzfunktionen sind ausführlichere Zusammenfassungen mit Ablaufdiagrammen, Lernmechanismen, die sich Feedback merken, pfadbezogene Anweisungen, die Einbindung von Linter-Ergebnissen und Unterstützung für mehrere Git-Plattformen. Die konkreten Funktionsgrenzen verschieben sich allerdings schnell, weil die Plattformanbieter nachziehen. Ein Vergleich sollte deshalb immer am eigenen Code und mit aktuellen Versionen erfolgen.
Die zweite Achse betrifft den Betrieb. Gehostete Dienste verarbeiten den Code in der Infrastruktur des Anbieters und geben ihn an ein Sprachmodell weiter, das häufig von einem dritten Unternehmen stammt. Für viele Anbieter bedeutet das Verarbeitung in den USA. Selbst betriebene Lösungen laufen dagegen in der eigenen CI-Umgebung, etwa als Pipeline-Schritt in GitLab oder als Container, und sprechen mit einem Modellzugang, den das Unternehmen selbst kontrolliert. Das kann ein Modell bei einem Cloud-Anbieter mit EU-Region, ein europäischer Modellanbieter oder ein vollständig lokal betriebenes Modell mit offenen Gewichten sein.
Zwischen beiden Polen gibt es Mischformen: Enterprise-Tarife mit dedizierter Umgebung, Bring-your-own-Model-Optionen, bei denen der gehostete Dienst den Modellzugang des Kunden nutzt, oder On-Premises-Installationen kommerzieller Produkte. Welche Variante passt, hängt weniger von der Teamgröße ab als von der Sensibilität des Codes und der vorhandenen Betriebskompetenz.
Die dritte Unterscheidung ist methodisch. Regelbasierte Werkzeuge, also Linter und statische Analyse, liefern reproduzierbare Ergebnisse: Dieselbe Eingabe erzeugt denselben Befund, und jeder Befund lässt sich auf eine dokumentierte Regel zurückführen. Sprachmodelle arbeiten probabilistisch: Sie finden Probleme, für die niemand eine Regel geschrieben hat, liefern aber nicht bei jedem Durchlauf exakt dieselben Hinweise. In der Praxis setzt sich der hybride Ansatz durch: Deterministische Werkzeuge bilden das verlässliche Fundament und können einen Merge blockieren, das KI-Review ergänzt die semantische Ebene und gibt Empfehlungen. Viele spezialisierte Dienste kombinieren beides bereits intern, indem sie Linter-Ergebnisse einlesen und vom Modell erklären lassen.
Ein brauchbares KI-Review deckt mehrere Ebenen ab. Auf der Ebene der Korrektheit geht es um Logikfehler, Randfälle, falsche Annahmen über Eingaben, Nebenläufigkeitsprobleme und fehlerhafte Fehlerbehandlung. Die Ebene der Sicherheit umfasst Injection-Anfälligkeiten, unsichere Kryptografie, fehlende Berechtigungsprüfungen und versehentlich eingecheckte Zugangsdaten. Bei der Wartbarkeit stehen Lesbarkeit, Duplikate, unnötige Komplexität, irreführende Namen und fehlende Dokumentation im Mittelpunkt. Hinzu kommen Testbarkeit und Testabdeckung sowie Performance, etwa unnötige Datenbankabfragen in Schleifen.
Für die Bewertung eines Werkzeugs lohnt es sich, diese Dimensionen getrennt zu betrachten. Manche Systeme sind stark bei Stil und Lesbarkeit, liefern aber wenig zu echten Fehlern. Andere finden Logikprobleme zuverlässig, kommentieren aber jede Kleinigkeit. Ein gezielter Test mit Pull Requests, in denen das Team bewusst bekannte Fehler platziert hat, zeigt schnell, wo die Stärken eines Werkzeugs liegen.
Die größte Gefahr für den Erfolg eines KI-Reviews ist nicht ein übersehener Fehler, sondern zu viele unwichtige Kommentare. Wenn jeder Pull Request zwanzig Hinweise zu Formulierungen, Formatierung und Geschmacksfragen erhält, gewöhnen sich Entwicklerinnen und Entwickler schnell daran, alle Kommentare ungelesen zu schließen. Dann gehen auch die wenigen wichtigen Hinweise unter. Gute Werkzeuge kategorisieren ihre Hinweise deshalb nach Schweregrad, etwa kritisch, wichtig und optional, und lassen sich so konfigurieren, dass nur ab einer bestimmten Stufe kommentiert wird.
Bewährt hat sich ein bewusstes Kommentarbudget: lieber drei treffende Hinweise pro Pull Request als fünfzehn mittelmäßige. Formatierungsfragen gehören in einen automatischen Formatierer, nicht in ein KI-Review. Stilfragen, auf die sich das Team geeinigt hat, gehören in den Linter. Das KI-Review sollte sich auf das konzentrieren, was regelbasierte Werkzeuge nicht können.
Die meisten Werkzeuge erlauben inzwischen eigene Anweisungen, oft in Form einer Konfigurationsdatei im Repository. Darin lässt sich festlegen, welche Pfade ignoriert werden, welche Konventionen gelten, welche Bibliotheken bevorzugt werden und worauf in bestimmten Modulen besonders zu achten ist, etwa auf Mandantentrennung in einer Datenbankschicht oder auf Einheiten bei physikalischen Größen in Steuerungssoftware. Diese Dateien sind wertvolles, versioniertes Teamwissen. Sie sollten wie Code behandelt werden: im Review geändert, begründet und regelmäßig überprüft.
Ein Modell, das nur den Diff sieht, beurteilt eine Änderung wie jemand, der eine einzelne Seite aus einem Buch liest. Es erkennt Rechtschreibfehler, aber nicht, ob die Handlung stimmig ist. Die Qualität eines KI-Reviews steigt deshalb mit dem Kontext, den das Werkzeug heranzieht. Dazu gehören die Definitionen aufgerufener Funktionen, die Stellen, an denen eine geänderte Schnittstelle verwendet wird, bestehende Tests und die Beschreibung im verknüpften Ticket. Werkzeuge mit einem Index der Codebasis können solche Zusammenhänge auch über Dateigrenzen hinweg herstellen.
Mehr Kontext bedeutet allerdings auch mehr Daten, die an das Modell fließen. Wer einen Index der gesamten Codebasis erlaubt, gibt dem Anbieter faktisch Zugriff auf das komplette Repository, nicht nur auf die geänderten Zeilen. Für die Datenschutzbewertung ist diese Unterscheidung wesentlich. Zudem kann zu viel ungefilterter Kontext die Qualität sogar verschlechtern, weil das Modell den Fokus verliert. Gute Werkzeuge wählen den Kontext deshalb gezielt aus.
Sprachmodelle formulieren auch dann überzeugend, wenn sie falsch liegen. Im Review äußert sich das in Hinweisen auf Fehler, die nicht existieren, in Behauptungen über das Verhalten von Bibliotheken, die nicht zutreffen, oder in Korrekturvorschlägen, die nicht kompilieren. Anbieter begegnen dem mit mehreren Techniken: Sie lassen Hinweise durch einen zweiten Modelldurchgang bestätigen, prüfen Vorschläge gegen Compiler oder Linter, verlangen Belegstellen im Code oder verwerfen Hinweise mit geringer Konfidenz.
Für Anwender heißt das: Fehlalarme gehören zum System und lassen sich nur reduzieren, nicht abschaffen. Entscheidend ist eine Kultur, in der KI-Hinweise begründet abgelehnt werden dürfen, ohne dass sich jemand rechtfertigen muss. Ein einfacher Daumen nach unten oder ein kurzer Kommentar reicht. Werkzeuge mit Lernfunktion nutzen solche Signale, um ähnliche Hinweise künftig zu unterdrücken.
Die neueste Entwicklungsstufe sind agentische Reviews. Statt den Code nur zu lesen, darf der Review-Agent Werkzeuge nutzen: Tests ausführen, im Repository suchen, Abhängigkeiten auflösen oder sogar einen Korrektur-Commit vorschlagen, der als eigener Pull Request oder als Commit auf dem Arbeitszweig erscheint. Manche Plattformen verbinden das Review direkt mit einem Coding-Agenten, der gefundene Probleme selbst behebt. Das spart Zeit, verschiebt aber die Verantwortung. Wenn die KI sowohl schreibt als auch prüft und korrigiert, fehlt die unabhängige Kontrolle.
INAGRO empfiehlt deshalb eine klare Regel: Automatische Korrekturen dürfen vorgeschlagen, aber nie ohne menschliche Freigabe auf geschützte Zweige gelangen. Agenten, die Code ausführen, brauchen eine abgeschottete Umgebung ohne Zugriff auf Produktionsdaten und Geheimnisse. Und wer Code von einem Agenten erzeugen lässt, sollte für das Review möglichst ein anderes Modell oder zumindest eine andere Konfiguration nutzen, damit sich systematische Schwächen nicht verdoppeln.
Die meisten Werkzeuge unterstützen GitHub, viele zusätzlich GitLab, Bitbucket und Azure DevOps. Für den Mittelstand ist ein Detail besonders wichtig: Viele Unternehmen betreiben ihre Git-Plattform selbst, etwa GitLab Self-Managed, GitHub Enterprise Server, Bitbucket Data Center oder Gitea. Gehostete Review-Dienste benötigen dann einen Zugang von außen auf den internen Server, was Firewall-Freigaben und eine sorgfältige Sicherheitsbewertung erfordert. Selbst betriebene Review-Agenten in der eigenen Pipeline umgehen dieses Problem, weil sie innerhalb des Netzes laufen. Vor der Auswahl sollte deshalb geprüft werden, welche Plattformvarianten ein Werkzeug offiziell unterstützt und ob alle Funktionen dort verfügbar sind.
In der Pipeline lässt sich das KI-Review mit bestehenden Prüfungen verzahnen. Ein bewährtes Muster: Zuerst laufen Formatierer, Linter, Typprüfung, Tests und Sicherheitsscans. Nur wenn diese grün sind oder ihre Ergebnisse vorliegen, startet das KI-Review und bekommt die Befunde als zusätzlichen Kontext. So kommentiert die KI nicht doppelt, was der Linter bereits gemeldet hat, und kann stattdessen erklären, warum ein Befund relevant ist. Für die Kostensteuerung ist es außerdem sinnvoll, das KI-Review nicht bei jedem Push, sondern erst beim Wechsel aus dem Entwurfsstatus oder auf ausdrückliche Anforderung auszulösen.
Ein wachsender Teil der Review-Arbeit wandert nach vorn, in die Entwicklungsumgebung. Viele Coding-Assistenten können die lokalen Änderungen vor dem Commit prüfen und auf Probleme hinweisen. Das ist effizienter als ein Review im Pull Request, weil Fehler korrigiert werden, bevor sie überhaupt im gemeinsamen Repository landen. Es ersetzt das Review im Pull Request aber nicht, denn dort entsteht die dokumentierte, für alle nachvollziehbare Prüfung. Sinnvoll ist eine Kombination: lokales KI-Review als persönliches Hilfsmittel, Review im Pull Request als Teamprozess mit Protokoll.
Funktionslisten ähneln sich zunehmend. Aussagekräftiger sind fünf Fragen. Erstens: Wie gut ist das Verhältnis von nützlichen zu überflüssigen Kommentaren am eigenen Code? Zweitens: Lässt sich das Werkzeug so konfigurieren, dass es die Konventionen und Schwerpunkte des Teams kennt? Drittens: Wohin fließt der Code, bei welchem Modellanbieter, in welcher Region, mit welcher Speicherdauer? Viertens: Unterstützt das Werkzeug die tatsächlich genutzte Git-Plattform einschließlich selbst betriebener Varianten? Fünftens: Wie hoch ist der laufende Pflegeaufwand für Konfiguration und Betrieb?
Die erste Frage lässt sich nur mit einem echten Test beantworten. Wir empfehlen, zwei oder drei Kandidaten parallel auf denselben zwanzig bis dreißig Pull Requests laufen zu lassen, darunter einige mit bewusst platzierten Fehlern, und die Ergebnisse im Team blind zu bewerten. Das dauert wenige Wochen und ersetzt jede Marketingaussage.
Der Plattform-Assistent ist der richtige Einstieg für Teams, die bereits einen Coding-Assistenten lizenziert haben, auf einer einzigen Plattform arbeiten und schnell Erfahrungen sammeln wollen. Ein spezialisierter Dienst lohnt sich, wenn das Review gründlicher und stärker auf das Team zugeschnitten sein soll oder mehrere Git-Plattformen im Einsatz sind. Open Source und Eigenbau passen zu Unternehmen mit selbst betriebener Infrastruktur, hohen Anforderungen an Datenhoheit und einem Team, das Pipelines selbst pflegen kann. Analysewerkzeuge mit KI sind kein Ersatz, sondern das Fundament, auf dem die anderen Klassen aufbauen sollten, besonders wenn Nachweispflichten bestehen.
Ob ein KI-Review hilft, lässt sich nicht an der Zahl der Kommentare ablesen. Viele Kommentare können genauso gut ein Zeichen für Rauschen sein. Aussagekräftig sind Kennzahlen, die Nutzen und Akzeptanz abbilden. Wir empfehlen, drei bis fünf davon auszuwählen und über mindestens ein Quartal zu verfolgen:
Besonders die letzte Kennzahl wird oft vergessen. Wenn die Zahl der substanziellen menschlichen Kommentare nach der Einführung stark sinkt, kann das bedeuten, dass die KI die Routinearbeit übernimmt. Es kann aber auch bedeuten, dass Menschen sich auf die KI verlassen und weniger genau hinsehen. Stichproben, bei denen eine erfahrene Person zufällig ausgewählte, bereits gemergte Pull Requests noch einmal prüft, schaffen hier Klarheit. Wichtig: Diese Kennzahlen dienen der Bewertung des Werkzeugs und des Prozesses, nicht der Bewertung einzelner Beschäftigter.
Für den Betrieb braucht es wenige, aber klare Regeln. Das KI-Review ist eine Empfehlung und kein Merge-Gate. Blockierende Prüfungen bleiben deterministischen Werkzeugen vorbehalten, deren Befunde reproduzierbar sind. Mindestens eine menschliche Freigabe bleibt für geschützte Zweige Pflicht, auch wenn die KI keine Einwände hat. Eine verantwortliche Person pflegt Konfiguration und Teamregeln, beobachtet die Kennzahlen und bewertet Modellwechsel des Anbieters, denn ein neues Modell kann das Verhalten des Reviews spürbar verändern. Und schließlich sollte dokumentiert sein, welche Repositorys mit welchem Werkzeug geprüft werden, damit Datenschutz und Informationssicherheit den Überblick behalten.
Ein typisches Beispiel ist die interne Entwicklungsabteilung eines Industrieunternehmens mit acht bis zwölf Personen. Sie betreut Schnittstellen zum ERP, ein Kundenportal und Software für die Fertigungssteuerung. Reviews hängen an zwei erfahrenen Personen, die gleichzeitig Architekturfragen klären und Fachbereiche beraten. Pull Requests liegen oft mehrere Tage, und unter Zeitdruck werden größere Änderungen nur noch überflogen.
Nach der Einführung eines KI-Reviews erhalten Autoren innerhalb weniger Minuten eine erste Rückmeldung und beheben einfache Punkte selbst. Die erfahrenen Reviewer berichten, dass sie sich wieder auf Architektur und Fachlogik konzentrieren können. Wichtig war in vergleichbaren Projekten die Phase der Konfiguration: Erst nachdem generierte Dateien ausgeschlossen, optionale Stilhinweise abgeschaltet und zehn bis fünfzehn Teamregeln formuliert waren, stieg die Akzeptanz spürbar.
Ein Softwarehaus entwickelt Branchenlösungen für mehrere Kunden, teils in deren Repositorys. Hier stellt sich zuerst die vertragliche Frage: Darf Kundencode überhaupt an einen KI-Dienst übermittelt werden? Viele Entwicklungsverträge enthalten Geheimhaltungsklauseln, die eine Weitergabe an Dritte untersagen oder an Zustimmung knüpfen. In der Praxis bewährt sich eine abgestufte Lösung: KI-Review mit Cloud-Dienst nur für eigene Produkte und für Kunden, die zugestimmt haben, für alle anderen ein selbst betriebener Review-Agent mit einem Modell in der EU oder lokal. Die Entscheidung gehört in die Projektdokumentation.
Unternehmen, die Software für Kunden oder regulierte Umfelder entwickeln, müssen ihre Qualitätsprozesse nachweisen. Ein dokumentiertes Review mit automatischer Zusammenfassung, nachvollziehbaren Hinweisen und menschlicher Freigabe ist ein gutes Argument in Lieferantenaudits und bei Anforderungen aus dem Cyber Resilience Act. Allerdings ersetzt ein KI-Review keine deterministischen Sicherheitsprüfungen. Für Audits zählt vor allem, dass der Prozess definiert, eingehalten und protokolliert ist. Das KI-Review ist ein Baustein darin, kein Nachweis für sich.
Kostenmodelle realistisch einschätzen. Die meisten gehosteten Dienste rechnen pro Nutzer und Monat ab, wobei teils nur aktive Autoren von Pull Requests zählen. Plattform-integrierte Review-Funktionen sind häufig Teil eines bestehenden Assistenten-Tarifs, können aber an Kontingente für Premium-Anfragen gebunden sein. Bei selbst betriebenen Lösungen entfallen Lizenzkosten, dafür fallen nutzungsabhängige Kosten beim Modellanbieter oder Kosten für eigene GPU-Infrastruktur sowie interner Betriebsaufwand an. Konkrete Preise, Kontingente und Tarifgrenzen ändern sich in diesem Markt häufig und sollten aktuell beim jeweiligen Anbieter geprüft werden.
Für die Wirtschaftlichkeit zählt weniger der Lizenzpreis als der Effekt auf Reviewer-Zeit und Fehlerkosten. Ein Fehler, der im Pull Request gefunden wird, kostet einen Bruchteil dessen, was er nach der Auslieferung verursacht. Rechnen Sie deshalb konservativ: Welche Wartezeit wird eingespart, wie viele Stunden erfahrener Reviewer werden frei, und wie viele Fehler wurden nachweislich vor dem Merge gefunden? Die Kennzahlen aus Kapitel 07 liefern dafür die Grundlage.
Viele Review-Dienste haben ihren Sitz in den USA oder nutzen Sprachmodelle von US-Anbietern. Der Code, der bei einem Review übertragen wird, verlässt damit in der Regel den Europäischen Wirtschaftsraum. Quellcode ist nicht automatisch personenbezogen, enthält aber oft Namen in Kommentaren, Commit-Metadaten, Testdaten oder Konfigurationen mit Bezug zu Personen. Sobald personenbezogene Daten betroffen sind, braucht es eine tragfähige Grundlage für den Drittlandtransfer, etwa eine Zertifizierung des Anbieters nach dem EU-US Data Privacy Framework oder Standardvertragsklauseln mit ergänzender Bewertung. Zu bedenken ist zudem, dass US-Anbieter auch bei Verarbeitung in europäischen Rechenzentren Zugriffsrechten von US-Behörden unterliegen können.
Entscheidend ist der Blick auf die gesamte Kette: Wer betreibt die Review-Plattform, welches Modell wird bei welchem Anbieter in welcher Region aufgerufen, wird Code zum Training verwendet und wie lange werden Code, Indizes und Protokolle gespeichert? Viele Anbieter bieten in Enterprise-Tarifen Trainingsausschluss, verkürzte Speicherdauer oder eine EU-Region an. Diese Zusagen sollten schriftlich vorliegen. Datenschutzfreundlichere Optionen sind Review-Agenten in der eigenen Pipeline mit einem Modell bei einem Cloud-Anbieter mit EU-Region, ein europäischer Modellanbieter oder ein lokal betriebenes Modell mit offenen Gewichten. Ein Sonderfall sind Modelle chinesischer Anbieter wie DeepSeek: Deren Cloud-Schnittstellen verarbeiten Daten nach unserem Kenntnisstand in China, wo weitreichende staatliche Zugriffsrechte bestehen. Für sensiblen Code raten wir von diesen Cloud-Diensten ab. Wer die offenen Gewichte solcher Modelle nutzen möchte, sollte sie ausschließlich in eigener Infrastruktur betreiben.
Quellcode ist in vielen Unternehmen ein Geschäftsgeheimnis im Sinne des Geschäftsgeheimnisgesetzes, das angemessene Schutzmaßnahmen voraussetzt. Wer Code an Dritte übermittelt, sollte dokumentieren, warum dies vertretbar ist und welche vertraglichen Sicherungen bestehen. Bei Kundenprojekten sind zusätzlich Geheimhaltungsklauseln zu beachten. Ein zweites Thema sind Geheimnisse im Code: Zugangsdaten, Schlüssel und Tokens haben im Repository nichts verloren, landen dort aber trotzdem. Ein vorgeschalteter Secret-Scanner verhindert, dass solche Daten an einen KI-Dienst übermittelt werden.
Ein neueres Risiko ist die Manipulation des Reviews selbst. Ein Pull Request kann Text enthalten, etwa in Kommentaren, Dokumentation oder Testdaten, der das Modell anweist, bestimmte Probleme zu ignorieren oder eine positive Bewertung abzugeben. Diese Form der Prompt Injection ist bei Beiträgen von außen, etwa in Open-Source-Projekten oder von externen Dienstleistern, besonders relevant. Darum gilt umso mehr: Das KI-Review ist eine Empfehlung, die menschliche Freigabe bleibt Pflicht, und Review-Agenten dürfen keine weitreichenden Schreibrechte haben.
KI-Review-Werkzeuge protokollieren, wer welchen Code geschrieben hat und wie viele Hinweise dazu entstanden sind. Damit sind sie grundsätzlich geeignet, Verhalten und Leistung von Beschäftigten zu überwachen. In Deutschland ist deshalb in der Regel der Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG zu beteiligen. Eine Betriebsvereinbarung oder eine Ergänzung bestehender Vereinbarungen zu Entwicklungswerkzeugen sollte klarstellen, dass Auswertungen ausschließlich auf Team- oder Prozessebene erfolgen. Der EU AI Act verpflichtet Unternehmen, die KI-Systeme einsetzen, seit Februar 2025 zur Förderung ausreichender KI-Kompetenz der Beschäftigten. Ein typisches Review-Werkzeug fällt nach unserer Einschätzung nicht in die Hochrisiko-Kategorien. Würden die Ergebnisse jedoch zur Leistungsbewertung oder für Personalentscheidungen genutzt, könnte sich diese Einordnung ändern. Auch das spricht dafür, KI-Review strikt als Qualitätswerkzeug zu betreiben.
