Warum Quellcode nicht in die Cloud-KI gehört

Die Idee liegt nahe: Sprachmodelle sind gut darin, Code zu lesen, also lässt man sie den eigenen Code auf Schwachstellen prüfen. Technisch funktioniert das erstaunlich gut. Organisatorisch scheitert es in vielen Unternehmen an derselben Stelle – und zwar aus guten Gründen.

Was Sie tatsächlich übertragen

Ein Repository ist nicht nur Quellcode. Es enthält in aller Regel:

• Architekturwissen. Wie Ihr Produkt funktioniert, wo die Engpässe liegen, welche Abkürzungen genommen wurden.
• Geschäftslogik. Preismodelle, Rabattregeln, Vertragslogik – bei vielen Unternehmen der Kern des Wettbewerbsvorteils.
• Konfiguration und Infrastrukturbeschreibung. Welche Dienste wie miteinander sprechen, welche Netze existieren.
• Historie. Der Git-Verlauf enthält, was irgendwann einmal eingecheckt und später entfernt wurde. Zugangsdaten zum Beispiel.
• Fremde Inhalte. Code unter Lizenzen, die Sie nicht beliebig weitergeben dürfen, und gelegentlich personenbezogene Daten in Testfixtures.

Wer „nur mal eben" ein Repository hochlädt, überträgt das alles.

Die vier Fragen der Rechtsabteilung

Die Prüfung läuft in fast jedem Unternehmen über dieselben vier Punkte.

1. Wo wird verarbeitet? Liegt die Verarbeitung außerhalb der EU, braucht es eine tragfähige Grundlage für den Drittlandtransfer. Ein Haken in einer Weboberfläche reicht dafür nicht.

2. Wird mit meinen Daten trainiert? Die meisten Anbieter schließen das in den Geschäftskundenbedingungen aus – in den kostenlosen Varianten häufig nicht. Der Unterschied zwischen dem Tarif, den ein Entwickler privat nutzt, und dem, den das Unternehmen eingekauft hat, ist hier erheblich.

3. Wie lange wird gespeichert? Fast alle Anbieter halten Eingaben eine Zeit lang für Missbrauchserkennung vor. Das ist legitim, verlängert aber den Zeitraum, in dem Ihr Code auf fremden Systemen liegt.

4. Wer hat im Zweifel Zugriff? Im Rahmen der Missbrauchsprüfung können Mitarbeitende des Anbieters Eingaben einsehen. Das steht in den Bedingungen, wird beim Hochladen aber selten mitgedacht.

Keiner dieser Punkte ist ein Skandal. Zusammengenommen erklären sie, warum eine sorgfältige Rechtsabteilung „nein" sagt – und warum dieses „nein" kein Zeichen von Fortschrittsfeindlichkeit ist.

Der Sonderfall: Kunden-Code

Besonders heikel wird es für Agenturen und Dienstleister, die Code im Auftrag Dritter entwickeln. Hier gilt fast immer eine vertragliche Vertraulichkeitsvereinbarung mit dem Auftraggeber. Wer diesen Code ohne Rücksprache an einen KI-Dienst gibt, verletzt in der Regel den eigenen Vertrag – unabhängig davon, wie sicher der Anbieter ist.

Der Ausweg: lokale Inferenz

Die technische Antwort ist unspektakulär: Man betreibt die Modelle selbst. Offene Modelle sind bei Code-Analyse inzwischen so weit, dass der Qualitätsunterschied zu den großen kommerziellen Modellen für diesen Zweck vertretbar ist – besonders, wenn ohnehin ein Mensch jedes Ergebnis prüft.

Entscheidend ist dabei weniger das Modell als die Umgebung drumherum:

• Ein Netzsegment ohne ausgehenden Internetzugang, sodass eine Übermittlung technisch nicht möglich ist – nicht nur vertraglich untersagt.
• Personengebundene Zugänge mit Mehrfaktor-Authentifizierung statt geteilter Konten.
• Definierte Aufbewahrungsfristen mit protokollierter Löschung.
• Dokumentierter Datenfluss, den die Gegenseite prüfen kann.

Die Prüffrage an jeden Anbieter

Wenn ein Dienstleister KI-gestützte Code-Analyse anbietet, ist die entscheidende Frage nicht, welches Modell er einsetzt, sondern:

„Gibt es in Ihrer Analyse-Umgebung eine ausgehende Internetverbindung?"

Lautet die Antwort „nein", lassen Sie sich die Netzkonfiguration als Vertragsanlage geben. Lautet sie „ja, aber wir senden nichts", ist das eine organisatorische Zusage, keine technische Eigenschaft. Beides kann vertretbar sein – aber Sie sollten wissen, was Sie einkaufen.