Die Kategorie, in die Stack AI fällt, lässt sich am ehesten als No-Code-KI-Plattform oder – etwas technischer – als „Builder für LLM-Anwendungen“ beschreiben. Gemeint ist eine Umgebung, in der die typischen Bestandteile moderner KI-Lösungen bereits als fertige, konfigurierbare Bausteine vorliegen: die Anbindung an große Sprachmodelle, das Durchsuchen eigener Dokumente über Retrieval-Augmented Generation (RAG), die Verkettung mehrerer Schritte zu einem Ablauf und die Bereitstellung einer Bedienoberfläche für den fertigen Assistenten. Der Zusatz, mit dem sich Stack AI vom Wettbewerb abgrenzt, ist der klare Enterprise-Fokus: Governance, Sicherheit und die Tauglichkeit für den Unternehmensalltag stehen im Vordergrund.
Für Fachanwender ohne technischen Hintergrund ist genau das der Reiz: Man muss weder ein Sprachmodell selbst betreiben noch eine Programmierschnittstelle ansprechen können, um eine funktionierende KI-Anwendung zu erhalten. Wo klassische Softwareentwicklung ein Projekt mit Entwicklern, Infrastruktur und langem Vorlauf bedeutet, verspricht Stack AI einen Weg über Konfiguration statt Programmierung. Das senkt die Einstiegshürde erheblich – verschiebt die eigentliche Arbeit aber, wie wir sehen werden, auf das saubere Zuschneiden von Anwendungsfällen, Daten und Verantwortlichkeiten.
Aus unserer Projektpraxis lässt sich die Zielgruppe recht klar umreißen. Stack AI ist ideal für Unternehmen, die konkrete KI-Anwendungsfälle rasch umsetzen wollen, ohne dafür ein eigenes Entwicklungsteam aufzubauen – etwa einen internen Wissensassistenten, eine automatische Vorsortierung von Anfragen oder einen Recherchehelfer für ein Fachteam. Überall dort, wo eine Fachabteilung eine KI-Idee hat, aber die Wartezeit auf ein klassisches Softwareprojekt scheut, spielt eine No-Code-Plattform ihre Stärke aus. Der Enterprise-Fokus macht sie zusätzlich für Organisationen interessant, die von Beginn an Wert auf Governance und Sicherheit legen.
Weniger geeignet ist Stack AI für hochspezialisierte Vorhaben, die tiefe, individuelle Eingriffe in Modelllogik oder Infrastruktur verlangen und bei denen ein eigenes Entwicklungsprojekt am Ende die passendere Antwort ist. Ebenso ist die Plattform als überwiegend cloudbasiertes Angebot eines Anbieters mit Sitz außerhalb der EU dann sorgfältig zu prüfen, wenn strenge Anforderungen an Datenhoheit und Serverstandort bestehen – ein Punkt, den wir in Kapitel 07 und 09 vertiefen.
Der Kern der Sache lässt sich an einem typischen Projektmoment festmachen. In fast jedem KI-Vorhaben liegt der eigentliche Aufwand nicht im Sprachmodell selbst – das ist ohnehin verfügbar –, sondern im Drumherum: die eigenen Dokumente durchsuchbar machen, die Anfrage sauber an das Modell übergeben, das Ergebnis in eine brauchbare Form bringen und dem Anwender eine verständliche Oberfläche geben. Genau diese undankbare Verdrahtungsarbeit nimmt eine No-Code-Plattform weitgehend ab. Was ohne sie ein mehrwöchiges Entwicklungsprojekt wäre, wird zu einer Frage von Konfiguration und Feinschliff.
Dieser Ansatz verschiebt die Grenze dessen, was eine Fachabteilung ohne Entwickler selbst bauen kann, spürbar nach oben. Gleichzeitig verlangt er Verantwortung: Eine Anwendung, die schnell zusammengeklickt ist, muss trotzdem geprüft, gepflegt und im Zweifel abgesichert werden – gerade wenn sie mit echten Unternehmensdaten arbeitet. Stack AI nimmt Unternehmen also nicht die Denkarbeit ab, sondern gibt Fachbereichen ein Werkzeug in die Hand, mit dem sie deutlich weiter kommen als bisher. Ob dieses Werkzeug zum Vorteil oder zur Belastung wird, hängt – wie bei jeder Plattform – von der Disziplin bei Anwendungsfall-Auswahl, Datenpflege und Governance ab.
Im Zentrum steht der visuelle Builder: die Umgebung, in der eine KI-Anwendung aus Datenquellen, Modellen, Logik und Oberfläche zusammengesetzt wird. Um diesen Kern herum haben sich weitere Bereiche gebildet, die denselben Unterbau nutzen, aber unterschiedliche Bedürfnisse bedienen – von der reinen internen Anwendung über bereitgestellte Assistenten bis hin zu Schnittstellen, die andere Systeme ansprechen. Ergänzt wird das durch die Verwaltungsebene, auf der Nutzer, Rechte und Sicherheit organisiert werden.
Stack AI besetzt eine Position zwischen zwei Welten. Auf der einen Seite steht die klassische Softwareentwicklung, bei der eine KI-Anwendung von Grund auf mit eigenen Entwicklern, Bibliotheken und Infrastruktur gebaut wird – maximal flexibel, aber aufwendig und langsam. Auf der anderen Seite stehen fertige KI-Produkte von der Stange, die zwar sofort nutzbar, aber kaum an eigene Prozesse und Daten anpassbar sind. Stack AI positioniert sich dazwischen: die Geschwindigkeit einer fertigen Lösung, kombiniert mit der Anpassbarkeit einer selbst gebauten Anwendung – und das über Konfiguration statt Programmierung.
Diese Positionierung erklärt, warum Stack AI besonders für Organisationen interessant ist, die viele verschiedene KI-Anwendungsfälle haben, aber nicht für jeden ein eigenes Entwicklungsprojekt starten wollen. Der Enterprise-Fokus erweitert die Positionierung zusätzlich in Richtung derjenigen, die KI nicht nur ausprobieren, sondern verantwortlich und kontrolliert im Unternehmen verankern wollen. Damit grenzt sich Stack AI von rein entwicklerorientierten Werkzeugen ab, bei denen die Governance-Frage oft erst spät und mühsam beantwortet wird.
Ein wichtiger Punkt der Einordnung ist das Betriebsmodell. Stack AI ist im Kern ein cloudbasiertes Angebot: Die Plattform läuft auf der Infrastruktur des Anbieters, man benötigt lediglich einen Zugang, um zu beginnen. Für Unternehmen mit erhöhten Anforderungen an Datenhoheit stellt der Anbieter jedoch – nach eigener Darstellung und je nach Vertragsmodell – weitergehende Optionen in Aussicht, bis hin zu On-Premises- beziehungsweise privat gehosteten Varianten. Ob und in welcher Form diese verfügbar sind, unter welchen Bedingungen und mit welchem Aufwand, sollte im Einzelfall direkt beim Anbieter geprüft werden. Für Unternehmen mit strengen Souveränitätsanforderungen ist diese Unterscheidung zentral – wir kommen darauf in Kapitel 07 und 09 zurück.
Jede Anwendung folgt demselben Grundmuster: eine Eingabe am Anfang, danach eine Kette aus Schritten, am Ende eine Ausgabe. Ein Schritt kann ein Modellaufruf sein, ein Zugriff auf die Wissensdatenbank, eine Verzweigung oder die Anbindung an ein anderes System. Entscheidend ist, dass jeder Schritt auf die Ergebnisse der vorherigen zugreifen kann: Was ein Modellbaustein liefert, steht den nachfolgenden Schritten strukturiert zur Verfügung. So entsteht ein Datenfluss von der Eingabe bis zur fertigen Antwort, der sich im Builder nachvollziehen lässt.
Ein typisches Beispiel aus dem Kundenservice: Die Eingabe ist die Nachricht eines Kunden. Ein Modellbaustein ordnet die Anfrage einem Thema zu. Je nach Ergebnis verzweigt der Ablauf – bei einer Wissensfrage greift ein RAG-Schritt auf die Handbücher zu und formuliert einen Antwortentwurf, bei einer Beschwerde wird ein Mitarbeiter benachrichtigt. Am Ende steht entweder ein Antwortvorschlag im Formular oder eine strukturierte Weitergabe an ein anderes System. Was ohne Plattform ein Entwicklungsprojekt wäre, entsteht hier durch Konfiguration.
Der wichtigste Baustein für den Unternehmenseinsatz verdient eine genauere Betrachtung. Eine Wissensdatenbank in Stack AI ist im Kern eine Sammlung eigener Dokumente, die so aufbereitet wird, dass die KI gezielt darauf zugreifen kann. Die Dokumente werden in Abschnitte zerlegt, in eine durchsuchbare Form gebracht und bei jeder Anfrage nach den passenden Stellen durchsucht. Nur diese relevanten Ausschnitte gehen an das Sprachmodell – das ist der Kern von RAG. Der Effekt: Die Antworten stützen sich auf das tatsächliche Unternehmenswissen statt auf das allgemeine, teils veraltete oder ungenaue Wissen des Modells.
Damit deckt Stack AI einen Bereich ab, der für die meisten Unternehmensanwendungen entscheidend ist – denn erst der Bezug auf die eigenen Daten macht einen Assistenten wirklich nützlich. Der Preis dafür ist Sorgfalt bei der Datenpflege: Eine Wissensdatenbank ist nur so gut wie die Dokumente, die in ihr liegen. Veraltete, widersprüchliche oder schlecht strukturierte Inhalte führen zu schlechten Antworten. Wir empfehlen in Projekten, die Wissensbasis bewusst kuratiert und aktuell zu halten, statt wahllos alle verfügbaren Dokumente einzuspeisen.
Eine der praktischen Stärken ist, dass die fertige Anwendung nicht im Builder gefangen bleibt. Zu jeder Lösung lässt sich eine Bedienoberfläche erzeugen – ein Formular, eine Chat-Oberfläche oder eine kleine Web-Anwendung –, die Endanwender direkt nutzen können. Alternativ oder ergänzend lässt sich die Anwendung als API bereitstellen, sodass andere Systeme sie aufrufen und in eigene Prozesse einbinden können. Damit deckt Stack AI beide typischen Bedürfnisse ab: die direkte Nutzung durch Menschen und die Einbindung in eine bestehende Systemlandschaft. Wir prüfen in Projekten immer, welche Form zur Anforderung passt – eine geführte Oberfläche für Fachanwender oder eine Schnittstelle für die technische Integration.
Die KI-Fähigkeiten von Stack AI lassen sich grob in drei Bereiche gliedern: die Anbindung von Sprachmodellen als Baustein im Ablauf, die Fundierung der Antworten auf eigenen Daten über RAG sowie der Aufbau von Assistenten und Agenten, die mehrere Schritte selbstständiger abarbeiten. Allen gemeinsam ist das Ziel, KI über eine bloße Chat-Antwort hinaus in konkrete, wiederholbare Abläufe zu bringen, die mit den Daten und Prozessen des Unternehmens verbunden sind.
Die naheliegendste Nutzung ist ein Modellbaustein innerhalb eines Ablaufs. Man wählt ein Sprachmodell, formuliert die Anweisung – den Prompt – und übergibt die Eingaben aus den vorherigen Schritten. Ein solcher Baustein kann eine eingehende Nachricht zusammenfassen, eine Anfrage nach Thema klassifizieren, aus einem Freitext strukturierte Felder extrahieren oder einen Antwortentwurf formulieren. Weil Stack AI verschiedene Modell-Anbieter unterstützt, lässt sich das Modell an die Aufgabe anpassen: ein leistungsfähiges für anspruchsvolle Aufgaben, ein schlankeres für einfache und häufige Aufrufe.
Aus unserer Sicht ist das der praxisnaheste KI-Einsatz: gezielt dort, wo eine Aufgabe Sprachverständnis erfordert, das sich mit starren Regeln nicht abbilden lässt. Ein spürbarer Vorteil gegenüber fest verdrahteten KI-Produkten ist die Wahlfreiheit beim Modell – man ist nicht an einen einzigen Anbieter gebunden und kann die Anbindung an die eigenen Anforderungen an Qualität, Kosten und Datenschutz ausrichten. Genau diese Wahl ist, wie wir in Kapitel 09 zeigen, auch datenschutzrechtlich relevant.
Ein Schwerpunkt, der über einfache Modellaufrufe hinausgeht, sind Assistenten und Agenten. Ein Assistent ist im Kern eine dialogfähige Anwendung, die auf eine Wissensbasis und definierte Fähigkeiten zurückgreift und im Gespräch mit dem Nutzer Aufgaben erledigt. Weiter gehen agentische Ansätze, bei denen die KI eine Aufgabe in mehrere Schritte zerlegt, dazwischen auf Werkzeuge und Datenquellen zugreift und Zwischenergebnisse selbst weiterverarbeitet. Vereinfacht gesagt: Ein solches System kann nicht nur Text erzeugen, sondern über angebundene Werkzeuge echte Aktionen anstoßen – eine Information abrufen, einen Datensatz nachschlagen, eine Zusammenfassung erstellen.
Der Reiz liegt darin, dass sich mit überschaubarem Aufwand Anwendungen bauen lassen, die früher ein größeres Entwicklungsprojekt bedeutet hätten. Das Konzept ist mächtig, aber gerade in seiner agentischen Ausprägung noch jung und fehleranfällig. Wir raten dazu, agentische Ansätze zunächst in unkritischen, gut überwachbaren Szenarien einzusetzen, bei denen ein Mensch die Ergebnisse kontrolliert, bevor sie wirksam werden. Je mehr Autonomie ein Agent erhält, desto sorgfältiger müssen seine Grenzen und seine Kontrolle definiert sein.
In der Praxis empfehlen wir einen nüchternen Blick: KI ist kein Selbstzweck und nicht für jede Aufgabe 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, das Auffinden der richtigen Passage in einem umfangreichen Regelwerk. 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 klassische Regel.
Wir prüfen in Projekten daher 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 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. Ein wichtiges Thema bleibt zudem die Halluzination: Auch mit RAG kann ein Modell überzeugend klingende, aber falsche Antworten geben. Für belastbare Auskünfte braucht es deshalb Kontrollmechanismen und, wo nötig, die Prüfung durch einen Menschen.
Auf der ersten Ebene stehen die Modelle. Stack AI bindet mehrere Anbieter großer Sprachmodelle an, sodass sich für jede Aufgabe ein passendes Modell wählen lässt. Das ist mehr als eine Bequemlichkeit: Die Wahl des Modells beeinflusst Antwortqualität, Geschwindigkeit, Kosten und – besonders relevant für den DACH-Raum – die Frage, wohin die Daten fließen. Die Möglichkeit, zwischen Modellen zu wechseln, ist damit auch ein strategisches Werkzeug, um Abhängigkeit von einem einzelnen Anbieter zu vermeiden.
Die zweite Ebene sind die Datenquellen. Neben dem klassischen Hochladen von Dokumenten in eine Wissensdatenbank lassen sich – je nach verfügbaren Konnektoren – auch andere Quellen anbinden, aus denen die Anwendung Wissen und Kontext zieht. Für ein Unternehmen ist das entscheidend, denn der Wert einer KI-Anwendung steht und fällt mit dem Zugang zu den relevanten, aktuellen Daten. Je nahtloser sich die vorhandenen Wissensquellen einbinden lassen, desto weniger manuelle Pflege ist nötig und desto verlässlicher bleibt die Anwendung auf dem aktuellen Stand. Welche Konnektoren im konkreten Fall verfügbar sind, sollte anhand der eigenen Systemlandschaft direkt beim Anbieter geprüft werden.
Praktisch heißt das: Vor jeder Einführung steht die Frage, wo das relevante Wissen des Unternehmens liegt und wie es in die Plattform gelangt. Manchmal genügt der Upload einer überschaubaren Dokumentensammlung; in anderen Fällen ist eine laufende Anbindung an ein bestehendes System sinnvoller, damit die Wissensbasis nicht veraltet. Diese Klärung nehmen wir in Projekten früh vor, weil sie über Aufwand und Qualität der späteren Anwendung entscheidet.
Die dritte Ebene ist die Anbindung nach außen. Eine fertige Anwendung lässt sich nicht nur als eigenständige App nutzen, sondern auch als API bereitstellen, die andere Systeme aufrufen. Damit wird Stack AI zu einem Baustein in einer größeren Prozesskette: Ein bestehendes System übergibt eine Anfrage, die KI-Anwendung verarbeitet sie und liefert ein Ergebnis zurück, das wiederum weiterverarbeitet wird. Diese Fähigkeit unterscheidet eine ernstzunehmende Plattform von einer bloßen Chatbot-Oberfläche – erst sie macht KI zu einem integrierten Teil der bestehenden Software statt zu einer Insel neben ihr.
Bei allem Komfort gilt: Ein No-Code-Baukasten ist naturgemäß auf die vorgesehenen Bausteine und Konnektoren begrenzt. Solange ein Anwendungsfall innerhalb dieser Grenzen liegt, ist die Umsetzung schnell und bequem. Verlangt ein Vorhaben jedoch eine sehr spezielle Anbindung, ein exotisches Datenformat oder tiefe Eingriffe, für die kein Baustein vorgesehen ist, stößt man an die Grenzen der Plattform. Dann ist ehrlich zu prüfen, ob sich der Fall über die bereitgestellte API und etwas Zwischen-Logik dennoch lösen lässt – oder ob ein Teil des Vorhabens doch klassische Entwicklung erfordert. Wir benennen diese Grenze in Projekten bewusst früh, damit keine falschen Erwartungen entstehen.
Der wichtigste Unterschied lässt sich in einem Satz fassen: Stack AI ist eine kommerzielle, gemanagte Enterprise-Plattform, während Dify, Flowise und Langflow quelloffene Projekte sind, die man selbst hosten kann. Für ein Unternehmen bedeutet das eine grundlegende Abwägung. Bei Stack AI erhält man eine fertige, betriebene Umgebung mit Enterprise-Funktionen, muss dafür aber Daten in die Cloud eines externen Anbieters geben und laufende Kosten tragen. Bei den Open-Source-Alternativen behält man die volle Kontrolle und kann die Software auf eigener Infrastruktur betreiben, trägt dafür aber den Aufwand für Installation, Betrieb, Aktualisierung und Absicherung selbst.
Am nächsten kommt Stack AI konzeptionell die Plattform Dify. Beide verstehen sich als vollständige Umgebung zum Bauen von KI-Anwendungen mit Modell-Anbindung, RAG und Oberflächen – nicht nur als reiner Flow-Editor. Der entscheidende Unterschied liegt im Modell: Dify ist quelloffen und lässt sich selbst hosten, was für Datenhoheit und Souveränität ein gewichtiges Argument ist. Stack AI setzt dagegen auf eine gemanagte, kommerziell betreute Umgebung mit ausgeprägtem Enterprise- und Governance-Fokus. Flowise und Langflow wiederum sind stärker als visuelle Flow-Builder positioniert, bei denen man KI-Abläufe aus Knoten zusammensteckt; sie sind flexibel und quelloffen, richten sich aber tendenziell an ein technisch versierteres Publikum und bringen weniger fertige Enterprise-Verwaltung mit.
In unseren Projekten formulieren wir die Faustregel gern so: Stack AI für Unternehmen, die eine gemanagte Plattform mit Governance und wenig Betriebsaufwand wollen; Dify, wenn dieselbe Idee quelloffen und selbst gehostet realisiert werden soll; Flowise oder Langflow, wenn technisch versierte Teams maximale Flexibilität beim Zusammenstecken von Abläufen suchen. Nicht selten ist die beste Lösung eine bewusste Kombination – etwa ein Prototyp auf einer schnellen Plattform und der spätere produktive Betrieb auf einer selbst gehosteten Lösung, wenn Datenhoheit im Vordergrund steht.
Der große Vorteil des gemanagten Modells ist der schnelle Start. Es genügt ein Zugang, um sofort mit dem Bau von Anwendungen zu beginnen; Rechenzeit, Skalierung, Verfügbarkeit und Aktualisierung der Plattform übernimmt der Anbieter. Für Fachbereiche, die sich auf den eigentlichen Anwendungsfall konzentrieren wollen und nicht auf den Betrieb, ist das ein echter Gewinn. Der Enterprise-Fokus bedeutet zugleich, dass Governance-Themen – Rollen, Rechte, Nachvollziehbarkeit – nicht nachträglich aufgesetzt, sondern von Beginn an mitgedacht werden können.
Aus unserer Projektpraxis hat sich ein schrittweises Vorgehen bewährt, das dem Charakter einer KI-Plattform gerecht wird und trotzdem beherrschbar bleibt.
Der Enterprise-Fokus von Stack AI zeigt sich vor allem in den Governance-Funktionen. Dass sich Nutzer, Rollen und Rechte zentral verwalten lassen und Zugriffe nachvollziehbar sind, ist ein echter Vorteil gegenüber einer Bastellösung, bei der solche Themen erst mühsam nachgerüstet werden müssen. Für Unternehmen, die KI kontrolliert und verantwortlich einsetzen wollen, ist das ein gewichtiges Argument. Wichtig ist jedoch die Unterscheidung: Governance-Funktionen regeln, wer intern was darf – sie beantworten aber nicht automatisch die Frage der Datenhoheit, also wo die Daten physisch liegen und wer außerhalb des Unternehmens Zugriff haben könnte. Beide Themen sind wichtig, aber getrennt zu bewerten.
Nach dem Start verschiebt sich der Fokus vom Bauen auf das Betreiben. Zentrale Themen sind die Beobachtung der Antwortqualität, die Pflege der Wissensdatenbank und die Kontrolle der Kosten. Anders als bei klassischer Software ist eine KI-Anwendung nie vollständig „fertig“: Modelle ändern sich, Daten veralten, Anforderungen wandeln sich. Wir empfehlen, für jede produktive Anwendung festzulegen, wer sie verantwortet, wie oft die Wissensbasis aktualisiert wird und wie mit fehlerhaften oder unerwünschten Ausgaben umgegangen wird. Diese Betriebsdisziplin entscheidet darüber, ob eine KI-Anwendung dauerhaft nützlich bleibt oder schleichend an Qualität verliert.
Auffällig ist ein Muster: Stack AI glänzt dort, wo eine klar umrissene Aufgabe mit den eigenen Daten verbunden wird – eine Wissensfrage, eine Einordnung, eine Zusammenfassung, ein Antwortentwurf. Sobald der Anwendungsfall scharf definiert ist und die nötigen Daten in guter Qualität vorliegen, entsteht mit überschaubarem Aufwand etwas Nutzbares. Der Mehrwert entsteht weniger durch technische Raffinesse als durch die schnelle Umsetzbarkeit von Anwendungen, die früher ein Entwicklungsprojekt bedeutet hätten.
Wichtig für die Erwartungshaltung: Der Nutzen realisiert sich nur, wenn Anwendungsfall und Daten stimmen. Ein unscharf definierter Anwendungsfall führt zu einer Anwendung, die niemand richtig nutzt; eine schlecht gepflegte Wissensbasis führt zu Antworten, denen niemand traut. Ein KI-Assistent, der gelegentlich überzeugend klingende, aber falsche Auskünfte gibt und den niemand kontrolliert, ist kein Fortschritt, sondern ein Risiko. Deshalb steht in unseren Projekten immer die ehrliche Frage nach Anwendungsfall, Datenqualität und Kontrollmechanismus vor dem Bau der ersten Anwendung.
Ein typischer Verlauf: Es beginnt mit einer einzelnen Anwendung, die ein konkretes Problem löst. Schnell folgen weitere, weil der Nutzen sichtbar wird. Nach einigen Monaten existiert eine ganze Sammlung – oft mit unterschiedlichen Wissensbasen, verteilt über mehrere Fachbereiche. Genau an diesem Punkt entscheidet sich, ob KI zum Vorteil oder zur unübersichtlichen Insellandschaft wird. Bei einer Plattform mit Enterprise-Governance wiegt dieser Punkt weniger schwer als bei einer Bastellösung, weil sich Zugriffe und Verantwortlichkeiten zentral verwalten lassen – vorausgesetzt, man nutzt diese Möglichkeiten auch.
Wir empfehlen daher, schon bei der zweiten oder dritten Anwendung eine einfache Übersicht anzulegen: Welche Anwendung erfüllt welchen Zweck, mit welchen Daten arbeitet sie, welches Modell nutzt sie, wer ist verantwortlich und welche Daten verlassen dabei das Unternehmen. Diese schlanke Dokumentation kostet wenig Aufwand, ist aber die Grundlage, um die KI-Landschaft überschaubar und datenschutzkonform zu halten und später fundiert über Ausbau oder Konsolidierung zu entscheiden.
Zur Kostenlogik zuerst: Bei einer KI-Plattform entstehen die Kosten typischerweise auf zwei Ebenen. Erstens die Plattformkosten für die Nutzung von Stack AI selbst – meist gestaffelt nach Funktionsumfang, Zahl der Nutzer und Nutzungsvolumen. Zweitens die Modellkosten für die eigentlichen KI-Aufrufe, die je nach Modell und Anbieter anfallen und mit der Nutzung skalieren. Konkrete Preise nennen wir hier bewusst nicht, weil der Anbieter Pläne und Konditionen regelmäßig anpasst. Entscheidend ist das Verständnis der Logik dahinter – die bleibt stabiler als jede Zahl. Verbindliche Konditionen sollten direkt beim Anbieter geprüft werden.
Der wichtigste Mechanismus: Kosten skalieren mit Nutzungsvolumen und Modellaufwand. Eine Anwendung, die selten genutzt wird und schlanke Modelle für einfache Aufgaben einsetzt, verursacht wenig; eine Anwendung, die sehr häufig aufgerufen wird oder ein leistungsstarkes, teureres Modell für jede Anfrage nutzt, verursacht mehr. Für den Mittelstand heißt das: Bei überschaubarem Volumen bleibt der Einsatz kalkulierbar, bei breiter Nutzung mit anspruchsvollen Modellen lohnt eine ehrliche Hochrechnung, bevor produktiv skaliert wird. Wir erstellen diese Hochrechnung in Projekten standardmäßig – erwartete Aufrufe, multipliziert mit dem typischen Aufwand und Modellpreis pro Aufruf – damit die tatsächlichen Kosten sichtbar werden, bevor eine Anwendung produktiv geht.
Datenschutzrechtlich ist der zentrale Ausgangspunkt: Stack AI ist ein Anbieter mit Sitz außerhalb der EU, dessen Plattform in der Standardnutzung cloudbasiert ist. Bei der Nutzung fließen Daten durch die Infrastruktur des Anbieters – und potenziell durch die Clouds der angebundenen Modell-Anbieter und Datenquellen. Wo eine Anwendung personenbezogene Daten verarbeitet – Namen, E-Mail-Adressen, Kontaktdaten, Inhalte von Anfragen – wird Stack AI zum Auftragsverarbeiter, und es gelten die entsprechenden Anforderungen der DSGVO.
Als Unternehmen mit Sitz außerhalb der EU unterliegt Stack AI grundsätzlich fremdem Recht. Auch wenn der Anbieter Schutzmaßnahmen und vertragliche Zusicherungen bietet, bleibt – wie bei allen Nicht-EU-Cloud-Diensten – ein rechtliches Restrisiko hinsichtlich behördlicher Zugriffsmöglichkeiten bestehen. Für viele Mittelständler ist dieses Risiko bei nicht hochsensiblen Daten und sauberer vertraglicher Grundlage tragbar. Für besonders schützenswerte Datenkategorien, für Berufsgeheimnisträger oder für Unternehmen mit hohen Souveränitätsanforderungen ist es jedoch ein gewichtiges Gegenargument. Hier gewinnt die Frage an Bedeutung, ob eine EU-Region oder eine On-Premises- beziehungsweise privat gehostete Variante verfügbar ist – diese Optionen können die datenschutzrechtliche Bewertung erheblich vereinfachen und sollten gezielt beim Anbieter erfragt werden.
Eine Besonderheit von KI-Plattformen ist, dass Daten nicht nur durch Stack AI selbst, sondern auch durch die angebundenen Modell-Anbieter und Datenquellen fließen. Eine einzige Anwendung kann Daten aus einer europäischen Quelle ziehen, durch die Stack-AI-Infrastruktur leiten, zur Verarbeitung an einen Modell-Anbieter senden und das Ergebnis in einem anderen System ablegen. Diese Kette muss vollständig betrachtet werden – Datenschutz endet nicht an der Plattform-Grenze. Besonders relevant ist der Schritt zum Modell: Genau hier verlassen Inhalte das Unternehmen und werden von einem KI-Dienst verarbeitet. Die Wahl EU-basierter oder lokal betreibbarer Modelle ist deshalb eine der wirksamsten Stellschrauben für einen datenschutzkonformeren Betrieb. Wir kartieren in Projekten für jede produktive Anwendung den kompletten Datenfluss von der Eingabe bis zur Ausgabe, ausdrücklich einschließlich der beteiligten Modelle.
Wenn Datenhoheit und Souveränität im Vordergrund stehen, ist die überwiegend cloudbasierte Natur von Stack AI ein Punkt, der sorgfältig geprüft werden muss. Zwei Wege können die Bewertung verbessern: erstens die Nutzung einer EU-Region oder On-Premises-Variante, falls der Anbieter sie anbietet; zweitens die konsequente Wahl von Modellen, die in der EU oder lokal betrieben werden. Reichen diese Optionen nicht aus, prüfen wir mit Kunden gezielt selbst-hostbare Alternativen wie die quelloffenen Plattformen Dify, Flowise oder Langflow, bei denen die Daten die eigene Infrastruktur nicht verlassen müssen. Das verlagert zwar den Aufwand auf Betrieb und Wartung, kann aber die datenschutzrechtliche Bewertung erheblich vereinfachen. Die Entscheidung ist letztlich eine Abwägung zwischen der Bequemlichkeit und den Enterprise-Funktionen der gemanagten Plattform und der Kontrolle über die eigenen Daten – und sollte bewusst getroffen werden.
