Zurück zum Blog
KI7. September 2026·9 min Lesezeit

Bring Your Own LLM: Warum das Modell hinter Ihrer KI Ihre Entscheidung sein sollte

Fast jede App im Atlassian Marketplace bekommt gerade ein KI-Feature. Fast immer läuft es nach demselben Muster: Der Hersteller wählt das Modell, betreibt einen eigenen Server dazwischen und verrechnet die Nutzung im Preis. Für Unternehmen, die einem ISMS, der DSGVO, NIS2 oder DORA unterliegen, ist das ein Problem – denn sie haften für einen Datenfluss, den sie weder ausgesucht haben noch kontrollieren. Bring Your Own LLM dreht das Verhältnis um.

Was „Bring Your Own LLM“ konkret bedeutet

Bei einem BYO-LLM-Ansatz liefert die App die Oberfläche, die Werkzeuge und die Berechtigungslogik – aber nicht das Modell. Das Sprachmodell ist eine Konfiguration: eine Adresse, ein API-Schlüssel, eine Liste erlaubter Modellnamen. Das kann ein OpenAI-kompatibler Dienst sein (LiteLLM, OpenRouter, Groq, DeepSeek, Mistral), Azure OpenAI, Anthropic oder ein selbst gehostetes Open-Weight-Modell im eigenen Rechenzentrum. In anyLLM hinterlegt die Administration bis zu fünf solcher Verbindungen mit jeweils bis zu 20 Modellen; die Nutzerinnen und Nutzer wählen im Chat nur noch aus dieser Liste.

Der Unterschied zum üblichen Muster ist kein Detail. Er verändert, wer im Datenpfad steht, wer Vertragspartner ist und wer entscheidet, wenn sich der Modellmarkt – wie derzeit alle paar Monate – wieder verschiebt.

Vergleich zweier Datenpfade: Bei einer herstellerbetriebenen KI-App laufen Prompts von Atlassian über den Server des App-Herstellers zu einem vom Hersteller gewählten Modellanbieter. Bei Bring Your Own LLM gehen Prompts von der Atlassian-Infrastruktur direkt an den vom Kunden freigegebenen Endpunkt.
Abbildung 1: Ein Zwischenschritt weniger. Bei BYO-LLM steht kein Herstellerserver zwischen Atlassian und dem Modell – Prompts erreichen ausschließlich die Adresse, die Ihre Administration freigegeben hat.

Governance: Das Modell ist eine Entscheidung, keine Voreinstellung

Governance beginnt mit einer einfachen Frage: Wer hat das entschieden? Bei gebündelter KI lautet die Antwort „der Hersteller, irgendwann, in einem Release“. Bei BYO-LLM lautet sie „unsere Jira-Administration, an diesem Datum, für diese Adresse“. anyLLM erreicht keine einzige externe Adresse, die nicht ausdrücklich freigegeben wurde – auch die bekannten Anbieter nicht. Es gibt keine vorab erlaubte Liste; jede Adresse läuft über den Bestätigungsdialog von Atlassian, je Produkt getrennt für Jira und Confluence. Die Seite „Endpunkt-Freigaben“ ist damit gleichzeitig das vollständige, jederzeit prüfbare Verzeichnis aller Ziele, an die Daten fließen können.

Dieselbe Logik schützt vor Lock-in. Ein Anbieterwechsel ist keine Migration, sondern eine neue Verbindung: Adresse eintragen, Schlüssel hinterlegen, Modellnamen pflegen, freigeben. Weil die App im Manifest keinen Anbieter fest verdrahtet, braucht ein neuer Anbieter weder ein App-Update noch eine neue Zustimmungsrunde bei allen Nutzern. Und weil Nutzung pro Modell sichtbar ist und die Administration ein Limit pro Person und Stunde setzen kann, bleibt auch die Kostenseite steuerbar – mit dem Vertrag, den Sie ohnehin schon haben, sei es ein Azure-Rahmenvertrag oder ein EU-Anbieter mit Auftragsverarbeitungsvertrag.

Sicherheit: Weniger Beteiligte, kürzerer Weg

Jede zusätzliche Partei im Datenpfad ist eine zusätzliche Angriffsfläche und ein zusätzlicher Ort, an dem Schlüssel und Inhalte liegen können. BYO-LLM verkürzt den Weg auf zwei Stationen: die Atlassian-Infrastruktur, in der die App läuft, und den Endpunkt, den Sie gewählt haben. Die API-Schlüssel liegen verschlüsselt im Secret Store von Atlassian Forge, erreichen nie den Browser und tauchen nicht in Logs auf; selbst die Administration kann einen Schlüssel nur ersetzen oder löschen, nicht lesen.

Genauso wichtig ist, was die KI in Jira und Confluence darf. Sie liest und sucht ausschließlich mit den Rechten der angemeldeten Person – es gibt keinen Modus mit erhöhten Rechten, und die App fordert keine Admin-Scopes an. Schreibende Aktionen wie das Anlegen eines Vorgangs, eines Kommentars oder einer Seite kann die KI nur vorschlagen; ausgeführt wird erst nach einem Klick, mit den Rechten und im Namen der Person. Inhalte, die die KI aus Seiten oder Vorgängen liest, werden dem Modell als reine Daten übergeben, und externe Bilder werden nicht automatisch geladen – zwei Maßnahmen gegen Prompt Injection und stille Datenabflüsse. Die App selbst betreibt keinen von außen erreichbaren Endpunkt.

Ablauf einer Anfrage mit vier Kontrollpunkten: Rechteprüfung des Nutzers beim Lesen von Jira und Confluence, Endpunkt-Freigabe durch die Administration, API-Schlüssel aus dem Secret Store, und Bestätigung durch den Nutzer vor jeder schreibenden Aktion.
Abbildung 2: Vier Kontrollpunkte auf dem Weg einer Anfrage. Drei davon greifen, bevor ein Prompt die Atlassian-Infrastruktur verlässt; der vierte, bevor irgendetwas in Jira oder Confluence geschrieben wird.

Compliance: Verträge, die Sie tatsächlich unterschreiben können

Die DSGVO verlangt, dass Sie jeden Auftragsverarbeiter kennen, vertraglich binden und prüfen können (Art. 28). Bei gebündelter KI steckt der Modellanbieter als Unter-Auftragsverarbeiter in der Kette des App-Herstellers – Sie erfahren aus einer Liste, wer es ist, und haben keinen direkten Vertrag. Bei BYO-LLM ist der Modellanbieter Ihr eigener Auftragsverarbeiter: Sie haben den AV-Vertrag, Sie wählen die Region, Sie legen fest, ob Trainingsnutzung ausgeschlossen ist. Die Liste der Unter-Auftragsverarbeiter der App ist dann identisch mit Ihrer Konfiguration.

Für Datenresidenz gilt Ähnliches. Alles, was anyLLM speichert – Verläufe, Agenten, Einstellungen – liegt im Forge-Speicher und folgt damit der Datenresidenz Ihrer Atlassian-Site in einer von elf Regionen, darunter Deutschland und die EU. Was den Speicher verlässt, sind ausschließlich die Prompts an den Endpunkt Ihrer Wahl; ein selbst gehostetes Modell in Frankfurt hält also auch diesen Teil im Land. Geschlossene Atlassian-Konten werden wöchentlich automatisch bereinigt (Art. 17), temporäre Chats werden gar nicht gespeichert, und maplee betreibt keine Telemetrie.

Dieselbe Transparenz zahlt auf ISO 27001 ein, wo Annex A.5.19 bis A.5.23 verlangen, Lieferanten und Cloud-Dienste zu kennen und zu steuern, ebenso auf die Lieferketten-Anforderungen der NIS2 und das IKT-Drittparteienregister der DORA. In allen drei Fällen ist die Vorbedingung dieselbe: Sie müssen wissen, welche dritte Partei Ihre Daten verarbeitet. Mit BYO-LLM ist die Antwort Teil Ihrer eigenen Einstellungen statt einer Fußnote im Vertrag eines Dritten. Und wenn die EU-KI-Verordnung Transparenz und KI-Kompetenz einfordert, hilft es, benennen zu können, welches Modell wo läuft.

Vergleichsmatrix mit drei Spalten – herstellerbetriebene KI-App, in die Plattform gebündelte KI, Bring Your Own LLM – und sechs Zeilen: Wer wählt das Modell, wer wählt Anbieter und Region, wo liegen die Schlüssel, wer ist Vertragspartner des Modellanbieters, wer sieht die Liste erreichbarer Adressen, Modellwechsel ohne App-Update.
Abbildung 3: Was sich für Governance, Sicherheit und Compliance ändert. Bei BYO-LLM liegen alle sechs Entscheidungen beim Unternehmen selbst.

Die Vorteile im Arbeitsalltag

Kontrolle ist der eine Teil; der andere ist Flexibilität. Wer das Modell selbst wählt, kann es nach Aufgabe wählen: ein schnelles, günstiges Modell für Zusammenfassungen und Formulierungshilfe, ein Reasoning-Modell für Analysen, ein Open-Weight-Modell im eigenen Haus für ein Projekt mit besonders sensiblen Daten. Bestehende Verträge und Kontingente – etwa ein Azure-Enterprise-Agreement – lassen sich weiternutzen, statt dieselbe Leistung ein zweites Mal über den App-Preis zu bezahlen. Und wenn nächsten Monat ein besseres Modell erscheint, ist es ein Eintrag in der Modellliste, kein neues Produkt.

Eine stabile App-Ebene mit Berechtigungen, Freigaben und Verlauf, in die austauschbare Modellverbindungen eingesteckt werden: ein EU-Cloud-Anbieter, Azure OpenAI und ein selbst gehostetes Modell. Der Wechsel ist eine Konfigurationsänderung, kein App-Update.
Abbildung 4: Das Modell wechseln, nicht die App. Berechtigungen, Freigaben und Verläufe bleiben; die Verbindung ist austauschbar.

Ehrliche Grenzen

BYO-LLM bedeutet per Definition, dass Prompts die Atlassian-Infrastruktur verlassen – zu Ihrem Endpunkt, aber sie verlassen sie. Das Atlassian-Siegel „Runs on Atlassian“ ist für einen solchen Ansatz deshalb nicht erreichbar, und wir sagen das lieber offen, als es zu umschreiben. Die Verantwortung für den Vertrag mit dem Modellanbieter liegt bei Ihnen, und Sie brauchen jemanden, der Adressen, Schlüssel und Modelllisten pflegt. Das ist der Preis der Kontrolle: Wer entscheidet, ist auch zuständig. Für Organisationen, die ohnehin ein ISMS betreiben, ist das keine neue Pflicht, sondern die Fortsetzung dessen, was sie bei jedem anderen Dienstleister längst tun.

So setzt anyLLM das um

anyLLM ist eine Forge-App von maplee: eine Installation für Jira und Confluence derselben Site, mit Chat, Agenten, Prompt-Vorlagen und Gedächtnis, erreichbar aus der Vollbild-Seite, der Confluence-Byline, dem Kontextmenü, den Vorgangsaktionen in Jira und einem Dashboard-Gadget – zweisprachig Deutsch und Englisch. Nach unserer Kenntnis ist sie die erste App im Atlassian Marketplace, die einen vollständigen Assistenten für beide Produkte mit BYO-LLM verbindet und dabei keine einzige externe Adresse vorab freigibt. Die vollständige Sicherheitsbeschreibung, der Datenfluss und das Handbuch sind öffentlich auf maplee.de dokumentiert.

anyLLM ist im Atlassian Marketplace verfügbar. Probieren Sie es mit Ihrem eigenen Modell aus – oder sprechen Sie mit uns über Ihren Anwendungsfall.

Zum Atlassian Marketplace →