GitHub-Copilot-Pläne: Der komplette Leitfaden zu Funktionen und Administration über alle Stufen

GitHub-Copilot-Pläne im Überblick

GitHub bietet mehrere klar abgegrenzte Stufen für sein Ökosystem. Bemerkenswert ist, dass die Plattform ihre Einführung nutzungsbasierter Abrechnung abschließt und im Juni 2026 das bisherige „Premium Request Unit“ (PRU)-Modell durch GitHub AI Credits ersetzt.

Im neuen System bleiben grundlegende Codevervollständigungen und „Next Edit“-Vorschläge unbegrenzt und verbrauchen keine Credits. 

Fortgeschrittene Vorgänge wie Multi-File-Chat, agentische Workflows, lang laufende Codingsessions und tiefgehende Code-Reviews verbrauchen hingegen AI Credits auf Basis des Tokenverbrauchs (Input, Output und gecachte Tokens) relativ zu den veröffentlichten API-Raten des jeweiligen Modells. 

Die Basis-Abopreise pro Monat bleiben konstant, aber die Umstellung verändert, wie Administratoren Zusatznutzungen budgetieren und die aktive Nutzung überwachen.

Individuelle Pläne: Free, Student, Pro und Pro+

Die individuellen Stufen unterscheiden sich bei Modellzugang, Nutzungslimits und experimentellen Funktionen. Während die Free-Stufe die grundlegende Erkundung ermöglicht, bietet Pro+ etwa Zugang zu GitHub Spark, einer Umgebung für den Aufbau KI-gestützter Anwendungen.

Aktuell sind Neuregistrierungen für die kostenpflichtigen Einzelkonten von GitHub – wie Pro, Pro+ und Student – pausiert. Bestehende Konten können von Pro auf Pro+ upgraden, aber neue Konten können sich erst anmelden, wenn GitHub die Umstellung auf das neue nutzungsbasierte Abrechnungssystem mit AI Credits abgeschlossen hat.

Business und Enterprise

Bei Business und Enterprise wandelt sich GitHub Copilot vom IDE-Plugin zu einem voll prüfbaren Enterprise-Infrastruktur-Asset.

GitHub Copilot Business führt zentrale Managementfunktionen ein:

• Zentrale Zuweisung und Entzug von Sitzplätzen.
• Organisationsweite Richtlinien-Baselines.
• Strukturierte Audit-Logs und Compliance-Ereignistracking.
• Inhalts- und Repository-Dateiausschlüsse.
• Kommerzielle Freistellung bei Ansprüchen zum geistigen Eigentum.

GitHub Copilot Enterprise erweitert Kontrolle und Leistungsumfang weiter:

• Copilot Spaces: Ein Wissenshub, der es Entwicklern ermöglicht, Copilot gegen interne Dokus, Wikis und systemische Codestandards zu prompten.
• Verbesserte GitHub.com-Chat-Integration.
• Hierarchische Richtlinienvererbung über untergeordnete Organisationen hinweg.

GitHub Copilot Enterprise erfordert ein aktives GitHub Enterprise Cloud-Abonnement. Da GitHub Enterprise Cloud 21 $ pro Nutzer und Monat kostet und die Copilot-Enterprise-Lizenz 39 $ pro Nutzer und Monat, liegen die tatsächlichen Mindestkosten bei 60 $ pro Nutzer und Monat für Enterprise. Dies gilt nicht für die Stufe GitHub Copilot Business, die Organisationen auch auf GitHub Free oder GitHub Team nativ erwerben können.

Organisationen verzichten damit zwar auf Enterprise-Vorteile wie Richtlinienvererbung, erhalten aber IP-Freistellung, Auditing, Dateiausschluss und Organisationsrichtlinien-Management – eine gute Alternative für mittelgroße Engineering-Teams.

Wenn du über ein Enterprise-Abo nachdenkst, zeigt dir unser Leitfaden GitHub Copilot Enterprise, wie du Features wie Copilot Spaces und die neue Usage-Metrics-API nutzt.

Was individuelle und Business-Pläne trennt

Datenmanagement, IP-Freistellung und Abrechnung sind die Hauptbereiche, in denen sich individuelle und Business-Pläne stark unterscheiden. Zusätzliche Nutzerfunktionen sind nett, aber diese Unterschiede sind entscheidend, wenn du zwischen vielen persönlichen Pro-Lizenzen und einem Business-Abo entscheidest.

Datenverarbeitung und Trainings-Defaults

Für Teams mit proprietären Systemen ist Datenschutz in der Regel der entscheidende Faktor zwischen persönlichen Plänen und Business-Abos.

Im April 2026 hat GitHub die Erfassung von Interaktionsdaten für individuelle Copilot-Pläne geändert. Bei Free-, Pro- und Pro+-Nutzern können Interaktionsdaten nun standardmäßig zum Modelltraining verwendet werden, es sei denn, die Nutzer widersprechen aktiv (Opt-out).

Lass uns den Unterschied zwischen ruhendem Code und Interaktionsdaten klären, um zu verstehen, was fürs KI-Training verwendet wird:

• Ruhender Code: Der Rohcode in deinem privaten Repository wird nicht gelesen oder in öffentliche Trainingssets aufgenommen.
• Interaktionsdaten: Dazu gehören Prompts, Chat-Anfragen, Cursor-Kontext, umliegende Codeblöcke, die während aktiver Editiersessions über die IDE-API gesendet werden, Annahmeraten von Vorschlägen und Feedback-Logs.

Business- und Enterprise-Verträge enthalten eine strikte vertragliche Zusicherung, dass Interaktionsdaten unter keinen Umständen zu Trainingszwecken verwendet werden. Kein manuelles Eingreifen durch Nutzer erforderlich.

Für einen tieferen Einblick, wie Daten genutzt werden und wie du Probleme in Copilot löst, empfehle ich unseren Leitfaden GitHub Copilot Privacy and Troubleshooting.

IP-Freistellung

GitHub Copilot Business und Enterprise beinhalten eine Freistellung beim geistigen Eigentum (IP Indemnity) für generierten Code. Individuelle Pläne nicht.

Praktisch bedeutet Freistellung, dass GitHub sich vertraglich verpflichtet, unter bestimmten Umständen rechtlichen Schutz zu bieten, falls generierter Code IP-Streitigkeiten auslöst. Das beseitigt nicht jedes Rechtsrisiko, verändert aber die Haftungsfrage für kommerzielle Softwareteams deutlich.

Freelancer, die Code für Kundinnen liefern, sollten genau hinschauen. Der Unterschied zwischen „persönlichem Produktivitätstool“ und „organisationsgestützter Entwicklungsplattform“ wird real, sobald Verträge und kommerzielle Lieferung im Spiel sind.

Abrechnung, Sitze und der Wechsel zu AI Credits

Bei individuellen Plänen erfolgt die Abrechnung Self-Service-basiert direkt über persönliche Accounts. Business-Pläne zentralisieren die Abrechnung über admin-vergebene Sitze. Und statt dass einzelne Nutzer in separaten Credit-Buckets agieren, bündelt die Organisation ihre monatlichen AI Credits gemäß Nutzeranzahl.

Enterprise-Pläne bieten noch feinere Kontrolle mit granularen Budgetlimits, Kostenstellen-Gruppierung und Abteilungszuweisungen – so leert nicht ein einziges Team mit intensiven agentischen Workflows das gesamte Firmenkontingent.

SKUs und Datenschutzüberlegungen

Das Verständnis der verschiedenen Schutzmechanismen für Datenschutz und SKUs ist wichtig. Die architektonischen Grenzen für Datenflüsse, Rechtschutz und Tracking in den einzelnen Stufen sind wie folgt zusammengefasst:

Änderungen der Trainingsrichtlinie im April 2026

Der Wechsel vom Opt-in- zum Opt-out-Modell für individuelle Pläne ist ein zentraler Compliance-Risikofaktor. Das während einer aktiven IDE-Session automatisch erfasste Interaktionsdatenpaket umfasst:

• Detaillierte Chatverläufe und Prompt-Kontext.
• Mehrzeilige Codevorschläge und lokale Annahmeraten.
• Aktiven Editor-Cursor-Kontext, der häufig angrenzende Dateiabschnitte, Import-Statements und Variablendeklarationen aus geöffneten Tabs einbezieht.

Stell dir vor, eine Entwicklerin nutzt ein persönliches Copilot-Pro-Konto in einem Firmen-Repository. Wenn Training aktiviert bleibt, können Interaktionsdaten aus dieser Arbeitssession in das Trainingsecosystem von GitHub einfließen. Genau dieses Szenario ist oft der Grund, warum Organisationen auf Business umsteigen.

Die passende SKU für deine Datenschutzanforderungen wählen

Je nach Arbeitsumfang brauchst du unterschiedliche SKUs. 

• Solo-Entwickler/Side Projects: Free oder Pro bieten maximale Flexibilität. Bei proprietärem Code einfach in den persönlichen Datenschutzeinstellungen abwählen.
• Freelancer/Auftragnehmer: Der Business-Plan stellt eine Schutzbarriere dar. In Kundenverträgen ist die Datenübertragung an externe LLM-Anbieter oft untersagt; ein dedizierter Organisationssitz schützt deine Verträge.
• Unternehmensteams mit Compliance-Vorgaben: Business ist der Standard, sichert Datenpipelines ab und ermöglicht administrative Governance.
• Regulierte Branchen (Finanzen, Gesundheitswesen): Enterprise ist in der Regel Pflicht und erlaubt die Integration spezieller Sicherheitskonfigurationen, strikte Datenresidenz sowie lokalisierte Fine-Tuning-Schichten.

Bestimmte Dateien von Copilot ausschließen

Das Einrichten von Dateiausschlussregeln für GitHub Copilot ist eine der wirksamsten Methoden, eine Umgebung defensiv abzusichern. Inhaltsausschlüsse verhindern, dass der lokale IDE-Agent bestimmte Dateien verarbeitet – sie sind für Inline-Completion, Chat und Hintergrund-Agents vollständig unsichtbar. 

Beachte, dass GitHub Copilot CLI, der Copilot Cloud Agent und der Agent-Modus in Copilot Chat in IDEs keine Inhaltsausschlüsse unterstützen.

Ausschlussregeln konfigurieren

Admin-Teams können Ausschlusskonfigurationen entweder im globalen Bereich „Organization Settings“ oder gezielt in den Repository-Einstellungen anwenden. Klicke dafür oben rechts auf den Button Settings des Repos oder der Organisation.

Wähle in der Seitenleiste unter den Copilot-Einstellungen „Code and automation“. Trage dann deine Ausschlüsse im Feld „Paths to exclude in this repository“ wie folgt ein:

# Ignore the /src/some-dir/kernel.rs file in this repository.
- "/src/some-dir/kernel.rs"

# Ignore files called secrets.json anywhere in this repository.
- "secrets.json"

# Ignore all files whose names begin with secret anywhere in this repository.
- "secret*"

# Ignore files whose names end with .cfg anywhere in this repository.
- "*.cfg"

# Ignore all files in or below the /scripts directory of this repository.
- "/scripts/**"

Auf Organisationsebene ist es ähnlich, nur dass die Einstellung unter „Repositories and Paths to exclude“ liegt und folgendes Format nutzt:

REPOSITORY-REFERENCE:
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - …

Die Beibehaltung von REPOSITORY-REFERENCE ist als Teil der Einstellungen wichtig. Häufige Basisregeln priorisieren harte Zugangsdaten, Produktions-Orchestrierungsprofile, sensible proprietäre Algorithmusmodule oder stark regulierte Compliance-Ordner.

So wirken Ausschlüsse in Copilot-Features

Wenn ein Ausschluss greift, ist die Datenisolation in allen Copilot-Subsystemen absolut:

• Inline-Completions: Es wird verhindert, dass Kontext im Dateiinhalt generiert oder daraus Kontext für angrenzende Dateien gezogen wird.
• Copilot-Chat/Agents: Das System meldet, dass die Datei aufgrund organisatorischer Richtlinien nicht geprüft werden kann.

Standard-Laufzeitfunktionen der IDE arbeiten unverändert. Komfortfunktionen wie Textparser, Syntaxhervorhebung und lokale IntelliSense-Komponenten laufen normal, da die Ausschlusslage ausdrücklich nur auf externe Copilot-Telemetrieströme wirkt. 

Admins sollten Pfad-Muster gründlich in Staging-Repositories testen; fehlerhafte Wildcards können „offen“ versagen und dadurch Daten exponieren, die eigentlich isoliert werden sollten.

Organisationsweite Richtlinienverwaltung

Das Erzwingen von GitHub-Copilot-Richtlinien auf Organisationsebene stellt sicher, dass die Unternehmenssicherheit vom Admin-Team bestimmt wird – nicht von individuellen Entwicklerpräferenzen.

Verfügbare Richtlinieneinstellungen

Organisationen können mehrere Einstellungen für Entwickler steuern:

• Feature-Toggles: Copilot Chat global in Entwicklungsumgebungen, in der Kommandozeile (via Copilot CLI) oder in fortgeschrittenen agentischen Code-Review-Systemen aktivieren oder unterbinden.
• Public Code Filter: Ein rechtlicher Kontrollmechanismus, der Copilot daran hindert, Codevorschläge zurückzugeben, die öffentlichen Open-Source-Repositories auf GitHub stark ähneln – das reduziert Lizenzrisiken.
• Modellrestriktionen: Einschränken, welche Modelle (z. B. bestimmte GPT- oder Claude-Varianten) Entwickler auswählen dürfen – so steuerst du Latenz, Credit-Verbrauch und Performance. Einen Überblick über die auf GitHubs Plattform verfügbaren Modelle gibt dieser Praxisleitfaden zu GitHub Models.
• Eigene Organisationsinstruktionen: Standard-Markdown-Policy-Dateien einbinden, die unternehmensweite Coding-Patterns, Sicherheitsframeworks und Architekturparadigmen an jeden Prompt anhängen.

Wenn dein Team mit GitHubs Organisations- und Berechtigungsmodell weniger vertraut ist, liefert der Kurs Intermediate GitHub Concepts hilfreichen Hintergrund. Für Engineering-Gruppen, die in CLI-Tools expandieren, empfehlen wir unser GitHub Copilot CLI Tutorial.

Richtlinienvererbung auf Enterprise-Ebene

In großen Unternehmensumgebungen folgt die Policy Engine einer klaren Vererbungskaskade: Enterprise-Policy > Organisations-Policy > Nutzerpräferenzen

Enterprise-Admins können Richtlinien global für alle Business Units sperren, selektive organisatorische Ausnahmen zulassen oder die Kontrolle komplett nach unten delegieren. So kann das Enterprise etwa global die Nutzung bestimmter Modelle einschränken.

Auf Teamebene könnte der Finanzbereich strikte Public-Code-Filter erhalten, während die interne Software-F&E mehr Spielraum für Experimente bekommt.

Audit-Logs

Wenn Compliance-Prüfer Nachweise für deine Softwarelieferkette benötigen oder Security-Teams einem Datenleck nachgehen, protokolliert GitHub Copilot Änderungen an der Plattform.

Copilot-Ereignisse im Audit-Log

Das System erfasst ein umfassendes Journal von Management-Operationen, darunter:

• Explizite Sitzplatzzuweisungen, Entzüge und Änderungen an Billing-Gruppen.
• Modifikationen am Public-Code-Duplizierungsfilter.
• Änderungen an Datei- und Verzeichnisausschlussmustern.
• Feature-Status (z. B. Aktivierung agentischer Code-Review-Modi).

Die Granularität hängt vollständig von deinem Abo ab. Während Business-Stufen sich auf organisationsbezogene Ereignisströme konzentrieren, schalten Enterprise-Accounts systemweite forensische Telemetrie über Organisationsgrenzen hinweg frei.

Suchen, filtern und exportieren

Audit-Log-Ströme sind nativ über das Panel „Organization Settings“ zugänglich. Admins können die Oberfläche mit spezifischen Action-Qualifikatoren abfragen:

# Filter logs to identify who adjusted Copilot access privileges
action:copilot.cfb_seat_assignment_created

# Identify changes made to systemic exclusions within a date window
action:copilot.content_exclusion_updated created:2026-05-01..2026-05-31

Enterprise-Accounts unterstützen das Streamen dieser Auditereignisse direkt in externe Security-Information-and-Event-Management-(SIEM)-Systeme (z. B. Splunk oder Datadog) für automatisiertes Alerting und zentrale, unveränderliche Aufbewahrung.

Copilot-Sitze über die REST-API verwalten

Die manuelle Bereitstellung von Sitzplätzen über ein UI-Dashboard funktioniert für kleine Teams, bricht aber bei umfangreichen Onboarding-Workflows schnell zusammen. Über die Endpunkte der GitHub-Copilot-REST-API für Sitze behandelst du Identity- und Access-Management komplett als Code.

Das ist einer meiner Lieblingsaspekte der Copilot-Administration, weil Licensing so sauber automatisierbar wird.

Zentrale API-Endpunkte

Häufige API-Workflows umfassen:

• Auflisten von Sitzplatzzuweisungen
• Zuweisen von Sitzplätzen
• Entfernen von Sitzplätzen
• Abrufen von Nutzungsmetriken
• Auslesen der Copilot-Einstellungen der Organisation

Für die Authentifizierung brauchst du in der Regel:

• Feingranulare Personal Access Tokens
• GitHub-App-Berechtigungen
• Organisationsadministrator-Rechte

Um auf diese Verwaltungswege zuzugreifen, müssen sich deine Integrationsskripte mit einem Personal Access Token (PAT) mit erweiterten admin:org-Scopes authentifizieren oder als autorisierte GitHub App mit expliziten Copilot-Managementrechten auf Organisationsebene ausgeführt werden. 

Für einen tieferen Einblick in programmatische Plattformintegrationen empfehle ich unseren GitHub Foundations-Lernpfad. 

Typische Automatisierungsmuster

Praktische Muster sind z. B.:

• Automatisiertes Identity-Onboarding: Ein HR-Informationssystem (wie Workday oder Okta) per Webhooks mit GitHub verbinden. Sobald ein Engineer einem bestimmten Team beitritt, sendet ein Skript eine POST-Anfrage zur automatischen Bereitstellung seines Copilot-Arbeitsbereichs.

• Rückgewinnung inaktiver Sitze: Ein geplanter Cron-Job fragt die aktive Sitzplatzauslastung über die API ab. Hat ein Nutzer Copilot seit über 30 Tagen nicht genutzt, führt das Skript einen DELETE-Befehl aus, um die Lizenz zurückzuholen und das Firmenkontingent zu schonen.

• Finanz-Dashboards: Tägliche Allokations- und Verbrauchstelemetrie ziehen und in interne BI-Plattformen (z. B. Tableau) einspeisen – für klares Cross-Charging auf Abteilungsebene.

Beispiel: Einen Copilot-Sitz mit Python zuweisen

Das folgende Skript zeigt, wie du einem bestimmten Entwickler programmatisch einen Organisationssitz mit Python zuweist:

	import requests
	# Identity Configuration
TOKEN = "YOUR_ORGANIZATION_ADMIN_PAT"
ORG = "your-corporate-org"
USERNAME = "target-developer-user"

url = f"https://api.github.com/orgs/{ORG}/copilot/billing/selected_users"

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "application/vnd.github+json",
    "X-GitHub-Api-Version": "2022-11-28"
}

payload = {
    "selected_usernames": [USERNAME]
}

response = requests.post(url, json=payload, headers=headers)

if response.status_code == 201:
    print(f"Successfully allocated Copilot seat to {USERNAME}.")
else:
    print(f"Failed allocation. Status: {response.status_code}")
    print(response.json())

Fazit

Die Planstruktur von GitHub Copilot wirkt auf der Preisseite simpel. Sobald du Teams verwaltest, werden die Unterschiede deutlich größer.

Datenschutzgrenzen, Trainingsrichtlinien, Prüfbarkeit und Governance-Kontrollen wiegen oft schwerer als der reine Modellzugang. Darum drehen sich Diskussionen zu GitHub Copilot Business vs. Enterprise meist um Security und Operations – weniger um reine Technik.

Wenn ich heute ein Team beraten würde, würde ich mit den Governance-Anforderungen beginnen:

• Brauchst du vertragliche Datenschutzgarantien?
• Brauchst du Audit-Logs?
• Brauchst du eine zentrale Richtlinienverwaltung?

Danach würde ich für Nutzung und Funktionsumfang optimieren.

Um die technischen Fähigkeiten deines Teams zu vertiefen und euch auf offizielle Zertifizierungen vorzubereiten, schau dir diese fortgeschrittenen Lernpfade an:

• Software Development with GitHub Copilot Course
• AI for Software Engineering Skills Track
• The GitHub Certification Guide for Data Professionals