Während viele Wettbewerber ihre KI-Funktionen ausschließlich aus der Cloud des Anbieters ausliefern, hat Tabnine früh auf ein anderes Betriebsmodell gesetzt. Der Assistent kann als Software-as-a-Service genutzt, in einer privaten Cloud des Kunden betrieben, im eigenen Rechenzentrum installiert oder vollständig vom Internet getrennt eingesetzt werden. Für Organisationen, deren Quellcode ein Betriebsgeheimnis darstellt, die unter Exportkontroll- oder Geheimschutzauflagen arbeiten oder die schlicht keine Lust auf Grundsatzdiskussionen mit ihrer Datenschutzbeauftragten haben, ist das ein gewichtiges Argument.
Drei Eigenschaften prägen Tabnine:
Tabnine begann als Werkzeug für intelligente Code-Vervollständigung, damals noch auf Basis kleinerer, spezialisierter Modelle, die direkt auf dem Rechner der Entwicklerinnen und Entwickler laufen konnten. Mit dem Siegeszug großer Sprachmodelle hat das Unternehmen sein Angebot schrittweise ausgebaut: um einen Chat, um projektweiten Kontext, um die Anbindung leistungsfähiger Drittmodelle und schließlich um Agenten, die definierte Aufgaben wie Code-Review oder Testgenerierung übernehmen. Die frühe Erfahrung mit lokal laufenden Modellen erklärt, warum Tabnine heute Self-Hosting so selbstverständlich beherrscht – das Thema ist Teil der Firmen-DNA.
Diese Geschichte hat auch eine Kehrseite, die man fair benennen sollte: Tabnine wird in Fachkreisen manchmal noch mit dem Bild des reinen Autocomplete-Werkzeugs verbunden. Wer das Produkt zuletzt vor einigen Jahren gesehen hat, unterschätzt womöglich, wie weit es sich inzwischen entwickelt hat. Umgekehrt gilt: Im Wettlauf um agentische Funktionen sind andere Anbieter teils schneller und lauter unterwegs. Für eine sachliche Bewertung lohnt daher immer ein Blick auf den aktuellen Stand statt auf Erinnerungen oder Marketingvergleiche.
Tabnine passt besonders gut zu Organisationen, in denen Quellcode einen hohen Schutzbedarf hat: Maschinen- und Anlagenbauer mit eingebetteter Software, Zulieferer mit vertraglichen Geheimhaltungspflichten gegenüber ihren Kunden, Softwarehäuser mit Branchenlösungen, Banken, Versicherungen, Gesundheitswesen, Energieversorger und öffentliche Auftraggeber. Ebenso interessant ist es für Unternehmen, die in heterogenen Entwicklungsumgebungen arbeiten – etwa Java in Eclipse, C# in Visual Studio und Webentwicklung in VS Code nebeneinander – und eine einheitliche KI-Lösung über alle Teams wünschen.
Weniger zwingend ist Tabnine für kleine Teams ohne besondere Vertraulichkeitsanforderungen, die einfach den funktional stärksten Cloud-Assistenten suchen, oder für Organisationen, die bereits vollständig in einer Plattform wie GitHub oder GitLab verankert sind und deren integrierte KI-Angebote ausreichend finden. Auch Teams, die gezielt mit stark autonomen Terminal-Agenten experimentieren wollen, werden eher bei spezialisierten Werkzeugen fündig. Die Kapitel 06 und 08 vertiefen diese Abgrenzung.
Grob lassen sich drei Ebenen unterscheiden, deren genaue Bezeichnungen und Zuschnitte sich ändern können. Die aktuellen Editionen, Funktionsumfänge und Konditionen sollten immer direkt beim Anbieter geprüft werden – gerade im Bereich der KI-Assistenten wandeln sich Pakete und Preise schnell.
Im Markt der KI-Coding-Assistenten lassen sich grob drei Lager unterscheiden. Erstens die Plattform-Assistenten, die eng an ein Ökosystem gebunden sind, etwa an GitHub, GitLab, Google Cloud oder Amazon Web Services. Zweitens die KI-first-Editoren und Agenten-Werkzeuge, die mit möglichst viel Autonomie und neuen Bedienkonzepten werben. Drittens die Anbieter, die Kontrolle, Betriebsflexibilität und Compliance in den Mittelpunkt stellen. Tabnine gehört klar ins dritte Lager und ist dort einer der bekanntesten kommerziellen Namen, neben offenen Selbstbau-Lösungen wie Tabby oder Continue.
Diese Positionierung prägt das gesamte Produkt. Viele Funktionen, die bei anderen Anbietern selbstverständlich in der Anbieter-Cloud laufen, sind bei Tabnine so gebaut, dass sie auch in einer isolierten Umgebung funktionieren. Das hat Konsequenzen: Neue Funktionen kommen manchmal etwas später in der Self-Hosted-Variante an als in der Cloud, und der Betrieb im eigenen Rechenzentrum erfordert Ressourcen und Know-how. Dafür erhält man ein Werkzeug, dessen Datenflüsse man selbst kontrollieren kann.
Ein Positionierungsmerkmal, das Tabnine seit Jahren betont, ist der sorgfältige Umgang mit der Herkunft von Trainingsdaten. Der Anbieter hat eigene Modelle angeboten, die nach eigenen Angaben ausschließlich auf Code mit permissiven Open-Source-Lizenzen trainiert wurden, um das Risiko zu verringern, dass Vorschläge urheberrechtlich problematische Fragmente enthalten. Ergänzend gibt es Funktionen, die erzeugten Code auf Ähnlichkeiten mit bekannten öffentlichen Quellen prüfen und Lizenzhinweise anzeigen können. Wie diese Mechanismen im Detail funktionieren und welche Garantien vertraglich zugesichert werden, sollte im Einzelfall beim Anbieter erfragt werden; Kapitel 09 geht auf die IP-Frage genauer ein.
Die Code-Vervollständigung ist unspektakulär im besten Sinne. Sie greift bei wiederkehrenden Mustern, beim Anlegen von Datenklassen, beim Schreiben von Schleifen, Mappings und Standardprüfungen, beim Ergänzen von Parametern und beim Fortführen eines erkennbaren Stils. Weil sie unaufdringlich arbeitet, wird sie in vielen Teams schnell zur Selbstverständlichkeit. Wie bei allen Assistenten gilt: Ein Vorschlag ist ein Entwurf, kein geprüftes Ergebnis.
Der Chat ergänzt die Vervollständigung um das Verstehen. Er ist besonders wertvoll bei der Einarbeitung in fremden oder alten Code, bei der Fehlersuche und beim Abwägen von Lösungsvarianten. Praktisch wichtig ist, dass der Chat sich auf den Projektkontext beziehen kann, statt nur generische Antworten zu liefern. Je besser Teams lernen, relevante Dateien und Fragestellungen präzise zu benennen, desto brauchbarer werden die Antworten. Die Qualität hängt zudem stark vom gewählten Modell ab – ein Punkt, der bei Tabnine durch die freie Modellwahl besonderes Gewicht bekommt.
Ein KI-Assistent ist nur so gut wie der Kontext, den er bekommt. Tabnine adressiert das mit einem mehrstufigen Ansatz: lokaler Kontext aus Editor und Arbeitsbereich, projektweiter Kontext über eine Indexierung des Repositories und – in Enterprise-Szenarien – organisationsweiter Kontext aus weiteren angebundenen Quellen. Der Anbieter beschreibt dies als eine Art Kontext-Engine, die interne Strukturen, Abhängigkeiten und Konventionen erfasst. Für Unternehmen mit eigenen Frameworks, gewachsenen Bibliotheken und eigenen Namenskonventionen ist das ein erheblicher Unterschied zu einem Assistenten, der nur allgemeines Wissen aus öffentlichem Code mitbringt.
Zusätzlich lassen sich in Tabnine Vorgaben hinterlegen, die das Verhalten steuern: bevorzugte Bibliotheken, Coding-Standards, Formatierungsregeln oder Hinweise zu Architekturprinzipien. In größeren Organisationen ist das ein wichtiger Hebel, um Konsistenz herzustellen, statt dass jede Entwicklerin individuelle Prompts pflegt. Wie fein solche Regeln zentral verwaltet werden können, unterscheidet sich je nach Edition.
Tabnine ist kein Allheilmittel. Die Qualität der Vorschläge schwankt je nach Programmiersprache, Framework und gewähltem Modell; in seltener genutzten Sprachen oder in sehr domänenspezifischem Code sind die Ergebnisse naturgemäß schwächer. Wer ausschließlich kleinere, lokal betriebene Modelle nutzt, um maximale Datenhoheit zu erreichen, muss mit einer geringeren Leistungsfähigkeit rechnen als bei den großen kommerziellen Modellen – ein Zielkonflikt, den man bewusst entscheiden sollte. Und schließlich ersetzt kein Kontextmechanismus das menschliche Verständnis der Fachlichkeit: Ob ein Vorschlag die Geschäftsregel korrekt abbildet, kann nur jemand beurteilen, der sie kennt.
Diese Herangehensweise passt zur Positionierung. In regulierten Umgebungen ist ein Agent, der eine definierte Aufgabe mit nachvollziehbarem Ergebnis erledigt, leichter zu verantworten als ein Generalist, der Terminal-Befehle ausführt und eigenständig Dateien quer durch das Projekt umbaut. Welche Agenten aktuell verfügbar sind, wie weit ihre Autonomie reicht und in welchen Editionen sie enthalten sind, entwickelt sich laufend weiter und sollte beim Anbieter geprüft werden.
Für viele mittelständische Teams ist der Review-Agent der interessanteste Einstieg in agentische Funktionen. Code-Reviews sind notwendig, aber zeitintensiv, und sie leiden in kleinen Teams oft darunter, dass immer dieselben erfahrenen Personen alles prüfen müssen. Ein Agent, der Änderungen vorab auf Verstöße gegen Coding-Standards, potenzielle Fehler, unsichere Muster oder fehlende Tests prüft, kann diese Personen spürbar entlasten. Besonders wertvoll ist die Möglichkeit, eigene Regeln zu hinterlegen, sodass der Agent nicht nur allgemeine Best Practices, sondern die Hausregeln des Unternehmens anwendet.
Entscheidend ist die Rollenverteilung: Der Agent liefert Hinweise, der Mensch entscheidet. Ein automatisches Review, das als Freigabe missverstanden wird, ist gefährlicher als gar keines. In unseren Projekten bewährt sich, den Review-Agenten als ersten Filter zu verstehen, der Routineanmerkungen übernimmt, damit sich menschliche Reviewer auf Architektur, Fachlogik und Sicherheit konzentrieren können.
Testgenerierung und Dokumentation gehören zu den Aufgaben, die in vielen Projekten liegen bleiben. Genau hier können Agenten einen überdurchschnittlichen Nutzen stiften, weil sie die Einstiegshürde senken: Ein erster Satz an Unit-Tests oder eine Grundstruktur für die Dokumentation ist schnell erzeugt und muss dann nur noch geprüft und verfeinert werden. Gerade bei Legacy-Code, der ohne Tests gewachsen ist, kann das helfen, ein Sicherheitsnetz für spätere Modernisierungen aufzuspannen.
Die typische Falle: Generierte Tests, die zwar grün sind, aber wenig prüfen, etwa weil sie nur das aktuelle Verhalten fixieren statt das gewünschte. Teams sollten deshalb klare Kriterien für gute Tests festlegen und KI-generierte Tests im Review genauso kritisch betrachten wie handgeschriebene.
Je mehr ein Agent eigenständig tun darf, desto wichtiger werden Leitplanken. Dazu gehören eingeschränkte Berechtigungen auf Repositories und Systeme, der Ausschluss sensibler Verzeichnisse, Protokollierung der Agenten-Aktivitäten und ein verbindlicher menschlicher Freigabeschritt vor dem Merge. Der Vorteil von Tabnine in diesem Punkt ist, dass sich diese Kontrollen in einer selbst betriebenen Umgebung vollständig in die eigene Sicherheitsarchitektur einbetten lassen. Der Nachteil: Die Verantwortung für die richtige Konfiguration liegt dann auch vollständig beim eigenen Team.
Tabnine bietet Erweiterungen für die verbreitetsten IDEs an, insbesondere Visual Studio Code, die JetBrains-Familie mit IntelliJ IDEA, PyCharm, WebStorm, Rider und weiteren, außerdem Eclipse und Visual Studio. Gerade die Unterstützung von Eclipse und Visual Studio ist für den Mittelstand relevant: In vielen Industrie- und Fertigungsunternehmen laufen gewachsene Java- und .NET-Anwendungen, die nicht ohne Weiteres in einen neuen Editor wandern. Welche Editoren und Versionen aktuell unterstützt werden und ob alle Funktionen in allen Umgebungen gleich verfügbar sind, sollte vor der Einführung geprüft werden – nicht selten erscheinen neue Funktionen zuerst in VS Code und JetBrains.
Für die Programmiersprachen gilt: Die gängigen Sprachen wie Java, C#, Python, JavaScript und TypeScript, Go, C und C++, PHP, Kotlin oder SQL werden breit abgedeckt. Bei Nischensprachen, Steuerungscode oder proprietären Skriptsprachen hängt die Qualität stark vom gewählten Modell und vom verfügbaren Projektkontext ab. Ein Pilot mit echtem Code ist hier aussagekräftiger als jede Liste.
Damit Tabnine organisationsweiten Kontext nutzen und Agenten wie den Code-Review-Agenten einsetzen kann, wird der Assistent mit den Repositories des Unternehmens verbunden. Unterstützt werden die verbreiteten Plattformen wie GitHub, GitLab und Bitbucket, jeweils in Cloud- und – je nach Konstellation – Self-Managed-Varianten. Für Unternehmen, die ihre Git-Server selbst betreiben, ist das ein wesentlicher Punkt: Ein selbst gehosteter Tabnine kann mit einem selbst gehosteten GitLab oder Bitbucket kommunizieren, ohne dass Code die eigene Infrastruktur verlässt. Welche Kombinationen offiziell unterstützt werden, bitte beim Anbieter prüfen.
Über die Code-Plattformen hinaus sind Anbindungen an Ticket- und Wissenssysteme interessant, etwa Jira oder Confluence. Sie erlauben es, Anforderungen und Dokumentation als Kontext einzubeziehen. Hier lohnt ein genauer Blick auf Berechtigungen: Der Assistent sollte nur auf Informationen zugreifen, die die jeweilige Person auch selbst sehen darf.
Im Enterprise-Umfeld spielt die Einbindung in vorhandene Verwaltungsstrukturen eine große Rolle. Tabnine unterstützt Single Sign-on über gängige Identitätsanbieter, eine zentrale Verwaltung von Nutzern und Lizenzen sowie Auswertungen zur Nutzung. Für die Integration in Build- und Deployment-Prozesse ist vor allem der Review-Agent relevant, der sich in den Ablauf von Pull- oder Merge-Requests einklinkt. Eine vollwertige Ausführung in CI-Pipelines im Sinne eines eigenständigen Agenten, der Builds repariert, ist dagegen nicht der Schwerpunkt des Produkts. Teams, die genau das suchen, sollten ergänzende Werkzeuge in Betracht ziehen.
Für Administratoren interessant sind außerdem Protokollierung und Nachvollziehbarkeit: Wer hat wann welche Funktion genutzt, welche Modelle wurden verwendet, welche Richtlinien greifen? Solche Informationen sind nicht nur für die IT-Sicherheit wichtig, sondern auch für die Dokumentationspflichten, die sich aus Datenschutz und künftig aus dem europäischen KI-Recht ergeben können.
Tabnine spielt seine Stärken aus, wenn drei Bedingungen zusammenkommen: Der Code hat einen hohen Schutzbedarf, man möchte trotzdem nicht auf einen professionell gepflegten, kommerziellen Assistenten mit Herstellersupport verzichten, und die Entwicklungsumgebungen im Haus sind heterogen. In dieser Konstellation ist Tabnine häufig die pragmatischste Lösung – deutlich weniger Eigenaufwand als ein selbst zusammengebauter Open-Source-Stack, aber deutlich mehr Kontrolle als ein reiner Cloud-Dienst.
Auch für Unternehmen, die sich nicht an einen einzigen Modellanbieter binden wollen, ist Tabnine interessant. Die Möglichkeit, je nach Projekt und Schutzbedarf unterschiedliche Modelle zu nutzen – etwa ein leistungsstarkes kommerzielles Modell für unkritische Projekte und ein selbst gehostetes offenes Modell für besonders sensible Bereiche –, ist ein strategischer Vorteil in einem Markt, in dem sich die Spitzenmodelle ständig abwechseln.
GitHub Copilot ist oft die naheliegendere Wahl, wenn ein Team bereits vollständig auf GitHub arbeitet, keine besonderen Anforderungen an den Speicherort des Codes hat und die größtmögliche Funktionsbreite in der Cloud sucht. Tabby oder Continue in Kombination mit offenen Modellen sind attraktiv für Teams mit starkem Infrastruktur-Know-how, die auf Lizenzkosten verzichten und alles selbst kontrollieren wollen – und bereit sind, den Betrieb dauerhaft zu stemmen. Ein europäisches Modell wie Codestral kann dort punkten, wo die Herkunft des Anbieters aus der EU ein ausdrückliches Kriterium ist; es lässt sich übrigens je nach Lizenz und Konfiguration auch als Modell hinter verschiedenen Frontends betreiben.
Wer schließlich maximale agentische Autonomie sucht, etwa terminalbasierte Agenten, die große Umbauten selbstständig planen und ausführen, wird bei spezialisierten Agenten-Werkzeugen mehr finden. Die Entscheidung ist daher weniger eine Frage nach dem besten Werkzeug als nach dem passenden Werkzeug für die eigene Risikolage und Arbeitsweise.
Wer Tabnine selbst betreibt, betreibt in der Regel auch die zugehörigen Sprachmodelle selbst – oder bindet ein Modell an, das in der eigenen Umgebung läuft. Damit wird die Frage nach geeigneter Hardware zentral. Leistungsfähige Modelle benötigen GPU-Kapazitäten, die nicht nur angeschafft, sondern auch betrieben, überwacht und aktualisiert werden müssen. Die konkreten Hardware-Anforderungen hängen von Modellgröße, Nutzerzahl und gewünschter Antwortgeschwindigkeit ab und sollten mit dem Anbieter anhand eines realistischen Mengengerüsts geklärt werden. Für viele Mittelständler ist eine private Cloud mit GPU-Instanzen bei einem europäischen Anbieter ein guter Kompromiss zwischen Kontrolle und Aufwand.
Zum laufenden Betrieb gehören Updates der Tabnine-Plattform, das Einspielen neuer Modellversionen, Monitoring, Backup der Konfiguration, Zugriffssteuerung und Kapazitätsplanung. Diese Aufgaben sollten von Beginn an einem verantwortlichen Team zugeordnet werden. Unterschätzter Aufwand ist der häufigste Grund, warum Self-Hosting-Projekte für KI-Werkzeuge ins Stocken geraten.
Unabhängig vom Betriebsmodell empfehlen wir einen strukturierten Pilot. Er beginnt mit einer klaren Zieldefinition: Welche Aufgaben sollen schneller oder besser werden, und woran wollen wir das messen? Anschließend wird eine überschaubare Gruppe aus verschiedenen Teams und Technologien ausgewählt, die Tabnine einige Wochen unter realen Bedingungen nutzt. Parallel werden Datenschutz- und Sicherheitsfragen geklärt, damit ein positiver Pilot nicht an fehlenden Freigaben scheitert.
Bewährt hat sich, im Pilot bewusst mit dem Betriebsmodell zu beginnen, das man später auch produktiv nutzen will. Wer im Pilot die Cloud-Variante mit einem Spitzenmodell testet, später aber on-premises mit einem kleineren offenen Modell arbeiten muss, erlebt sonst eine Enttäuschung. Die Ergebnisse des Pilots fließen in eine interne Richtlinie, ein Schulungskonzept und die Entscheidung über den breiten Rollout.
In Maschinenbau, Automatisierungstechnik und Automobilzulieferung ist Software längst ein zentraler Wertschöpfungsfaktor. Gleichzeitig ist der Quellcode häufig vertraglich geschützt, weil er Know-how des Kunden enthält oder in sicherheitskritischen Produkten läuft. In solchen Umgebungen scheitert die Einführung von Cloud-Assistenten nicht selten an der Frage, ob Code die eigene Infrastruktur verlassen darf. Ein selbst betriebener Tabnine kann diese Blockade lösen, weil sich die Verarbeitung vollständig im eigenen Netz halten lässt. Für Teams, die in C und C++, Java oder C# entwickeln und dabei mit Eclipse-basierten Werkzeugketten oder Visual Studio arbeiten, ist zudem die breite IDE-Unterstützung ein praktischer Vorteil.
Wichtig ist, die Erwartungen realistisch zu halten: Bei sehr hardwarenahem Code, proprietären Steuerungssprachen oder sicherheitszertifizierter Software sind KI-Vorschläge mit besonderer Sorgfalt zu prüfen, und für zertifizierungsrelevante Prozesse sollte geklärt werden, wie KI-Unterstützung in die Nachweisführung passt.
Mittelständische Softwarehäuser und Agenturen entwickeln häufig für mehrere Kunden gleichzeitig, jeweils mit eigenen Geheimhaltungsvereinbarungen. Hier ist die Möglichkeit, Richtlinien und Kontexte pro Projekt sauber zu trennen, ebenso wichtig wie eine belastbare Zusage, dass Code nicht gespeichert oder zum Training genutzt wird. Ein Argument, das in Kundengesprächen zunehmend zählt: Wer nachweisen kann, dass der eingesetzte KI-Assistent im eigenen Rechenzentrum oder in einer kontrollierten europäischen Cloud läuft, beantwortet die Datenschutzfragen seiner Auftraggeber deutlich leichter.
Interne IT-Abteilungen mittelständischer Unternehmen, die Eigenentwicklungen rund um ERP-Systeme, Schnittstellen und Fachanwendungen pflegen, profitieren vor allem bei der Einarbeitung in alten Code, bei Dokumentation und Tests. Gerade hier, wo oft wenige Personen viel Wissen tragen, kann ein Assistent mit Unternehmenskontext helfen, Wissen zugänglicher zu machen.
In unseren Projekten zeigen sich immer wieder dieselben Erfolgsfaktoren. Erstens eine klare Verantwortung: Jemand muss das Thema fachlich und technisch führen, von der Modellauswahl bis zur Richtlinie. Zweitens ein ehrlicher Blick auf den Betriebsaufwand, insbesondere bei On-Premises-Varianten. Drittens Schulung, die über Tastenkürzel hinausgeht und vermittelt, wie man gute Fragen stellt, Kontext steuert und Vorschläge kritisch prüft. Viertens eine gelebte Review-Kultur, in der KI-generierter Code genauso gründlich geprüft wird wie jeder andere. Und fünftens Messung: Durchlaufzeiten, Zufriedenheit der Teams und Qualitätsindikatoren nach dem Merge sagen mehr über den Nutzen als die Zahl angenommener Vorschläge.
Tabnine wird in der Regel pro Nutzerin und Nutzer und Zeitraum lizenziert, mit unterschiedlichen Stufen je nach Edition. Konkrete Preise nennen wir bewusst nicht, weil sie sich häufig ändern und im Enterprise-Umfeld meist individuell verhandelt werden – bitte aktuell beim Anbieter prüfen. Für eine realistische Kalkulation sind neben den Lizenzen weitere Positionen zu berücksichtigen: Bei Self-Hosting die Hardware oder Cloud-Instanzen mit GPU, der Betriebsaufwand für Plattform und Modelle, gegebenenfalls Kosten für Drittmodelle, die über eigene Zugänge angebunden werden, sowie Aufwände für Einführung, Schulung und Governance.
Im Vergleich zu reinen Cloud-Assistenten sind die Gesamtkosten einer On-Premises-Lösung typischerweise höher. Dem steht gegenüber, dass sich KI-Unterstützung in vielen Umgebungen überhaupt erst mit Self-Hosting einführen lässt. Die richtige Vergleichsgröße ist daher oft nicht der günstigste Cloud-Assistent, sondern die Alternative ohne KI-Unterstützung oder ein selbst gebauter Open-Source-Stack mit entsprechendem Personalaufwand.
Für die DSGVO-Bewertung ist zunächst relevant, dass Quellcode personenbezogene Daten enthalten kann – etwa Namen in Kommentaren, Commit-Informationen, Testdaten oder Konfigurationen. Sobald Code-Kontext an einen externen Dienst übertragen wird, liegt in aller Regel eine Auftragsverarbeitung vor, für die ein Vertrag nach Art. 28 DSGVO erforderlich ist. Bei Tabnine kommt eine Besonderheit hinzu: Das Unternehmen hat seine Wurzeln in Israel, und für Israel hat die Europäische Kommission einen Angemessenheitsbeschluss erlassen, der im Rahmen späterer Überprüfungen bestätigt wurde. Übermittlungen nach Israel sind damit grundsätzlich ohne zusätzliche Standardvertragsklauseln möglich. Prüfhinweis: Vertragspartner, tatsächliche Verarbeitungsorte und der aktuelle Stand des Angemessenheitsbeschlusses sollten im Einzelfall verifiziert werden.
Die Angemessenheit für Israel löst allerdings nicht alle Fragen. Wird Tabnine als SaaS genutzt, können Infrastrukturanbieter und Rechenzentren in anderen Ländern beteiligt sein, etwa US-amerikanische Hyperscaler. Werden zusätzlich kommerzielle Drittmodelle angebunden, verarbeiten deren Anbieter den übermittelten Kontext – häufig mit Sitz in den USA. Für solche Übermittlungen ist zu prüfen, ob die Anbieter unter dem EU-US Data Privacy Framework zertifiziert sind oder andere Garantien greifen. Die DSGVO-freundlichste Option ist der Betrieb in einer selbst kontrollierten Umgebung in der EU mit selbst gehosteten Modellen, denn dann verlässt der Code das Unternehmen gar nicht erst.
Neben dem Datenschutz im engeren Sinne geht es um den Schutz von Betriebsgeheimnissen. Hier sind drei Fragen zentral: Wird Code beim Anbieter gespeichert, und wenn ja, wie lange? Wird er zum Training verwendet? Und wer hat Zugriff? Tabnine beantwortet die ersten beiden Fragen mit einem Zero-Data-Retention-Ansatz und dem Ausschluss von Kundencode aus dem Training allgemeiner Modelle. Diese Zusagen sind wertvoll, sollten aber für die gewählte Edition und alle angebundenen Modelle schriftlich vorliegen. Ergänzend empfehlen wir, sensible Verzeichnisse, Zugangsdaten und Konfigurationsdateien vom Kontext auszuschließen und Secrets grundsätzlich nicht im Code zu halten.
Beim geistigen Eigentum geht es um die umgekehrte Richtung: Können Vorschläge fremden, lizenzrechtlich geschützten Code enthalten? Tabnine adressiert das mit Modellen, die nach Anbieterangaben auf permissiv lizenziertem Code trainiert wurden, sowie mit Funktionen zur Herkunfts- und Lizenzprüfung von Vorschlägen. Ob und in welchem Umfang der Anbieter darüber hinaus vertragliche Freistellungen gewährt, ist im Einzelfall zu klären. Unabhängig davon bleibt die eigene Verantwortung: Eine Richtlinie zum Umgang mit KI-generiertem Code und ein Review-Prozess, der auch Lizenzfragen im Blick hat, gehören zu jeder professionellen Einführung.
Zur sauberen Einführung gehört die Aufnahme der Verarbeitung in das Verzeichnis von Verarbeitungstätigkeiten, die Prüfung, ob eine Datenschutz-Folgenabschätzung erforderlich ist, eine interne KI-Richtlinie für Entwicklerinnen und Entwickler sowie die Einbindung von Betriebsrat und Informationssicherheit, wo dies vorgesehen ist. Mit der europäischen KI-Verordnung kommen zusätzliche Anforderungen an Transparenz und Kompetenz hinzu, etwa die Pflicht, für ausreichende KI-Kompetenz der Beschäftigten zu sorgen. Coding-Assistenten sind dabei in der Regel keine Hochrisiko-Systeme, die Pflichten zur Schulung und Dokumentation gelten jedoch auch für sie.
