GitHub Copilot DSGVO-konform einführen: Mittelstand und regulierte Branchen

Pexon Consulting | 15 Min. Lesezeit | 15.06.2026

TL;DR

GitHub Copilot DSGVO ist 2026 für die meisten deutschen Mittelständler nicht das technische, sondern das vertragliche Problem: Microsoft bietet AVV, EU-Datenresidenz und IP-Indemnification — aber Banking-, Versicherungs- und KRITIS-Compliance verlangt zusätzliche Klärungen zu Code-Privacy, Trainings-Garantien und Audit-Trail. Pexon Consulting organisiert die Lizenzen über einen Partner und begleitet das Compliance-Setup für regulierte Branchen. Compliance für Cloud & KI, die euer Business nicht ausbremst — sondern

Warum DSGVO bei Copilot mehr als ein Häkchen ist

Wir hören das aktuell wöchentlich in CISO- und Compliance-Erstgesprächen: Das Engineering-Team will GitHub Copilot, der Datenschutzbeauftragte zögert. Die Diskussion bewegt sich oft im Allgemeinen („AI-Tools sind kritisch“), während die konkreten DSGVO-Anforderungen eine differenzierte Antwort verlangen.

Was DSGVO konkret verlangt bei Copilot-Einsatz: Erstens, ein wirksamer Auftragsverarbeitungsvertrag (AVV) nach Art. 28 mit GitHub als Auftragsverarbeiter. Zweitens, Klarheit über die Datenverarbeitung — werden personenbezogene Daten in den Code-Snippets verarbeitet, fließen sie in Trainings-Daten. Drittens, Datenresidenz innerhalb der EU bei sensitiven Workloads. Viertens, ein nachvollziehbarer Audit-Trail bei Vorfällen.

Was Microsoft konkret bietet: Ein Standard-AVV ist Teil des Enterprise-Agreements. Code-Snippets, die Engineers durch Copilot schicken, werden vertraglich nicht für Trainings genutzt. Datenresidenz EU ist seit 13.04.2026 über GitHub Enterprise Cloud mit Data Residency konfigurierbar (Microsoft EU Data Boundary, seit 01.05.2026 inklusive EFTA). Die Policy ist standardmäßig aus, Anfragen kosten 10 % mehr Modell-Multiplikator, Gemini-Modelle sind ausgenommen. Das Audit-Log hält Ereignisse 180 Tage und enthält keine Prompts.

Wo die Lücke entsteht: Bei regulierten Branchen (Banking, Versicherung, KRITIS) reichen die Standard-Klauseln oft nicht. BaFin-Bankaufsichts-Audit verlangt zusätzlich Vor-Ort-Audit-Rechte bei Sub-Unternehmern, Solvency II verlangt explizite Drittparteien-Bewertung, KRITIS-Konkretisierung des BSI verlangt klare Klassifikation der Datenflüsse. Mehr zur systematischen Compliance-Architektur für AI-Werkzeuge.

Drei Risiko-Kategorien beim Copilot-Einsatz

Wir bauen mit Compliance-Verantwortlichen eine klare Klassifikation auf.

Kategorie 1: Standard-Code ohne Geschäftsgeheimnis-Charakter. Boilerplate-Code, Standard-Patterns, gängige Algorithmen. Hier ist das Risiko minimal. Standard-Vertragslage mit Microsoft reicht aus. 70-85% des typischen Engineering-Codes fallen in diese Kategorie.

Kategorie 2: Code mit Geschäftsgeheimnis-Charakter aber ohne personenbezogene Daten. Eigene Algorithmen, interne Optimierungs-Logik, Produkt-spezifische Patterns. Hier sind die vertraglichen Trainings-Garantien wichtig — Microsoft committet sich vertraglich, dass diese Snippets nicht in Trainings-Daten fließen. Wir empfehlen zusätzlich Code-Privacy-Filter aktivieren plus klare interne Klassifikation, welche Repositories als Geschäftsgeheimnis gelten.

Kategorie 3: Code mit personenbezogenen Daten oder besonders sensitiven Inhalten. Test-Daten mit echten Kundendaten, Banking-Algorithmen mit Risiko-Bewertungs-Logik, medizinische Datenverarbeitung. Hier reicht Standard-Copilot oft nicht. Wir empfehlen je nach Sensitivitäts-Stufe: Filter-Konfiguration, separates Tenant-Setup, oder bei höchster Stufe alternative Werkzeuge — mehr im Pattern für sovereign-konforme Engineering-Tools.

Die Klassifikation muss vor dem Roll-out stehen, sonst entstehen schleichende Compliance-Lücken.

Banking, Versicherung, KRITIS: spezifische Anforderungen

Drei Branchen mit erhöhtem Compliance-Druck haben jeweils eigene Pattern.

Banking unter BaFin (BAIT). BAIT verlangt klare Auslagerungs-Bewertung für externe IT-Werkzeuge. Wir bauen typisch ein dokumentiertes Risk-Assessment, das Copilot als Tier-2-Auslagerung klassifiziert (begrenzte Auswirkung auf Kerngeschäfts-Funktionen). Plus Audit-Log-Anbindung an eure SIEM-Plattform, die wir bauen. Wichtig: Das Copilot-Audit-Log enthält keine Prompts. Wer jeden Copilot-Aufruf protokollieren muss, braucht eine eigene Lösung, zum Beispiel über Hooks. Nutzungsdaten liefert die Copilot Usage Metrics API.

Versicherung unter Solvency II. Drittparteien-Risiko-Bewertung pro AI-Werkzeug ist Pflicht. Solvency II verlangt zusätzlich Business-Continuity-Bewertung: Was passiert, wenn Copilot ausfällt. Bei Engineering-Werkzeugen ist das niedrig-kritisch (Engineers können ohne Copilot weiterarbeiten), aber muss dokumentiert sein.

KRITIS-Konkretisierung BSI. Klare Klassifikation der Datenflüsse plus Lieferanten-Vor-Ort-Audit-Rechte sind die zwei zentralen Anforderungen. Microsoft als Standard-Auftragsverarbeiter erfüllt das nicht direkt — wir verhandeln Sondervereinbarungen mit Branchen-Kontext, sind aber transparent: Bei höchsten KRITIS-Tier-1-Stufen ist Copilot nicht der richtige Stack.

Bei allen drei Branchen ist der Compliance-Setup-Sprint typisch 4-8 Wochen zusätzlich zum Standard-Rollout.

Regulator-Matrix: Was DSGVO, BaFin, NIS2 und KRITIS erlauben

Welche Lizenz und welches Setup reicht, entscheidet die strengste Regulierung, die für ein Repository gilt. Die Matrix fasst die Schichten zusammen.

Daraus folgen drei rote Linien: keine privaten Free- oder Pro-Lizenzen für Firmencode, ein nachgewiesener Verarbeitungspfad je Repository-Klasse und ein Audit-Trail, der außerhalb von GitHub länger als die 180 Tage des Audit-Logs hält. Wer eine davon übergeht, läuft in den nächsten Audit-Befund.

KRITIS Tier-1 und Defence: wo Copilot an Grenzen stößt

Bei KRITIS-Betreibern (Energie, Wasser, Gesundheit, Verkehr) ist nicht die Lizenz die Frage, sondern der Nachweis jedes Verarbeitungspfads. Cloud-Dienste mit US-Anteil sind nicht per se ausgeschlossen, aber jeder Pfad muss dokumentiert sein.

Ohne Mehraufwand: Repositories ohne Bezug zur kritischen Anlage, also Frontend, Reporting-Pipelines und interne Tools. Hier reicht das Banking-Setup: Business oder Enterprise, Content Exclusion für sensible Repos, Audit-Log im SIEM.

Mit Mehraufwand: Repositories mit Bezug zur kritischen Infrastruktur, etwa SCADA-Anbindungen, Netzsteuerung oder Systeme mit Patientendaten. Für viele davon beantwortet die EU-Datenresidenz (Details oben) die Residenzfrage ohne eigenen Modellbetrieb.

On-Prem-Code-Assistance nur für Air-Gap-Repos. Wo Code das Unternehmensnetz gar nicht verlassen darf, laufen Code-Modelle wie Codestral, DeepSeek-Coder oder Qwen-Coder auf eigenen GPU-Servern. Die Teams arbeiten dann mit zwei Werkzeugen je nach Repository-Klasse. Das ist operativ aufwendiger, deshalb nur dort, wo EU-Datenresidenz nicht reicht. Mehr zur Compute-Strategie bei strikten Datenresidenz-Anforderungen.

Defence als Sonderfall. Bei Zulieferern der Bundeswehr und der NATO-Partnerindustrie greifen zusätzlich ITAR und EAR, US-Cloud-Anteile sind in vielen Verträgen ausgeschlossen. Dann scheidet die Cloud-Variante von Copilot für die betroffenen Repositories aus, und die On-Prem-Variante wird zum Standard. Der Aufwand liegt deutlich über dem normalen Compliance-Sprint und wird eigens geplant.

Welcher Pfad passt, hängt am Repository-Portfolio und am Risikoappetit des CISO. Grundlage ist die Klassifikation nach den drei Risiko-Kategorien oben.

Audit-Trail und Compliance-Report: was ins SIEM gehört

Vorab die Grenze: Das Copilot-Audit-Log enthält keine Prompts und keine anderen Client-Sessiondaten und hält Ereignisse 180 Tage. Es zeigt, wer Lizenzen, Richtlinien und Einstellungen geändert hat. Nutzungs- und Adoptionsdaten kommen aus der Copilot Usage Metrics API, inzwischen auch auf Team- und Repository-Ebene.

Pipeline: Das Audit-Log läuft per Streaming ins SIEM (Sentinel, Splunk oder vergleichbar) und wird dort mit der Sensitivitätsklasse des Repositories angereichert. Die Langzeit-Historie liegt im SIEM, nicht bei GitHub. Wer Prompts protokollieren muss, braucht eine eigene Lösung, zum Beispiel über Hooks.

Quartals-Compliance-Report aus SIEM-Daten und Usage Metrics API:

• Nutzung je Repository-Klasse (öffentlich, intern, vertraulich, KRITIS) aus den Metriken auf Repository-Ebene
• Anomalie-Indikatoren, etwa ungewöhnlich hohe Nutzung in KRITIS-Repos oder Richtlinienänderungen außerhalb des Change-Prozesses
• Adoptions-Kennzahlen wie aktive Nutzer und Akzeptanzrate
• Treffer aus Secret Scanning und Code Scanning

Bei einer Prüfung durch BaFin, BSI oder interne Revision ist dieser Report der Compliance-Nachweis.

Pexon-Sprint für Compliance-konformen Copilot-Roll-out

Wir liefern den Compliance-konformen Roll-out als 6-10-Wochen-Sprint mit klarer Branchen-Anpassung.

Wochen 1-2: Klassifikations-Inventur eurer Code-Repositories nach den drei Risiko-Kategorien, Vertrags-Lage mit eurem CISO und Datenschutzbeauftragten, Lizenz-Beschaffung über einen Partner.

Wochen 3-5: Tenant-Setup mit EU-Datenresidenz, Filter-Konfiguration, Audit-Trail-Anbindung an euer SIEM (Sentinel, Splunk, Sumo Logic). Pilot mit 4-8 Engineers aus den niedrigeren Risiko-Kategorien.

Wochen 6-10: Roll-out auf das gesamte Engineering-Team, dokumentierter Compliance-Nachweis für euren Auditor, Übergabe inkl. Quarterly-Review-Pattern.

Investment 22-35k EUR Setup-Sprint je nach Branchen-Compliance-Tiefe. Lizenz-Kosten kommen zusätzlich.

Häufig gestellte Fragen

Reicht der Standard-Microsoft-AVV für BaFin-konforme Banken?

Für die meisten Tier-2- und Tier-3-Banken ja, mit ergänzender interner Auslagerungs-Doku. Für Tier-1-Banken oder bei Engagements mit erhöhtem regulatorischen Druck empfehlen wir branchenspezifische Sondervereinbarungen. Wir kennen die typischen BaFin-Fragestellungen aus mehreren Banking-Projekten.

Können wir Code-Snippets verhindern, die in die Copilot-Cloud gehen?

Bei Standard-Copilot: nein, das ist die Arbeitsweise. Mit Copilot Spaces (in allen Plänen, Nachfolger der eingestellten Knowledge Bases) und Content Exclusion habt ihr mehr Kontrolle über den Kontext, der mitgegeben wird. Content Exclusion greift allerdings nicht im Edit- und Agent-Modus der IDEs. Für maximale Souveränität braucht es alternative Werkzeuge — mehr im Pattern für on-prem-LLM-Setups.

Was passiert mit personenbezogenen Daten in Test-Daten?

Best Practice: Test-Daten mit echten personenbezogenen Daten haben in der Codebase nichts zu suchen, unabhängig von Copilot. Wir bauen typisch Mock-Daten-Pipelines auf, die das systematisch verhindern. Wenn ihr es heute trotzdem habt, ist Copilot-Risiko nur ein Teil eines größeren Problems.

Wie reagiert ein BaFin- oder BSI-Audit auf Copilot-Nutzung?

Sehr unterschiedlich je nach Auditor und Reife eures Compliance-Setups. Mit dokumentiertem Klassifikations-Pattern, klarem Risk-Assessment und Audit-Trail habt ihr belastbare Unterlagen für die Prüfung. Ohne strukturierten Setup ist es ein Glücksspiel.

Was, wenn der Datenschutzbeauftragte zögert?

Häufig berechtigt. Wir bauen typisch ein zweistufiges Setup auf: Erst eine 4-Wochen-Pilot-Phase mit 5-8 Engineers und unkritischen Repositories, dann mit dokumentierten Erfahrungen die Diskussion mit dem Datenschutzbeauftragten. Das schafft Faktenbasis statt theoretischer Debatte.

Was tun bei Drittland-Transfer-Bedenken des Datenschutzbeauftragten?

Microsoft hat die Standardvertragsklauseln (SCCs) und das EU-US Data Privacy Framework im Enterprise-Vertrag. Dazu kommt seit 13.04.2026 die Copilot-Datenresidenz in der EU (GitHub Enterprise Cloud mit Data Residency, Policy standardmäßig aus). Für Standard-DSGVO-Anwendungen ist die rechtliche Lage damit sauber. Banken und Versicherer verlangen intern oft zusätzlich ein Transfer Impact Assessment (TIA), die Vorlage dafür gehört zum Sprint.

Reicht Copilot Business statt Enterprise?

In vielen Fällen ja, auch bei BaFin- oder NIS2-Pflicht: Content Exclusion und IP Indemnification gibt es in Business und Enterprise. Enterprise lohnt sich für Codebase-Indexing, die native Nutzung auf github.com und mehr AI Credits (3.900 statt 1.900 pro User und Monat), setzt aber GitHub Enterprise Cloud voraus. Bei KRITIS-Repositories mit Air-Gap-Anforderung kommt eine On-Prem-Variante für genau diese Repos dazu.

Wer haftet, wenn eine Copilot-Suggestion eine Sicherheitslücke einbaut?

Das Restrisiko liegt beim Code-Owner: Wer die Suggestion akzeptiert und in Produktion bringt, trägt die Verantwortung. Die IP-Freistellung deckt Ansprüche wegen reproduziertem Open-Source-Code ab, nicht funktionale oder sicherheitsbezogene Fehler. Deshalb gehören Secret Scanning und Security-Reviews fest ins Setup.

Welche branchenspezifischen Regeln werden oft übersehen?

Bei Versicherern kommt § 32 VAG (Ausgliederung) dazu: Die Copilot-Nutzung kann als IT-Ausgliederung eingestuft werden, dann braucht es die passende Ausgliederungs-Doku. Im Gesundheitswesen gelten für Gesundheitsdaten die strengeren Regeln aus Art. 9 DSGVO. Repositories mit Bezug zu Patientendaten sollten keine echten Patientendaten enthalten und zusätzlich Content Exclusion bekommen, mit den genannten Grenzen im Agent-Modus.

Was passiert nach dem Compliance-Sprint?

Übergabe an euer Engineering- und Security-Team. Optional übernimmt Pexon danach laufend die Quartals-Compliance-Reports, die Untersuchung von Anomalien und die Lizenz-Optimierung.

Nächster Schritt

Wenn dein Unternehmen in einer regulierten Branche operiert und GitHub Copilot DSGVO-konform einführen will: Wir machen einen 60-Minuten-Call mit dir und idealerweise dem CISO oder Datenschutzbeauftragten. Du beschreibst die Compliance-Lage und Engineering-Struktur, wir skizzieren den Setup-Sprint inkl. Lizenz-Beschaffung.

Verwandte Themen