Die Kategorie, in die Automatisch fällt, ist dieselbe wie bei Zapier, Make oder n8n: iPaaS, also Integration Platform as a Service – eine Plattform, die als Vermittler zwischen Softwaresystemen sitzt und Daten sowie Aktionen zwischen ihnen bewegt. Der Zusatz, mit dem sich Automatisch vom Wettbewerb abgrenzt, lautet „Open Source“. Wo klassische Anbieter ihre Plattform ausschließlich als geschlossenes Cloud-Produkt anbieten, legt Automatisch den Quellcode offen und stellt die Wahl frei: selbst betreiben oder das gehostete Angebot des Anbieters nutzen.
Für viele Fachanwender ist genau das zunächst zweitrangig – sie interessiert vor allem, ob sich ihre Werkzeuge verbinden lassen und ob die Bedienung verständlich bleibt. Und hier folgt Automatisch bewusst dem vertrauten Muster: eine App als Auslöser wählen, eine oder mehrere Aktionen anhängen, die Verbindung testen, aktivieren. Der Reiz der Plattform liegt darin, dass diese Zugänglichkeit nicht mit der Preisgabe der Datenhoheit erkauft werden muss.
Aus unserer Projektpraxis lässt sich die Zielgruppe klar umreißen. Automatisch ist besonders interessant für Unternehmen, bei denen Datenhoheit und Datenschutz an erster Stelle stehen – etwa weil sie mit sensiblen Daten arbeiten, in regulierten Branchen tätig sind oder aus grundsätzlicher Überzeugung keine personenbezogenen Daten durch fremde Clouds leiten möchten. Für diese Unternehmen ist die Möglichkeit, eine ausgereifte Automatisierungsplattform vollständig selbst zu betreiben, ein entscheidender Vorteil gegenüber reinen Cloud-Anbietern.
Ebenfalls angesprochen sind kostenbewusste Organisationen: Wer die Software selbst hostet, zahlt keine nutzerabhängigen oder ausführungsabhängigen Gebühren an einen Anbieter, sondern trägt lediglich die Kosten der eigenen Infrastruktur und des Betriebs. Weniger geeignet ist Automatisch dagegen für Unternehmen, die eine besonders große Zahl exotischer Integrationen benötigen und keinerlei technische Ressourcen für den Betrieb aufbringen können oder wollen – hier haben etablierte Cloud-Anbieter mit ihrer schieren Integrationsbreite oft die Nase vorn.
Der Kern der Sache lässt sich an einer Frage festmachen, die in fast jedem Automatisierungsprojekt auftaucht: Wohin fließen die Daten eigentlich? Bei einem reinen Cloud-Dienst lautet die Antwort zwangsläufig, dass die Daten durch die Infrastruktur des Anbieters laufen – mit allen datenschutzrechtlichen Folgefragen, gerade bei Anbietern außerhalb der EU. Bei einer selbst betriebenen Automatisch-Instanz kann die Antwort dagegen lauten: durch unsere eigene Umgebung, unter unserer Kontrolle, an einem Standort unserer Wahl.
Dieser Unterschied verschiebt die Ausgangslage für die Datenschutzbewertung spürbar. Automatisch nimmt Unternehmen die Prüfpflichten nicht ab – verbundene Dienste und die eigene Betriebssorgfalt bleiben relevant –, aber es eröffnet einen Weg, die eigentliche Automatisierungsplattform aus der Kette externer Datenempfänger herauszunehmen. Der Preis dafür ist Verantwortung: Wer selbst betreibt, muss Aktualisierungen einspielen, Sicherungen anlegen und die Verfügbarkeit im Blick behalten. Automatisch tauscht also die Bequemlichkeit einer gemanagten Cloud gegen ein Maximum an Kontrolle ein – eine bewusste Abwägung, die zu manchem Unternehmen hervorragend passt und zu anderem weniger.
Im Kern steht dieselbe Software: die Umgebung, in der Flows aus Auslösern und Aktionen gebaut, ausgeführt und überwacht werden. Der Unterschied zwischen den Nutzungswegen liegt nicht im grundlegenden Prinzip, sondern darin, wer die Software betreibt – das Unternehmen selbst oder der Anbieter – und welche Zusatzfunktionen dabei zur Verfügung stehen.
Automatisch besetzt bewusst eine Position, die man mit einem Satz zusammenfassen kann: die Zugänglichkeit von Zapier, aber quelloffen und selbst betreibbar. Auf der einen Seite stehen die etablierten Cloud-Anbieter wie Zapier oder Make, die auf maximale Bequemlichkeit und eine riesige Integrationsbreite setzen, dafür aber die Daten durch ihre eigene Infrastruktur leiten. Auf der anderen Seite stehen technisch anspruchsvollere Werkzeuge. Automatisch positioniert sich als der einfache, datenschutzfreundliche Vertreter unter den quelloffenen Optionen.
Diese Positionierung erklärt, warum Automatisch vor allem bei datenschutzbewussten Organisationen und bei Unternehmen mit knappem Budget Anklang findet. Für sie ist die Kombination aus vertrautem Bedienkonzept, offenem Quellcode und Selbstbetrieb genau das Richtige. Gleichzeitig ist ehrlich einzuräumen, dass die Plattform bei der reinen Zahl verfügbarer Integrationen und bei der Tiefe einzelner Funktionen mit den langjährig etablierten Cloud-Anbietern noch nicht überall mithalten kann. Diese Lücke wird kleiner, sollte in der Bewertung aber realistisch benannt werden.
Ein wichtiger Punkt der Einordnung: Anders als reine Cloud-Dienste zwingt Automatisch nicht in ein einziges Betriebsmodell. Ein Unternehmen kann sich für den Selbstbetrieb entscheiden und die volle Datenhoheit behalten – oder das gehostete Angebot des Anbieters wählen und den Betriebsaufwand abgeben. Diese Wahlfreiheit ist selbst ein Merkmal: Man kann etwa mit dem gehosteten Angebot beginnen, um die Plattform kennenzulernen, und später auf Selbstbetrieb wechseln, wenn die Datenschutzanforderungen es verlangen. Bei der Bewertung des gehosteten Angebots ist der Serverstandort ein zentraler Prüfpunkt, den wir in Kapitel 09 vertiefen.
Jeder Flow folgt demselben Grundmuster: ein Trigger am Anfang, danach eine Kette aus Aktionen. Der Trigger legt fest, wodurch der Ablauf startet – ein Ereignis in einer App, ein Webhook oder ein Zeitplan. Die nachfolgenden Aktionen führen dann Schritt für Schritt die gewünschten Operationen aus. Entscheidend ist, dass jede Aktion auf die Daten der vorherigen Schritte zugreifen kann: Was der Auslöser liefert und was eine Aktion zurückgibt, steht den folgenden Schritten zur Zuordnung bereit. So entsteht ein nachvollziehbarer Datenfluss vom Auslöser bis zur letzten Aktion.
Ein typisches Beispiel aus dem Alltag: Trigger ist ein neuer Eintrag in einem Formular oder einer Tabelle. Eine erste Aktion legt daraus einen Kontakt in einem CRM an, eine zweite verschickt eine Benachrichtigung an das zuständige Team, eine dritte trägt einen Vermerk in ein weiteres System ein. Was zuvor mehrere manuelle Handgriffe erforderte, läuft nun bei jedem neuen Eintrag automatisch und einheitlich ab – ohne dass jemand die einzelnen Systeme von Hand bedienen muss.
Ein oft unterschätzter Baustein sind die Verbindungen. Statt in jedem einzelnen Flow erneut Zugangsdaten einzugeben, richtet man eine App einmal ein – über einen sicheren Anmeldeprozess wie OAuth oder über einen Schlüssel – und nutzt diese Verbindung anschließend in beliebig vielen Flows. Beim Selbstbetrieb liegt ein besonderer Vorteil darin, dass diese Zugangsdaten in der eigenen Instanz gespeichert werden und nicht bei einem externen Anbieter. Für die Sicherheit ist entscheidend, Verbindungen nach dem Prinzip der minimalen Rechte einzurichten: Eine App sollte nur die Berechtigungen erhalten, die sie für ihre Aufgabe tatsächlich benötigt.
Die verfügbaren Auslöser decken die gängigen Bedürfnisse ab. App-Event-Trigger reagieren auf Ereignisse in angebundenen Diensten, etwa einen neuen Datensatz; technisch werden solche Ereignisse häufig durch regelmäßiges Abfragen (Polling) erkannt. Ein Webhook-Trigger stellt eine eigene Adresse bereit, an die andere Systeme Daten senden können – die naheliegende Wahl, um eigene Anwendungen oder Formulare anzubinden. Und ein Zeitplan-Trigger startet den Flow in festen Intervallen, ideal für regelmäßige Abgleiche. Wir prüfen in Projekten immer, welcher Trigger-Typ zur zeitlichen Anforderung passt – ein Webhook reagiert nahezu sofort, ein Polling-Trigger prüft in Intervallen, was für viele Anwendungsfälle vollkommen ausreicht.
Die Automatisierungslogik von Automatisch ist bewusst geradlinig gehalten: Ein Auslöser startet den Flow, Aktionen arbeiten ihn ab, Daten werden von Schritt zu Schritt zugeordnet. Das deckt einen sehr großen Teil der Automatisierungsbedürfnisse im Mittelstand ab – die meisten wertvollen Automatisierungen sind schlichte, aber verlässliche Datenweitergaben zwischen Systemen. KI kommt dort ins Spiel, wo eine Aufgabe echtes Sprach- oder Kontextverständnis erfordert, das sich mit festen Regeln nicht abbilden lässt.
Der naheliegendste KI-Einsatz ist die Anbindung eines Sprachmodell-Dienstes als Aktion innerhalb eines bestehenden Flows. Wo eine entsprechende App verfügbar ist, lässt sich ein KI-Dienst wie ein gewöhnlicher Baustein einbinden: Der Flow übergibt einen Text an das Modell und erhält ein Ergebnis zurück, das nachfolgende Aktionen weiterverarbeiten. So kann eine eingehende Nachricht zusammengefasst, eine Anfrage nach Thema klassifiziert oder aus einem Freitext ein strukturiertes Feld extrahiert werden. In der Regel benötigt man dafür einen eigenen Zugang zum jeweiligen KI-Dienst.
Für Anwendungsfälle, in denen es noch keine fertige KI-App gibt, bleibt der Weg über einen generischen HTTP-Baustein: Praktisch jeder KI-Dienst mit einer offenen Programmierschnittstelle lässt sich so ansprechen. Das ist weniger komfortabel als eine fertige App, erweitert aber die Möglichkeiten erheblich. Aus unserer Sicht ist das der praxisnaheste KI-Einsatz: gezielt dort, wo eine Aufgabe Sprachverständnis erfordert, und nicht als Selbstzweck.
In der Praxis empfehlen wir einen nüchternen Blick: KI ist 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 Absicht hinter einer Anfrage, das Verdichten langer Texte auf das Wesentliche. Für rein strukturierte Aufgaben, bei denen Daten nur von Feld A nach Feld B wandern, ist KI dagegen unnötig, fehleranfälliger und teurer als eine schlichte Aktion.
Wir prüfen in Projekten daher bei jedem geplanten KI-Schritt zwei Fragen: Erstens, ob die Aufgabe wirklich Verständnis erfordert oder ob eine einfache Regel genügt. Zweitens, ob das Ergebnis toleranzfähig ist – also ob ein gelegentlicher Fehler des Modells im Prozess aufgefangen wird oder unmittelbar schädlich wäre. Diese beiden Fragen verhindern, dass KI aus Begeisterung an Stellen eingebaut wird, an denen sie weder nötig noch verantwortbar ist. Gerade bei einer schlanken Automatisierungsplattform gilt: Die verlässliche, regelbasierte Datenweitergabe ist oft der eigentliche Gewinn, nicht der spektakuläre KI-Einsatz.
Auf der ersten Ebene bringt Automatisch eine wachsende Sammlung vorgefertigter Apps mit – Integrationen zu gängigen Business-Werkzeugen mit ihren jeweiligen Auslösern und Aktionen. Ehrlich gesagt ist die Zahl dieser Integrationen derzeit überschaubarer als bei den großen, langjährig etablierten Cloud-Anbietern; der Katalog wächst jedoch stetig, getragen von einer offenen Community. Für ein Unternehmen heißt das konkret: Vor einer Entscheidung sollte geprüft werden, ob die tatsächlich benötigten Werkzeuge bereits als Apps vorliegen. Diese Prüfung nehmen wir in Projekten grundsätzlich zu Beginn vor.
Die entscheidende Frage bei jeder Automatisierungsplattform lautet: Was passiert, wenn ein benötigtes System nicht als fertige Integration vorliegt? Automatisch bietet hier die üblichen offenen Auswege. Über einen generischen HTTP-Baustein lässt sich jede Anwendung ansprechen, die eine offene Programmierschnittstelle (API) bereitstellt. Und über Webhooks können beliebige Systeme Daten an einen Flow senden, um ihn auszulösen. Damit ist auch Software erreichbar, für die es keine dedizierte App gibt – vorausgesetzt, sie stellt eine Schnittstelle bereit.
Weil das Projekt quelloffen ist, gibt es zusätzlich einen weiteren Weg: Fehlende Apps lassen sich grundsätzlich ergänzen oder erweitern. Das verlangt allerdings technisches Verständnis und den Willen, sich am Projekt zu beteiligen oder eine Anpassung selbst zu pflegen – ein Punkt, den wir vor jeder Empfehlung klar benennen. Für die meisten Mittelständler ist der pragmatische Weg über HTTP und Webhooks der realistischere.
Ein Aspekt, der über den reinen Funktionsumfang hinausgeht: Die Offenheit des Projekts bedeutet, dass ein Unternehmen nicht vollständig von den Entscheidungen eines einzelnen Anbieters abhängig ist. Läuft die Plattform selbst gehostet, kann sie weiterbetrieben werden, auch wenn sich am Angebot des Anbieters etwas ändert. Der Quellcode bleibt einsehbar, die eingesetzte Version bleibt nutzbar. Diese Unabhängigkeit von der Preis- und Produktpolitik eines einzelnen Anbieters ist für die langfristige Planung ein nicht zu unterschätzender Vorteil – gerade im Vergleich zu reinen Cloud-Diensten, deren Konditionen sich jederzeit ändern können.
Der wichtigste Unterschied lässt sich in einem Satz fassen: Zapier ist ein geschlossener Cloud-Dienst, Automatisch ist quelloffen und selbst betreibbar. Zapier ist konsequent für maximale Bequemlichkeit und eine riesige Integrationsbreite gebaut und in diesen Punkten kaum zu schlagen – der Preis ist, dass die Daten durch die Cloud des Anbieters laufen und man an dessen Konditionen gebunden ist. Automatisch dreht diese Priorität um: Es stellt Datenhoheit und Unabhängigkeit in den Vordergrund und nimmt dafür eine schmalere Integrationsbreite und den eigenen Betriebsaufwand in Kauf. Wer Datenschutz als wichtigstes Kriterium betrachtet, ist bei Automatisch besser aufgehoben; wer maximale Breite und null Betriebsaufwand braucht, findet bei Zapier den leichteren Weg.
Am nächsten kommen Automatisch die ebenfalls quelloffenen Werkzeuge n8n und Activepieces. Alle drei lassen sich selbst hosten und stellen Datenhoheit in den Mittelpunkt. Die Unterschiede liegen im Charakter: n8n ist das technisch anspruchsvollste der drei, mit voller Code-Freiheit und großer Logik-Tiefe – dafür mit höherer Einstiegshürde. Activepieces ist wie Automatisch stärker auf einfache Bedienung ausgelegt, bietet aber ebenfalls Code-Bausteine. Automatisch positioniert sich als besonders schlankes, geradliniges Werkzeug für einfache App-zu-App-Automatisierung mit Datenhoheit – wer keine tiefe Logik oder umfangreiche Programmierung braucht, findet hier oft den unkompliziertesten Einstieg unter den Open-Source-Optionen.
In unseren Projekten formulieren wir die Faustregel gern so: Zapier für maximale Breite ohne Betriebsaufwand, Automatisch für einfache Automatisierung mit Datenhoheit, Activepieces als naher, gut bedienbarer Open-Source-Verwandter, n8n für technische Tiefe und komplexe Logik. Make wiederum ist der visuelle Cloud-Vertreter mit mittlerer Komplexität – leistungsfähig, aber wie Zapier cloud-gebunden. Nicht selten ist die beste Lösung eine bewusste Kombination mehrerer Werkzeuge.
Die selbst gehostete Variante wird typischerweise containerisiert über Docker bereitgestellt. Das vereinfacht die Installation erheblich, weil die Software mitsamt ihrer Bestandteile in klar definierten Containern läuft und sich weitgehend reproduzierbar aufsetzen lässt. Benötigt werden eine geeignete Server-Umgebung, grundlegende Kenntnisse im Umgang mit Containern und die Bereitschaft, sich um Aktualisierungen und Sicherungen zu kümmern. Für Unternehmen mit einer IT-Abteilung oder einem Dienstleister ist das gut beherrschbar; für Organisationen ganz ohne technische Ressourcen ist stattdessen das gehostete Angebot der realistischere Weg.
Aus unserer Projektpraxis hat sich ein schrittweises Vorgehen bewährt, das den Betriebscharakter der Plattform berücksichtigt und trotzdem beherrschbar bleibt.
Nach dem Start verschiebt sich der Fokus vom Bauen auf das Betreiben. Beim Selbstbetrieb sind drei Themen zentral: die Verfügbarkeit der Instanz, das regelmäßige Einspielen von Aktualisierungen – auch sicherheitsrelevanter – und verlässliche Sicherungen, damit keine Konfigurationen oder Verbindungen verloren gehen. Diese Aufgaben unterscheiden sich nicht grundsätzlich vom Betrieb anderer selbst gehosteter Software; wer bereits eigene Systeme betreibt, kann Automatisch gut in bestehende Betriebsprozesse einordnen.
Gleichzeitig gilt: Die gewonnene Kontrolle ist kein Selbstläufer. Ein Flow, der auf eine externe Schnittstelle zugreift, muss mit deren Ausfall umgehen können; eine Instanz, die nicht aktualisiert wird, veraltet und kann zum Sicherheitsrisiko werden. Wir empfehlen, für geschäftskritische Flows von Beginn an festzulegen, wer im Fehlerfall verantwortlich ist und wie schnell reagiert werden muss. Wer den Betriebsaufwand nicht selbst tragen möchte, für den ist das gehostete Angebot die naheliegende Alternative – zum Preis, dass die Daten dann wieder durch fremde Infrastruktur laufen.
Auffällig ist ein Muster: Automatisch glänzt dort, wo einfache, verlässliche Automatisierung auf hohe Datenschutzanforderungen trifft. Die Aufgaben selbst sind meist unspektakulär – Daten von einem System ins andere übertragen, benachrichtigen, abgleichen. Der eigentliche Wert entsteht aus der Kombination: Diese alltäglichen Automatisierungen laufen zuverlässig, und die Daten bleiben dabei unter der eigenen Kontrolle. Sobald eine Aufgabe dagegen tiefe, verzweigte Logik oder umfangreiche Programmierung verlangt, lohnt der prüfende Blick auf technisch mächtigere Werkzeuge.
Wichtig für die Erwartungshaltung: Der Nutzen realisiert sich nur, wenn der Betrieb sichergestellt ist. Ein schlecht durchdachter Prozess wird durch Automatisierung nicht besser – nur schneller falsch. Und eine selbst betriebene Instanz, um die sich niemand kümmert, verliert ihren Souveränitätsvorteil, sobald sie veraltet oder ausfällt. Deshalb steht in unseren Projekten immer die ehrliche Frage nach Prozess, Betrieb und Verantwortlichkeit vor dem Bau des ersten Flows.
Ein typischer Verlauf: Es beginnt mit einem einzelnen Flow, der ein konkretes Problem löst. Schnell folgen weitere, weil der Nutzen sichtbar wird. Nach einigen Monaten existiert eine ganze Sammlung – oft über mehrere Personen verteilt. Genau an diesem Punkt entscheidet sich, ob Automatisierung zum Vorteil oder zur Belastung wird. Bei einer selbst betriebenen Plattform kommt hinzu, dass auch die Instanz selbst mitwächst: mehr Flows bedeuten mehr Verbindungen, mehr Verantwortung und mehr, das im Betrieb im Blick behalten werden 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, welche Daten verarbeitet er und wer ist verantwortlich. Diese schlanke Dokumentation kostet wenig Aufwand, ist aber die Grundlage, um die Automatisierungs-Landschaft überschaubar zu halten und später fundiert über Erweiterung oder Konsolidierung zu entscheiden.
Zur Kostenlogik zuerst: Automatisch unterscheidet grundlegend zwischen zwei Wegen. In der selbst gehosteten Variante ist die Software selbst frei nutzbar – es fallen keine nutzer- oder ausführungsabhängigen Gebühren an einen Anbieter an. Die Kosten beschränken sich im Wesentlichen auf die eigene Infrastruktur und den internen oder externen Betriebsaufwand. Beim gehosteten Angebot des Anbieters fällt dagegen ein Abonnement an, dessen Konditionen direkt beim Anbieter zu prüfen sind. Konkrete Preise nennen wir hier bewusst nicht, weil sie sich ändern können. Entscheidend ist das Verständnis der Logik dahinter – die bleibt stabiler als jede Zahl.
Der wichtigste Mechanismus unterscheidet sich fundamental von reinen Cloud-Diensten: Beim Selbstbetrieb skalieren die Kosten nicht mit der Zahl der Ausführungen oder Nutzer, sondern hängen an der eigenen Infrastruktur und dem Betriebsaufwand. Wer viele einfache Automatisierungen betreibt, profitiert davon besonders – die Kosten bleiben weitgehend konstant, während sie bei ausführungsbasierten Cloud-Diensten mit dem Volumen steigen. Für den Mittelstand heißt das: Bei hohem Automatisierungsvolumen kann der Selbstbetrieb wirtschaftlich deutlich attraktiver sein, sofern die nötige Betriebskompetenz vorhanden ist. Wir erstellen in Projekten standardmäßig eine ehrliche Gegenüberstellung – Infrastruktur- und Betriebskosten des Selbstbetriebs gegenüber den zu erwartenden Abonnement- oder Nutzungskosten der Cloud-Alternativen.
Datenschutzrechtlich ist der zentrale Punkt zugleich die größte Stärke von Automatisch: Weil die Plattform quelloffen und selbst betreibbar ist, kann die eigentliche Automatisierungssoftware aus der Kette externer Datenempfänger herausgenommen werden. Betreibt ein Unternehmen Automatisch auf eigener Infrastruktur – idealerweise an einem Standort in der EU oder direkt im eigenen Rechenzentrum (on-prem) –, verlassen die durch die Plattform verarbeiteten Daten die eigene Umgebung nicht zwangsläufig. Gegenüber reinen Cloud-Diensten, insbesondere solchen außerhalb der EU, ist das ein struktureller Vorteil und macht Automatisch zu einer klar DSGVO-freundlicheren Option.
Für datenschutzbewusste Unternehmen im DACH-Raum ist die Möglichkeit des Selbstbetriebs oft das entscheidende Argument. Anders als bei einem Cloud-Dienst, bei dem man die Verarbeitung personenbezogener Daten durch fremde Infrastruktur grundsätzlich hinnehmen und vertraglich absichern muss, kann man bei Automatisch die eigentliche Plattform vollständig in die eigene Hand nehmen. Das vereinfacht die datenschutzrechtliche Argumentation erheblich: Wo keine Daten an einen externen Plattform-Anbieter übermittelt werden, entfallen die entsprechenden Fragen zu Auftragsverarbeitung und Drittlandtransfer für diese Ebene. Diese strukturelle Stärke ist der Hauptgrund, warum wir Automatisch bei hohen Datenschutzanforderungen in die engere Wahl nehmen.
So stark der Datenhoheitsvorteil ist – eine Besonderheit von Automatisierungsplattformen muss klar benannt werden: Daten fließen nicht nur durch Automatisch, sondern auch durch die verbundenen Apps und genutzten Dienste. Ein einziger Flow kann Daten aus einer Quelle ziehen, durch die eigene Automatisch-Instanz leiten und schließlich in einer dritten App ablegen, die ihrerseits ein Cloud-Dienst außerhalb der EU sein kann. Der Datenschutzvorteil des Selbstbetriebs endet also an der Grenze der eigenen Instanz: Sobald Daten an eine verbundene App gehen, gelten für diese die jeweils eigenen Bedingungen. Wir kartieren in Projekten daher für jeden produktiven Flow den kompletten Datenfluss vom Auslöser bis zur letzten Aktion – und bewerten jede verbundene App und jeden genutzten Dienst einzeln. Erst diese Gesamtbetrachtung ergibt ein belastbares Datenschutzbild.
