Dein Quellcode in fremden Rechenzentren: was du regeln musst, bevor deine Entwickler KI-Coding-Tools nutzen

Frühjahr 2023, Samsung. Innerhalb von nicht einmal drei Wochen fügt ein Entwickler vertraulichen Halbleiter-Quellcode in ChatGPT ein, um einen Fehler zu finden, ein Kollege lädt eine Testsequenz zur Chip-Optimierung hoch, und ein dritter lässt eine interne Meeting-Aufnahme transkribieren, so berichtete es damals die koreanische Presse. Samsungs Antwort: ein Komplettverbot generativer KI für die Belegschaft.

Ich erzähle diese Geschichte gerne, weil sie zwei Dinge gleichzeitig zeigt. Erstens: Das Risiko kommt nicht von Angreifern, sondern aus dem ganz normalen Arbeitsalltag: Keiner der drei wollte dem Unternehmen schaden. Zweitens: Das Verbot ist die falsche Lehre aus der richtigen Beobachtung. Laut Stack-Overflow-Umfrage 2025 nutzen oder planen 84 Prozent der Entwickler KI-Tools. Die Frage ist längst nicht mehr, ob deine Entwickler mit KI arbeiten, sondern ob es unter deinen Regeln passiert oder unter gar keinen.

Kennst du diese Situation auch:

• In der Kreditkartenabrechnung taucht eine Copilot-Lizenz auf, die nie jemand offiziell freigegeben hat?
• Ein Entwickler sagt im Daily beiläufig „hab ich mir von ChatGPT bauen lassen“, und im Raum wird es kurz still?
• Dein größter Kunde schickt einen Vertragsnachtrag mit einer KI-Klausel, und du weißt nicht, ob du ihn guten Gewissens unterschreiben kannst?

Dann lass uns das sortieren, mit offenen Karten: Ich entwickle seit 2009, und ein erheblicher Teil meiner täglichen Arbeit läuft über Claude Code und KI-Agenten. Das hier ist also kein Verbots-Text, sondern die Regelungs-Anleitung, die ich mir selbst gegeben habe. Die allgemeinen Grundlagen findest du im Artikel über die fünf DSGVO-Entscheidungen: Auftragsverarbeitungsvertrag, Modell-Standort, Nutzungsrichtlinie fürs ganze Unternehmen. Die Produktivitätsfrage samt J-Kurve hatten wir vor drei Wochen. Heute geht es ausschließlich um das, was bei Quellcode dazukommt. Und da kommt einiges dazu.

Warum Quellcode ein anderes Kaliber ist als die Office-E-Mail

Als der Security-Anbieter Netskope 2024 untersucht hat, welche sensiblen Daten in generativen KI-Apps landen, stand auf Platz eins nicht Kundenkommunikation oder Finanzdaten, sondern proprietärer Quellcode: 46 Prozent aller registrierten Datenrichtlinien-Verstöße. Kein Wunder: Der Code ist das Material der Entwickler, und die KI ist am nützlichsten, wenn sie möglichst viel davon sieht.

Trotzdem behandeln viele Nutzungsrichtlinien Code wie jede andere Dateiart. Ein Fehler, denn Code hat drei Eigenschaften, die die Office-E-Mail nicht hat. Er ist erstens ein Geschäftsgeheimnis mit echtem wirtschaftlichem Wert. Oft ist er das Produkt selbst. Er ist zweitens häufig gar nicht dein Eigentum: In Kundenprojekten, unter NDAs, mit OEM-Vorgaben arbeitet dein Team an fremdem Code, und der Kunde hat ein Wort mitzureden, wohin der fließt. Und drittens transportiert Code blinde Passagiere: API-Schlüssel, Passwörter, personenbezogene Daten in Datenbank-Dumps und Konfigurationsdateien. Wer eine Datei in ein KI-Tool kopiert, kopiert oft mehr mit, als er meint.

Fünf Punkte machen den Einsatz trotzdem sauber. Gehen wir sie durch.

Punkt 1: Business-Tarif statt Privat-Account. Die Trainingsfrage

Lange galt die bequeme Annahme: Der private Account des Entwicklers tut es doch auch. Diese Zeit ist vorbei. Im August 2025 hat Anthropic seine Consumer-Bedingungen umgestellt: Daten aus Claude Free, Pro und Max, ausdrücklich einschließlich Claude Code, fließen seither ins Modelltraining, wenn der Nutzer nicht widerspricht; bei Zustimmung werden sie bis zu fünf Jahre aufbewahrt. Und seit dem 24. April 2026 gilt bei GitHub dasselbe Modell: Copilot Free, Pro und Pro+ nutzen Interaktionsdaten per Voreinstellung fürs Training: Eingaben, Code-Schnipsel, den Kontext um den Cursor, Dateinamen, Repository-Struktur. (Ruhender Repository-Code bleibt außen vor, die Interaktionsdaten bei der Arbeit darin nicht.) Die Business- und Enterprise-Tarife sind jeweils ausdrücklich ausgenommen, bei GitHub sogar vertraglich zugesichert.

Die Übersetzung für dich als Geschäftsführer: Die Tarifwahl ist keine Komfort-Frage mehr, sondern eine Compliance-Entscheidung. Verglichen mit einem einzigen Geheimnisschutz-Vorfall sind die Mehrkosten eines Business-Tarifs Portokasse. Aber der Business-Tarif ist kein Freifahrtschein: Er regelt, dass nicht trainiert wird. Nicht, welche Daten überhaupt raus dürfen. Womit wir bei Punkt 2 wären.

Punkt 2: Geschäftsgeheimnis und Kunden-NDAs. Der Schutz, den du verlieren kannst

Jetzt der Teil, der mich bei der Recherche am meisten überrascht hat. (Vorab: Ich bin Praktiker, kein Jurist. Was folgt, ist Praxiswissen, keine Rechtsberatung.) Das Geschäftsgeheimnisgesetz definiert in § 2, was überhaupt ein Geschäftsgeheimnis ist. Und dort steht eine Bedingung, die man leicht überliest: Eine Information ist nur dann ein Geschäftsgeheimnis, wenn sie „Gegenstand von den Umständen nach angemessenen Geheimhaltungsmaßnahmen“ ist. Kein Schutz ohne Schutzmaßnahmen. Wer die KI-Nutzung im Dev-Team gar nicht regelt, riskiert also nicht nur, dass Code abfließt. Er riskiert den rechtlichen Status des Codes als Geschäftsgeheimnis gleich mit.

Die gute Nachricht: Geregelte Nutzung ist selbst eine Geheimhaltungsmaßnahme. Business-Tarif, dokumentierte Richtlinie, technische Kontrollen: Mit genau diesen Bausteinen belegst du im Ernstfall, dass du dein Geheimnis angemessen geschützt hast. Die Regelung schützt also doppelt: deine Daten und deren Rechtsstatus.

Der zweite Teil dieses Punkts brennt vor allem bei Dienstleistern und Zulieferern: Der Code, an dem dein Team arbeitet, gehört oft dem Kunden. Viele NDAs und Projektverträge beschränken die Weitergabe an Dritte oder die Verarbeitung außerhalb definierter Systeme, und ein KI-Cloud-Dienst ist so ein Dritter. In meinen Workshops erlebe ich regelmäßig dieselbe Szene: Die Entwickler nutzen die Tools längst, meist über private Konten, und die Tarif- oder NDA-Frage hat schlicht noch nie jemand gestellt. Mach sie zur Routine: Vor jedem Kundenprojekt einmal klären, ob der Vertrag Cloud-Verarbeitung und Unterauftragsverarbeiter zulässt, und im Zweifel schriftlich mit dem Kunden festhalten, welche Tools eingesetzt werden dürfen. Das ist ein Absatz in einer E-Mail und im Streitfall Gold wert.

Punkt 3: Urheberrecht. Zwei offene Fragen und drei Anbieter-Versprechen

Beim Urheberrecht musst du in zwei Richtungen schauen, und in beiden lautet die ehrliche Antwort: rechtlich offen.

Richtung eins: Kommt fremder Code in dein Produkt? In den USA läuft seit 2022 Doe v. GitHub, die Sammelklage rund um Copilot: Der Großteil der Ansprüche wurde abgewiesen, eine Kernfrage liegt beim Berufungsgericht. Im Februar 2026 wurde mündlich verhandelt, die Entscheidung steht noch aus. Übersetzt: praktisch selten, aber nicht null, und die Gerichte sind noch nicht fertig damit.

Richtung zwei hat kaum jemand auf dem Schirm: Ist dein KI-generierter Code überhaupt geschützt? § 69a Abs. 3 UrhG schützt Computerprogramme nur als „Ergebnis der eigenen geistigen Schöpfung ihres Urhebers“, und Urheber kann nur ein Mensch sein. Rein KI-generierter Code ohne prägenden menschlichen Anteil dürfte danach schutzlos sein; wo die Grenze verläuft, ist offen. Ein Produkt, dessen Kern urheberrechtlich niemandem gehört, ist aber eine seltsame Grundlage für ein Software-Unternehmen.

Die Anbieter reagieren auf dieses Dilemma pragmatisch: mit Freistellungszusagen. Microsoft verteidigt zahlende Copilot-Kunden über das Customer Copyright Commitment, OpenAI nennt sein Pendant Copyright Shield (nur für ChatGPT Enterprise und die API), Anthropic hat die Freistellung Anfang 2024 in seine Commercial Terms aufgenommen. Die Details unterscheiden sich, aber das Muster ist identisch: Freistellung gibt es nur im Business-Kontext und nur unter Bedingungen, etwa dass die eingebauten Schutzfilter aktiv bleiben. Für dich heißt das: ein weiteres Argument für den Business-Tarif. Und kein Ersatz für Code-Review. Denn der Mensch, der KI-Code prüft, anpasst und strukturiert, liefert nebenbei genau den Schöpfungsanteil, der die Schutzfähigkeit deines Codes sichert.

Punkt 4: Datenaufbewahrung. Was „gelöscht“ wirklich heißt

Selbst mit Business-Tarif bleibt die Frage, wie lange deine Eingaben beim Anbieter liegen. OpenAI etwa bewahrt API-Daten standardmäßig bis zu 30 Tage auf, zur Missbrauchskontrolle; für qualifizierte API-Kunden gibt es Zero Data Retention: Die Eingaben werden dann gar nicht erst gespeichert.

Warum mir dieser Punkt wichtig ist, zeigt der Rechtsstreit zwischen der New York Times und OpenAI: Ein US-Gericht zwang OpenAI 2025 monatelang, auch von Nutzern gelöschte Chats aufzubewahren. Die Anordnung endete im September 2025, die Daten aus diesem Zeitraum bleiben aber für das Verfahren gespeichert. (Zero-Data-Retention-Kunden waren ausgenommen.) Die Lehre ist keine Anti-Cloud-Parole, sondern nüchtern: Löschversprechen stehen unter dem Vorbehalt fremder Rechtsordnungen. Ein US-Anbieter kann dir viel zusichern – wenn ein US-Gericht anders entscheidet, entscheidet das US-Gericht.

Die Konsequenz ist dieselbe, die ich im Vergleich lokales LLM vs. Cloud-API beschrieben habe: Datenklassifizierung statt Panik. Es gibt Code und Daten, die nie in eine US-Cloud gehören: Dafür gibt es lokale Modelle. Zero Data Retention ist das Werkzeug für die Fälle dazwischen.

Punkt 5: Technik, die deine Regeln durchsetzt. Secrets-Hygiene und die .gitignore für die KI

Papier allein hält keinen Entwickler unter Deadline-Druck auf. Nicht zynisch gemeint, sondern als Planungsgrundlage. Deine Richtlinie braucht deshalb technische Zähne. Wie nötig das ist, zeigen die Zahlen von GitGuardian: Allein 2025 landeten 28,65 Millionen neue hartcodierte Secrets (Passwörter, API-Schlüssel und Co.) in öffentlichen GitHub-Commits, 34 Prozent mehr als im Vorjahr. Repositories mit aktivem Copilot leaken dabei häufiger: In einer Stichprobe von rund 20.000 Copilot-Repos enthielten 6,4 Prozent mindestens ein geleaktes Secret, 40 Prozent über der Basisrate. Und der Satz, den du ruhig zweimal lesen darfst: 64 Prozent der 2022 geleakten gültigen Zugangsdaten funktionierten Anfang 2026 immer noch.

Drei Handgriffe, übersetzt in Geschäftsführer-Sprache. Erstens: Secrets raus aus dem Code, hinein in einen Secret-Manager oder in Umgebungsvariablen. Was nicht im Code steht, kann die KI weder sehen noch weiterreichen. Zweitens: ein Pre-Commit-Scanner als automatischer Türsteher. Werkzeuge wie gitleaks oder ggshield prüfen jede Code-Änderung auf Zugangsdaten, bevor sie das Haus verlässt; GitHubs Push Protection ergänzt das serverseitig. Drittens: Content Exclusion in Copilot Business und Enterprise, eine Art .gitignore für die KI: Sensible Pfade und Dateien werden dem Modell gar nicht erst gezeigt.

Das alles ist Entwickler-Handwerk, und du musst es nicht selbst können. Dein Anteil ist, es zu beauftragen und in der Definition of Done zu verankern, sonst bleibt es ein „machen wir irgendwann“. Und falls du dich fragst, ob ich hier vom hohen Ross predige: Ich habe bei meinen eigenen KI-Agenten erst nachträglich gemerkt, dass mein Sicherheitskonzept der Automatisierung hinterherhinkte. Dieser Punkt steht also auch aus eigener Lektion auf der Liste.

Die Ein-Seiten-Dev-Richtlinie: fünf Punkte, ein Nachmittag

Zum Schluss das Ganze als Übersicht, als Dev-Ergänzung zur allgemeinen KI-Nutzungsrichtlinie deines Unternehmens, nicht als Ersatz dafür:

Bei webiator ist genau das der Rahmen, in dem ich selbst arbeite. Ich habe mir 2021 geschworen, KI ausschließlich DSGVO-konform einzusetzen; daraus ist eine einfache Trennung geworden: Sensibles bleibt auf eigenen Servern, in die Cloud geht nur, was sie sehen darf, und zwar über Zugänge, deren Eingaben nicht ins Training fließen. Und Code, den mir die KI schreibt, lese ich, bevor er in Produktion geht; sie hat mir schon einmal eine „vereinfachte“ Sicherheitsprüfung untergeschoben, und solche Momente kuriert man nur mit Review. Ich verkaufe dir hier also nichts, was ich nicht selbst benutze.

Nach meiner Erfahrung (ein Erfahrungswert, kein Versprechen) ist das Meiste davon in einer Woche geregelt: die Tarif-Entscheidung ein Nachmittag, die Richtlinie eine Seite, die technischen Kontrollen ein überschaubares Ticket für dein Team. Verglichen mit dem, was ein einziger abgeflossener Kundencode kosten kann, ist das fast schon verdächtig günstig.

Wenn deine Entwickler längst mit KI arbeiten und du beim Lesen gemerkt hast, dass es bei dir weder eine Tarif-Entscheidung noch eine Dev-Richtlinie gibt: Lass uns reden. Im Erstgespräch schauen wir gemeinsam, welche Tools bei dir im Einsatz sind, welche Verträge betroffen sind und was sich davon erfahrungsgemäß in einer Woche regeln lässt. Pragmatisch, ohne Verbots-Reflex. Genau diese Übersetzung von Regulatorik in konkrete technische Maßnahmen ist der Kern unserer Arbeit in KI und Compliance.