In einem Team, das stark auf Coding-Agents setzt, eröffnen diese einen großen Teil der Pull Requests, die deployed werden. Oft sind sie gut in der sichtbaren Aufgabe: Die Funktion funktioniert, die Tests bestehen, die Abhängigkeiten sind aktuell. Was ein Agent jedoch nicht berücksichtigen muss, ist, ob eine Änderung eine Kontrolle betrifft, für die das Unternehmen geprüft wird. Denn diese Verpflichtung existiert in Ihren Frameworks und Ihrem Kontext, nicht im Diff, den der Agent erstellen sollte. Diese Lücke schließt eine Compliance-Prüfung für KI-generierten Code.
Die bestehenden Übersichten zu KI-Code-Compliance-Tools beziehen sich meist auf eines von drei Dingen: statische Analyse auf Bugs, Abhängigkeits- und Lizenzscans oder die Erkennung von Secrets. Diese sind real und sinnvoll. Keines davon ist jedoch dafür ausgelegt, eine Änderung gegen SOC 2, ISO 27001 oder die DSGVO auf Ebene einer spezifischen Kontrolle zu prüfen, was eine andere Frage an denselben Pull Request darstellt.
Was Compliance hier auf Kontrollebene bedeutet
Compliance für KI-generierten Code ist keine Prüfung von Lizenzheadern oder Schwachstellenbewertungen. Es geht um die Frage, ob eine Änderung eine Kontrolle betrifft, die Sie einhalten müssen: eine logische Zugriffsgrenze, einen Audit-Log-Eintrag, eine Verschlüsselungsanforderung oder eine Aufbewahrungsfrist. Diese Verpflichtungen sind in den von Ihrem Unternehmen ausgewählten Frameworks definiert, auf einer Ebene, die Sie überprüfen können, z. B. ISO 27001:2022 A.8.15 für Logging oder DSGVO Art. 5(1)(c) für Datenminimierung.
Der Grund, warum dies eine separate Prüfung ist, liegt darin, dass eine kontrollrelevante Änderung in der Regel korrekter Code ist. Er kompiliert, ist sicher, korrekt lizenziert und erfüllt die gestellte Aufgabe. Das Problem liegt nicht in einem Fehler in der Änderung, sondern darin, dass die Änderung stillschweigend etwas verschiebt, das ein Prüfer später untersuchen könnte. Eine Prüfung, die nur nach Fehlern sucht, ist nicht dafür ausgelegt, dies zu markieren.
Ein praktisches Beispiel: Ein Agent reichert ein Profil mit mehr Daten an, als nötig
Angenommen, ein Agent wird gebeten, ein Loyalitätsstufen-Badge zur Kontoseite hinzuzufügen. Um die Stufe zu berechnen, fügt er einen user_profile-Cache hinzu und füllt ihn mit Daten aus dem Identity-Service. Die naheliegendste Methode, und eine, die ein Agent zur Aufgabenoptimierung wählen könnte, besteht darin, den gesamten Identitätsdatensatz in den neuen Speicher zu kopieren: Geburtsdatum, nationale ID, Heimatadresse und Telefonnummer, zusammen mit der Stufe und dem Anzeigenamen, die das Badge tatsächlich verwendet.
Die Migration ist sauber, und die Funktion funktioniert beim ersten Versuch. Doch der neue Speicher enthält nun vier Kategorien personenbezogener Daten, die für das Loyalitäts-Badge nicht benötigt werden. Das betrifft die Datenminimierung, DSGVO Art. 5(1)(c): Personenbezogene Daten müssen angemessen, relevant und auf das für den Zweck Notwendige beschränkt sein. Die Lösung ist eine Zeile Absicht: Befüllen Sie den Cache nur mit der Stufe und dem Anzeigenamen. Es ist am günstigsten, dies im Pull Request zu korrigieren, der den Speicher eingeführt hat, solange der Autor noch den Kontext hat. Wird dies nicht behoben, entsteht ein neuer Speicher mit unnötigen personenbezogenen Daten für seinen angegebenen Zweck, der Monate später entdeckt wird.
Warum Bug-, Schwachstellen- und Lizenzscanner dies nicht erkennen
Die oben beschriebene Änderung ist nicht die Art von Problem, die diese Scanner erkennen sollen: Der Code ist korrekt, also besteht ein Bug-Scanner ihn; es gibt keine neue Abhängigkeit, also besteht ein Lizenzscanner ihn; und ein Schwachstellenscanner ist nicht dafür ausgelegt, eine erweiterte personenbezogene Datenmenge als Befund zu interpretieren. Daher arbeiten die Scanner, die nach diesen Dingen suchen, wie vorgesehen, wenn sie die Änderung bestehen lassen, weil eine kontrollrelevante Änderung, die ansonsten sauber ist, nicht das ist, wofür sie ausgelegt sind. Das ist keine Kritik an ihnen; das Erkennen von Bugs, Schwachstellen und Lizenzabweichungen ist tatsächlich wertvoll, und die Ausgabe eines Agents benötigt all das.
Es bedeutet jedoch, dass eine Compliance-Prüfung eine eigenständige Ebene ist, keine erweiterte Version desselben Scans. Sie prüft den Diff gegen die Frameworks, an die Sie gebunden sind, und benennt die Kontrolle, die die Änderung betrifft. Dies sind Informationen, die die anderen Tools nicht liefern können. Die sinnvolle Vorgehensweise ist, beides auszuführen: die Code-Qualitäts- und Sicherheits-Scanner für Fehler und eine Compliance-Prüfung für Kontrollabweichungen, am selben Pull Request.
Die Veränderung, die dies dringend macht
Zwei Dinge ändern sich, wenn Agents einen großen Teil des Codes schreiben. Volumen: Ein Agent eröffnet mehr Pull Requests, als eine sorgfältige manuelle Compliance-Prüfung bewältigen kann, sodass die Prüfung entweder zum Engpass wird oder übersprungen wird. Fehlerart: Ein Agent optimiert für die sichtbare Aufgabe, sodass Kontrollcode, der als Reibung wahrgenommen wird – eine Log-Zeile, eine Berechtigungsprüfung, eine Aufbewahrungsfrist – genau die Art von Dingen ist, die ein Diff ohne weitere Überlegung kürzen oder erweitern kann.
Unabhängig davon, wer eine Änderung vorgenommen hat, bewertet der Prüfer weiterhin, ob die Kontrolle funktioniert hat. Daher wird KI-generierter Code nach denselben Maßstäben bewertet wie von Menschen geschriebener Code. Was sich ändern muss, ist, dass die Compliance-Prüfung nun mit Maschinengeschwindigkeit durchgeführt werden muss, um Schritt zu halten. Das bedeutet, den ersten Durchlauf zu automatisieren und menschliche Beurteilung für die markierten Fälle vorzubehalten.
So fügen Sie die Prüfung hinzu
Eine Compliance-Prüfung für KI-generierten Code wird auf dem Pull Request ausgeführt, genau wie Ihre anderen Prüfungen: Sie wird ausgelöst, wenn ein PR geöffnet oder aktualisiert wird, prüft den Diff gegen die von Ihnen ausgewählten Frameworks und Ihren Unternehmenskontext und postet die Kontrollen, die eine Änderung betrifft, mit der jeweiligen Klausel als Kommentar sowie einem neutralen Status. Wenn ein Agent den PR eröffnet, trifft die Prüfung auf den Code, den der Agent bereits bereitgestellt hat, ohne zusätzlichen Schritt für den Menschen, der die Freigabe erteilen muss.
heygrc ist als GitHub App dafür konzipiert: Installieren Sie es, konfigurieren Sie Ihre Frameworks und Ihren Kontext einmal (ein einzelner REST-Aufruf, den Ihr Coding-Agent für Sie durchführen kann), und es prüft jeden Pull Request auf Compliance-Auswirkungen und verweist auf die Kontrolle im Diff. Es postet einen neutralen Checks-Status sowie Inline-Kommentare, sodass es informiert, anstatt zu blockieren, es sei denn, Sie entscheiden sich, dies zu erfordern. Verwenden Sie es zusammen mit Ihren Bug- und Sicherheits-Scannern, nicht an deren Stelle.