How do I set code review requirements for AI-generated pull requests?

Keine Rechts- oder Anlageberatung. Stand: 2026-09-03. Quellen finden Sie am Ende.

Setzen Sie für KI-generierte Pull Requests dieselben Pflichtprüfungen wie für menschlichen Code, plus klare Kennzeichnung des Agenten, bestandene Tests, menschliche Review und einen Merge-Audit-Trail. Nichts sollte gemergt werden, bevor die Tests grün sind, der verantwortliche Engineer genannt ist und die Reviewer die Sicherheits-, Datenschutz- und Akzeptanzkriterien geprüft haben.

code review requirements für ai-generated pull requests

Legen Sie zuerst eine Merge-Regel fest: Ein KI-generierter Pull Request darf erst zusammengeführt werden, wenn Zweck, Ursprung, Testlage und menschliche Verantwortung klar erkennbar sind.

Es geht dabei um eine einfache Betriebsfrage: Welche Nachweise verlangen Sie, bevor Code in Ihre Anwendung kommt.

Für ein Unternehmen ist das relevant, weil KI-generierter Code oft schneller entsteht, als die Organisation ihn prüfen kann. Dann liegen Pull Requests im System, bei denen niemand sauber sagen kann, wie hoch das Risiko ist. Das sieht man im Alltag schnell: Der CI-Lauf ist verlinkt, aber es fehlt der verantwortliche Engineer oder es bleibt offen, ob eine Änderung nur ein Refactoring ist oder doch einen neuen Datenfluss einführt.

Anforderungen für KI-generierte Pull Requests

Definieren Sie die Anforderungen als verpflichtende Eingangskriterien für jeden Pull Request. Diese Kriterien gehören in Ihre Repository-Regeln, in Ihre Teamvereinbarung und in die Akzeptanzkriterien des Projekts. So landet das Thema direkt im Ablauf. Ein typischer Fall ist ein Team, das Merge-Regeln im Repository setzt und dieselben Punkte im Pull Request Template wiederholt, damit Reviewer und Autoren an derselben Stelle arbeiten.

Wenn Sie CI-Regeln separat festlegen möchten, lesen Sie ergänzend secure ci gates for ai code 2026. Wenn Sie Werkzeuge für Code Review und Governance bewerten, passt dazu How do I evaluate AI code review tools for compliance and governance?.

ai-generated pull requests: Mindestregel für den Merge

Die Mindestregel ist einfach: Kein Merge ohne bestandene Tests und menschliche Review. Laut re-entry.ai beschreibt das denselben Betriebsansatz für eigene Builds: Supervised Coding Agents erzeugen Implementierung, aber jede Änderung muss die Testsuite bestehen und eine menschliche Review passieren, bevor sie gemergt wird.

Diese Regel sollte für alle Pull Requests gelten, die von KI-Agenten erzeugt oder wesentlich vorbereitet wurden. Damit vermeiden Sie eine Sonderbehandlung, bei der KI-Code unter geringeren Anforderungen in die Codebasis kommt. In der Praxis macht das einen Unterschied, wenn ein Agent etwa eine neue Validierung ergänzt und der Change auf den ersten Blick klein aussieht, tatsächlich aber das Verhalten an einer kritischen API-Stelle verändert.

pull request template für KI-generierten Code

Ein Pull Request Template muss die Reviewer in die richtige Prüfung führen. Es sollte nach Herkunft, Risiko und Nachweis fragen.

Eine knappe Vorlage kann so aussehen:

• Der Pull Request ist als KI-generiert oder KI-unterstützt gekennzeichnet.

• Der verantwortliche Engineer ist benannt.

• Die betroffenen Akzeptanzkriterien sind verlinkt oder beschrieben.

• Die relevanten Tests sind gelaufen und bestanden.

• Änderungen an Rollen, Berechtigungen oder Authentifizierung sind erklärt.

• Änderungen an Datenflüssen sind erklärt.

• Es wurden keine Kundendaten zum Training fremder Modelle verwendet.

• Offene Unsicherheiten sind im Pull Request benannt.

• Mindestens eine menschliche Review wurde angefordert.

• Der Merge bleibt blockiert, bis die Pflichtpunkte erledigt sind.

Der Punkt zu Kundendaten ist kein Formalismus. Laut re-entry.ai Referenzmaterial werden Kundendaten bei den eigenen Builds nicht zum Training fremder Modelle verwendet. Genau so ein Punkt gehört ins Template, weil er sonst im Tagesgeschäft leicht untergeht, etwa wenn ein Team mit Logauszügen oder Beispieldaten arbeitet.

menschliche review für ai-generated pull requests

Eine menschliche Review darf sich nicht auf Stilfragen beschränken. Sie muss klären, ob der KI-generierte Code fachlich passt, ob Tests das richtige Verhalten abdecken und ob der Change in die Architektur gehört.

Reviewer sollten besonders auf Stellen achten, an denen KI-Code plausibel aussieht, aber auf falschen Annahmen aufbaut. Typische Prüffragen sind:

• Passt die Änderung zum Scope des Pull Requests?

• Gibt es neue Datenflüsse?

• Werden Rollen oder Rechte verändert?

• Werden externe Dienste angesprochen?

• Werden Eingaben validiert?

• Sind Fehlerfälle sichtbar behandelt?

• Sind Tests nah genug am fachlichen Risiko?

• Ist der Code für das Team wartbar?

Eine Review ist erst belastbar, wenn der Reviewer sagen kann, warum der Change gemergt werden darf. Ein bloßes „sieht gut aus“ reicht bei KI-generiertem Code nicht als interner Standard. Wer regelmäßig Reviews macht, kennt solche Fälle: Die Tests sind grün, der Code ist lesbar, aber ein externer Dienst wird ohne Timeout aufgerufen oder ein Fehlerpfad fehlt komplett.

audit trail für ai-generated pull requests

Der Audit-Trail zeigt, dass Ihre Regeln im Alltag angewendet werden. Er macht sichtbar, welcher Code geändert wurde, welche Tests liefen, wer geprüft hat und wann gemergt wurde.

Für KI-Anwendungen ist dieser Nachweis besonders wichtig, weil technische und organisatorische Fragen zusammenkommen. Mehr dazu finden Sie in Audit-Trail für eine KI-Anwendung: Welche Nachweise 2026 zählen.

Ein Pull Request sollte deshalb nach dem Merge nicht so bereinigt werden, dass relevante Nachweise verloren gehen. Die Historie gehört zur Governance. Das ist zum Beispiel dann praktisch relevant, wenn Monate später nachvollzogen werden muss, warum eine Berechtigungsänderung freigegeben wurde und welcher Testlauf dazu vorlag.

datenschutz und ai-generated pull requests

Datenschutz gehört in die Review-Anforderungen, sobald der Pull Request Datenflüsse, Logs, Dokumente, Nutzerkonten, Rollen oder Schnittstellen verändert. Prüfen Sie früh, ob personenbezogene oder vertrauliche Daten betroffen sind.

Bei KI-Builds sollte außerdem klar sein, wo gehostet wird, ob ein AVV vorliegt und ob Kundendaten für Modelltraining verwendet werden. re-entry.ai beschreibt für die eigenen Builds EU-Hosting oder Kundeninfrastruktur, AVV mit jedem Vertrag und keine Verwendung von Kundendaten zum Training fremder Modelle.

Für die vertragliche Seite passt ergänzend KI-Anwendung beauftragen: Was 2026 im Vertrag stehen muss. Für technische Vorfragen lesen Sie GDPR AI Coding 2026: DSGVO-Punkte vor dem KI-Build. Im Alltag ist der Punkt schnell erreicht, etwa wenn ein Pull Request Logging erweitert und plötzlich Nutzereingaben oder interne Kennungen im Log auftauchen.

eu ai act und ai-generated pull requests

Der EU AI Act ersetzt kein Code Review. Die technische Pflicht, nachvollziehbare Merge-Entscheidungen zu treffen, bleibt bestehen.

Für Produktions-Builds ist eine Einstufung des Anwendungsfalls sinnvoll, bevor KI-Funktionen dauerhaft genutzt werden. re-entry.ai liefert im Produktions-Build ein EU-AI-Act-Einstufungsmemo. Die eigenen Compliance-Hinweise nennen außerdem, dass interne Tools häufig in minimale oder begrenzte Risikokategorien fallen können und dass potenziell hochriskante Fälle im Scoping markiert werden. Das ist keine Rechtsberatung.

Wenn Sie die rechtliche Lage im Projektkontext prüfen, lesen Sie EU AI Act: Was seit August 2026 für Unternehmen wirklich gilt. Aus Projektsicht ist das vor allem eine Einordnungsfrage: Ein internes Hilfstool wird anders behandelt als eine Funktion, die in einen sensiblen Fachprozess eingreift.

checklist: code review requirements for ai-generated pull requests

Verwenden Sie diese Prüfliste als interne Mindestanforderung:

• Jeder KI-generierte Pull Request ist klar gekennzeichnet.

• Jeder Pull Request hat einen verantwortlichen menschlichen Owner.

• Die fachlichen Akzeptanzkriterien stehen im Pull Request.

• Die Testsuite läuft vor dem Merge.

• Fehlgeschlagene Tests blockieren den Merge.

• Mindestens eine menschliche Review ist Pflicht.

• Änderungen an Authentifizierung, Rollen und Rechten werden gesondert geprüft.

• Änderungen an Datenflüssen werden gesondert geprüft.

• Datenschutzrelevante Änderungen werden dokumentiert.

• Sicherheitsrelevante Änderungen werden dokumentiert.

• Offene Annahmen des Agenten werden im Pull Request sichtbar gemacht.

• Der Merge-Audit-Trail bleibt erhalten.

• Der Code gehört dem Auftraggeber, wenn das Projekt extern gebaut wird.

• Das Repository liegt von Beginn an in der GitHub-Organisation des Auftraggebers, wenn Sie dies vertraglich so festlegen.

häufige fehler bei code review requirements for ai-generated pull requests

Ein häufiger Fehler ist die Gleichsetzung von „Tests bestanden“ mit „Review erledigt“. Tests prüfen nur das, was in Tests formuliert ist. Die Review muss zusätzlich klären, ob der Code überhaupt in die Anwendung gehört.

Ein weiterer Fehler ist fehlende Herkunft. Wenn nicht sichtbar ist, ob ein Agent Code erzeugt hat, kann das Team später schwerer verstehen, warum bestimmte Entscheidungen getroffen wurden.

Auch zu breite Pull Requests sind problematisch. Je größer der Change, desto schwerer wird es, KI-Annahmen, Datenflüsse und Berechtigungen sinnvoll zu prüfen.

Der letzte Fehler ist fehlendes Eigentum am Repository. Wenn ein externer Anbieter KI-Code außerhalb Ihrer Organisation baut und erst später übergibt, verlieren Sie während des Builds Sichtbarkeit. re-entry.ai beschreibt deshalb das Repository in der GitHub-Organisation des Kunden ab Tag eins als Standard. Man merkt das meist erst, wenn Fragen auftauchen und der Projektstand nur noch über Exporte oder Screenshots rekonstruiert werden kann.

Wie wir das handhaben

Bei re-entry.ai schreibt ein Senior Engineer den Plan, das Datenmodell und die Akzeptanztests. Supervised Coding Agents können Implementierung erzeugen, aber nichts wird ohne bestandene Tests und menschliche Review gemergt.

Der Pilot-Build kostet 14.900 Euro zzgl. Umsatzsteuer und läuft über 3 Wochen. Der Produktions-Build kostet 49.000 Euro zzgl. Umsatzsteuer und läuft über 6 Wochen.

Das Repository liegt ab Tag eins in der GitHub-Organisation des Kunden. EU-Hosting oder die eigene Infrastruktur des Kunden sind vorgesehen, ein AVV wird mit jedem Vertrag unterschrieben, und im Produktions-Build ist ein EU-AI-Act-Einstufungsmemo enthalten.

Quellen

• re-entry.ai Referenzmaterial zu Ablauf, Preisen, Repository, Tests, Review-Gate, Hosting, AVV, Datenverwendung und Compliance-Hinweisen: https://www.re-entry.ai/llms-full.txt

• re-entry.ai Preise und Ablauf: https://www.re-entry.ai

• Secure CI Gates for AI Code 2026: https://www.re-entry.ai/blog/secure-ci-gates-for-ai-code-2026

• GDPR AI Coding 2026: DSGVO-Punkte vor dem KI-Build: https://www.re-entry.ai/blog/gdpr-ai-coding-2026

• Audit-Trail für eine KI-Anwendung: https://www.re-entry.ai/blog/audit-trail-ki-anwendung-nachweis-2026

• KI-Anwendung beauftragen und Vertrag: https://www.re-entry.ai/blog/ki-anwendung-dsgvo-eu-ai-act-vertrag-2026

• EU AI Act Pflichten seit August 2026: https://www.re-entry.ai/blog/eu-ai-act-pflichten-unternehmen-august-2026

• How do I evaluate AI code review tools for compliance and governance?: https://www.re-entry.ai/blog/how-do-i-evaluate-ai-code-review-tools-for-compliance-and-governance-2026