Wie JetBrains AI Assistant den Schutz von proprietärem Code und die Datenaufbewahrung bei externen LLMs regelt

Für Entwicklungsleiter (Engineering Directors), IT-Sicherheitsverantwortliche (CISOs) und Datenschutzbeauftragte wirft die Einführung KI-gestützter Entwicklerwerkzeuge eine entscheidende Frage auf: Wie lässt sich die Entwicklerproduktivität maximieren, ohne geistiges Eigentum preiszugeben oder proprietären Quellcode für das Training fremder Modelle zu exponieren? Die zentrale Sorge bei der Evaluierung des JetBrains AI Assistant lautet: Wird der an cloudbasierte Large Language Models (LLMs) übermittelte private Code von Drittanbietern dauerhaft gespeichert, analysiert oder in Trainingsdatensätze integriert?

Dieser Leitfaden analysiert die Datenschutzarchitektur, den Anfrage-Lebenszyklus, vertragliche Garantien zur Zero Data Retention (ZDR), die Kapselung von RAG-Vektoren sowie administrative Kontrollmechanismen von JetBrains und seinen externen Modellpartnern.

Management-Zusammenfassung: Zentrale Sicherheitsaspekte

• Kein Modelltraining mit Kundencode: Unter regulären kommerziellen Lizenzbedingungen ist es sowohl JetBrains als auch externen LLM-Anbietern vertraglich streng untersagt, proprietären Code, Prompts oder generierte Antworten zum Trainieren öffentlicher Basismodelle zu verwenden.
• Zero Data Retention (ZDR) bei Cloud-Inferenzen: Externe LLM-Anbieter unterliegen verbindlichen B2B-Vereinbarungen, die eine Speicherung von Daten über die flüchtige Inferenzberechnung im Arbeitsspeicher hinaus untersagen.
• Durchgehende Transportverschlüsselung: Sämtliche Kommunikationskanäle zwischen der IDE, der JetBrains-Proxy-Infrastruktur und den nachgelagerten Modellbetreibern sind per TLS 1.2 oder höher verschlüsselt.
• Isolierte Vektor- und RAG-Verarbeitung: Code-Vektorisierung, semantische Einbettungen (Embeddings) und Reranking erfolgen über Open-Weight-Modelle direkt auf der Infrastruktur von JetBrains. Embedding-Anfragen werden niemals an externe Anbieter wie OpenAI oder Google weitergeleitet.
• Detaillierte Datenerfassung standardmäßig deaktiviert: Das optionale Programm zur Erfassung detaillierter Codedaten zur Verbesserung von JetBrains-eigenen Modellen (wie Mellum) ist bei Unternehmenslizenzen standardmäßig deaktiviert und kann von einzelnen Entwicklern nicht eigenmächtig aktiviert werden.
• Granulare Ausschlussregeln: Entwicklungsteams können über .aiignore-Dateien gezielt vertrauliche Verzeichnisse und Dateien sperren oder per .noai die KI-Funktionalität für ein gesamtes Repository vollständig deaktivieren.
• Betrieb in geschlossenen Netzen: Für regulatorisch hochgradig eingeschränkte oder physisch getrennte Netze (Air-Gapped) stehen Offline-Vervollständigungen (Full Line Code Completion), Bring Your Own Key (BYOK) und die On-Premises-Lösung JetBrains AI Enterprise zur Verfügung.

1. Anfrage-Lebenszyklus und mehrschichtige Verarbeitungsarchitektur

Um den Schutz proprietären Quellcodes zu beurteilen, ist der vollständige technische Pfad einer Anfrage von Bedeutung:

[ IDE des Entwicklers ]
       |
       +---> [ Lokale statische Analyse und Filter (.aiignore / .noai) ]
       |
       +---> [ Full Line Completion (Lokale Modellinferenz, kein Netzwerkverkehr) ]
       |
       v (TLS 1.2+ verschlüsselter Tunnel)
[ JetBrains AI Plattform-Proxy (EWR-Rechenzentren) ]
       |
       +---> [ Semantische Suche / RAG (JetBrains-gehostete Embedding-Modelle) ]
       |       (Keine Vektoranfragen an OpenAI, Google oder sonstige Dritte)
       |
       v (TLS 1.2+ flüchtiger API-Aufruf)
[ Externe LLM-Auftragsverarbeiter ]
  (OpenAI, Anthropic, Google Cloud Vertex, AWS Bedrock, xAI)
       |
       +---> [ Inferenzverarbeitung ausschließlich im flüchtigen RAM ]
       |
       v (Streaming-Rückgabe; keine Datenspeicherung; kein Modelltraining)
[ IDE stellt Code-Vorschlag dar ]

Minimale Kontextzusammenstellung in der IDE

Der JetBrains AI Assistant lädt niemals vollständige Repositories unkontrolliert in die Cloud hoch. Stattdessen nutzt die IDE ihre semantische Code-Analyse (AST-Parsing, Symbolindizes, Abhängigkeitsgraphen), um ausschließlich den zwingend erforderlichen Kontextausschnitt zusammenzustellen:

• Die aktive Datei und die Codezeilen unmittelbar um die Cursorposition.
• Relevante Dateitypen, Frameworks und Sprachdefinitionen.
• Vom Entwickler explizit ausgewählte Codeblöcke oder eingegebene Chat-Prompts.
• Relevante Projektmetadaten, die nicht durch Ausschlussregeln blockiert sind.

Sicherer Proxy als Gateway

Entwickler-Workstations kommunizieren nicht direkt mit öffentlichen Endverbraucher-Endpunkten von Drittanbietern. Der gesamte Datenverkehr wird über den JetBrains AI Service Proxy geleitet, der in Rechenzentren innerhalb des Europäischen Wirtschaftsraums (EWR) betrieben wird. Dieser Proxy erfüllt zentrale Schutzfunktionen:

1. Bereinigung von Metadaten: Entfernt unnötige Rechner- und Umgebungskennungen vor der Weiterleitung.
2. Quoten- und Ratenbegrenzung: Validiert Unternehmenskonten und schützt vor Denial-of-Service- und Missbrauchsmustern.
3. Dedizierte B2B-Routen: Leitet Anfragen gezielt über abgesicherte Unternehmens-APIs und trennt sie strikt von Consumer-Warteschlangen.

2. Externe LLM-Anbieter und die Zero-Data-Retention-Grenze

Während kostenlose Consumer-Webdienste Eingaben häufig zur Modelloptimierung heranziehen, gelten für professionelle Unternehmenswerkzeuge grundlegend andere vertragliche und technische Grenzen.

Liste der autorisierten Modell-Subunternehmer

Gemäß den offiziellen rechtlichen Bestimmungen bindet JetBrains ausgewählte Drittanbieter als Unterauftragsverarbeiter ein:

• OpenAI: Modelle der GPT-Familie.
• Anthropic: Modelle der Claude-Familie (direkt oder über AWS Bedrock angebunden).
• Google: Modelle der Gemini-Familie.
• Amazon Web Services (AWS): Modelle auf der Plattform Amazon Bedrock.
• SpaceXAI: Modelle der Grok-Familie.

Zusätzlich betriebene eigene Modelle von JetBrains (wie Mellum, Mellum2 sowie quelloffene Qwen-Modelle unter Apache 2.0) laufen vollständig auf JetBrains-eigener Infrastruktur. Deren Ein- und Ausgaben werden nicht mit den ursprünglichen Modellentwicklern geteilt.

Vertragliches Trainingsverbot und flüchtige Speicherung

JetBrains schließt mit allen externen Partnern verbindliche Datenverarbeitungsnachträge (Data Processing Addenda, DPA) und B2B-Verträge ab. Diese Verträge schreiben verbindlich vor:

1. Verbot von Modelltraining: Drittanbieter dürfen übermittelten Quellcode, Prompts und Inferenzantworten unter keinen Umständen zum Trainieren, Verbessern oder Feintunen ihrer Modelle verwenden.
2. Zero Data Retention (ZDR): Eingabedaten verbleiben ausschließlich während der Berechnung im flüchtigen Arbeitsspeicher (RAM). Sobald die Antwort an den JetBrains-Proxy gestreamt wurde, werden die Speicherbereiche freigegeben; eine persistente Speicherung auf Festplatten findet nicht statt.
3. Keine Weitergabe an Dritte: Die Weitergabe oder der Weiterverkauf von Kundendaten an externe Prüfer, Dritte oder öffentliche Suchmaschinen ist untersagt.

Isolation von Vektoreinbettungen (RAG)

Bei semantischer Codesuche und Retrieval-Augmented Generation (RAG) sorgt JetBrains für eine strikte Datenkapselung:

• Die Vektorisierung und das Reranking (Qwen3-Embedding-4B und Qwen3-Reranker-0.6B) erfolgen intern auf JetBrains-Infrastruktur.
• Vektor-Anfragen verlassen das interne Netzwerk zu keinem Zeitpunkt in Richtung OpenAI oder Google.
• Die Struktur Ihrer Codebasis wird niemals in geteilten Vektordatenbanken von Drittanbietern abgelegt.

3. Daten-Governance: Telemetriedaten vs. detaillierte Codedaten

JetBrains unterscheidet klar zwischen zwei Erfassungsarten:

Schutzmechanismen bei der detaillierten Codedatenerfassung

JetBrains bietet Entwicklern die freiwillige Möglichkeit, Interaktionsdaten für das Training hauseigener Modelle (wie Mellum) bereitzustellen. Für Unternehmen gelten hierbei strikte Hürden:

1. Standardmäßig inaktiv: Für alle kommerziellen, Unternehmens- und Bildungslizenzen ist diese Datenerfassung ab Werk ausgeschaltet.
2. Administrative Sperre: Einzelne Entwickler können die Option in ihren lokalen IDE-Einstellungen nicht aktivieren, solange der Administrator der JetBrains-Unternehmensorganisation dies nicht zentral genehmigt hat.
3. Speicherung im EWR: Selbst bei freiwilliger Aktivierung verbleiben die Daten im EWR, sind nur autorisiertem Personal zugänglich und werden niemals an Drittanbieter weitergegeben.

4. Administrative Kontrollmechanismen für Unternehmen

IT-Sicherheitsverantwortliche können Schutzrichtlinien auf vier komplementären Ebenen durchsetzen:

[ Ebene 1: Zentrale Verwaltungskonsole ] ---> Master-Schalter: KI unternehmensweit aktivieren/deaktivieren
                                                          |
[ Ebene 2: Repository-Wurzel (.noai) ]    ---> Vollständige Abschaltung aller KI-Funktionen im Projekt
                                                          |
[ Ebene 3: Datei- und Pfadausschluss (.aiignore) ] ---> Gezielter Ausschluss von Secrets, Schlüsseln und Kerncode
                                                          |
[ Ebene 4: Lokale Protokollprüfung ]      ---> Überprüfung via ai-assistant-requests.md

1. Zentrale Administration im JetBrains Account

Administratoren können im Webportal unternehmensweite Richtlinien für alle Lizenzen festlegen:

• Zentraler Not-Aus-Schalter: Die KI-Nutzung kann für die gesamte Belegschaft mit einem Klick sofort ausgesetzt werden.
• Erzwungene Deaktivierung der Datenerfassung: Die Option zur Übermittlung detaillierter Codedaten kann zentral gesperrt werden, sodass lokale Änderungen wirkungslos bleiben.

2. Projektweiter Not-Aus per .noai

Für Repositories, die strengsten Geheimhaltungsvereinbarungen (NDA) unterliegen, genügt eine leere .noai-Datei im Projektstamm:

touch .noai

Sobald diese Datei erkannt wird, stellt der JetBrains AI Assistant sämtliche Dienste in diesem Projekt vollständig ein – einschließlich Inline-Vervollständigungen, Refactorings und Chat.

3. Granulare Ausschlussregeln per .aiignore

Möchte ein Team KI-Unterstützung für allgemeine Aufgaben nutzen, jedoch Kernalgorithmen, kryptografische Module oder Konfigurationsdateien absichern, wird eine .aiignore-Datei im Projektstamm hinterlegt.

Die Syntax entspricht der von .gitignore:

# Ausschluss geschützter Kernalgorithmen
src/core/crypto/
src/proprietary/trade_engine/

# Ausschluss von Zugangsdaten und Konfigurationen
config/secrets/
**/*.env
**/*.pem
**/*.key

# Ausschluss von Patentunterlagen und Compliance-Dokumenten
docs/patents/
internal_compliance/

Der JetBrains AI Assistant berücksichtigt automatisch auch bereits vorhandene Ausschlussdateien wie .cursorignore, .codeiumignore und .aiexclude.

4. Transparenz durch lokale Anfrageprotokolle

Sicherheitsbeauftragte müssen sich nicht auf Annahmen verlassen, sondern können die Payload-Inhalte direkt auf Entwicklungsrechnern überprüfen:

1. In der IDE zweimal die Taste Shift drücken, um Search Everywhere zu öffnen.
2. Den Befehl Open AI Assistant Requests Log in Editor suchen und ausführen.
3. Die IDE öffnet die Datei ai-assistant-requests.md mit den exakten Prompts, Codeausschnitten und Modellparametern der laufenden Sitzung.

5. Bereitstellungsoptionen für hochregulierte Umgebungen

Für Sektoren wie Banken, Behörden oder Rüstung, in denen Datenübertragungen an öffentliche Clouds untersagt sind, bietet JetBrains alternative Architekturen:

Full Line Code Completion (Lokales Offline-ML)

• Funktionsweise: Lokale, von JetBrains entwickelte neuronale Netze generieren Einzeilen-Vervollständigungen direkt auf der CPU oder GPU des Entwickler-PCs.
• Datenschutz: Funktioniert ohne jede Internetverbindung und erzeugt keinerlei Netzwerkverkehr.
• Verfügbarkeit: Standardmäßig in modernen JetBrains-IDEs integriert, ohne Zusatzkosten oder Cloud-Abonnement.

Bring Your Own Key (BYOK)

• Funktionsweise: Das Unternehmen hinterlegt eigene Unternehmens-API-Keys von OpenAI, Anthropic oder Azure OpenAI in der IDE.
• Datenschutz: API-Schlüssel werden lokal verschlüsselt gespeichert und gelangen nicht zu JetBrains. Der Datenverkehr unterliegt direkt dem eigenen Cloud-Rahmenvertrag und DPA des Unternehmens.

JetBrains AI Enterprise (On-Premises und Private Cloud)

• Funktionsweise: Als Bestandteil der JetBrains IDE Services ermöglicht diese Lösung den Betrieb einer eigenen KI-Steuerungsebene im Unternehmensnetz oder der privaten VPC.
• Datenschutz: Unterstützt selbst gehostete Open-Weight-Modelle (über Ollama, vLLM oder LM Studio) sowie private Cloud-Endpunkte. Sämtliche Audit-Logs und Daten verbleiben vollständig innerhalb der Unternehmensgrenzen.

6. Architekturvergleich

Fazit und empfohlene Einführungsschritte

JetBrains AI Assistant kombiniert Transportverschlüsselung (TLS 1.2+), Metadatenbereinigung über EWR-Proxys, vertragliche Garantien für Zero Data Retention und Trainingsverbote, interne Vektorberechnung sowie lokale Dateiausschlüsse (.aiignore).

Empfohlene Schritte für Entwicklungsleiter:

1. Unternehmenseinstellungen prüfen: Im JetBrains Account sicherstellen, dass die „Detaillierte Erfassung codebezogener Daten“ unternehmensweit deaktiviert und gesperrt ist.
2. Ausschlussdateien standardisieren: Repositories mit sensiblen Algorithmen, Passwörtern oder Patenten mit .aiignore- oder .noai-Dateien versehen.
3. Audit-Logs stichprobenartig sichten: Während der Pilotphase ai-assistant-requests.md prüfen, um die Kontextgrenzen der übermittelten Daten zu verifizieren.
4. Passende Architektur wählen: Für reguläre Teams genügt die Standard-Cloud-Lizenz; für Hochsicherheitsbereiche empfiehlt sich Full Line Completion, BYOK oder JetBrains AI Enterprise.

Referenzen

• JetBrains AI Service Providers
• AI Assistant in JetBrains IDEs | IntelliJ IDEA Documentation
• JetBrains AI Terms of Service (AI Assistant, Junie)
• Product Data Collection and Usage Notice
• Frequently Asked Questions About Detailed Code-Related Data Collection
• JetBrains AI Enterprise: Securely leverage the power of AI and unleash developer productivity
• JetBrains Data Processing Addendum