GitLab Privatemode: Vertrauliche KI ohne eigenen GPU-Cluster

Self-Hosted heißt nicht mehr zwangsläufig eigenes Modell

GitLab erweitert Duo Self-Hosted um Privatemode AI als Modellanbieter. Unternehmen können GitLab und den AI Gateway selbst betreiben, während die eigentliche Inferenz in einer externen, hardwaregeschützten Umgebung läuft. Das ist weder klassische Public-Cloud-KI noch vollständiger Eigenbetrieb. Es ist ein pragmatischer Mittelweg für Teams, die Quellcode kontrollieren wollen, aber keinen GPU-Cluster pflegen möchten.

Die Architektur beschreibt GitLab im offiziellen Beitrag zu Confidential AI. Der selbst betriebene AI Gateway leitet Anfragen an einen lokal installierten Privatemode-Proxy weiter. Dieser spricht eine OpenAI-kompatible /v1-API und prüft vor der Übertragung per Remote Attestation, ob die entfernte vertrauenswürdige Ausführungsumgebung dem erwarteten Zustand entspricht.

Das Angebot zielt auf ein bekanntes Problem: Entwicklungsdaten sind hochsensibel, leistungsfähige Modelle benötigen jedoch teure und wartungsintensive Beschleuniger. Confidential Computing soll die Lücke schließen, indem Daten während der Verarbeitung geschützt bleiben. Das ist technisch substanzieller als ein Versprechen, der Anbieter werde schon nicht hinsehen. Es ersetzt trotzdem keine vollständige Risiko- und Vertragsprüfung.

Für regulierte Organisationen ist diese Aufteilung interessant, weil sie den eigenen Betriebsumfang reduziert, ohne Klartextverarbeitung auf normaler Cloudinfrastruktur vorauszusetzen. Sie müssen dennoch nachweisen, welche Kontrollen tatsächlich greifen. Architekturdiagramm, Attestierungsrichtlinie, Datenfluss und Verantwortlichkeiten gehören deshalb in die Freigabeunterlagen. Der Produktname allein ist kein belastbarer Nachweis gegenüber Revision oder Kunden.

Der Datenweg vom GitLab-Server bis zur TEE

Eine Anfrage beginnt in GitLab Duo Self-Hosted und gelangt zum lokal betriebenen AI Gateway. Der Gateway bündelt die KI-Funktionen und leitet den Aufruf an den Privatemode-Proxy weiter. Erst nach erfolgreicher Prüfung der entfernten Umgebung übermittelt der Proxy Prompt, Quellcode und zusätzlichen Kontext. Diese Reihenfolge ist entscheidend: Vertrauen soll technisch geprüft werden, bevor sensible Nutzdaten die lokale Grenze verlassen.

Nach GitLabs Darstellung werden die Daten ausschließlich innerhalb einer hardwaregestützten Trusted Execution Environment, kurz TEE, entschlüsselt und verarbeitet. Genannt werden AMD SEV, Intel TDX und NVIDIA Confidential Computing. Solche Technologien sollen Speicher und Berechnung gegenüber Host, Hypervisor oder Infrastrukturbetreiber abschirmen. Die konkrete Sicherheit hängt dennoch von Hardware, Firmware, Attestierungsdienst, Konfiguration und zeitnahen Updates ab.

Antworten kehren über denselben kontrollierten Pfad zurück. Für Entwickler sollen Code Suggestions, Chat, Code Review und agentische Abläufe ohne veränderten Workflow funktionieren. Nutzer sehen also möglichst wenig von Kryptografie und Attestation. Für den Betrieb ist die Unsichtbarkeit nur an der Oberfläche sinnvoll: Logs, Messwerte und klare Fehlerzustände müssen zeigen, ob eine Attestation scheiterte oder ein ungeschützter Fallback verhindert wurde.

Besonders wichtig ist die Verschlüsselung zwischen den Komponenten und die Behandlung der Schlüssel. Wer kann einen gültigen Verbindungsaufbau initiieren, und wie wird ein kompromittierter Proxy widerrufen? Geheimnisse sollten nicht in Container-Images oder statischen Konfigurationsdateien liegen. Die TEE schützt die entfernte Verarbeitung, während der lokale Proxy selbst weiterhin gehärtet und überwacht werden muss.

Remote Attestation ist der technische Vertrauensanker

Remote Attestation liefert kryptografisch prüfbare Aussagen darüber, welche Software in welcher geschützten Umgebung läuft. Der Proxy kann Messwerte und Zertifikatsketten gegen eine erwartete Konfiguration prüfen. Stimmen sie nicht, darf er die sensiblen Daten nicht freigeben. Damit wird „vertraue dem Cloudanbieter“ durch „prüfe einen technischen Nachweis“ ergänzt. Ergänzt, nicht vollständig ersetzt – auch Nachweisregeln werden von Menschen definiert.

Unternehmen müssen deshalb festlegen, welche Messwerte akzeptiert werden, wie Schlüssel aktualisiert und widerrufene Plattformen behandelt werden. Eine zu großzügige Policy lässt veraltete oder unerwartete Images zu; eine zu enge Policy kann Updates blockieren und die Verfügbarkeit beeinträchtigen. Besonders kritisch ist das Verhalten bei Fehlern: Ein Fail-open auf normale Inferenz würde das Schutzversprechen genau dann auflösen, wenn die Vertrauenskette nicht funktioniert.

Attestation schützt außerdem nicht vor jeder logischen Fehlfunktion des Modells oder der erlaubten Anwendung. Wenn ein autorisierter Agent zu viele Repositorys lesen darf, verarbeitet die TEE diese Daten zwar vertraulich, aber weiterhin in zu großem Umfang. Confidential Computing begrenzt Infrastrukturzugriffe. Least Privilege, Zweckbindung und menschliche Freigaben bleiben Aufgaben der GitLab- und Organisationskonfiguration.

Attestierungsnachweise haben eine zeitliche Dimension. Ein vormals vertrauenswürdiges Image kann nach einer bekannt gewordenen Schwachstelle aus der zulässigen Menge entfernt werden müssen. Dafür braucht es Aktualisierungs- und Notfallprozesse. Prüfen Sie, wer Policies ändert und ob Änderungen protokolliert werden. Sonst kann aus einem präzisen technischen Kontrollpunkt eine undurchsichtige Administrationsentscheidung werden.

Dieses Bild wurde komplett mit KI generiert

Providerhiggsfield

Modellseedream_v4_5/high/5120x2880

PromptA security engineer verifies remote attestation before encrypted code context enters a hardware-backed trusted execution environment. The scene shows an attestation certificate, protected inference enclave, and denied path for unverified infrastructure without implying absolute security. Photorealistic style image. Mood: skeptical and security-focused. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Was Sie lokal betreiben – und was nicht

AI Gateway und Privatemode-Proxy können laut GitLab als Linux-Paket, in Docker oder Kubernetes bereitgestellt werden. Damit passen sie in übliche Self-Hosted-Betriebsmodelle. Ein eigener GPU-Cluster ist nicht erforderlich. Das reduziert Hardwarebeschaffung, Treiberpflege, Kapazitätsplanung und Modellbetrieb. Es beseitigt aber nicht den Bedarf an Hochverfügbarkeit, Zertifikatsmanagement, Proxy-Updates und einem belastbaren Netzwerkpfad zum Inferenzdienst.

Der lokale Anteil gibt Unternehmen Kontrolle über Routing und die Integration in ihre GitLab-Umgebung. Die Rechenleistung und Teile der Vertrauenskette bleiben beim externen Dienst und der zugrunde liegenden Hardwareplattform. Damit entstehen Abhängigkeiten von Verfügbarkeit, unterstützten Modellen, Attestierungsformaten und Vertragsbedingungen. Wer Self-Hosting mit vollständiger Lieferantenunabhängigkeit gleichsetzt, wird an dieser Stelle nüchtern nachrechnen müssen.

Wartbarkeit entscheidet sich auch an Upgrades. Gateway, Proxy, GitLab-Version und API-Kompatibilität müssen gemeinsam getestet werden. Support Bundles dürfen keine vertraulichen Prompts oder Schlüssel enthalten. Wie wichtig aktuelle Stände für Diagnose und Herstellerhilfe sind, zeigt unser Beitrag zu Support Bundles und Patchständen. Das Prinzip gilt unabhängig vom konkreten Git-Server.

Kubernetes erleichtert Skalierung und Deployment, bringt aber eigene Komplexität mit. Network Policies, Service Accounts, Secrets und Pod-Sicherheitsregeln müssen zum Schutzversprechen passen. Ein privilegierter Proxy-Container oder breit erreichbarer Gateway schwächt die lokale Seite der Kette. Wählen Sie das Betriebsmodell, das Ihr Team zuverlässig warten kann, nicht das mit den meisten YAML-Dateien.

Voraussetzungen, Editionen und Beta-Grenzen

GitLab nennt als Voraussetzung GitLab Self-Managed ab Version 17.9, eine Premium- oder Ultimate-Lizenz sowie das Duo-Enterprise-Add-on. Interessierte Teams müssen daher nicht nur die technische Plattform, sondern auch die vertragliche Produktkombination prüfen. Die Bezeichnung Self-Hosted allein sagt nichts über verfügbare KI-Funktionen aus. Lizenzinventar gehört hier ausnahmsweise direkt neben das Kubernetes-Manifest.

Generische OpenAI-kompatible Modelle befinden sich nach GitLabs Angaben derzeit im Beta-Status. Beta bedeutet, dass Schnittstellen, unterstützte Funktionen oder Betriebsgrenzen sich ändern können. Produktive Piloten sollten deshalb Versionsbindungen, Rollback und Kompatibilitätstests vorsehen. Besonders agentische Abläufe verdienen enge Grenzen, weil sie nicht nur Text erzeugen, sondern gegebenenfalls Werkzeuge und Repository-Aktionen auslösen.

Auch die Aussage, mehrere Duo-Funktionen nutzten dieselbe vertrauliche Verbindung, ist zunächst eine Herstellerbeschreibung. Prüfen Sie pro Funktion, welche Daten tatsächlich übertragen werden: aktiver Codeausschnitt, Nachbardateien, Issues, Merge Requests oder Repository-Metadaten. Ein gemeinsamer sicherer Kanal beantwortet nicht automatisch die Frage, ob der Umfang des übermittelten Kontexts für den jeweiligen Zweck angemessen ist.

Planen Sie Lizenz- und Versionsprüfungen automatisiert, damit ein Upgrade nicht unbemerkt eine inkompatible Kombination erzeugt. Für Beta-Schnittstellen ist ein separater Freigabekanal sinnvoll. Änderungen sollten zuerst mit Testprojekten und synthetischen, nicht vertraulichen Anfragen geprüft werden. Erst danach folgt ein begrenzter produktiver Bereich mit klarer Rückfallstrategie auf deaktivierte KI-Funktionen.

Bedrohungsmodell statt Datenschutzetikett

Ein sinnvoller Einsatz beginnt mit einem expliziten Bedrohungsmodell. Soll der Infrastrukturbetreiber vom Klartext ausgeschlossen werden? Müssen Administratoren des eigenen Clusters begrenzt werden? Welche Risiken bleiben durch kompromittierte Clients, bösartige Erweiterungen oder zu breite GitLab-Rechte bestehen? Eine TEE adressiert vor allem Daten während der Verarbeitung. Endgeräte, Identitäten und Ergebnisnutzung liegen weiterhin außerhalb dieser Grenze.

Protokollierung erfordert besondere Sorgfalt. Für Betrieb und Audit brauchen Sie Request-IDs, Dauer, Modell, Attestierungsstatus und Fehlerklasse. Prompts, Quellcode oder vollständige Antworten sollten nicht standardmäßig in zentralen Logs landen. Auch Telemetrie des Proxys und Gateways muss auf Datenminimierung geprüft werden. Vertrauliche Inferenz mit ungeschütztem Debug-Logging wäre ein bemerkenswert effizienter Weg, das eigene Sicherheitsziel zu umgehen.

Berücksichtigen Sie außerdem Lieferkette und Updatekanäle. Images und Pakete müssen verifiziert, Abhängigkeiten überwacht und attestierte Messwerte nachvollziehbar geändert werden. Offener Quellcode kann Inspektion erleichtern, ersetzt aber keine reproduzierbaren Builds oder kontrollierte Artefakte. Welche Abhängigkeiten neue Modelle und Entwicklungswerkzeuge mitbringen, diskutiert ergänzend unser Beitrag zu GPT-5.6 und OpenAIs Dev-Offensive.

Auch generierte Ergebnisse können vertrauliche Inhalte reproduzieren. Zugriffsrechte und Aufbewahrung für Antworten müssen daher den Eingabedaten entsprechen. Nutzer sollten erkennen, welche Projekte als Kontext dienten. Für Code Review und agentische Abläufe empfiehlt sich zusätzlich eine nachvollziehbare Freigabe vor schreibenden Aktionen. Vertrauliche Berechnung macht einen falschen Änderungsvorschlag nicht automatisch richtig.

Ein Pilot, der mehr prüft als eine erfolgreiche Antwort

Beginnen Sie mit einem isolierten GitLab-Projekt und nicht sensiblen, aber repräsentativen Codebeständen. Installieren Sie Gateway und Proxy im vorgesehenen Betriebsmodell und dokumentieren Sie alle ausgehenden Verbindungen. Testen Sie erfolgreiche Attestation, abgelaufene Nachweise, unerwartete Messwerte, Netzwerkausfall und ein nicht verfügbares Modell. Der wichtigste Test ist, dass bei fehlendem Vertrauen keine Klartextanfrage gesendet wird.

Messen Sie danach Qualität, Latenz, Verfügbarkeit und Betriebsaufwand je Duo-Funktion. Vergleichen Sie nicht nur mit einem ungeschützten Cloudmodell, sondern auch mit lokalem Modellbetrieb und dem Verzicht auf die Funktion. Prüfen Sie Kosten anhand realer Nutzung; GitLab veröffentlicht in der zugrunde liegenden Meldung keinen universellen Wirtschaftlichkeitsnachweis. Ein eingesparter GPU-Cluster kann durch andere Anforderungen teilweise ersetzt werden.

GitLab Privatemode bietet einen technisch interessanten Kompromiss: lokale Kontrolle über Plattform und Gateway, vertrauliche externe Inferenz ohne eigenen GPU-Betrieb. Ob dieser Mittelweg für Sie tragfähig ist, hängt von Attestierungsvertrauen, Abhängigkeiten, Lizenz und Datenumfang ab. Self-Hosting wird damit nicht abgeschafft. Es wird präziser – und verlangt endlich die Frage, welchen Teil Sie wirklich selbst kontrollieren müssen.

Beziehen Sie Datenschutz, Informationssicherheit, Plattformbetrieb und Entwicklung früh ein. Jede Gruppe sieht andere Risiken: Datenübermittlung, Vertrauenskette, Wartbarkeit oder Workflow. Ein gemeinsamer Pilotbericht sollte offene Punkte ausdrücklich nennen und keine Universalzulassung behaupten. So bleibt die Entscheidung reversibel, falls sich Beta-API, Kosten, unterstützte Hardware oder organisatorische Anforderungen verändern.