Private-Cloud-KI-App-Builder: Was Unternehmen brauchen

Ein Private-Cloud-KI-App-Builder ist eine Plattform, bei der das KI-gestützte Building-Erlebnis Anwendungen produziert, die in Infrastruktur laufen, die ihr kontrolliert: euer eigenes AWS-, Azure- oder GCP-Konto oder eine für euch bereitgestellte private VPC. Die Unterscheidung klingt nach Klempnerei, aber für ein Unternehmen ist sie häufig der Unterschied zwischen einem Tool, das das Security-Review besteht, und einem Tool, das im Procurement stirbt. Denn wo die Software und ihre Daten leben, bestimmt, welche Richtlinien, Regulierer und Verträge gelten.

Das Bedürfnis ist einfach zu formulieren. Fachbereiche wollen die Geschwindigkeit, eine Anwendung zu beschreiben und funktionierende Software zu bekommen. Security-Teams brauchen, dass diese Software, und die Daten darin. Netzwerkgrenzen, Residency-Regeln und Zugriffsrichtlinien respektiert, die bereits existieren. Ein Builder, der nur auf seiner eigenen Shared Cloud hosten kann, zwingt zur Wahl zwischen diesen beiden Gruppen. Ein Private-Cloud-Builder löst den Konflikt auf: dasselbe Building-Erlebnis, Deployment innerhalb des Perimeters.

Dieser Artikel legt die Anforderungsliste dar, gegen die Unternehmen testen sollten. Deployment-Ziele, Modell-Datenverarbeitung, Identität, Audit, Zertifizierungen, einen Vergleich der vier Deployment-Modelle und eine Evaluierungssequenz, die Ausschlusskriterien in der ersten Woche zutage fördert statt in der letzten.

Der Blocker ist selten der Anwendungscode; es sind die Daten. Ein internes Tool ist nur nützlich, wenn es sich mit Kundendatensätzen, Finanzdaten oder operativen Systemen verbindet. Genau die Datenklassen, die Residency-Gesetze, Branchenregulierung und Kundenverträge regeln. Wenn die Plattform Workloads nur auf ihrer eigenen Multi-Tenant-Infrastruktur betreiben kann, braucht jede dieser Datenklassen eine Ausnahme, ein Legal-Review oder ein Redesign. Die meisten Projekte überleben diese Warteschlange nicht.

Das Security-Review baut die zweite Mauer. Enterprise-Security-Teams bewerten Netzwerkisolation, Verschlüsselungsgrenzen, Admin-Zugriffspfade und Incident-Prozeduren. Multi-Tenant-Plattformen können darauf gut antworten. Viele tun es, aber manche Organisationen haben harte Regeln, die keine Antwort erfüllt: Dieser Workload verlässt unsere Tenancy nicht. Für sie lautet die Frage nicht, ob die Cloud des Anbieters gut ist; sondern ob die Cloud des Anbieters ihre ist.

Die dritte Mauer ist die KI selbst. KI-App-Builder senden Prompts, Kontext und manchmal Code an Modellanbieter, also stellt das Procurement neue Fragen: Wo läuft die Inferenz, wird irgendetwas gespeichert, wird unser Code fürs Training verwendet? Eine enterprise-taugliche Plattform braucht vertragliche Antworten. Zero-Retention-Inferenzbedingungen und eine klare Aussage, dass Kundencode keine Modelle trainiert. Neben den Infrastruktur-Antworten. Ohne sie wird die KI-Pipeline zum Datenleck, das der Rest der Architektur verhindern sollte.

Beachtet, dass alle drei Mauern von verifizierbarem Ort und Kontrolle handeln, nicht von Produktqualität. Deshalb läuft diese Evaluierung anders als die meisten Softwarekäufe: Die Demo zählt weniger als das Architekturdiagramm, und die Feature-Liste zählt weniger als das, was euer Security-Team unabhängig inspizieren kann. Die Anforderungsliste unten ist entsprechend geordnet. Deployment zuerst, weil es entscheidet, ob der Rest des Gesprächs überhaupt stattfindet.

Das erste Missverständnis ist, dass privates Deployment ein schlechteres Building-Erlebnis bedeutet. Es stammt aus einer älteren Generation von Enterprise-Software, in der die Self-Hosted-Edition dem Cloud-Produkt ein Jahr hinterherhinkte. Auf einer gut architektierten Plattform ist das Building-Erlebnis identisch, unabhängig vom Deployment-Ziel; was sich ändert, ist, wo die Anwendungen und ihre Daten landen. Prüft diese Behauptung direkt im Piloten. Baut in derselben Sitzung, die euer Security-Team inspiziert, statt entweder die Angst oder das Versprechen anzunehmen.

Das zweite Missverständnis läuft in die andere Richtung: dass Private Cloud bedeutet, euer Team betreibt alles. In der Praxis teilen die Modelle die Arbeit auf. In eurem eigenen Cloud-Konto oder einer privaten VPC gehören Tenancy und Netzwerkgrenzen euch, während der Plattformanbieter die Plattform trägt. Die Shared-Responsibility-Linie dokumentiert zu bekommen, Service für Service, ist nützlicher als jede allgemeine Zusicherung, und es ist eine Ein-Seiten-Anfrage, die jeder ernsthafte Anbieter beantworten kann.

Das dritte Missverständnis ist, dass sich Deployment-Modelle später entscheiden lassen. Ein Programm mitten im Flug von Shared Cloud auf privates Deployment umzurüsten bedeutet, das Security-Review erneut zu durchlaufen, Datenvereinbarungen neu aufzusetzen und manchmal Daten umzuziehen. Alles teurer, als am Anfang richtig zu wählen. Die Datenklassifizierungsübung aus Schritt eins kostet eine Woche und verhindert genau das. Entscheidet das Deployment-Modell beim Programmstart, selbst wenn der erste Pilot-Workload anspruchslos ist.

Das letzte Missverständnis ist, dass eine Zertifizierung das Gespräch beendet. SOC 2 Type II ist die Eintrittskarte, und eure Prüfer brauchen trotzdem die Architektur: wo Inferenz läuft, welche Metadaten die Grenze verlassen, wer Admin-Zugriff hält und wie dieser Zugriff protokolliert wird. Ein Anbieter, der diese Details entspannt mit eurem Security-Team durchgeht, zeigt euch die Haltung, die das Zertifikat nur zusammenfasst.

Automo wurde mit der Deployment-Frage als erstklassigem Feature gebaut statt als Enterprise-Nachgedanke. Anwendungen deployen in die Automo-Cloud, euer eigenes AWS-, Azure- oder GCP-Konto, eine private VPC oder On-Prem unter separaten Bedingungen. Sodass das Building-Erlebnis, das Fachbereiche wollen, und die Infrastrukturkontrolle, die Security-Teams verlangen, kein Trade-off mehr sind. Die zugrunde liegende Plattform läuft auf Kubernetes mit isolierten Pods, Hibernation und Aufwachen sowie Multi-Region-Unterstützung.

Die Procurement-Antworten sind ebenso konkret. SOC 2 Type II Berichte sind unter NDA verfügbar. SSO funktioniert via SAML und OIDC mit optionaler MFA und rollenbasierter Zugriffskontrolle. Kundencode wird nicht zum Training von Modellen verwendet, und Inferenz läuft unter Zero-Retention-Modellverträgen. Ein unveränderlicher (append-only) Audit-Trail deckt Prompts, Merges, Deployments und Admin-Aktionen ab, und alles, was Automo baut, ist Standard-React, TypeScript und Supabase mit 100 % Code-Eigentum, jederzeit exportierbar in euer eigenes Repository.

Kommerziell ist das Enterprise-Software: Ernsthafte Entwicklungsprogramme starten bei 10.000 USD pro Jahr, und Private-Cloud- und On-Prem-Arrangements werden mit dem Vertrieb abgesteckt. Wenn eure Evaluierung echt ist, ist der schnellste Weg ein Gespräch, das mit eurer Datenklassifizierung und dem erforderlichen Deployment-Modell beginnt. Den beiden Fakten, die alles andere bestimmen.