JiCoSchwärzen. Freigeben. Belegen.
Lokal zuerst, Cloud als Option
Das Modell ist austauschbar. Womit JiCo ohne jedes Zutun startet, ist es nicht zufällig.
Hintergrund · 2026-09-19 · 4 Min.
Eine Vorgabe ist das, was passiert, wenn niemand eine Entscheidung trifft
Es gibt einen Unterschied zwischen einer Möglichkeit und einer Vorgabe, der in Produktbeschreibungen gerne verwischt wird, aber in der Praxis alles entscheidet: Eine Möglichkeit ist etwas, das man aktiv wählen kann. Eine Vorgabe ist das, was passiert, wenn niemand etwas wählt — der Zustand, in dem das System aus der Kiste kommt, bevor irgendjemand eine einzige Einstellung angefasst hat.
JiCo startet mit einem lokalen Modell über Ollama, das direkt auf der eigenen Maschine läuft. Wer stattdessen die Claude-API einsetzen möchte, kann das — aber ausdrücklich als bewusst freizuschaltendes Opt-in, nicht als zweite, gleichberechtigte Vorgabe, zwischen der man beim Onboarding beiläufig wählt. Der Unterschied klingt nach einer Kleinigkeit in der Formulierung. Er ist es nicht: Er entscheidet darüber, was am ersten Tag passiert, wenn eine IT-Abteilung das Werkzeug installiert und dann erst einmal andere Prioritäten hat, als jede einzelne Einstellung durchzugehen. Bei JiCo bedeutet das konkret: kein Abfluss von Daten an einen Cloud-Anbieter, es sei denn, jemand hat diesen Schritt aktiv und bewusst freigeschaltet.
Warum eine starre Regel ohne Ausweg trotzdem die falsche Antwort wäre
Man könnte an dieser Stelle argumentieren, dass die konsequenteste Lösung eine feste, unveränderliche Regel wäre: immer lokal, keine Ausnahme, keine Diskussion. Diese Haltung wäre einfacher zu kommunizieren und würde sich in jeder Marketingpräsentation gut machen. Sie wäre für einige reale Aufgaben aber schlicht zu schwach.
Ein lokales Modell auf gewöhnlicher Bürohardware ist nicht in jeder Hinsicht so leistungsfähig wie ein aktuelles Cloud-Modell — bei komplexeren Zusammenfassungen, bei mehrsprachigen Tickets, bei Aufgaben, die viel Kontext gleichzeitig im Blick behalten müssen, macht sich das bemerkbar. Und manche Unternehmen haben bereits eine geprüfte, vertraglich abgesicherte Cloud-Anbindung, die sie ohnehin nutzen wollen und für die die interne Freigabe längst vorliegt. Eine starre Vorgabe ohne Ausweg würde JiCo in genau diesen Fällen unbrauchbar machen — an der Stelle, an der es eigentlich die Entscheidung an die richtige Person weitergeben sollte, nämlich diejenige, die das Risiko am Ende tatsächlich verantwortet.
Was in beiden Fällen technisch unverändert bleibt
Ganz gleich, welches Modell im Einsatz ist — ob lokal auf der eigenen Maschine oder als geprüfte Cloud-Option — läuft die Schwärzung personenbezogener Daten in beiden Fällen davor, nicht danach. Das Modell sieht in beiden Konstellationen ausschliesslich den Platzhalter, niemals den Klartext dahinter. Der Unterschied zwischen den beiden Wegen liegt nicht darin, was geschwärzt wird oder wie gründlich — das bleibt identisch. Er liegt ausschliesslich darin, wohin der bereits geschwärzte, bereinigte Text am Ende geschickt wird: auf dieselbe Maschine, auf der auch die Jira-Daten liegen, oder über das offene Internet zu einem Rechenzentrum eines Drittanbieters.
Diese Konsistenz ist kein Zufall, sondern eine bewusste Architekturentscheidung: Die Schwärzung sitzt strukturell vor der Frage, welches Modell überhaupt zum Einsatz kommt, nicht danach als nachträgliche Anpassung an den jeweiligen Modellweg.
Eine Zwischenstufe, die leicht übersehen wird
Zwischen „ganz lokal" und „vollständig in der Cloud" gibt es eine Zwischenstufe, die bei einer oberflächlichen Betrachtung leicht durchrutscht: Manche lokal betreibbaren Modelle bieten inzwischen selbst eine Cloud-Variante an, die unter demselben vertrauten Namen läuft, ihre eigentliche Berechnung aber auf der Infrastruktur des Modell-Anbieters durchführt statt auf der eigenen Maschine. Wer nur auf den Modellnamen schaut, könnte leicht annehmen, weiterhin „lokal" zu arbeiten, obwohl die Anfrage in Wirklichkeit längst das Haus verlassen hat.
Diese Unterscheidung wird deshalb nicht dem Zufall überlassen: Eine als Cloud-Variante gekennzeichnete Ausführung desselben Modells gilt technisch als entferntes Modell, mit denselben Konsequenzen wie jeder andere externe Modellweg — sie fällt unter dieselbe Opt-in-Pflicht und dieselbe Protokollierung, unabhängig davon, wie vertraut oder „lokal" der Name klingen mag.
Warum diese Wahl im Nachhinein nachvollziehbar bleiben muss
Ein Umschalten zwischen den Modellwegen, das niemand nachträglich nachvollziehen kann, wäre am Ende so gut wie gar keine Kontrolle — es wäre eine einmalige Entscheidung, die irgendwann in einer Konfigurationsdatei verschwindet und von der später niemand mehr sicher sagen kann, wann sie eigentlich getroffen wurde. Deshalb steht das tatsächlich verwendete Modell in jedem einzelnen Audit-Eintrag, nicht nur als globale, versteckte Einstellung irgendwo im System.
Das ist kein zusätzliches Feature, das man auch weglassen könnte, ohne dass etwas Wesentliches fehlt. Es ist der eigentliche Grund, warum das Umschalten überhaupt vertretbar ist: Eine Entscheidung, für einen bestimmten Auftrag ein Cloud-Modell statt eines lokalen zu verwenden, lässt sich im Nachhinein für genau diesen einen Auftrag nachvollziehen — nicht nur als vage globale Einstellung, an die sich sechs Monate später niemand mehr im Detail erinnert. Wer später prüft, was ein Modell tatsächlich gesehen hat, muss nicht zusätzlich mühsam rekonstruieren, welches Modell das in diesem konkreten Fall überhaupt war — die Antwort steht bereits an derselben Stelle wie alles andere, was zu diesem Vorgang gehört.