Die Kategorie, in die Rivet fällt, unterscheidet sich spürbar von klassischen iPaaS-Werkzeugen wie Zapier oder Make. Es geht nicht in erster Linie darum, Geschäfts-Apps miteinander zu verdrahten, sondern darum, die innere Logik von KI-Anwendungen zu gestalten: Wie wird ein Prompt aufgebaut, wie reagiert ein Agent auf eine Modellantwort, wann ruft er ein Werkzeug auf, wann verzweigt der Ablauf? Rivet ist damit dem Feld der KI-Orchestrierung zuzuordnen – jener Klasse von Werkzeugen, die zwischen der Anwendung und dem Sprachmodell vermitteln und den Ablauf steuern.
Der entscheidende Kunstgriff von Rivet ist die Kombination zweier Welten, die sonst getrennt sind. Auf der einen Seite steht die visuelle Oberfläche einer Desktop-Anwendung, in der man Abläufe mit der Maus zusammensetzt und ihre Ausführung Schritt für Schritt beobachten kann. Auf der anderen Seite steht eine Programmbibliothek, mit der sich exakt derselbe Graph in eine eigene Anwendung einbetten und dort produktiv ausführen lässt. Man entwirft und prüft also visuell und betreibt am Ende dieselbe Logik als Teil der eigenen Software.
Aus unserer Projektpraxis lässt sich die Zielgruppe klar umreißen. Rivet ist ideal für Entwicklerteams, die ernsthaft KI-Funktionen in eigene Produkte bauen – also nicht für die schnelle Fachabteilungs-Automatisierung, sondern für die technisch geführte Entwicklung von Assistenten, Agenten und komplexen Prompt-Abläufen. Wo eine Anwendung mehrere Modellaufrufe verketten, Zwischenergebnisse prüfen, verzweigen und externe Werkzeuge einbinden muss, spielt die visuelle Darstellung ihre Stärke aus: Sie macht das Zusammenspiel begreifbar und die Fehlersuche erträglich.
Weniger geeignet ist Rivet für reine Fachanwender ohne technische Begleitung, die eine fertige Klick-Automatisierung zwischen Standard-Apps suchen. Dafür sind klassische No-Code-Werkzeuge zugänglicher. Ebenso ist Rivet kein vollständiger, gehosteter Betriebsdienst mit Konten, Nutzerverwaltung und Rund-um-die-Uhr-Support aus einer Hand – es ist ein Werkzeug für Teams, die die Verantwortung für Betrieb und Einbettung selbst tragen können und wollen.
Der Kern der Sache lässt sich an einem typischen Projektmoment festmachen. Sobald eine KI-Anwendung über einen einzigen Prompt hinauswächst – also mehrere Modellaufrufe kombiniert, Antworten prüft, je nach Ergebnis unterschiedlich weiterläuft und dabei vielleicht noch Daten aus anderen Systemen einbezieht – wird reiner Code schnell unübersichtlich. Man verliert den Überblick, welcher Aufruf welchen Kontext bekommt und warum ein Agent sich in einer bestimmten Situation so und nicht anders verhält.
Genau hier setzt Rivet an: Der Ablauf wird zur sichtbaren Struktur, und die Ausführung lässt sich beobachten wie ein Film. Man sieht, welche Verzweigung genommen wurde, welcher Prompt tatsächlich beim Modell ankam und welche Antwort zurückkam. Diese Nachvollziehbarkeit verkürzt die Fehlersuche erheblich und macht Entscheidungen im Team diskutierbar, weil alle auf dasselbe Bild schauen. Der Preis dafür ist eine gewisse Einarbeitung in die Denkweise des Werkzeugs und die Bereitschaft, KI-Logik bewusst zu modellieren statt sie nur zu programmieren.
Im Zentrum steht die Vorstellung, dass KI-Abläufe als Graphen beschrieben werden. Ein Graph besteht aus Nodes, die über Verbindungen Daten austauschen. Diese Beschreibung ist der eigentliche Wert – sie lässt sich sowohl visuell in der Desktop-Anwendung bearbeiten als auch über eine Bibliothek in einer eigenen Anwendung ausführen. Die folgenden Bausteine machen dieses Grundprinzip nutzbar.
Rivet besetzt eine bewusste Nische zwischen zwei Welten. Auf der einen Seite stehen reine Code-Frameworks wie LangChain, die maximale Freiheit bieten, aber alles der Programmierung überlassen und dadurch schwer überschaubar werden. Auf der anderen Seite stehen gehostete Baukästen, die KI-Abläufe zwar visuell zusammensetzen lassen, dafür aber an die Cloud und die Konditionen eines Anbieters binden. Rivet positioniert sich dazwischen: die visuelle Klarheit eines grafischen Editors, kombiniert mit der Kontrolle und Offenheit eines quelloffenen, lokal betreibbaren Werkzeugs.
Diese Positionierung erklärt, warum Rivet besonders bei technischen Teams beliebt ist, die KI-Funktionen in bestehende Produkte einbauen. Für sie ist die Kombination aus visuellem Entwurf und einbettbarer Bibliothek ideal: Sie können komplexe Agentenlogik gemeinsam entwerfen und diskutieren, ohne die Kontrolle über Code und Datenfluss abzugeben. Der ursprüngliche Entstehungskontext bei einem Software-Unternehmen, das Rivet für den Eigenbedarf entwickelt hat, prägt diesen Charakter bis heute: Es ist ein Werkzeug von Entwicklern für Entwickler.
Ein wichtiger Punkt der Einordnung ist das Betriebsmodell. Rivet ist quelloffen und läuft in seinem Kern als lokale Desktop-Anwendung; der produktive Betrieb erfolgt über die eingebettete Bibliothek in der eigenen Software. Das unterscheidet Rivet grundlegend von reinen Cloud-Diensten: Es gibt keinen zwingenden Zwischen-Server des Herstellers, durch den alle Abläufe laufen müssten. Wer möchte, kann Entwurf und Ausführung vollständig in der eigenen Umgebung halten.
Diese Eigenschaft ist der größte strukturelle Vorteil von Rivet – gerade mit Blick auf Datenhoheit, auf die wir in Kapitel 09 ausführlich eingehen. Zugleich verlagert sie Verantwortung: Wer keinen gehosteten Dienst nutzt, muss Betrieb, Aktualisierung und Absicherung selbst organisieren. Rivet nimmt einem also nicht die Betriebsarbeit ab, sondern gibt technischen Teams die Freiheit und die Pflicht, sie selbst zu gestalten.
Diese vier Ebenen bauen aufeinander auf. Nodes sind die Vokabeln, Graphen die Sätze, Verzweigungen die Grammatik, und das Debugging ist das Werkzeug, mit dem man prüft, ob der Satz auch das aussagt, was er soll. Wer diese Logik verstanden hat, kann in Rivet auch anspruchsvolle KI-Abläufe strukturiert und wartbar aufbauen.
Ein Node ist die kleinste Einheit in Rivet: ein einzelner Baustein mit einer klar umrissenen Aufgabe. Es gibt Nodes, die einen Prompt an ein Sprachmodell schicken, andere, die Text zusammenfügen oder umformen, wieder andere, die eine Bedingung prüfen, Daten aus einer Schnittstelle holen oder ein Ergebnis in ein bestimmtes Format bringen. Jeder Node hat Eingänge, über die er Daten empfängt, und Ausgänge, über die er sein Ergebnis weitergibt. Man verbindet diese Ein- und Ausgänge mit der Maus und legt so fest, wie die Daten durch den Ablauf wandern.
Der praktische Nutzen dieses Baustein-Prinzips liegt in der Kombinierbarkeit. Weil jeder Node eine überschaubare Aufgabe erfüllt, entsteht die Komplexität erst aus dem Zusammenspiel vieler kleiner, für sich genommen einfacher Teile. Das macht Abläufe verständlich und einzelne Schritte austauschbar: Will man etwa das verwendete Modell wechseln oder eine Umformung anpassen, betrifft das nur den betreffenden Node, nicht den gesamten Ablauf.
Aus verbundenen Nodes entsteht ein Graph – die vollständige Beschreibung eines KI-Ablaufs. Entscheidend ist, dass ein Graph nicht nur einen geraden Weg von A nach B abbilden kann, sondern auch Verzweigungen: Je nachdem, wie die Antwort eines Modells ausfällt oder ob eine Bedingung erfüllt ist, läuft der Ablauf unterschiedlich weiter. So lassen sich Entscheidungen modellieren – etwa: „Wenn die Klassifizierung ‚Beschwerde‘ ergibt, nimm diesen Zweig, sonst jenen.“
Diese Fähigkeit, Verzweigungen und wiederkehrende Muster sichtbar darzustellen, ist einer der zentralen Vorzüge von Rivet gegenüber reinem Code. In einem Programm sind Bedingungen und Schleifen im Text versteckt und erschließen sich nur durch aufmerksames Lesen. Im Graphen sind sie als Linien und Knoten sichtbar. Größere Abläufe lassen sich zudem in Untergraphen gliedern, sodass ein übergeordneter Graph einen ganzen Teilablauf als einzelnen Baustein aufruft – ein wichtiges Mittel gegen Unübersichtlichkeit.
Was Rivet im Alltag besonders wertvoll macht, ist die Beobachtbarkeit der Ausführung. Man kann einen Graphen in der Desktop-Anwendung laufen lassen und dabei zusehen, wie die Daten von Node zu Node fließen. Für jeden Baustein lässt sich einsehen, welche Eingaben er erhalten und welches Ergebnis er erzeugt hat – bei einem Modellaufruf also der tatsächlich gesendete Prompt und die zurückgelieferte Antwort. Diese Transparenz verwandelt die sonst mühsame Fehlersuche bei KI-Abläufen in eine nachvollziehbare Übung.
Besonders bemerkenswert ist das Remote-Debugging. Ein Graph, der über die Bibliothek bereits in einer laufenden Anwendung eingebettet ist, kann aus der Rivet-Oberfläche heraus über eine Fernverbindung beobachtet werden. Man sieht also nicht nur einen isolierten Testlauf, sondern die tatsächliche Ausführung im realen Kontext der eigenen Software. Damit schließt sich die Lücke zwischen Prototyp und Produktivbetrieb – ein Aspekt, den viele rein textbasierte Frameworks in dieser Form nicht bieten.
Allen gemeinsam ist das Ziel, über den einzelnen, isolierten Modellaufruf hinauszukommen. Ein einzelner Prompt kann viel, aber anspruchsvolle Anwendungen entstehen erst, wenn mehrere Aufrufe zusammenwirken, Zwischenergebnisse geprüft werden und das Modell auf die reale Welt zugreifen kann. Genau diese Zusammenarbeit macht Rivet sichtbar und beherrschbar.
Die grundlegendste KI-Fähigkeit von Rivet ist die Prompt-Kette: Mehrere Modellaufrufe werden so verknüpft, dass das Ergebnis des einen Schrittes zur Eingabe des nächsten wird. Ein typisches Muster ist, zunächst einen Text zu klassifizieren, dann auf Basis der Klassifizierung einen passenden Prompt aufzubauen und schließlich eine Antwort zu erzeugen. Jeder dieser Schritte ist ein eigener Node, und der Graph zeigt, wie sie zusammenhängen.
Der Gewinn gegenüber einem einzigen großen Prompt liegt in Verlässlichkeit und Wartbarkeit. Wer eine komplexe Aufgabe in mehrere kleinere Modellaufrufe zerlegt, kann jeden Schritt gezielt formulieren, prüfen und verbessern, ohne alles auf einmal umbauen zu müssen. In Rivet lässt sich diese Zerlegung nicht nur bauen, sondern auch beobachten – man sieht, an welcher Stelle der Kette ein Ergebnis vom Erwarteten abweicht, und kann gezielt dort ansetzen.
Über einfache Ketten hinaus lassen sich in Rivet Agenten modellieren: Abläufe, in denen ein Sprachmodell nicht nur Text erzeugt, sondern im Rahmen des Graphen selbst über den nächsten Schritt mitentscheidet. Ein Agent kann etwa entscheiden, ob er zusätzliche Informationen benötigt, ein Werkzeug aufruft, das Ergebnis prüft und den Vorgang wiederholt, bis ein Ziel erreicht ist. Die Verzweigungen und wiederkehrenden Muster, die Rivet abbilden kann, sind die Grundlage für solche adaptiven Abläufe.
Wichtig ist hier eine nüchterne Erwartungshaltung, die wir in Projekten stets betonen: Agentische Abläufe sind mächtig, aber auch anspruchsvoll im Betrieb. Je mehr Freiheit ein Agent hat, desto schwerer wird sein Verhalten vorhersagbar – und desto wichtiger werden klare Grenzen, Prüfschritte und eine gute Beobachtbarkeit. Genau bei Letzterer spielt Rivet seine Stärke aus: Weil sich jeder Schritt des Agenten im Graphen verfolgen lässt, wird sein Verhalten transparenter als in einer reinen Code-Lösung.
Damit ein Agent mehr kann, als Text zu erzeugen, muss er Werkzeuge nutzen können – also externe Funktionen aufrufen, um Informationen abzurufen oder Aktionen auszulösen. In Rivet wird eine solche Werkzeug-Nutzung als Teil des Graphen modelliert: Ein Node ruft eine Schnittstelle auf, holt Daten oder löst eine Aktion aus, und das Ergebnis fließt zurück in den Ablauf. So kann ein KI-Agent beispielsweise eine Datenbank abfragen, eine Berechnung anstoßen oder eine Information aus einem anderen System einholen, bevor er seine Antwort formuliert.
Diese Fähigkeit ist es, die aus einem reinen Sprachmodell eine handlungsfähige Anwendung macht. Zugleich ist sie der Punkt, an dem Datenschutz und Sicherheit besonders sorgfältig zu bedenken sind: Jedes angebundene Werkzeug ist ein Kanal, über den Daten fließen. Wir empfehlen, für jeden Werkzeug-Node bewusst festzulegen, welche Daten er erhält und welche Rechte er benötigt – ein Aspekt, den wir in Kapitel 09 vertiefen.
Die Offenheit von Rivet als Open-Source-Projekt prägt alle drei Ebenen. Weil der Quellcode einsehbar und die Architektur auf Erweiterbarkeit ausgelegt ist, ist Rivet nicht auf ein bestimmtes Modell, einen bestimmten Anbieter oder einen bestimmten Einsatzweg festgelegt. Diese Anpassbarkeit ist ein zentraler Grund, weshalb technische Teams das Werkzeug schätzen.
Rivet ist darauf ausgelegt, verschiedene Sprachmodelle anzubinden. Über entsprechende Nodes lassen sich Modelle unterschiedlicher Anbieter ansprechen – von großen kommerziellen Cloud-Diensten bis, je nach Konfiguration und Erweiterung, hin zu lokal betriebenen Modellen. Für den Ablauf im Graphen ist der konkrete Anbieter zunächst nebensächlich: Ein Modellaufruf-Node erhält einen Prompt und liefert eine Antwort zurück; welches Modell dahintersteht, ist eine Frage der Konfiguration.
Diese Flexibilität ist strategisch bedeutsam. Sie erlaubt es, das eingesetzte Modell zu wechseln, ohne den gesamten Ablauf neu zu bauen, und sie eröffnet – wichtig für den Datenschutz – die Option, statt eines US-Cloud-Modells ein in der EU gehostetes oder ein lokal betriebenes Modell zu verwenden. Welche Modelle konkret und wie bequem unterstützt werden, hängt vom jeweiligen Stand des Projekts und der eingesetzten Erweiterungen ab und sollte im Einzelfall geprüft werden.
Die vielleicht wichtigste Integration ist die Einbettung in die eigene Anwendung. Über die bereitgestellte Bibliothek lässt sich ein in Rivet entworfener Graph in einer eigenen Software laden und ausführen. Das bedeutet: Der visuelle Entwurf ist kein Wegwerf-Prototyp, sondern wird zum tatsächlichen Bestandteil des Produkts. Änderungen am Graphen lassen sich in der Desktop-Anwendung vornehmen und anschließend in die Anwendung übernehmen.
Für Software-Anbieter und für Unternehmen mit eigener Entwicklungsmannschaft ist das ein großer Vorteil: Sie behalten die KI-Logik in ihrer eigenen Codebasis und ihrer eigenen Betriebsumgebung, statt sie an einen externen Dienst auszulagern. Der Preis dafür ist, dass die Einbettung Entwicklungsarbeit erfordert und der Betrieb – anders als bei einem gehosteten Dienst – in der eigenen Verantwortung liegt.
Als quelloffenes Werkzeug ist Rivet auf Erweiterbarkeit ausgelegt. Über Plugins lassen sich zusätzliche Node-Typen, Anbindungen an weitere Modelle und Dienste sowie spezielle Funktionen ergänzen. Weil der Quellcode offenliegt, können Teams mit entsprechender Kompetenz eigene Bausteine schreiben, die genau auf ihre Anforderungen zugeschnitten sind – etwa eine Anbindung an ein internes System, für das es keinen fertigen Node gibt.
Diese Offenheit hat zwei Seiten. Einerseits macht sie Rivet extrem anpassungsfähig und verhindert eine Abhängigkeit von den Entscheidungen eines einzelnen Anbieters. Andererseits verlagert sie Verantwortung: Eigene Erweiterungen müssen entwickelt, gepflegt und bei neuen Versionen von Rivet gegebenenfalls angepasst werden. Wie bei jeder Open-Source-Lösung gilt, dass die Freiheit mit dem Aufwand für Pflege und Aktualisierung einhergeht – ein Punkt, den wir bei der Einführung offen ansprechen.
Flowise und Langflow sind Rivet am nächsten: Auch sie sind quelloffene, visuelle Werkzeuge zum Zusammensetzen von LLM-Abläufen. Der wichtigste Unterschied liegt im Grundcharakter. Flowise und Langflow sind typischerweise als Server-Anwendungen ausgelegt, die man selbst hostet und im Browser bedient – sie tendieren dazu, selbst zum Betriebsdienst zu werden, der Abläufe bereitstellt und ausführt. Rivet dagegen ist im Kern eine Desktop-Anwendung für Entwurf und Debugging, deren Ergebnis ein Graph ist, den man anschließend in die eigene Software einbettet.
Vereinfacht gesagt: Flowise und Langflow neigen dazu, die Ausführung selbst zu übernehmen, während Rivet die Ausführung bewusst in die eigene Anwendung verlagert. Für Teams, die KI-Logik als integralen Bestandteil ihres eigenen Produkts betreiben wollen, passt der Rivet-Ansatz oft besser; für Teams, die einen eigenständigen, browserbasierten Baukasten mit sofort nutzbarem Dienst suchen, können Flowise oder Langflow näherliegen. Alle drei sind quelloffen und lassen sich datenschutzfreundlich betreiben – die Wahl ist eine Frage von Architektur und Arbeitsweise, nicht von gut oder schlecht.
Grundlegend anders gelagert ist der Vergleich mit LangChain. LangChain ist kein visuelles Werkzeug, sondern ein reines Code-Framework: eine Programmbibliothek, mit der Entwickler LLM-Abläufe direkt im Quelltext aufbauen. Es bietet maximale Freiheit und Ausdrucksstärke, verlangt aber, dass jede Verzweigung, jede Kette und jeder Werkzeugaufruf programmiert wird – ohne die visuelle Landkarte, die Rivet liefert.
Die beiden Ansätze schließen sich nicht zwingend aus, sondern beantworten unterschiedliche Fragen. Wer die volle Kontrolle im Code will und ein Team hat, das komplexe Abläufe gut überblickt, findet in LangChain ein mächtiges Fundament. Wer die Logik sichtbar machen, im Team diskutieren und Schritt für Schritt debuggen möchte, ist mit Rivet oft schneller und robuster unterwegs. In der Praxis sehen wir beides: Manche Teams nutzen ein visuelles Werkzeug für Entwurf und Nachvollziehbarkeit und ein Code-Framework für besonders individuelle Bausteine.
In unseren Projekten hat sich ein pragmatisches Vorgehen bewährt, das die Stärken von Rivet nutzt und zugleich die typischen Fallstricke vermeidet. Die folgenden Schritte skizzieren, wie eine Einführung sinnvoll aufgebaut ist.
Nach dem Start verschiebt sich der Fokus vom Bauen auf das Betreiben. Zentrale Themen sind die Beobachtung der Ausführungen, das saubere Behandeln von Fehlern und das Aktuellhalten der eingesetzten Rivet-Version samt Erweiterungen. Weil sich Abläufe über das visuelle und das Remote-Debugging genau beobachten lassen, ist die Fehlersuche vergleichsweise komfortabel – man sieht, welcher Node welche Daten erhalten und welches Ergebnis erzeugt hat. Diese Nachvollziehbarkeit ist einer der unterschätzten Vorteile von Rivet und ein Grund, warum technische Teams gern damit arbeiten.
Gleichzeitig gilt: Ein quelloffenes, selbst betriebenes Werkzeug enthebt niemanden der Verantwortung für den eigenen Betrieb. Anders als bei einem gehosteten Dienst gibt es keinen Anbieter, der Aktualisierungen automatisch einspielt oder rund um die Uhr Support leistet. Wir empfehlen deshalb, für geschäftskritische KI-Funktionen von Beginn an festzulegen, wer im Fehlerfall verantwortlich ist, wie Aktualisierungen getestet werden und wie schnell reagiert werden muss.
Die folgenden Szenarien stammen aus der typischen Projektpraxis. Sie zeigen, wo Rivet seine Stärken ausspielt – und machen zugleich deutlich, dass fast immer technische Kompetenz und ein klar umrissener Anwendungsfall die Voraussetzung sind.
Auffällig ist ein Muster: Rivet glänzt dort, wo KI-Logik über einen einzelnen Prompt hinausgeht und wo Nachvollziehbarkeit sowie Datenhoheit wichtig sind. Sobald mehrere Modellaufrufe zusammenspielen, Entscheidungen getroffen und externe Werkzeuge eingebunden werden, wird der visuelle Graph zum Vorteil. Der Mehrwert entsteht weniger durch fertige Standard-Integrationen als durch die Fähigkeit, anspruchsvolle Abläufe sichtbar, prüfbar und einbettbar zu machen.
Wichtig für die Erwartungshaltung: Der Nutzen realisiert sich nur, wenn die nötige technische Kompetenz vorhanden ist. Ein schlecht durchdachter KI-Ablauf wird durch eine schöne Oberfläche nicht besser – nur ansehnlicher falsch. Und ein Graph, der ohne Verständnis zusammengeklickt wurde, ist kein Fortschritt, sondern eine spätere Belastung. Deshalb steht in unseren Projekten immer die ehrliche Frage nach Anwendungsfall und Kompetenz vor dem Bau des ersten Graphen.
Ein typischer Verlauf: Es beginnt mit einem visuellen Prototyp, der eine Idee greifbar macht. Überzeugt das Ergebnis, folgt die Einbettung in die eigene Software – und aus dem Experiment wird eine echte Produktfunktion. Nach einiger Zeit existieren womöglich mehrere Graphen, gepflegt von verschiedenen Personen. Genau an diesem Punkt entscheidet sich, ob die KI-Entwicklung zum Vorteil oder zur Belastung wird.
Wir empfehlen daher, schon beim zweiten oder dritten Graphen eine einfache Übersicht anzulegen: Welcher Graph erfüllt welchen Zweck, welche Modelle und Werkzeuge nutzt er, welche Daten verarbeitet er und wer ist verantwortlich. Diese schlanke Dokumentation kostet wenig Aufwand, ist bei einem quelloffenen, selbst betriebenen Werkzeug aber besonders wertvoll – sie hält die KI-Logik wartbar und ist die Grundlage, um später fundiert über Ausbau oder Konsolidierung zu entscheiden.
Zur Kostenlogik zuerst: Rivet selbst ist als quelloffenes Werkzeug ohne Lizenzgebühr nutzbar. Die eigentlichen Kosten entstehen an anderer Stelle – vor allem bei den angebundenen Sprachmodellen, deren Nutzung je nach Anbieter und Volumen abgerechnet wird, sowie beim eigenen Aufwand für Einbettung, Betrieb und Pflege. Konkrete Preise nennen wir hier bewusst nicht, weil sie von der Wahl des Modells, dem Nutzungsvolumen und dem eigenen Betriebsmodell abhängen und sich beim jeweiligen Anbieter ändern. Entscheidend ist das Verständnis der Logik dahinter – die bleibt stabiler als jede Zahl.
Der wichtigste Mechanismus: Anders als bei einem gehosteten Dienst gibt es bei Rivet keine plattformseitige Nutzungsgebühr. Die laufenden Kosten skalieren stattdessen mit der Nutzung der angebundenen Modelle und mit dem eigenen Betriebsaufwand. Ein Graph, der ein günstiges oder lokales Modell nutzt und selten läuft, ist im Betrieb sehr preiswert; ein Graph, der ein teures Cloud-Modell häufig aufruft, verursacht entsprechend höhere Modellkosten. Für den Mittelstand heißt das: Die Kosten lassen sich durch die Wahl von Modell und Betriebsform gut steuern. Wir erstellen in Projekten standardmäßig eine ehrliche Hochrechnung – erwartete Aufrufe, multipliziert mit den typischen Modellkosten pro Aufruf, zuzüglich des eigenen Betriebsaufwands –, damit die tatsächlichen Kosten sichtbar werden, bevor eine KI-Funktion produktiv geht.
Datenschutzrechtlich ist die Ausgangslage bei Rivet vergleichsweise komfortabel – mit einer wichtigen Einschränkung. Das Werkzeug selbst ist quelloffen und lässt sich lokal als Desktop-Anwendung oder eingebettet in der eigenen Umgebung betreiben. Es gibt keinen zwingenden Hersteller-Dienst, durch den alle Daten laufen müssten. Das ist ein struktureller Vorteil für die Datenhoheit: Der Entwurf, die Ausführung und die verarbeiteten Daten können vollständig unter eigener Kontrolle bleiben.
Der entscheidende Punkt liegt woanders: bei den angebundenen Sprachmodellen. Sobald ein Graph ein Modell aufruft, das als Cloud-Dienst – häufig bei US-Anbietern – betrieben wird, verlassen die übermittelten Daten die eigene Umgebung und fließen zu diesem Dienst. Der Datenfluss wird also nicht durch Rivet bestimmt, sondern durch die Wahl des Modells und seines Betreibers. Wer personenbezogene Daten in solche Cloud-Modelle gibt, muss dieselben DSGVO-Anforderungen beachten wie bei jedem anderen US-Cloud-Dienst – vom Auftragsverarbeitungsvertrag bis zur Bewertung des Datentransfers.
Die zentrale Botschaft dieses Kapitels lautet: Rivet verschiebt die Datenschutzfrage vom Werkzeug hin zur Modellwahl – und gibt dem Unternehmen damit ungewöhnlich viel Kontrolle. Weil das Werkzeug quelloffen und lokal betreibbar ist, kann ein Unternehmen den gesamten Ablauf in der eigenen Umgebung halten. Nutzt es dazu ein lokal oder in der EU betriebenes Sprachmodell, lässt sich eine KI-Anwendung aufbauen, bei der zu keinem Zeitpunkt personenbezogene Daten an einen US-Cloud-Dienst gelangen. Das ist ein deutlicher Vorteil gegenüber vielen rein gehosteten KI-Plattformen.
Die Kehrseite ist die Eigenverantwortung: Der datenschutzfreundliche Betrieb entsteht nicht von selbst, sondern durch bewusste Entscheidungen – bei der Modellwahl, bei der Absicherung der Werkzeug-Zugriffe und bei der Dokumentation der Datenflüsse. Rivet macht den datenschutzfreundlichen Weg möglich; begehen muss ihn das Unternehmen selbst. Für Mittelständler mit erhöhten Souveränitätsanforderungen ist genau diese Möglichkeit oft der ausschlaggebende Grund, Rivet gegenüber einer reinen Cloud-Lösung den Vorzug zu geben.
