Damit gehört Activepieces zu einer wachsenden Gruppe von Werkzeugen, die den etablierten Automatisierungsmarkt herausfordern, indem sie Offenheit und Datenhoheit ins Zentrum stellen. Statt einen geschlossenen SaaS-Dienst zu mieten, erhalten Unternehmen den vollständigen Quellcode und die Freiheit, die Plattform dort laufen zu lassen, wo sie ihre Daten haben wollen – im eigenen Rechenzentrum, bei einem europäischen Hoster oder in einer Cloud ihrer Wahl. Genau diese Kombination aus No-Code-Einfachheit und quelloffener Souveränität ist das Alleinstellungsmerkmal, das Activepieces im DACH-Mittelstand interessant macht.
Zugleich hat sich Activepieces früh auf einen zweiten Trend ausgerichtet: den Einsatz von künstlicher Intelligenz und KI-Agenten innerhalb von Automatisierungen. Die Plattform ist nicht nur ein klassisches „Wenn-dies-dann-das“-Werkzeug, sondern versteht sich ausdrücklich als Baukasten für KI-gestützte Abläufe – inklusive der Anbindung an das Model Context Protocol (MCP), über das wir in Kapitel 04 ausführlich sprechen.
Aus unserer Projektpraxis lässt sich die Zielgruppe klar umreißen. Activepieces passt besonders zu Unternehmen, die Automatisierung nutzen möchten, ohne die Kontrolle über ihre Daten aus der Hand zu geben. Das betrifft Organisationen mit erhöhten Datenschutzanforderungen, mit vorhandener IT-Kompetenz für den Betrieb sowie Teams, die von vornherein auf quelloffene, langfristig unabhängige Werkzeuge setzen wollen. Auch für den Einstieg in KI-gestützte Automatisierung ist die Plattform interessant, weil sie Modelle und Agenten strukturiert einbindet.
Weniger naheliegend ist Activepieces, wenn ein Unternehmen bewusst keinerlei eigenen Betrieb übernehmen möchte und stattdessen einen vollständig gemanagten Dienst sucht – auch wenn es dafür eine gehostete Cloud-Variante gibt. Wer maximale Breite an fertigen, tief gepflegten Integrationen zu Nischenanwendungen benötigt, findet bei den etablierten Marktführern häufig noch mehr vorgefertigte Anbindungen. Diese Abwägungen ziehen wir in Kapitel 06 im Detail.
Der Markt für Automatisierung war lange von geschlossenen Cloud-Diensten dominiert. Ihr Versprechen ist Bequemlichkeit: keine Installation, keine Wartung, sofort startklar. Der Preis dafür ist Abhängigkeit – von den Konditionen, den Datenschutz-Rahmenbedingungen und der Preispolitik eines einzelnen Anbieters. Genau an dieser Stelle setzen quelloffene Werkzeuge wie Activepieces an. Sie verlagern etwas Aufwand auf das Unternehmen, geben dafür aber Kontrolle zurück.
Für den DACH-Mittelstand ist dieser Perspektivwechsel oft mehr als eine technische Frage. Wer personenbezogene Daten oder Betriebsgeheimnisse durch eine Automatisierungsplattform leitet, muss genau wissen, wo diese Daten liegen und wer darauf zugreifen kann. Ein quelloffenes, selbst gehostetes Werkzeug macht diese Frage im Kern einfacher beantwortbar: Die Daten bleiben dort, wo das Unternehmen die Plattform betreibt. Das ist kein Freifahrtschein für Datenschutz-Nachlässigkeit, aber es entfernt eine ganze Klasse von Risiken, die bei reinen US-Cloud-Diensten strukturell bestehen bleiben.
Gleichzeitig ist Nüchternheit angebracht. Open Source und Self-Hosting nehmen einem Unternehmen nicht die Verantwortung ab – im Gegenteil, sie verschieben Teile davon vom Anbieter zum Betreiber. Wer die Plattform selbst betreibt, ist auch für Updates, Sicherheit und Verfügbarkeit zuständig. Activepieces ist ein mächtiges Werkzeug, aber es ersetzt keine durchdachte Betriebs- und Governance-Strategie. Diese Unterscheidung ziehen wir in jedem Projekt bewusst.
Grundsätzlich lassen sich drei Wege unterscheiden, Activepieces zu nutzen: die frei verfügbare, selbst gehostete Community-Variante, eine vom Anbieter betriebene Cloud sowie eine an größere Organisationen adressierte Enterprise-Ausrichtung. Alle teilen denselben quelloffenen Kern; sie unterscheiden sich vor allem darin, wer den Betrieb übernimmt und welche organisatorischen Funktionen hinzukommen.
Wichtig für das Verständnis: Die Editionen sind keine völlig getrennten Produkte, sondern Ausbaustufen um denselben quelloffenen Kern herum. Wer mit der Community-Variante startet, arbeitet mit derselben grundlegenden Logik aus Flows und Pieces wie in der Cloud. Das reduziert das Risiko eines späteren Wechsels zwischen den Varianten erheblich – ein Vorteil gegenüber Plattformen, bei denen sich die zugrunde liegende Architektur je nach Tarif unterscheidet.
Aus unserer Beratungspraxis lässt sich eine grobe Orientierung geben. Die Community-Variante ist die richtige Wahl für Unternehmen, die Datenhoheit priorisieren und über die nötige IT-Kompetenz verfügen oder einen Partner für den Betrieb haben. Die Cloud eignet sich zum schnellen Ausprobieren, für Proof-of-Concepts und für Teams ohne eigene Betriebsressourcen – hier ist jedoch der Serverstandort und der Datenfluss datenschutzrechtlich zu prüfen. Die Enterprise-Ausrichtung wird relevant, sobald viele Anwender, mehrere Abteilungen und formale Governance-Anforderungen ins Spiel kommen.
Jeder Flow folgt demselben Grundmuster: ein Trigger am Anfang, danach eine Kette aus Schritten, die entweder App-Aktionen aus Pieces oder Steuerungs-Bausteine sind. Ein typisches Beispiel aus dem Vertrieb: Trigger ist ein neu eingegangenes Kontaktformular. Eine Bedingung prüft, ob eine Pflichtangabe vorhanden ist. Anschließend legt ein Schritt den Kontakt im CRM an, ein zweiter sendet eine Benachrichtigung in den Team-Chat, und ein dritter verschickt eine automatische Eingangsbestätigung. Weil sich Schritte verzweigen und über Listen wiederholen lassen, sind auch anspruchsvollere Abläufe abbildbar als bei rein linearen Werkzeugen.
Der vielleicht wichtigste konzeptionelle Unterschied zu geschlossenen Plattformen ist, dass die Integrationen – die Pieces – selbst quelloffen sind. Das bedeutet: Fehlt eine Anbindung oder ist eine bestehende unvollständig, kann ein technisches Team sie erweitern oder eine neue schreiben, statt auf den Anbieter warten zu müssen. Für Unternehmen mit branchenspezifischen oder selbst entwickelten Systemen ist das ein handfester Vorteil. Der Preis dafür ist, dass die Qualität und Tiefe von Community-Pieces variieren kann – ein Punkt, den wir in Kapitel 05 vertiefen.
Activepieces positioniert sich als No-Code-Werkzeug, hält aber bewusst einen Ausweg für technische Anforderungen offen. Über das Code-Piece lässt sich eigene Logik einbauen, wo vorgefertigte Bausteine nicht ausreichen. Das ist die pragmatische Antwort auf ein bekanntes Dilemma: Reine No-Code-Werkzeuge sind einfach, stoßen aber an Grenzen; reine Code-Werkzeuge sind mächtig, aber für Fachabteilungen unzugänglich. Activepieces versucht, beide Welten zu verbinden – die Mehrheit der Abläufe ohne Code, die Sonderfälle mit. Wir prüfen in Projekten früh, welcher Anteil eines Vorhabens wirklich No-Code bleiben kann und wo Code-Pieces nötig werden, weil das die Frage nach den benötigten Kompetenzen im Team beantwortet.
Die KI-Fähigkeiten von Activepieces lassen sich grob in drei Bereiche gliedern: KI-Bausteine innerhalb von Flows, teilautonome KI-Agenten sowie die Anbindung an das Model Context Protocol. Alle drei verfolgen dasselbe Ziel – Automatisierung über reine Datenweitergabe hinaus zu echtem Verstehen und Handeln zu erweitern.
Die naheliegendste Nutzung ist KI als zusätzlicher Schritt innerhalb eines bestehenden Flows. Über KI-Bausteine lassen sich Sprachmodelle verschiedener Anbieter einbinden, um eine konkrete Aufgabe zu erledigen: eine eingehende Nachricht zusammenfassen, eine Anfrage nach Thema klassifizieren, aus einem Freitext strukturierte Felder extrahieren oder einen Antwortentwurf formulieren. In der Regel wird dafür ein eigener Zugang zum jeweiligen KI-Dienst hinterlegt. Weil Activepieces selbst gehostet werden kann, behält das Unternehmen dabei die Kontrolle darüber, welche Daten an welches Modell gehen.
Aus unserer Sicht ist das der praxisnaheste KI-Einsatz: gezielt dort, wo eine Aufgabe Sprachverständnis braucht, das mit Regeln nicht abbildbar wäre. Ein klassisches Beispiel ist die automatische Vorsortierung eingehender Kontaktanfragen nach Dringlichkeit und Thema, bevor sie an das richtige Team geroutet werden. Für rein strukturierte Aufgaben – Daten von Feld A nach Feld B übertragen – ist KI dagegen unnötig, fehleranfälliger und teurer als ein einfacher regelbasierter Schritt.
Über einzelne KI-Schritte hinaus setzt Activepieces auf das Konzept der KI-Agenten. Ein Agent folgt nicht starr einem festen Ablauf, sondern entscheidet eigenständig, welche Schritte und Werkzeuge zur Erfüllung einer Aufgabe nötig sind. Statt „Wenn A, dann B“ lautet die Logik hier eher „Erreiche dieses Ziel und nutze dafür die verfügbaren Werkzeuge“. Das Konzept ist mächtig, aber jung. Wir raten dazu, Agenten zunächst in unkritischen, gut überwachbaren Szenarien einzusetzen, bei denen ein Mensch die Ergebnisse kontrolliert, bevor sie wirksam werden.
Der Reiz solcher Agenten liegt darin, dass sie auch mit Situationen umgehen können, die beim Bau des Ablaufs nicht vollständig vorhersehbar waren. Wo ein klassischer Flow an einer unerwarteten Eingabe scheitert, kann ein Agent versuchen, selbst eine sinnvolle Lösung zu finden. Diese Flexibilität ist zugleich das Risiko: Ein System, das eigenständig entscheidet, ist schwerer vorherzusagen und zu testen als eine feste Regelkette. Für geschäftskritische Abläufe, bei denen jeder Schritt nachvollziehbar sein muss, bleibt der klassische, deterministische Flow auf absehbare Zeit die solidere Grundlage.
Ein Alleinstellungsmerkmal in der KI-Ausrichtung von Activepieces ist die Unterstützung des Model Context Protocol (MCP). Vereinfacht gesagt ist MCP ein offener Standard, über den KI-Modelle auf externe Werkzeuge und Datenquellen zugreifen können. Für Activepieces bedeutet das: Die vorhandenen Pieces – also die Anbindungen an CRM, Datenbanken, Chat-Dienste und Co. – lassen sich als Werkzeuge bereitstellen, die ein KI-Assistent nutzen kann. Umgekehrt kann Activepieces auch selbst mit MCP-fähigen Systemen zusammenarbeiten.
Der praktische Nutzen liegt darin, dass sich damit die Lücke zwischen Sprachmodellen und den realen Systemen eines Unternehmens schließen lässt, ohne für jede Verbindung Sonderentwicklung zu betreiben. Ein KI-Assistent kann so – kontrolliert und über definierte Werkzeuge – Aktionen in Geschäftsanwendungen anstoßen. Weil MCP ein offener Standard ist, passt er gut zur quelloffenen Philosophie von Activepieces. Gleichzeitig gilt hier dieselbe Vorsicht wie bei allen agentischen Ansätzen: Je mehr Handlungsspielraum ein KI-System erhält, desto sorgfältiger müssen Berechtigungen, Grenzen und menschliche Kontrolle definiert sein.
In der Praxis empfehlen wir einen nüchternen Blick: KI ist kein Selbstzweck und nicht für jede Automatisierung sinnvoll. Der Mehrwert entsteht überall dort, wo bisher ein Mensch eingreifen musste, weil eine Entscheidung Sprach- oder Kontextverständnis erforderte – das Einordnen einer Beschwerde, das Erkennen der eigentlichen Absicht hinter einer Anfrage, das Verdichten langer Texte auf das Wesentliche. Wir prüfen bei jedem geplanten KI-Schritt zwei Fragen: Erstens, ob die Aufgabe wirklich Verständnis erfordert oder ob eine simple Regel genügt. Zweitens, ob das Ergebnis toleranzfähig ist – also ob ein gelegentlicher Fehler des Modells im Prozess aufgefangen wird oder unmittelbar geschäftsschädigend wäre.
Ein Piece kapselt die Anbindung an einen Dienst: Es bringt dessen Trigger und Aktionen mit und macht sie im visuellen Builder nutzbar. Activepieces liefert eine wachsende Sammlung solcher Pieces für gängige Business-Anwendungen – von Kommunikations- und CRM-Systemen über Datenbanken und Tabellen bis zu KI-Diensten. Für den typischen Automatisierungsbedarf im Mittelstand sind die wichtigsten Kategorien abgedeckt.
Der entscheidende strukturelle Unterschied zu geschlossenen Plattformen liegt in der Offenheit des Frameworks. Pieces sind quelloffen und lassen sich mit einem definierten Entwicklungsansatz selbst erstellen oder erweitern. Das hat drei praktische Konsequenzen: Erstens kann die Community neue Anbindungen beisteuern, was die Bibliothek dynamisch wachsen lässt. Zweitens können Unternehmen fehlende oder unvollständige Integrationen selbst ergänzen, statt auf einen Anbieter angewiesen zu sein. Drittens ist die Funktionsweise einer Integration transparent einsehbar – wichtig, wenn man genau wissen muss, welche Daten wie verarbeitet werden.
Die Offenheit hat auch eine Kehrseite, die wir offen ansprechen. Weil Pieces von einer Community beigetragen werden können, variieren Qualität, Vollständigkeit und Pflegezustand. Ein populäres Piece für ein weit verbreitetes System ist meist gut gewartet; ein Piece für eine Nischenanwendung kann veraltet oder unvollständig sein. Für Unternehmen bedeutet das eine Sorgfaltspflicht: Bevor eine Integration produktiv genutzt wird, sollte geprüft werden, ob sie die benötigten Trigger und Aktionen tatsächlich abdeckt und in welchem Zustand sie sich befindet. Wir testen kritische Integrationen in Projekten grundsätzlich an einem realen Beispiel, bevor wir sie freigeben.
Selbst bei einer wachsenden Bibliothek gibt es Systeme ohne fertiges Piece – häufig branchenspezifische oder selbst entwickelte Anwendungen. Für diese Fälle bietet Activepieces mehrere Auswege. Über generische HTTP-Bausteine und Webhooks lassen sich beliebige Systeme anbinden, sofern sie eine offene Schnittstelle besitzen. Über das Code-Piece lässt sich individuelle Logik einbauen. Und über das Pieces-Framework kann ein technisches Team eine vollwertige, wiederverwendbare Integration entwickeln. Damit ist die Plattform nach oben hin offen – der Preis ist, dass diese Wege technisches Verständnis voraussetzen und den reinen No-Code-Charakter verlassen.
Activepieces punktet dort, wo Datenhoheit, Offenheit und ein moderner KI-Werkzeugkasten zusammenkommen sollen. Wenn ein Unternehmen Automatisierung nutzen will, aber die Kontrolle über seine Daten behalten muss, ist die quelloffene, selbst hostbare Natur ein starkes Argument. Gegenüber Zapier ist der offensichtlichste Unterschied das Betriebsmodell: Zapier ist ein reiner Cloud-Dienst, Activepieces lässt sich selbst betreiben. Gegenüber Make gilt Ähnliches – Make bietet zwar viel Logik-Tiefe, bleibt aber ein gehosteter Dienst.
Der spannendste Vergleich ist der mit n8n, weil beide eine ähnliche Philosophie teilen: quelloffen, selbst hostbar, mit starkem KI-Bezug und der Möglichkeit, Code einzubinden. Die Unterschiede liegen im Detail und im Reifegrad. n8n ist am Markt länger etabliert, hat ein größeres Ökosystem und richtet sich tendenziell an technisch versiertere Anwender mit seinem knotenbasierten Ansatz. Activepieces positioniert sich mit der MIT-Lizenz als besonders freizügig, legt großen Wert auf eine zugängliche No-Code-Oberfläche und rückt KI-Agenten und MCP prominent in den Vordergrund. Ein pauschales „besser“ gibt es nicht – die Wahl hängt von Reifegrad-Anforderungen, Lizenzpräferenz und dem technischen Niveau des Teams ab.
Sucht ein Unternehmen bewusst den maximal bequemen, vollständig gemanagten Dienst ohne jeden eigenen Betrieb und legt Wert auf die größtmögliche Zahl fertiger, tief gepflegter Integrationen zu Nischen-Tools, ist Zapier oft die pragmatischere Wahl. Geht es um sehr komplexe, vielschrittige Abläufe mit visuellem Fluss-Modell, spielt Make seine Stärken aus. Und wenn ein technisch reifes Team maximale Tiefe und ein besonders großes quelloffenes Ökosystem sucht, ist ein Blick auf n8n geboten. In unseren Projekten formulieren wir die Faustregel gern so: Activepieces für souveräne, KI-nahe No-Code-Automatisierung mit MIT-Freiheit; Zapier für Breite und Bequemlichkeit; Make für visuelle Komplexität; n8n für maximale Tiefe und ein reifes Open-Source-Ökosystem.
Der selbst gehostete Betrieb ist der Weg, der die volle Datenhoheit ausschöpft. Activepieces wird dabei üblicherweise per Docker installiert – ein etablierter Standard, der die Plattform mitsamt ihren Abhängigkeiten in gekapselten Containern ausliefert. Für Teams mit grundlegender Container-Erfahrung ist die Erstinstallation überschaubar. Der eigentliche Aufwand liegt weniger im ersten Start als im dauerhaften, verantwortungsvollen Betrieb.
Self-Hosting klingt nach einer einmaligen Installation, ist aber eine dauerhafte Aufgabe. Wer die Plattform selbst betreibt, übernimmt Verantwortung für mehrere Bereiche: das Einspielen von Updates und Sicherheits-Patches, die Absicherung des Zugriffs, die regelmäßige Datensicherung, die Überwachung der Verfügbarkeit und die Skalierung bei wachsender Last. Nichts davon ist außergewöhnlich für Unternehmen, die bereits Server oder Container betreiben – aber es sollte bewusst eingeplant und einer verantwortlichen Rolle zugeordnet werden.
Wir empfehlen daher, vor der Entscheidung für Self-Hosting eine ehrliche Bestandsaufnahme zu machen: Gibt es im Haus die Kompetenz und die Kapazität, eine solche Plattform verlässlich zu betreiben? Falls nicht, ist entweder die Cloud-Variante die pragmatischere Antwort oder der Betrieb wird an einen Partner ausgelagert, der das Hosting auf europäischer Infrastruktur übernimmt. Beide Wege bewahren einen Großteil der Souveränitätsvorteile, ohne das Unternehmen mit einer Aufgabe zu überfordern, für die es nicht aufgestellt ist.
Die vom Anbieter gehostete Cloud ist der schnellste Weg, Activepieces auszuprobieren und erste Automatisierungen zu bauen, ohne sich um Infrastruktur zu kümmern. Für einen Proof-of-Concept, für kleine Teams ohne Betriebsressourcen oder für einen zeitlich begrenzten Test ist das oft der richtige Start. Wichtig ist, dabei den Serverstandort und den Datenfluss datenschutzrechtlich zu bewerten – denn in der Cloud-Variante gilt der zentrale Souveränitätsvorteil des Self-Hostings nicht automatisch. Dazu mehr in Kapitel 09.
Auffällig ist ein Muster: Activepieces spielt seine Stärken dort aus, wo Automatisierung auf Datenschutz- oder Souveränitätsanforderungen trifft – oder wo KI-Nähe gefragt ist. Für rein triviale Verknüpfungen zweier Cloud-Dienste, bei denen Datenhoheit keine Rolle spielt und maximale Bequemlichkeit zählt, mag ein reiner Cloud-Dienst schneller sein. Sobald aber sensible Daten im Spiel sind oder ein Unternehmen unabhängig bleiben will, verschiebt sich die Rechnung zugunsten einer quelloffenen, selbst hostbaren Lösung.
Wichtig für die Erwartungshaltung: Der Nutzen realisiert sich nur, wenn die Prozesse vorher sauber durchdacht sind. Ein schlecht definierter Prozess wird durch Automatisierung nicht besser – nur schneller falsch. Deshalb steht in unseren Projekten immer die Prozessanalyse vor dem Bau des ersten Flows.
Ein typischer Verlauf in Unternehmen: Es beginnt mit einem einzelnen Flow, der ein konkretes Ärgernis löst. Schnell folgen weitere, weil der Nutzen sichtbar wird. Nach einigen Monaten existiert eine ganze Sammlung von Automatisierungen – oft verteilt über mehrere Personen, ohne dass jemand den Gesamtüberblick hat. Genau an diesem Punkt entscheidet sich, ob Automatisierung zum Vorteil oder zur Belastung wird. Bei einer selbst betriebenen Plattform kommt hinzu, dass auch der Betrieb mitwachsen muss.
Wir empfehlen daher, schon beim zweiten oder dritten Flow eine einfache Übersicht anzulegen: Welcher Flow erfüllt welchen Zweck, welche Systeme berührt er, wer ist verantwortlich und welche Daten verarbeitet er. Diese schlanke Dokumentation kostet wenig Aufwand, verhindert aber, dass aus nützlichen Helfern eine unübersichtliche Schatten-IT wird. Der Vorteil einer quelloffenen Plattform ist dabei, dass diese Governance vollständig in der eigenen Hand liegt – niemand kann Ihnen die Automatisierungen unter geänderten Konditionen entziehen.
Ein verbreitetes Missverständnis lautet, quelloffene Software sei schlicht gratis. Der Quellcode und die MIT-Lizenz sind zwar frei, doch die tatsächlichen Kosten entstehen an anderer Stelle. Beim Self-Hosting fallen keine nutzungsabhängigen Plattform-Gebühren an – dafür trägt das Unternehmen die Kosten für Server, Betrieb, Wartung und die dafür nötige Kompetenz. Diese Kosten sind planbar und skalieren nicht automatisch mit dem Automatisierungsvolumen, was gegenüber volumenabhängigen Cloud-Modellen bei hohem Durchsatz ein wirtschaftlicher Vorteil sein kann.
Bei der Cloud- und Enterprise-Variante hingegen gibt es Konditionen des Anbieters, die sich – wie bei jungen Produkten üblich – ändern können. Konkrete Preise nennen wir hier bewusst nicht, weil jede genannte Zahl schnell veralten würde. Entscheidend ist das Verständnis des Grundmusters: Self-Hosting tauscht laufende Plattformgebühren gegen eigenen Betriebsaufwand; die Cloud tauscht Betriebsaufwand gegen laufende Gebühren. Nicht zu vergessen sind die separaten Kosten für angebundene KI-Modelle, die unabhängig vom Betriebsmodell beim jeweiligen KI-Anbieter anfallen.
Das Grundprinzip einer Automatisierungsplattform bedeutet datenschutzrechtlich: Activepieces ist ein Vermittler, durch den personenbezogene Daten zwischen Systemen hindurchlaufen. Bei jedem Flow, der personenbezogene Daten verarbeitet – Namen, E-Mail-Adressen, Kontaktdaten, Bestellinformationen – gelten die entsprechenden Anforderungen der DSGVO. Der entscheidende Unterschied zu reinen Cloud-Diensten ist, dass beim Self-Hosting diese Daten die eigene Infrastruktur nicht verlassen müssen.
Der zentrale Datenschutz-Vorteil von Activepieces ist die Kombination aus Open Source und Self-Hosting. Wenn die Plattform auf eigener oder europäisch gehosteter Infrastruktur läuft, bleibt die Kontrolle über die verarbeiteten Daten beim Unternehmen. Eine ganze Klasse von Risiken, die bei reinen US-Cloud-Diensten strukturell bestehen bleibt – etwa die Frage nach behördlichen Zugriffsmöglichkeiten nach ausländischem Recht –, lässt sich damit deutlich entschärfen. Für Berufsgeheimnisträger, für besonders schützenswerte Datenkategorien und für Unternehmen mit hohen Souveränitätsanforderungen ist das ein gewichtiges Argument.
Wichtig ist die klare Unterscheidung: Der Souveränitätsvorteil gilt für das Self-Hosting, nicht automatisch für die gehostete Cloud. Wer die Cloud-Variante nutzt, sollte wie bei jedem SaaS-Dienst den Serverstandort, den möglichen Datentransfer in Drittländer und die vertraglichen Grundlagen – insbesondere einen Auftragsverarbeitungsvertrag – prüfen und bewerten. Die Bequemlichkeit der Cloud wird also mit denselben datenschutzrechtlichen Fragen erkauft, die für gehostete Dienste generell gelten. Diese Abwägung zwischen Bequemlichkeit und Kontrolle sollte bewusst und dokumentiert getroffen werden.
Eine Besonderheit ergibt sich aus dem KI-Fokus. Auch bei einer selbst gehosteten Plattform verlassen Daten das Haus, sobald ein KI-Schritt sie an ein externes Modell übermittelt. Das Self-Hosting schützt die Automatisierungslogik und die durchlaufenden Daten innerhalb der Plattform – aber nicht das, was bewusst an einen externen KI-Dienst gesendet wird. Deshalb ist bei jedem KI-Baustein gesondert zu klären, welche Daten an welchen Anbieter gehen, ob dieser Anbieter datenschutzkonform arbeitet und ob sich sensible Inhalte vermeiden oder anonymisieren lassen. Wir kartieren in Projekten für jeden produktiven Flow den kompletten Datenfluss – vom Auslöser über jeden Schritt bis zu externen KI-Diensten.
