GitHub Copilot vs. Private Coding-Assistenten

Ich führe seit einem Monat dasselbe Gespräch mit drei verschiedenen Teams. Jedes begann gleich: Jemand leitete das GitHub-Copilot-Policy-Update vom 24. April herum, und ein Slack-Thread, der ein Jahr lang ruhig war, erwachte plötzlich wieder zum Leben. Sollten wir bei Copilot bleiben? Sollten wir wechseln? Sollten wir selbst hosten? Was bedeutet „privat” in dieser Kategorie überhaupt?

Ich bin Dora. Ich habe vor ein paar Wochen über die Policy-Änderung selbst geschrieben – was sich geändert hat, wer ausgenommen ist, was Teams überprüfen sollten. Dieser Artikel behandelt die nächste Frage: Wenn man seine Copilot-Einrichtung überprüft hat, wie entscheidet man eigentlich zwischen dem Verbleib bei einem gehosteten Assistenten und dem Wechsel zu einem privaten oder selbst gehosteten? Ich werde nicht sagen, welches man wählen soll. Ich werde die Entscheidungskriterien darlegen, die ich Teams verwenden sehe, und wo jedes einzelne still und leise scheitert.

Dies ist kein Enterprise-Beschaffungsleitfaden. Ich bin Anwenderin, keine CISO. Aber „gehostet vs. privat” ist nicht mehr abstrakt – es taucht in Workflow-Entscheidungen auf, die Entwickler jede Woche treffen.

Die zwei Richtungen, die Teams jetzt in Betracht ziehen

Zwei Lager im Moment. Keines ist falsch. Sie optimieren für unterschiedliche Dinge.

Bei Copilot mit Policy-Kontrollen bleiben

Das erste Lager sagt: Copilot Business oder Copilot Enterprise adressiert die Datenschutzbedenken bereits. Die Änderung vom 24. April betrifft nur Copilot Free, Pro und Pro+ – die persönlichen Tarife. Laut GitHubs Copilot-Pläne-Dokumentation verwendet GitHub keine Daten aus Copilot Business oder Copilot Enterprise, um seine Modelle zu trainieren, und diese vertragliche Zusage bestand bereits vor dem 24. April und gilt noch immer. Wenn das Team auf einem Business- oder Enterprise-Platz ist, ändert das Policy-Update die Datenexposition nicht. Es ändert, wie sorgfältig man bei persönlichen Konten auf Arbeits-Laptops sein muss.

Dieses Lager bekommt zunehmend mehr Belege. GitHub hat kürzlich Datenresidenz für US- und EU-Regionen sowie FedRAMP-autorisierte Modelle eingeführt, wobei Admins ihre Organisation auf datenresidente oder FedRAMP-konforme Modelle aus den Copilot-Einstellungen beschränken können. Nützlich, wenn man sich fragt „wo findet die Inferenz statt” und nicht „trainiert mein Code jemanden”.

Das Argument ist einfach. Copilot hat tiefe IDE-Integration, die größte Nutzerbasis und starken mehrdateilichen Kontext. Wechselkosten sind real. Wenn das Risiko vertraglich adressiert ist, warum dann den Stack umwerfen?

Zu privaten oder selbst gehosteten Coding-Assistenten wechseln

Das zweite Lager akzeptiert den Vertrag nicht als letztes Wort. Ihre Frage ist strukturell: Selbst bei Copilot Business läuft die Inferenz noch auf Microsoft-Infrastruktur, das Modell wird von einem Dritten betrieben, und die Datenflüsse werden durch eine Vendor-Policy geregelt, die wieder aktualisiert werden kann. Die Änderung vom 24. April war für sie ein Beweis, dass sich Policies ändern.

Also betrachten sie private Bereitstellung. Einige Varianten:

Vom Anbieter verwaltete private Bereitstellung – Assistenten wie Tabnine und Codeium bieten VPC-, On-Premises- oder Air-Gapped-Bereitstellung an, bei der das Modell innerhalb der eigenen Infrastruktur läuft. Die meisten Enterprise-Kunden in regulierten Branchen wählen diesen Weg.
Open-Source-Assistenten kombiniert mit selbst gehosteten Modellen – zum Beispiel Continue.dev plus Ollama plus ein codeoptimiertes Open-Weight-Modell. Continue ist nicht an einen einzigen KI-Anbieter gebunden und unterstützt lokale Modelle, die vollständig auf eigener Hardware laufen.
BYO-Modell-Setups über Enterprise-Plattformen, die es ermöglichen, den Assistenten auf einen eigenen LLM-Endpunkt zu richten.

Die Hypothese hier ist nicht „Copilot ist schlecht”. Sie lautet: „Die langfristige Governance-Haltung sollte nicht von der Vertragssprache eines einzelnen Anbieters abhängen.”

Die eigentlichen Entscheidungskriterien

Hier stecken die meisten Teams, die ich gesehen habe, fest. Sie beginnen das Gespräch als „gehostet vs. privat” und enden ohne Entscheidung, weil der Rahmen falsch war. Die eigentliche Entscheidung liegt in zwei Fragen, und beide sind Workflow-Fragen, bevor sie Sicherheitsfragen sind.

Daten-Governance und Compliance

Teilt man seinen Code in drei Eimer, nicht zwei:

Code, bei dem Vendor-Training wirklich kein Problem ist (Open-Source-Beiträge, Marketing-Site-Code, Dev-Tooling).
Code, der proprietär, aber nicht reguliert ist (interne Tools, die meisten Produkt-Codes bei den meisten Unternehmen).
Code, der regulierte Datenflüsse berührt (Finanzen, Gesundheitswesen, Verteidigung, öffentlicher Sektor – alles mit expliziten Datenverarbeitungsregeln).

Eimer 1 ist bei jedem Tarif in Ordnung. Eimer 3 drängte Teams bereits vor dem 24. April zu Enterprise-Verträgen. Die Ambiguität liegt in Eimer 2 – und das ist der größte Eimer für die meisten Teams.

Für Eimer 2 lautet die Frage, ob die vertragliche Ausnahme ausreicht. Die Mindestanforderung: Business- oder Enterprise-Tarif verlangen und diese Anforderung in der KI-Richtlinie für akzeptable Nutzung dokumentieren. Ob man weiter zu privater Bereitstellung geht, hängt davon ab, was der Prüfer, das Rechtsteam oder Enterprise-Kunden zu demonstrieren verlangen. Wenn „Wir sind bei Copilot Business und hier ist die Vertragsklausel” eine Antwort ist, die Stakeholder akzeptieren, ist man wahrscheinlich auf der sicheren Seite. Wenn sie fragen „Und wo findet die Inferenz statt”, führt man ein anderes Gespräch.

Entwicklererfahrung und Wartungskosten

Das ist der Teil, den Build-vs-Buy-Debatten normalerweise überspringen. Es ist der Teil, der entscheidet, ob die Entscheidung sechs Monate überlebt.

Gehostete Assistenten haben hier einen echten Vorteil. Copilot aktualisiert Modelle, liefert Features und übernimmt Infrastrukturarbeit, die man nicht sieht. Die meisten Entwickler-Umfragen setzen die KI-Tool-Akzeptanz über 70% – und die meisten dieser Workflows laufen auf gehosteten Tools, weil gehostete Tools keinen laufenden operativen Aufwand vom Entwickler erfordern.

Selbst gehostete Assistenten kehren das um. Continue.dev plus Ollama plus ein codeoptimiertes Modell ist ein Workflow, der gut funktionieren kann – aber er erfordert, dass jemand im Team Modellauswahl, GPU- oder Hardware-Budget, Versions-Updates und die Lücke zwischen dem, was lokale Modelle leisten können, und dem, was Frontier-Hosted-Modelle leisten können, übernimmt. Diese Lücke ist real. Lokale Modelle haben viel aufgeholt. Bei komplexem mehrdateilichem Reasoning sind gehostete Frontier-Modelle noch vorne.

Vom Anbieter verwaltete private Bereitstellung teilt den Unterschied. Man erhält die Datenschutz-Haltung des Selbst-Hostings plus laufende Modell-Updates von einem Anbieter. Der Preis sind höhere Sitzpreise und mehr Beschaffungsaufwand im Voraus. Für Teams in regulierten Branchen ist das ein Trade, den viele eingehen. Für Teams in nicht regulierten Branchen lohnt es sich oft nicht.

Die fünf Dimensionen, auf die ich immer wieder zurückgreife, wenn Teams mich bitten, Optionen zu vergleichen:

Wahrgenommene Geschwindigkeit – wie schnell Vorschläge erscheinen, wenn man tatsächlich tippt
Workflow-Passform – wie gut es sich in IDE, Repository und Überprüfungsprozess integriert, die man bereits verwendet
Modellabdeckung vs. Auswahlkosten – ob man Modellauswahl bekommt und ob Auswahl Evaluierungsaufwand erzeugt
Kostenprediktabilität – festes Sitzpreis vs. nutzungsbasiert vs. selbst gehostete Infrastrukturkosten
Leistung im Maßstab – was passiert, wenn zehn Entwickler gleichzeitig zugreifen oder wenn die Codebasis eine bestimmte Größe überschreitet

Gehostete Tools gewinnen standardmäßig bei den ersten drei. Private Bereitstellung gewinnt bei Kostenprediktabilität bei stabilem Nutzung. Leistung im Maßstab hängt vollständig davon ab, wie die Bereitstellung eingerichtet ist.

Wann Copilot noch sinnvoll ist und wann nicht

Hier muss ich ehrlich über Grenzen sein – sowohl die von Copilot als auch die meinen.

Copilot ist noch sinnvoll, wenn das Team auf dem Business- oder Enterprise-Tarif ist und der Code in Eimer 1 oder Eimer 2 fällt; wenn Prüfer und Kunden vertragliche Datenverpflichtungen als ausreichend akzeptieren; wenn Entwickler tief in das GitHub-Ökosystem integriert sind und der Kontext, den Copilot aus Repositories, Pull Requests und Issues zieht, tragend ist; und wenn man nicht die Personalkapazität oder den Appetit hat, Modellinfrastruktur zu betreiben.

Copilot macht keinen Sinn mehr, wenn der Code in Eimer 3 fällt und das Compliance-Framework nachweisbare Datenisolierung erfordert; wenn Enterprise-Kunden vertraglich fordern, dass ihre Daten keine KI-Inferenz von Drittanbietern durchlaufen, und der Code ihre Daten berührt; oder wenn man bereits in private Modellinfrastruktur aus anderen Gründen investiert hat und das Hinzufügen eines Coding-Assistenten darauf inkrementell statt greenfield ist.

Was ich nicht sagen werde, ist, dass eine Richtung die Zukunft ist und die andere nicht. Die meisten Entwickler einigen sich auf 2-3 Tools – ein üblicher Stack ist ein schwerer Agent, ein Inline-Completion-Tool und eine Open-Source-Option für Flexibilität. „Gehostet vs. privat” ist auf Teamebene zunehmend eine falsche Dichotomie. Viele Teams betreiben beides, mit verschiedenen Tools, die durch verschiedene Policies für verschiedene Code-Pfade geregelt werden.

FAQ

Braucht jedes Team jetzt einen privaten Coding-Assistenten?

Nein. Die Policy-Änderung vom 24. April betraf persönliche Copilot-Pläne. Wenn das Team auf Business- oder Enterprise-Tarif ist und der Code nicht in einer regulierten Kategorie liegt, ist die vertragliche Ausnahme dieselbe wie zuvor. Die Teams, die private Bereitstellung ernsthaft evaluieren sollten, sind solche, bei denen die Antwort auf „Was verlangt Ihr Prüfer oder Ihr Enterprise-Kunde?” bereits über Vertragssprache hinausging.

Was sind die Kompromisse des Selbst-Hostings?

Drei echte. Modellqualität – lokale Open-Weight-Modelle haben viel aufgeholt, liegen aber bei komplexem Reasoning noch hinter Frontier-Hosted-Modellen. Betriebskosten – jemand muss Infrastruktur, Modellauswahl und Updates übernehmen. Hardware – lokale Inferenz mit akzeptabler Geschwindigkeit benötigt anständige GPUs.

Der Vorteil ist auch real: kein Datenabfluss, vorhersehbare Kosten im Maßstab, volle Kontrolle darüber, welches Modell das Team verwendet.

Wie sollten Teams Governance vs. Geschwindigkeit vergleichen?

Nicht abstrakt vergleichen. Gegenüberstellen an einem spezifischen Code-Pfad. „Können unsere Entwickler einen gehosteten Assistenten im Marketing-Site-Repository verwenden” ist eine andere Frage als „Können unsere Entwickler einen gehosteten Assistenten im Zahlungsdienst verwenden”. Die meisten Teams, die ich gesehen habe, einigen sich auf eine differenzierte Policy – gehosteter Assistent auf den meisten Repos erlaubt, private Bereitstellung oder keine KI-Unterstützung auf einer spezifischen Liste sensibler Repos. Schwieriger einzurichten als eine einzelne Policy. Ehrlicher darüber, wie sich Risiken tatsächlich über eine Codebasis verteilen.

Was sollte eine Neubewertung der Tool-Wahl auslösen?

Drei Signale, auf die ich achten würde. Eine Vendor-Policy-Änderung, die die Datenexposition wesentlich beeinflusst – der 24. April war eine. Eine neue Compliance-Verpflichtung – ein SOC-2-Audit, eine Kundenvertragsklausel, eine regionale Datenschutzregel. Eine Workflow-Änderung innerhalb des Teams – Engineering geht von fünf auf fünfundzwanzig Entwickler, wo sich die Kostendynamik von pro-Sitz gehostetem Preis vs. selbst gehosteter Infrastruktur umkehrt.

Wenn keines davon eingetreten ist, ist die bestehende Entscheidung wahrscheinlich noch gültig.

Fazit

Die ehrliche Antwort auf „GitHub Copilot vs. private Coding-Assistenten” ist, dass es keine einzelne Antwort gibt. Es ist eine Frage, die man jedes Mal neu stellt, wenn sich etwas ändert – der Code, die Kunden, die Policy des Anbieters, die Teamgröße. Die Policy-Änderung vom 24. April ließ die Frage dringend erscheinen. Sie ist es nicht, für die meisten Teams. Sie ist eine Erinnerung, dass die Entscheidung nie dauerhaft war.

Ich verwende weiterhin eine Mischung. Gehostet für die meiste Arbeit, lokal für Code, den ich nicht von meinem Rechner lassen möchte, vom Anbieter verwaltete private Bereitstellung in einem Team-Kontext, wo Kundenverträge es erfordern. Das ist ein funktionierendes Setup, keine Empfehlung. Wenn man einen anderen Code-Mix oder andere Verpflichtungen hat, wird die richtige Antwort anders aussehen.

Damit endet meine Datenbasis. Führt euer eigenes Audit durch. Der Policy-Review, den ich vor ein paar Wochen geschrieben habe, ist ein vernünftiger Ausgangspunkt. Die Entscheidung danach liegt bei euch.

Wird fortgesetzt.

Vorherige Beiträge: