Default-on seit 24. April: GitHub trainiert Copilot mit Nutzer-Code

Teil 1 einer dreiteiligen Serie zu GitHub-Alternativen.

Seit dem 24. April 2026 gilt bei GitHub Copilot eine neue Hausordnung. Wer im Free-, Pro- oder Pro+-Tarif arbeitet, trägt seine Eingaben standardmäßig zum KI-Training bei. Wer das nicht will, muss aktiv widersprechen. Geschäftskunden bleiben außen vor — und genau das ist die eigentliche Geschichte.

Defaults sind die mächtigste Form der Verhaltenssteuerung, weil sie unsichtbar funktionieren. Niemand klickt sie weg, weil niemand sie sieht. Genau diese Eigenschaft hat GitHub genutzt, als das Unternehmen am 26. März die Ankündigung veröffentlichte und dem Markt vier Wochen Zeit ließ, sich daran zu gewöhnen. Seit dem 24. April ist der Schalter umgelegt. Wer in den Einstellungen unter /settings/copilot/features nichts unternimmt, schickt fortan Code-Kontext um die Cursor-Position, Prompts, Dateinamen, Navigationsmuster und Kommentare an die Modellpipeline der Plattform — eine ziemlich vollständige Beschreibung dessen, woran ein Entwickler gerade arbeitet.

Die juristische Inszenierung ist sauber: rechtzeitige Ankündigung, dokumentierte Privacy-FAQ, klar bezeichneter Opt-out-Schalter, sogar die Bestandsregel, dass alte Entscheidungen übernommen werden. Wer den vorherigen, allgemeineren Schalter „use my code snippets to improve products" bereits deaktiviert hatte, dessen Präferenz bleibt erhalten. Was diese Änderung trotzdem zum Lehrstück macht, ist nicht ein Verfahrensfehler. Es ist die Grundkonstruktion: Default-on für individuelle Nutzer, Default-off für zahlende Geschäftskunden.

Wer was bekommt

Die Trennlinie verläuft zwischen Tarifen. Copilot Free, Pro und Pro+ — die individuellen Konten — geben Interaktionsdaten ab. Copilot Business und Enterprise nicht. Geteilt werden dürfen die Daten laut FAQ „mit GitHub-Affiliates", was Microsoft als Konzernmutter explizit einschließt; OpenAI und Anthropic sollen sie nicht erhalten. So weit der offizielle Stand.

Auffällig ist nicht, was im Detail passiert, sondern was die Aufteilung selbst sagt. Microsoft erkennt damit zweierlei an. Erstens, dass die Verarbeitung sensibel genug ist, um Geschäftskunden davor zu schützen — wäre sie folgenlos, müsste man Business-Tarife nicht ausnehmen. Die Existenz der Ausnahme ist das Eingeständnis. Zweitens, dass die individuelle Nutzerschicht als Trainingsmaterial einkalkuliert ist. Nicht beiläufig, nicht als Nebeneffekt, sondern als Plattform-Entscheidung. Wer privat mit Pro-Account in einem Hobbyprojekt, einer Nebentätigkeit oder einem OSS-Beitrag arbeitet, liefert standardmäßig Trainingsdaten für die Modelle, die anschließend an Geschäftskunden vermarktet werden.

Für deutsche Mittelstandsentwickler ist die Konstellation besonders unangenehm. Wer im Büro mit Copilot Business und zu Hause mit Copilot Pro arbeitet — ein Setup, dessen Häufigkeit nicht zu unterschätzen ist —, lebt zwischen zwei Welten mit unterschiedlichen Default-Annahmen über Datenfluss. Die Trennung der mentalen Modelle muss der Entwickler selbst leisten.

Wie der Schalter zu dem wurde, was er ist

Die Vorgeschichte erklärt vieles. Im Juni 2021 startete Copilot als Public Preview, trainiert wurde das zugrundeliegende OpenAI-Codex-Modell auf öffentlichem GitHub-Code, ohne dass Lizenzbedingungen wie GPL oder Apache 2.0 systematisch berücksichtigt wurden. Im November 2022 folgte die Klage Doe et al. v. GitHub, die in Teilen bis heute läuft. 2023 stellte GitHub klar, dass private Repositories nicht zum Copilot-Training herangezogen werden — eine Selbstverpflichtung, kein einklagbares Versprechen, und sie betraf den Trainingsdatensatz, nicht jede Verarbeitungsschicht.

Zwischen 2023 und 2025 existierte der allgemeine Schalter „use my code snippets to improve products". Was unter „verbessern" fiel, definierte GitHub: Bug-Triage, Telemetrie-Aggregation, ML-Modelle für Search-Ranking, Prompt-Tuning — nichts davon explizit ausgeschlossen. Im März 2026 schließlich der jetzt diskutierte Schritt. Aus der vagen Verbesserungs-Klausel wurde ein expliziter, namentlich KI-Training adressierender Toggle, mit klarer Default-on-Position für Free, Pro und Pro+.

Die Stoßrichtung ist erkennbar: erst das vage Versprechen, dann die explizite Verarbeitung beim Namen genannt. Juristisch ist das sauberer als die alte Lösung, weil Konsens zumindest formal informiert ist. Es ist aber auch ein Signal dafür, dass Microsoft die Datennutzung jetzt offen ausweisen will, statt sie unter „Service-Verbesserung" zu subsumieren. Aus einer impliziten Praxis wird eine deklarierte.

Was Default-on rechtlich heißt

Default-on bei sensiblen Verarbeitungen ist nicht unproblematisch. Die DSGVO verlangt für Einwilligungen eine „eindeutige bestätigende Handlung" (Art. 4 Nr. 11), und der EuGH hat in Planet49 (2019) klargestellt, dass voreingestellte Häkchen keine wirksame Einwilligung darstellen. GitHub argumentiert, der Opt-out-Schalter sei keine DSGVO-Einwilligung, sondern eine vertragliche Nutzungsregel auf Grundlage berechtigten Interesses oder Vertragserfüllung. Die Konstruktion ist möglich, aber bestreitbar. Wenn ein Verarbeitungszweck so weit gefasst ist wie „Trainingsdaten für KI-Modelle, geteilt mit dem Microsoft-Konzernverbund", wird das berechtigte Interesse auf Anbieterseite zur Generalvollmacht.

Der Streitwert wird ausgefochten, sobald die ersten Datenschutzbehörden tätig werden. Lead Authority für Microsoft ist die irische DPC, was Verfahren erfahrungsgemäß verlangsamt. Bis zu einer rechtskräftigen Klärung — realistisch frühestens 2028 — gilt der Default-on-Zustand für alle, die ihn nicht aktiv ändern.

Aus Compliance-Sicht ist die Lage für Unternehmen, die Mitarbeiter mit privaten GitHub-Konten arbeiten lassen, neu zu bewerten. Wer im Home-Office mit dem privaten Pro-Account Code für ein Firmen-OSS-Projekt schreibt, schickt jetzt Interaktionsdaten an GitHub, die mit Microsoft geteilt werden können. Ob das Verzeichnis von Verarbeitungstätigkeiten und die DSFA das abdecken, ist eine Frage, die Datenschutzbeauftragte sehr schnell beantworten müssen.

Der bequeme Reflex und die ehrlichere Begründung

Hier eine Klarstellung, die zur Ehrlichkeit gehört. Das US-Hosting-Argument — CLOUD Act, Schrems II, FISA 702 — ist real und juristisch ernst zu nehmen. Aber es taugt nur begrenzt als alleiniger Migrationsanlass für Unternehmen, die ohnehin AWS, Azure, Cloudflare und ähnliche US-Dienste in ihrer Infrastruktur nutzen. Wer seine Web-Infrastruktur über Cloudflare laufen lässt und seine Daten-Pipelines auf AWS hat, kann nicht widerspruchsfrei argumentieren, GitHub sei ausgerechnet wegen US-Sitz unhaltbar.

Die ehrlichere Begründung ist eine andere. Code ist sensibler als Web-Traffic oder Object-Storage. Code ist aktive Geschäftsgrundlage, oft Geschäftsgeheimnis, manchmal sogar wettbewerbsentscheidend. Bei AWS werden Bytes gespeichert, bei Cloudflare wird HTTPS TLS-terminiert. Bei GitHub bekommt eine Plattform seit dem 24. April das Recht, Code-Eingaben für Modelltraining zu nutzen — sofern das Konto im Free-, Pro- oder Pro+-Tarif liegt und nicht aktiv widersprochen wurde. Das ist eine andere Klasse von Vertrauensentscheidung.

Der Datenschutz-Aspekt bleibt damit relevant, aber als Verstärker eines spezifischeren Arguments. Default-on bei Trainingsnutzung ist die primäre Grenzlinie. CLOUD Act und ähnliche Drittstaaten-Probleme sind sekundärer Faktor — sie verschärfen die Konsequenzen einer Default-on-Entscheidung, weil Daten dann nicht nur im Konzernverbund eines Anbieters, sondern auch im Zugriff staatlicher Stellen landen können.

Drei Hebel im Werkzeugkasten

Drei rechtliche Instrumente lohnen sich zu kennen, weil sie greifen, auch wenn die Plattform US-amerikanisch bleibt.

Der erste ist die TDM-Reservation nach Art. 4 DSM-Richtlinie / § 44b UrhG. EU-Recht erlaubt Text- und Data-Mining für kommerzielle Zwecke nur, wenn der Rechteinhaber keinen maschinenlesbaren Vorbehalt erklärt. Eine Prosa-Klausel im README reicht nach herrschender Auslegung nicht. Konkret braucht es Header, robots.txt-Einträge, idealerweise eine ai.txt. Mehr dazu in Teil 2.

Der zweite ist der EU AI Act, seit August 2024 in Kraft. Art. 53 verpflichtet Anbieter sogenannter General-Purpose-AI-Modelle zur Trainingsdaten-Transparenz und zur Achtung von TDM-Vorbehalten. Das Sanktionsregime greift ab August 2026, also vier Monate nach der GitHub-Änderung. Die Einhaltung von TDM-Vorbehalten wird damit nicht nur urheberrechtlich, sondern auch produktrechtlich relevant.

Der dritte ist die DSGVO über Metadaten. Code selbst ist meist kein personenbezogenes Datum, Commit-Metadaten und Interaktionsdaten dagegen sehr wohl. Name, E-Mail, IP, Zeitstempel, Cursor-Position über die Zeit — das ist Art-4-Material. Ein Anbieter, der diese für eigene Zwecke wie Modelltraining nutzt, braucht eine eigene Rechtsgrundlage; ein Auftragsverarbeitungsvertrag genügt dafür nicht.

Die drei Hebel ergeben kein Komplettpaket, aber einen Werkzeugkasten, mit dem sich der Default-on-Mechanismus zumindest punktuell außer Kraft setzen lässt.

Vom Schalter zur Plattformfrage

Die Änderung vom 24. April 2026 ist ein Anlass, sich über die strukturellen Defaults der Plattform Gedanken zu machen — nicht nur über den einen Schalter. Bei kommerziellen Wettbewerbern wie GitLab, Bitbucket oder Azure DevOps existieren strukturell ähnliche Mechanismen, mit unterschiedlichen Defaults und unterschiedlich offen kommunizierten KI-Anbindungen.

Teil 2 stellt die Alternativen vor: Codeberg und Forgejo als die heute am weitesten ausgereiften Default-off-Plattformen, GitLab CE als Self-Hosting-Variante mit garantiert deaktiviertem KI-Layer, dazu Sourcehut, Gogs, Launchpad — und als Kontrast AWS CodeCommit, das seit Juli 2024 keine neuen Kunden mehr akzeptiert. Teil 3 wird operativ.

Diese Serie:

Teil 1: Default-on seit 24. April – GitHub trainiert Copilot mit Nutzer-Code (dieser Artikel)
Teil 2: Alternativen im Vergleich – Codeberg, Forgejo, Gogs, Launchpad und mehr
Teil 3: Migration mit CI-Fokus – vom Plan zur Ausführung

Quellen: