Low-Code im eigenen Rechenzentrum

Was On-Premise bei Low-Code-Anbietern wirklich bedeutet, und welche Fragen vor der Entscheidung zu klären sind.

Die meisten Low-Code-Plattformen sind Mietsysteme. So ist ihr Geschäftsmodell angelegt, und solange eine Anwendung nur einen kleinen Prozess trägt, spricht nichts dagegen. Zum Problem wird es, sobald diese Anwendung personenbezogene Daten verarbeitet, zehn Jahre laufen soll und in einem Bereich liegt, in dem Sie jederzeit auskunftsfähig sein müssen.

Warum die Frage schwerer zu beantworten ist, als sie klingt

„Können wir das on-premise betreiben?“ ist eine Ja-Nein-Frage, auf die es drei verschiedene Jas gibt. Anbieter verwenden denselben Begriff für eine dedizierte Cloud-Instanz, für eine selbst gehostete, aber lizenzgebundene Laufzeitumgebung und für ein eigenständig lauffähiges System. Zwischen diesen drei Antworten liegt der Unterschied zwischen Handlungsfähigkeit und Abhängigkeit.

Erschwerend kommt hinzu, dass die Frage im Auswahlprozess meist zu spät gestellt wird. Dann nämlich, wenn die Fachabteilung sich längst in einen Prototyp verliebt hat. Deshalb lohnt sich die halbe Stunde vorher.

Drei Stufen, ein Wort

Alle drei heißen im Vertrieb On-Premise. Fragen Sie nach, welche gemeint ist: Handlungsfähig sind Sie erst auf der dritten.

Dedizierte Cloud-Instanz

Läuft weiter beim Anbieter, nur getrennt von anderen Kunden und oft in einer EU-Region. Endet der Vertrag, endet die Anwendung.

Selbst gehostete Laufzeitumgebung

Die Plattform steht in Ihrem Rechenzentrum, gehört aber dem Anbieter. Fragen Sie, ob sie ohne gültige Lizenz weiterläuft, und ob Anmeldung per SSO, feine Rechte und Protokolle im eigenen Betrieb überhaupt dabei sind.

Eigenständige Anwendung

Ein gewöhnliches Software-Projekt: Container, Git-Repository, Datenbank. Wo es läuft, ist eine Frage Ihrer Infrastruktur und nicht mehr Ihres Vertrags.

Was ein Zertifikat abdeckt und was Ihre Aufgabe bleibt

Ein Anbieter kann nach SOC 2 Type II und ISO 27001 zertifiziert sein, seine Plattform in der EU betreiben und trotzdem für Ihr Verfahren ungeeignet sein. Die Zertifikate beschreiben, wie der Anbieter seinen Betrieb führt. Ihre Verantwortung als Verantwortlicher im Sinne der DSGVO nehmen sie Ihnen nicht ab.

Praktisch relevant sind vier Dinge: der tatsächliche Verarbeitungsort einschließlich Backups, die vollständige Liste der Unterauftragsverarbeiter, bei der bei KI-Funktionen fast immer Modellanbieter mit drinhängen, die Umsetzbarkeit von Betroffenenrechten in der Anwendung selbst und ein Löschkonzept, das auf Datensatzebene greift.

Was vor der Plattformentscheidung geklärt sein sollte

Nicht juristisch erschöpfend, aber ausreichend, um in einer Stunde zu erkennen, ob ein Anbieter für ein verarbeitungsrelevantes Verfahren infrage kommt.

An welchem physischen Ort werden die Daten verarbeitet, und wo die Sicherungen?

„EU-Region“ auf der Produktseite genügt nicht. Verlangen Sie die Angabe im Vertrag, einschließlich Backups und Protokolldaten.

Wer sind die Unterauftragsverarbeiter?

Bei KI-Funktionen hängen fast immer Modellanbieter mit drin. Lassen Sie sich die vollständige Liste geben und prüfen Sie, ob sie einseitig geändert werden darf.

Gilt das Zertifikat der Plattform oder Ihrem Verfahren?

SOC 2 und ISO 27001 beschreiben den Betrieb des Anbieters. Über die Sicherheit dessen, was Sie damit bauen, sagen sie nichts.

Werden Ihre Eingaben zum Training verwendet?

Achten Sie darauf, ob das ein Widerspruchs- oder ein Zustimmungsrecht ist, und ob die Einstellung an einen teureren Tarif gebunden ist.

Lassen sich Betroffenenrechte in der Anwendung umsetzen?

Auskunft, Berichtigung, Löschung: Das muss die Anwendung können, nicht der Support des Anbieters.

Gibt es ein Lösch- und Aufbewahrungskonzept auf Datensatzebene?

Zehn Jahre für Belege, ein Jahr für Protokolle, danach anonymisieren: solche Regeln gehören ins Datenmodell, nicht in eine Betriebsanweisung.

Was passiert am Tag nach der Kündigung?

Lassen Sie sich schriftlich geben, in welchem Format Sie Daten und Anwendung erhalten, und wie lange die Anwendung ohne den Anbieter weiterläuft.

Wie wir es lösen

Konzeption bei uns

Das Anforderungsgespräch mit Claudette und die Konfiguration laufen auf unseren Systemen in Deutschland. Der Einsatz des Sprachmodells ist offengelegt und vertraglich geregelt.

Betrieb, wo Sie wollen

Die generierte Anwendung ist ein Container-Deployment: unser Kubernetes-Betrieb, Ihre Cloud oder Ihr Rechenzentrum, dieselbe Anwendung, nur ein anderer Ort.

Ohne KI im Betrieb

Die fertige Anwendung braucht kein Sprachmodell. Sie läuft in einem abgeschotteten Netz genauso wie mit Internetzugang.

Kein Training mit Ihren Eingaben

Weder wir noch der Modellanbieter geben Ihre Eingaben in ein Training. Sie werden verarbeitet, um Ihre Anwendung zu erzeugen, und für nichts sonst.

Vault - ein sicherer, verschlüsselter Credential Store

Sicherheit, die im Datenmodell beginnt

Zugriffsrechte setzen wir nicht nachträglich auf, sondern legen sie in der Architektur an: Regeln greifen auf Anwendungs-, Modell- und Feldebene, zeilenbasierte Filter schränken jede Abfrage automatisch auf den erlaubten Ausschnitt ein, und besonders schützenswerte Felder liegen verschlüsselt in SOLUTIONS.vault, sichtbar erst nach einer zweiten Authentifizierung. Rollen und Rechte pflegen wir dabei als versionierte Konfiguration im Repository und halten sie damit reproduzierbar und prüfbar.

Weiterlesen

Häufige Fragen

Welche Low-Code-Plattformen kann man on-premise betreiben?

Deutlich weniger, als das Marketing vermuten lässt. Bei vielen Anbietern bedeutet „On-Premise“ eine dedizierte Cloud-Instanz, nicht Ihr Rechenzentrum, und ist an den teuersten Vertrag gebunden. Prüfen Sie drei Dinge konkret: Läuft die Laufzeitumgebung ohne Verbindung zum Anbieter? Bekommen Sie Container-Images oder nur einen Zugang? Und was passiert mit der Anwendung, wenn die Lizenz endet?

Ist Low-Code DSGVO-konform?

Die Plattform kann zertifiziert sein und die damit gebaute Anwendung trotzdem nicht konform betrieben werden. Zertifikate wie SOC 2 oder ISO 27001 gelten für den Anbieterbetrieb, nicht für Ihr Verfahren. Entscheidend sind Verarbeitungsort, Auftragsverarbeitungsvertrag, Unterauftragsverarbeiter, Löschkonzept und Ihre Fähigkeit, Betroffenenrechte in der Anwendung tatsächlich umzusetzen.

Wo liegen die Daten bei Prompt Your App?

Während der Konzeptionsphase auf unseren Systemen in Deutschland. Für den produktiven Betrieb wählen Sie: unser Kubernetes-Betrieb, Ihre eigene Cloud oder Ihr Rechenzentrum. Weil die generierte Anwendung ein gewöhnliches Container-Deployment ist, ist das eine Frage des Betriebs, nicht des Nutzungsrechts.

Verlässt unser Anforderungstext das Haus, wenn wir mit der KI sprechen?

Für das Anforderungsgespräch nutzen wir ein Sprachmodell eines externen Anbieters. Das legen wir offen und regeln es im Auftragsverarbeitungsvertrag. Die fertige Anwendung braucht anschließend kein Sprachmodell mehr: Sie läuft ohne KI-Anbindung, auch vollständig abgeschottet.

Werden unsere Eingaben zum Training verwendet?

Nein. Weder wir noch der Modellanbieter geben Ihre Eingaben in ein Training. Verarbeitet werden sie zu einem einzigen Zweck: Ihre Anwendung daraus zu erzeugen. Dafür sehen wir uns das Datenmodell an, das im Designer entsteht, denn ohne das lässt sich nichts generieren. Eine Auswertung der Gespräche für eigene Zwecke findet nicht statt.

Was ist mit dem EU AI Act?

Für Sie als Anwender ist relevant, dass Transparenzpflichten dokumentiert sind. Unser Einsatz von KI ist in der Datenschutzerklärung zum KI-Einsatz offengelegt; die generierte Anwendung selbst enthält kein KI-System, solange Sie keines beauftragen.