Claude Code Self-Hosted: Was KMU zur Datenkontrolle wissen

Ein KMU, das Claude Code für die interne Softwareentwicklung einsetzt, hat bislang keine Wahl gehabt: Jede Cloud-Session – gestartet über die Web-Oberfläche, eine App oder eine geplante Routine – lief auf Anthropics eigener Infrastruktur. Das eigene Repository, sensible Konfigurationsdateien und interne Build-Artefakte verliessen dabei zwangsläufig das eigene Netzwerk, selbst wenn die IT-Abteilung das lieber vermieden hätte.

Seit dem 7. August 2026 ändert sich das. Mit Version 2.1.224 hat Anthropic sogenannte Self-Hosted Environments für Claude Code eingeführt: Organisationen können Cloud-Sessions jetzt auf eigenen Servern ausführen lassen, innerhalb der eigenen Netzwerkgrenze. Für Schweizer KMU, die sich seit dem revDSG ohnehin mit der Frage beschäftigen, wo ihre Daten eigentlich landen, klingt das zunächst nach der naheliegenden Lösung für ein altbekanntes Problem.

Ganz so einfach ist es nicht. Was tatsächlich auf der eigenen Infrastruktur bleibt – und was weiterhin in die USA übermittelt wird – lohnt sich, bevor eine Aktivierung ansteht, genau zu verstehen.

Wie Self-Hosted Environments technisch funktionieren

Das Prinzip orientiert sich an bekannten CI/CD-Mustern: Eine Organisation richtet in den claude.ai-Admin-Einstellungen eine sogenannte Umgebung ein und startet darin einen oder mehrere Runner-Prozesse auf eigenen Maschinen. Startet eine Entwicklerin oder ein Entwickler eine Cloud-Session und wählt diese Umgebung aus, platziert Anthropics Steuerungsebene die Session in einer Warteschlange. Ein Runner mit freier Kapazität übernimmt sie, klont das gewählte Repository und startet lokal einen Claude-Code-Prozess.

Von diesem Moment an läuft die Session innerhalb des eigenen Netzwerks. Der Runner authentifiziert sich mit selbst konfigurierten Zugangsdaten beim Git-Host, erreicht interne Dienste direkt und muss keinen eingehenden Zugriff von aussen erlauben – die gesamte Kommunikation nach aussen läuft ausgehend über HTTPS. Anthropic verbindet sich zu keinem Zeitpunkt aktiv in das eigene Netzwerk hinein.

Wichtig für die Praxis: Ein einzelner Runner bedient jeweils nur ein Nutzerkonto gleichzeitig. Die erste Session, die ein Runner übernimmt, bindet ihn an dieses Konto, bis er wieder freigegeben wird. Damit wird verhindert, dass ausgecheckter Code verschiedener Nutzerinnen und Nutzer auf derselben Maschine vermischt wird – ein Detail, das für die interne Absicherung mehrerer Teams relevant ist.

Was tatsächlich im eigenen Netzwerk bleibt – und was nicht

Genau hier liegt der Punkt, den viele KMU beim ersten Lesen der Ankündigung überspringen. Laut Anthropics eigener Dokumentation bleiben Repository-Checkouts, Build-Artefakte, Secrets und alle Dateien, die eine Session erstellt oder verändert, auf den selbst betriebenen Maschinen. Das ist ein echter Fortschritt für Betriebe mit sensiblem Quellcode oder internen Zugriffsdaten, die bislang zwangsläufig auf fremde Infrastruktur gelangten.

Die eigentliche Konversation mit dem Modell – jeder Prompt, jede Antwort, jedes Tool-Ergebnis – wird jedoch weiterhin zur Verarbeitung an api.anthropic.com übermittelt. Modellinferenz findet nicht lokal statt und lässt sich in Self-Hosted Environments auch nicht über Amazon Bedrock, Google Cloud oder einen eigenen LLM-Gateway umleiten. Wer also über Claude Code mit Code arbeitet, der Personendaten enthält – etwa Kundendatensätze in Testfixtures, echte E-Mail-Adressen in Log-Dateien oder personenbezogene Kommentare im Repository –, übermittelt diese weiterhin in die USA, ganz gleich, ob die Session selbst gehostet läuft oder nicht.

Diese Unterscheidung ist für die revDSG-Einordnung entscheidend. Self-Hosting löst ein Netzwerk- und Code-Kontrollproblem. Es löst nicht die Frage der grenzüberschreitenden Übermittlung von Personendaten, sobald solche Daten Teil dessen sind, was tatsächlich verarbeitet wird.

Die revDSG-Perspektive: Was für Schweizer KMU wirklich zählt

Das revidierte Datenschutzgesetz gilt technologieneutral und erfasst damit auch KI-gestützte Datenverarbeitung direkt. Wer Personendaten in einem KI-Tool verarbeitet, gilt als verantwortliche Stelle – unabhängig davon, ob das Tool von Anthropic, einem anderen US-Anbieter oder einem europäischen Dienstleister betrieben wird. Seit dem 1. September 2023 drohen der verantwortlichen Person bei Verstössen persönliche Bussen bis 250'000 Franken, nicht nur eine Sanktion gegen das Unternehmen als solches.

Für die Übermittlung von Personendaten in die USA gilt gemäss dem Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB): Die USA sind nur für Empfänger als angemessenes Schutzniveau anerkannt, die unter dem Swiss-U.S. Data Privacy Framework zertifiziert sind. Für alle anderen Übermittlungen braucht es zusätzliche Garantien, etwa Standardvertragsklauseln, sowie eine Prüfung, ob diese im konkreten Fall ausreichen.

Für ein KMU, das Claude Code mit Self-Hosted Environments einsetzt, bedeutet das konkret: Die Frage "Wo läuft der Code?" ist mit Self-Hosting weitgehend geklärt. Die Frage "Welche Personendaten gelangen über Prompts, Dateiinhalte oder Tool-Ergebnisse an api.anthropic.com, und auf welcher Rechtsgrundlage?" bleibt bestehen und muss unabhängig davon beantwortet werden, ob eine Session lokal oder bei Anthropic ausgeführt wird. Wer Self-Hosting allein als Compliance-Lösung verkauft, verspricht mehr, als das Feature tatsächlich hält.

Für wen sich Self-Hosting lohnt – und für wen nicht

Self-Hosted Environments sind aktuell auf Claude-Team- und Enterprise-Pläne beschränkt, standardmässig deaktiviert und müssen von einer Administratorin oder einem Administrator aktiv eingerichtet werden. Organisationen mit aktivierter Zero Data Retention können das Feature nicht nutzen. Für kleinere KMU auf tieferen Plänen stellt sich die Frage vorerst nicht direkt – bleibt aber relevant für wachsende Betriebe, die perspektivisch auf höhere Pläne wechseln.

Sinnvoll ist Self-Hosting vor allem für Organisationen mit sensiblen Repositories: proprietärem Quellcode, internen Konfigurationsdateien oder Zugangsdaten zu internen Systemen, bei denen es zusätzlichen Wert hat, wenn Checkouts und Build-Artefakte das eigene Netzwerk gar nicht erst verlassen. Wer dagegen überwiegend mit ohnehin öffentlichem Code oder synthetischen Testdaten arbeitet, hat wenig zusätzlichen Nutzen – trägt aber trotzdem den vollen Betriebsaufwand.

Und dieser Aufwand ist real. Anthropic selbst weist darauf hin, dass die meisten Organisationen mit der gehosteten Variante besser bedient sind, weil diese keine eigene Infrastruktur zum Betreiben oder Warten benötigt. Wer sich für Self-Hosting entscheidet, muss ein Runner-Image bauen und pflegen, die Flotte betreiben und den Netzwerkzugriff aktiv kontrollieren – Aufgaben, die ein KMU ohne dedizierte Plattform-Kapazität nicht nebenbei erledigt.

Checkliste vor der Aktivierung

Bevor eine Organisation Self-Hosted Environments für Claude Code produktiv schaltet, lassen sich fünf Punkte klären:

1. Datenbestand im Repository prüfen. Enthalten die betroffenen Repositories tatsächlich Personendaten – etwa in Testfixtures, Log-Dateien oder Kommentaren –, oder handelt es sich überwiegend um reinen Quellcode ohne Personenbezug? Diese Einschätzung entscheidet, wie dringend die revDSG-Frage überhaupt ist.

2. Rechtsgrundlage für die US-Übermittlung klären. Solange Prompts und Tool-Ergebnisse an api.anthropic.com gehen, braucht es eine tragfähige Grundlage für die Datenübermittlung – etwa Standardvertragsklauseln im Rahmen der Auftragsverarbeitungsvereinbarung mit Anthropic. Das gilt unabhängig davon, ob Self-Hosting aktiv ist.

3. Betriebsaufwand realistisch einschätzen. Ein Runner-Image bauen, patchen und betreiben ist eine dauerhafte Aufgabe, keine einmalige Einrichtung. Ohne eigene Plattform- oder DevOps-Kapazität lohnt sich eine ehrliche Abwägung, ob der Zusatznutzen den Aufwand rechtfertigt.

4. Zugriffsrechte der Runner begrenzen. Da Runner-Prozesse interne Dienste direkt erreichen können, sollte der Netzwerkzugriff auf das Nötigste beschränkt und regelmässig überprüft werden – insbesondere, wenn mehrere Teams dieselbe Umgebung nutzen.

5. Pilotphase statt Vollausrollung. Ein einzelnes, gut abgegrenztes Repository mit überschaubarem Risiko eignet sich besser als Startpunkt als ein sofortiger Rollout über alle Teams hinweg. So lässt sich der tatsächliche Betriebsaufwand einschätzen, bevor er sich auf die gesamte Organisation auswirkt.

Was das für die Praxis bedeutet

Die naheliegende Reaktion vieler KMU auf revDSG-Bedenken ist, KI-Tools entweder ganz zu meiden oder unreflektiert zu übernehmen, sobald ein Anbieter das Wort "Datenschutz" in einer Ankündigung verwendet. Beides greift zu kurz. Self-Hosted Environments für Claude Code sind ein sinnvolles Werkzeug für ein spezifisches Problem – den Schutz von Code, Build-Artefakten und internen Zugangsdaten –, aber kein Ersatz für eine saubere Auftragsverarbeitungsvereinbarung, eine Prüfung der eingesetzten Rechtsgrundlage für die Datenübermittlung und eine bewusste Entscheidung, welche Daten überhaupt in Prompts landen dürfen.

Für ein KMU, das Claude Code oder vergleichbare Agenten-Tools produktiv einführen will, lohnt sich deshalb eine differenzierte Prüfung: Welche Daten sind im jeweiligen Repository tatsächlich enthalten, welche davon sind Personendaten im Sinne des revDSG, und welche Sicherheitsstufe – gehostet oder self-hosted – passt zum tatsächlichen Risiko. Diese Einordnung lässt sich nicht pauschal beantworten, sondern hängt vom konkreten Anwendungsfall ab.

---

Bei der Einführung von Claude Code oder anderen KI-Agenten-Tools unterstützt die KI-Integration von Hedinger-Digital bei der technischen Einrichtung und der Einordnung, welche Daten wo landen. Für Betriebe, die grundsätzlich klären möchten, wie sich KI-Werkzeuge revDSG-konform einsetzen lassen, bietet die Digitalberatung für KMU eine strukturierte Auslegeordnung. Eine Kontaktaufnahme lohnt sich, bevor eine Self-Hosted-Umgebung produktiv geschaltet wird.