Confidential AI für GitLab Self-Hosted

Entwicklungsteams wollen KI-Coding-Agenten nutzen. Der Quellcode ist reguliertes geistiges Eigentum, das nicht an einen KI-Dienst Dritter gehen darf, und das Compliance-Team hat das schriftlich festgehalten. Der übliche Ausweg, ein eigenes GPU-Cluster aufzubauen und die Modelle selbst zu betreiben, bedeutet knappe Hardware zu beschaffen, ein Team für den Betrieb einzustellen und den führenden Modellen trotzdem um Monate hinterherzulaufen. Also passiert nichts, und die eigenen Teams fallen gegenüber jenen zurück, die KI vor einem Jahr eingeführt haben.

GitLab Duo Self-Hosted kann jetzt Privatemode AI als Modellanbieter nutzen. Privatemode betreibt aktuelle Modelle innerhalb von Confidential-Computing-Hardware, sodass Prompts, Quellcode und Completions durchgehend verschlüsselt bleiben, auch während der Inferenz. Das AI Gateway von GitLab Duo wird auf den Privatemode-Proxy gerichtet. Die Entwicklungsteams erhalten dann dieselben Duo-Funktionen wie mit jedem anderen Modell, mit einem Unterschied, der für eine regulierte Organisation zählt: Der Code verlässt nie eine verschlüsselte Grenze, und kein Dritter kann ihn lesen.

Die Unterstützung, die regulierten Teams bisher verwehrt bleibt

KI-Unterstützung beim Programmieren ist längst mehr als Autovervollständigung. Die GitLab Duo Agent Platform übernimmt mehrstufige Arbeit: Sie reviewt Merge Requests, refaktoriert über Dateien hinweg, erzeugt Tests und führt sie aus, steuert agentische Flows als CI-Jobs und einiges mehr. Das verändert die Art, wie Teams liefern, und die Wirkung summiert sich. Teams, die sie nutzen, wenden weniger Aufwand für Standardaufgaben auf und mehr für inhaltliche Reviews.

Der Haken: Jede einzelne dieser Funktionen sendet Prompts und Quellcode an einen Modellanbieter. Für ein Team, das an proprietärem Code, regulierter Software oder sensiblem geistigem Eigentum arbeitet, ist allein diese Tatsache ein Ausschlusskriterium.

Warum regulierte Organisationen selbst hosten

Für diese Organisationen ist Quellcode zentrales geistiges Eigentum, und wo er verarbeitet wird, ist eine vertragliche, branchenspezifische und regulatorische Frage, keine der Bequemlichkeit. Die Handelsalgorithmen einer Bank, die Firmware eines Medizingeräteherstellers, die Steuerungssoftware eines Rüstungsunternehmens: Dieses geistige Eigentum an einen externen KI-Dienst zu senden, kann IP-Schutz, Auftragsverarbeitungsverträge und Branchenregeln in einem einzigen Schritt verletzen.

Der Druck kommt aus mehreren Richtungen zugleich. NIS2 und der Digital Operational Resilience Act (DORA) heben die Anforderungen an operative Resilienz und Drittparteienrisiken in kritischer Infrastruktur und im Finanzsektor. Die DSGVO regelt, wie personenbezogene Daten in Code und Logs verarbeitet werden. Branchenregime wie die BaFin-Aufsicht im deutschen Finanzwesen, BSI C5 als Beschaffungsgrundlage und Vorgaben für Gesundheitsdaten setzen eigene Rahmen. Und viele europäische Organisationen behandeln Datensouveränität ohnehin als Anforderung erster Ordnung, unabhängig von einer einzelnen Regulierung.

Am deutlichsten spüren das Finanzdienstleister, Gesundheitswesen und Pharma, Verteidigung, der öffentliche Sektor und kritische Infrastruktur. GitLab Self-Hosted existiert genau dafür, dass dieser Code einen vertrauenswürdigen Perimeter nie verlassen muss. KI in den Workflow zu holen, sollte das nicht stillschweigend aushebeln.

Warum KI das Selbst-Hosten erschwert

Ein selbst hostendes Team, das KI-Unterstützung beim Programmieren möchte, hat drei herkömmliche Optionen, und jede hat Kosten, die eine regulierte Organisation kaum tragen kann.

Die Tabelle zeigt: Öffentliche KI-SaaS und VPC-Optionen legen Code offen und stützen sich auf vertragliche Zusicherungen, während ein eigener Stack den Code zwar privat hält, aber erheblichen Aufwand für GPUs und Modellbetrieb mit sich bringt.

Nüchtern zusammengefasst: Öffentliche SaaS scheidet aus, weil der Code das Haus verlässt. Ein VPC-isolierter oder Private-Cloud-Dienst verringert die Offenlegung, übergibt den Klartext aber weiterhin an den Betreiber und den darunterliegenden Cloud-Anbieter. Ein Vertrag ist zudem ein Versprechen, keine kryptografische Zusicherung. Eigene Modelle zu betreiben, hält den Code privat, ist aber teuer in der Beschaffung, teuer im Personal und strukturell hinter den besten verfügbaren Modellen. Vor dieser Wahl führen die meisten regulierten Organisationen KI nur eng begrenzt oder gar nicht ein.

Damit stellt sich die Frage: Wie erhalten Entwicklungsteams moderne KI-Coding-Agenten, ohne dass Quellcode den Perimeter verlässt und ohne selbst einen LLM-Stack zu betreiben? Die Antwort verlangt eine andere Art von Zusicherung, als ein Vertrag sie geben kann, nämlich eine, die Hardware durchsetzt.

Confidential Computing: die architektonische Antwort

Confidential Computing hält Daten im Arbeitsspeicher verschlüsselt, also während der Verarbeitung, mithilfe eines hardwarebasierten Trusted Execution Environment (TEE), eines isolierten Bereichs einer CPU oder GPU, in den weder Betriebssystem noch Hypervisor noch der Betreiber der Maschine hineinlesen können. Die relevante Hardware ist hier AMD SEV oder Intel TDX auf CPU-Seite, kombiniert mit NVIDIA Confidential Computing auf der GPU. Daten sind bei der Übertragung und im Ruhezustand mit AES-256 verschlüsselt und werden ausschließlich innerhalb des TEE entschlüsselt.

Was daraus statt eines Versprechens eine Zusicherung macht, ist die Remote Attestation. Bevor ein Client Daten sendet, fordert er das TEE auf nachzuweisen, was es ist: Die Hardware erzeugt signierte, kryptografische Belege darüber, welcher Code genau innerhalb der Enclave läuft. Der Client prüft diese Belege gegen bekannte Sollwerte und baut erst danach den verschlüsselten Kanal auf und sendet seine Anfrage. Erst prüfen, dann senden.

Das Datenflussdiagramm zeigt Prompts, die auf dem Client verschlüsselt, als Chiffrat übertragen und erst innerhalb eines Hardware-TEE entschlüsselt werden, in das weder der Betreiber des Dienstes noch der Cloud-Anbieter hineinsehen kann.

Die daraus folgende Sicherheitseigenschaft ist der eigentliche Punkt: Weder der Betreiber des KI-Dienstes noch der darunterliegende Cloud-Anbieter sieht Prompts, Completions oder Kontext. Nicht, weil sie versprechen, nicht hinzusehen, sondern weil die Hardware es nicht zulässt.

Privatemode AI

Privatemode AI stammt von Edgeless Systems, einem auf Confidential-Computing-Software spezialisierten Unternehmen aus Deutschland. Laut NVIDIA ist Privatemode das "first generative AI framework that keeps prompts encrypted at all times".

Für die Entwicklungsarbeit bleibt die Mechanik unsichtbar. Privatemode stellt eine OpenAI-kompatible API bereit, und ein clientseitiger Proxy übernimmt Attestation und Verschlüsselung transparent, sodass Werkzeuge und SDKs, die die Standard-/v1-API sprechen, unverändert funktionieren. Aktuelles Flaggschiffmodell fürs Programmieren ist Kimi K2.6 mit 256K Kontext, weitere wie Kimi K3 und GLM folgen.

Das ist kein Laborexperiment. Privatemode läuft bereits produktiv bei Organisationen mit genau den oben beschriebenen Rahmenbedingungen. Capgemini nutzt es für Kunden aus regulierten Branchen, einschließlich vertraulicher Programmierarbeit. Die Bundesagentur für Arbeit setzt es im öffentlichen Sektor ein. Und Banken, Versicherer und Verteidigungsorganisationen nutzen es dort, wo Quellcode und Daten eine vertrauenswürdige Grenze nicht verlassen dürfen. Die Kryptografie ist post-quantensicher, was auch gegen Angriffe nach dem Muster "harvest now, decrypt later" schützt. Wer heute Chiffrat abgreift, um es mit der Hardware von morgen zu entschlüsseln, erhält nichts Verwertbares.

So funktioniert die Integration

Mit GitLab Duo Self-Hosted lassen sich die KI-Funktionen von Duo aus einem selbst kontrollierten Modell bedienen statt aus einem von GitLab betriebenen Gateway. Privatemode tritt an diese Stelle.

Der Weg ist unkompliziert. GitLab Duo spricht mit einem selbst gehosteten AI Gateway, das die Inferenz an einen beliebigen OpenAI-kompatiblen Endpunkt weiterreicht. Der Privatemode-Proxy ist dieser Endpunkt: Er stellt eine Standard-/v1-API bereit und übernimmt Verschlüsselung und Attestation gegenüber dem Privatemode-Dienst. Trifft eine Anfrage ein, verschlüsselt der Proxy sie, bevor sie das eigene Netz verlässt, prüft das entfernte TEE per Attestation und leitet sie erst dann weiter. Entschlüsselt wird ausschließlich innerhalb der Confidential-Computing-Umgebung. Innerhalb von Duo, über Code Suggestions, Chat, Code Review und agentische Flows hinweg, bleibt die Arbeitsweise für Entwickelnde unverändert.

sequenceDiagram
    autonumber
    actor Dev as Entwickelnde /<br>Duo Agent Platform
    participant GW as Selbst gehostetes<br>GitLab AI Gateway
    participant Proxy as Privatemode<br>Proxy
    participant TEE as Entferntes TEE<br>(CPU + GPU)

    Dev->>GW: Inferenz-Anfrage (Code<br>Suggestions, Chat,<br>Code Review, Flows)
    GW->>Proxy: Anfrage an OpenAI-<br>kompatiblen Endpunkt<br>weiterleiten

    rect rgb(255, 244, 214)
        Note over Proxy,TEE: Attestation, bevor Code gesendet wird
        Proxy->>TEE: Attestation-Belege anfordern
        TEE-->>Proxy: Signierte Belege des Enclave-Codes
        Proxy->>Proxy: Belege gegen bekannte Sollwerte prüfen
        Proxy->>TEE: Verschlüsselten Kanal aufbauen (AES-256, post-quantensicher)
    end

    Proxy->>TEE: Verschlüsselte Anfrage weiterleiten
    Note over TEE: Entschlüsselung und Inferenz<br>nur innerhalb der Enclave
    TEE-->>Proxy: Verschlüsselte Antwort
    Proxy-->>GW: Verschlüsselte Antwort
    GW-->>Dev: Completion (Arbeitsweise<br>unverändert)

Im Sequenzdiagramm läuft eine Anfrage aus GitLab Duo über das selbst gehostete AI Gateway zum Privatemode-Proxy, der die entfernte Enclave attestiert und einen verschlüsselten Kanal aufbaut. Erst danach reicht er die Anfrage zur Inferenz innerhalb des TEE weiter. AI Gateway und Proxy werden selbst betrieben, und das Setup ist deployment-agnostisch (Linux-Paket, Docker oder Kubernetes). Die Schritte sind dokumentiert und versionsspezifisch, deshalb hier nicht wiederholt: siehe Privatemodes Integrationsanleitung für GitLab Duo.

Die Kompromisse

Keine Architektur ist umsonst, und ein technisches Publikum hat Anspruch darauf, die Kosten klar benannt zu bekommen.

Gateway und Proxy werden selbst betrieben. Das ist echte Infrastrukturarbeit: das AI Gateway unter einem passenden Hostnamen bereitstellen, seine Image-Version bei jedem Upgrade zur GitLab-Version passend halten, JWT-Schlüssel und Zertifikate konfigurieren und den Proxy erreichbar halten. Es ist allerdings gewöhnlicher Infrastrukturbetrieb, keine GPU-Beschaffung und kein Modellbetrieb. Genau darin liegt der Unterschied. Die Alternative, die den Code ebenfalls privat hält, nämlich ein eigener LLM-Stack, bedeutet knappe GPUs zu kaufen und ein Team für Betrieb und Modell-Updates zu stellen, während man den führenden Modellen hinterherläuft. Privatemode ist ein gehosteter SaaS-Dienst, der den Modellbetrieb übernimmt, und was bleibt, sind ein Proxy und ein Gateway.

Generische OpenAI-kompatible Modelle sind in GitLab Duo Self-Hosted noch nicht ausgereift. Sie laufen derzeit als Beta-Funktion, Support für modellspezifische Probleme ist also noch nicht zugesichert. Eine Härtung steht auf der Roadmap, doch wer jetzt eine vollständig unterstützte Konfiguration braucht, sollte diesen Zeithorizont im Rollout berücksichtigen.

Attestation und Verschlüsselung erzeugen zusätzlichen Aufwand. Der zusätzliche Roundtrip und die kryptografische Arbeit kosten pro Anfrage etwas. In unseren Tests war das praktisch kein Problem, die Integrationsanleitung empfiehlt allerdings, das Timeout des AI Gateway für langsamere selbst gehostete Backends heraufzusetzen, weshalb sich eine Messung am eigenen Latenzbudget lohnt.

Vertrauen bleibt nötig, aber es ist begrenzt. Die Zusicherung beruht darauf, dass das Hardware-TEE und die Kette der Attestation solide sind. Das ist eine kleinere, besser prüfbare Vertrauensannahme als "dem Betreiber vertrauen, dass er nicht hinsieht", und die Belege der Attestation lassen sich selbst nachprüfen, aber null ist sie nicht. Confidential Computing verengt das Vertrauen auf das Silizium. Es beseitigt es nicht.

Was das in der Praxis bedeutet

• Für regulierte Organisationen: Der Weg zu modernen KI-Coding-Agenten passt zur bestehenden Richtlinie für IP- und Datenschutz, weil der Code innerhalb einer hardwareverschlüsselten Grenze bleibt, und das ohne GPU-Kauf und ohne eigenen Modellbetrieb.
• Für Entwickelnde: Die GitLab-Duo-Erfahrung bleibt dieselbe, die Modelle sind dieselben oder besser, und neue Werkzeuge braucht es nicht. Da die Modellauswahl auf der Instanz liegt, übernehmen auch Chat und Code Suggestions im Editor über die GitLab Workflow Extension dasselbe vertrauliche Setup.
• Für Compliance- und Security-Teams: Die Architektur passt zur Richtung von BSI C5:2026 hin zu Confidential Computing und Remote Attestation, und sie liefert konkrete technische Belege, nämlich Verschlüsselung während der Verarbeitung und attestierte Ausführung, für Gespräche zu NIS2, DORA und DSGVO. Compliance stellt sie damit nicht allein her, denn Compliance ist organisatorisch und fortlaufend. Sie räumt aber den Einwand aus, der KI-Einführung überhaupt erst blockiert: "Unser Code würde den Perimeter verlassen."

Mit Privatemode starten

Für Privatemode als selbst gehosteten Modellanbieter braucht es GitLab Self-Managed mit Premium oder Ultimate, ab Version 17.9. Hinzu kommt das Add-on GitLab Duo Enterprise. Agentische Flows benötigen zusätzlich die GitLab Duo Agent Platform (allgemein verfügbar ab Version 18.8). Die Nutzung verbraucht GitLab Credits nach den Regeln und Multiplikatoren für Bring-your-own-Model, die in der Dokumentation zu GitLab Credits beschrieben sind.

Weiterlesen

• Privatemode-Dokumentation
• Integrationsanleitung für GitLab Duo
• Leitfaden für Coding-Assistenten
• Capgemini-Fallstudie
• NVIDIA-Lösungsbeschreibung