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 im Ökosystem. Bemerkenswert ist, dass die Plattform ihre Umstellung auf nutzungsbasierte Abrechnung abschließt und das alte „Premium Request Unit“ (PRU)-Modell im Juni 2026 durch GitHub AI Credits ersetzt.

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

Fortgeschrittene Aktionen wie Multi-File-Chat, agentische Workflows, lang laufende Codingsessions und tiefgehende Code-Reviews verbrauchen hingegen AI Credits auf Basis des Token-Verbrauchs (Input, Output und Caching) relativ zu den veröffentlichten API-Raten des jeweiligen Modells. 

Die Basispreise der Monatsabos sind stabil geblieben, aber die Umstellung verändert, wie Admins Überziehungen budgetieren und aktive Nutzung überwachen.

Einzelpläne: Free, Student, Pro und Pro+

Die Einzelstufen unterscheiden sich bei Modellempfang, Nutzungslimits und experimentellen Funktionen. Während die Free-Stufe die Erkundung abdeckt, bietet Pro+ z. B. Zugang zu GitHub Spark, einer Umgebung für den Aufbau KI-gestützter Anwendungen.

Derzeit sind Neuregistrierungen für bezahlte Einzelkonten von GitHub, etwa Pro, Pro+ und Student, pausiert. Bestehende Konten können von Pro auf Pro+ upgraden, neue Konten können sich jedoch nicht anmelden, bis GitHub die Umstellung auf die nutzungsbasierte AI-Credits-Abrechnung abgeschlossen hat.

Business und Enterprise

In Business und Enterprise wandelt sich GitHub Copilot von einer IDE-Erweiterung zu einem vollständig geprüften Infrastrukturbaustein für Unternehmen.

GitHub Copilot Business bringt zentrale Managementfunktionen mit:

• Zentrale Zuweisung und Entzug von Seats.
• Organisationsweite Richtlinien-Baselines.
• Strukturelle Audit-Logs und Compliance-Event-Tracking.
• Inhalts- und Repository-Dateiausschlüsse.
• Kommerzielle Freistellung bei geistigem Eigentum (IP Indemnity).

GitHub Copilot Enterprise ergänzt zusätzliche Kontrolle und Fähigkeiten:

• Copilot Spaces: Ein Wissens-Hub, in dem Entwickler Copilot mit interner Doku, Wikis und systemischen Codestandards anstoßen können.
• Erweiterte 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 effektiven Mindestkosten bei 60 $ pro Nutzer und Monat für Enterprise. Dies gilt nicht für GitHub Copilot Business, das Organisationen auch mit GitHub Free oder GitHub Team nativ erwerben können.

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

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

Was Einzel- von Business-Plänen trennt

Datenhandhabung, IP-Freistellung und Abrechnung sind die Hauptfelder, in denen sich Einzel- und Business-Pläne stark unterscheiden. Zusätzliche Nutzerfeatures sind schön – aber wer zwischen vielen persönlichen Pro-Lizenzen und einem Business-Abo abwägt, sollte diese Unterschiede verstehen.

Datenhandhabung und Training-Defaults

Für Teams mit proprietären Systemen ist Datenschutz meist der ausschlaggebende 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 dürfen Interaktionsdaten nun standardmäßig für das Modelltraining verwendet werden, sofern der Nutzer nicht aktiv widerspricht (Opt-out).

Wichtig ist der Unterschied zwischen ruhendem Code und Interaktionsdaten – nur so wird klar, was fürs KI-Training genutzt wird:

• Ruhender Code: Der Rohcode in deinem privaten Repository wird nicht gelesen oder in öffentliche Trainingssätze aufgenommen.
• Interaktionsdaten: Dazu gehören Prompts, Chat-Abfragen, Cursor-Kontext, umgebende Codeblöcke, die während aktiver Editiersessions über die IDE-API gesendet werden, Annahmeraten für Vorschläge und Feedback-Logs.

Business- und Enterprise-Verträge enthalten eine strikte Garantie, dass Interaktionsdaten unter keinen Umständen für Trainingszwecke verwendet werden. Es ist keine manuelle Nutzeraktion nötig.

Für einen tieferen Einblick in Datennutzung und Fehlerbehebung in Copilot lies unseren Guide GitHub Copilot Privacy and Troubleshooting.

IP-Freistellung (Indemnity)

GitHub Copilot Business und Enterprise enthalten eine IP-Freistellung für generierten Code. Einzelpläne nicht.

Praktisch bedeutet Freistellung, dass GitHub sich vertraglich verpflichtet, unter definierten Bedingungen rechtlichen Schutz zu bieten, falls es durch generierten Code zu Streitigkeiten um geistiges Eigentum kommt. Das eliminiert nicht jedes Risiko, verändert aber die Haftungsdiskussion für kommerzielle Softwareteams.

Freelancer, die Code für Kundinnen liefern, sollten das beachten. Der Unterschied zwischen „persönlichem Produktivitätstool“ und „unternehmenstragender Entwicklungsplattform“ wird real, sobald Verträge und Lieferverpflichtungen ins Spiel kommen.

Abrechnung, Seats und der Wechsel zu AI Credits

Bei Einzelplänen erfolgt die Selbstbedienungsabrechnung direkt über persönliche Accounts. Business-Pläne zentralisieren die Abrechnung mit adminvergebenen Seats. Außerdem nutzt nicht jede Person ihren eigenen Credit-Pool – die Organisation bündelt die monatlichen AI Credits basierend auf der Nutzeranzahl.

Enterprise-Pläne bieten noch feinere Steuerung mit granularen Budgetlimits, Cost-Center-Gruppierung und Abteilungenkontingenten, damit nicht ein einzelnes Team mit intensiven agentischen Workflows das gesamte Unternehmensbudget aufbraucht.

SKUs und Datenschutzüberlegungen

Es ist wichtig, die verschiedenen Datenschutzgarantien und SKUs zu verstehen. Die architektonischen Grenzen für Datenflüsse, rechtlichen Schutz und Nachverfolgung über die Stufen hinweg sind hier zusammengefasst:

Änderungen der Trainingsrichtlinie im April 2026

Der Wechsel von Opt-in zu Opt-out bei Einzelplänen ist ein wesentlicher Angriffsvektor für Compliance-Lecks. Das während aktiver IDE-Sessions automatisch erfasste Interaktionsdatenpaket umfasst:

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

Nutzt eine Entwicklerin ein persönliches Copilot-Pro-Konto in einem Firmen-Repository, können – sofern Training aktiviert bleibt – Interaktionsdaten dieser Session in GitHubs Trainingsökosystem gelangen. Genau dieses Szenario ist ein häufiger Grund, warum Organisationen zu Business wechseln.

Die richtige SKU für deine Datenschutzanforderungen

Je nach Arbeitsebene brauchst du unterschiedliche SKUs. 

• Solo-Entwickler/Side-Projects: Free oder Pro bieten maximale Flexibilität. Einfach in den persönlichen Datenschutzeinstellungen abwählen, wenn du an proprietärem Code arbeitest.
• Freelancer/Auftragnehmer: Der Business-Plan bietet eine Schutzbarriere. Kund:innen untersagen oft ausdrücklich die Datenübertragung an externe LLM-Anbieter; ein dedizierter Organisations-Seat 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 – für Integration mit speziellen Sicherheits-Setups, strikten Datenresidenzvorgaben und lokalen Fine-Tuning-Schichten.

Bestimmte Dateien von Copilot ausschließen

Das Einführen von Dateiausschlussregeln für GitHub Copilot ist eine der wirksamsten defensiven Maßnahmen. Inhaltsausschlüsse verhindern, dass der lokale IDE-Agent bestimmte Dateien verarbeitet – sie sind für Inline-Completions, Chat und agentische Hintergrundprozesse komplett 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 Ausschlüsse entweder in den globalen Organisationseinstellungen oder auf Ebene einzelner Repositories setzen. Gehe dazu in die Einstellungen des Repos oder der Organisation über den Settings-Button oben rechts.

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“ so 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 liegt die Einstellung unter „Repositories and Paths to exclude“ und nutzt folgendes Format:

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

Die Bezeichnung REPOSITORY-REFERENCE ist als Teil der Einstellungen wichtig. Übliche Baselines priorisieren harte Zugangsdaten, Produktions-Orchestrierungsprofile, sensible proprietäre Algorithmusmodule oder streng regulierte Compliance-Ordner.

So greifen Ausschlüsse in Copilot-Features

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

• Inline-Completions: Es werden weder Kontexte innerhalb der Datei generiert noch aus ihr Kontexte für benachbarte Dateien gezogen.
• Copilot-Chat/Agents: Das System weist darauf hin, dass die Datei aus organisatorischen Richtliniengründen nicht geprüft werden kann.

Standard-Engines der IDE arbeiten weiter normal. Komfortfunktionen wie Text-Parsing, Syntax-Highlighting und lokale IntelliSense-Kompilierung laufen, da die Ausschlussschicht explizit auf externe Copilot-Telemetrieströme zielt. 

Admins sollten Pfad-Pattern gründlich in Staging-Repos testen; fehlerhafte Wildcards können „offen“ fehlschlagen und Daten exponieren, die isoliert sein sollten.

Organisationsweite Richtlinienverwaltung

Die Durchsetzung von Copilot-Richtlinien auf Organisationsebene stellt sicher, dass die Unternehmenssicherheit vom Admin-Team und nicht von individuellen Entwicklerpräferenzen bestimmt wird.

Verfügbare Richtlinieneinstellungen

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

• Feature-Toggles: Copilot Chat global in Entwicklungsumgebungen, an der Kommandozeile (über die Copilot CLI) oder in fortgeschrittenen agentischen Code-Review-Systemen aktivieren oder unterdrücken.
• Public-Code-Filter: Ein rechtlicher Kontrollmechanismus, der verhindert, dass Copilot Vorschläge mit hoher Übereinstimmung zu öffentlichen Open-Source-Repos auf GitHub zurückgibt – und so Lizenzrisiken senkt.
• Modellwahl-Einschränkungen: Beschränke, welche Modelle (z. B. bestimmte GPT- oder Claude-Varianten) gewählt werden dürfen, um Latenz, Credit-Verbrauch und Performance zu steuern. Einen Überblick über verfügbare Modelle bietet dieser Praxisleitfaden zu GitHub Models.
• Eigene Organisationsanweisungen:Hinterlege standardisierte Markdown-Policies, die bei jedem Prompt deiner Entwickler Unternehmensmuster, Sicherheitsframeworks und Architekturprinzipien ergänzen.

Ist dein Team weniger vertraut mit GitHubs Organisations- und Berechtigungsmodell, bietet der Kurs Intermediate GitHub Concepts guten Hintergrund. Für Teams, die die Kommandozeile ausbauen, siehe unser GitHub Copilot CLI Tutorial.

Richtlinienvererbung auf Enterprise-Ebene

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

Enterprise-Admins können Policies global sperren, selektive Organisations-Overrides zulassen oder die Kontrolle vollständig delegieren. So kann das Enterprise z. B. die Nutzung bestimmter Modelle global einschränken.

Auf Teamebene lässt sich etwa die Finanzsparte mit strengen Public-Code-Filtern belegen, während ein internes Software-R&D-Team freier experimentieren darf.

Audit-Logs

Wenn Compliance-Prüfer eine Verifikation deiner Softwarelieferkette brauchen oder Security-Teams einem Datenleck nachgehen, dokumentiert GitHub Copilot Änderungen an der Plattform.

Copilot-Events im Audit-Log

Das System protokolliert eine umfassende Historie von Verwaltungsaktionen, darunter:

• Explizite Seat-Zuweisungen, Entzüge und Änderungen an Billing-Gruppen.
• Änderungen am Public-Code-Duplizierungsfilter.
• Anpassungen an Datei- und Verzeichnisausschlüssen.
• Feature-Aktivierungszustände (z. B. das Einschalten agentischer Code-Review-Modi).

Die Granularität hängt von deinem Abo ab. Während Business auf organisationsbezogene Ereignisströme fokussiert, schalten Enterprise-Accounts systemische, organisationsübergreifende Forensik frei.

Suchen, filtern und exportieren

Audit-Logs sind nativ über die Organisationseinstellungen abrufbar. Admins können die Oberfläche mit gezielten Action-Qualifizierern 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 Streaming dieser Auditevents direkt in externe SIEM-Systeme (z. B. Splunk oder Datadog) für automatisierte Alerts und zentrale, unveränderliche Aufbewahrung.

Copilot-Seats mit der REST-API verwalten

Die manuelle Seat-Bereitstellung über ein UI-Dashboard ist für kleine Teams okay, bricht aber bei hohem Onboarding-Volumen schnell. Über die Github-Copilot-REST-API für Seats kannst du Identity- und Access-Management vollständig als Code behandeln.

Das ist einer meiner Lieblingsbereiche in der Copilot-Administration, weil Lizenzen so sauber automatisierbar werden.

Wichtige API-Endpunkte

Typische API-Workflows umfassen:

• Seat-Zuweisungen auflisten
• Seats zuweisen
• Seats entfernen
• Nutzungsmetriken abrufen
• Copilot-Einstellungen der Organisation lesen

Die Authentifizierung erfordert in der Regel:

• Feingranulare Personal-Access-Tokens
• GitHub-App-Berechtigungen
• Organisationsadministratorrechte

Um diese Verwaltungspfade zu nutzen, müssen sich deine Skripte mit einem Personal Access Token (PAT) mit erhöhten admin:org-Scopes authentifizieren oder als autorisierte GitHub App mit expliziten Copilot-Org-Rechten laufen. 

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

Übliche Automatisierungsmuster

Praktische Muster sind u. a.:

• Automatisiertes Identity-Onboarding: Anbindung eines HR-Systems (z. B. Workday oder Okta) via Webhooks an GitHub. Wenn ein Engineer einem bestimmten Team beitritt, sendet ein Skript einen POST, um den Copilot-Arbeitsplatz automatisch zu provisionieren.

• Rückgewinnung inaktiver Seats: Ein geplanter Cron-Job fragt die Seat-Nutzung per API ab. Wenn ein Nutzer 30 Tage nicht mit Copilot interagiert hat, führt das Skript ein DELETE aus, um die Lizenz zurückzuholen und den Credit-Pool zu schonen.

• Finanz-Dashboards: Tägliche Allokations- und Verbrauchstelemetrie ziehen und in interne BI-Plattformen (z. B. Tableau) einspeisen – für klare Kostenstellen-Verrechnung je Abteilung.

Beispiel: Einen Copilot-Seat mit Python zuweisen

Das folgende Skript zeigt, wie du einer bestimmten Entwicklerperson programmatisch einen Organisations-Seat 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 sind oft wichtiger als reiner Modellzugang. Darum drehen sich Business-vs.-Enterprise-Diskussionen bei GitHub Copilot meist um Security und Betrieb – weniger um reine Technik.

Würde ich heute ein Team beraten, würde ich bei den Governance-Anforderungen starten:

• Brauchst du vertragliche Datenschutzgarantien?
• Brauchst du Audit-Logs?
• Brauchst du zentrales Richtlinienmanagement?

Danach würde ich Nutzungskontingente und Featurezugang optimieren.

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

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