Warum Enterprise-AI-Anwendungsplattformen zuerst selbst gehostet werden sollten
Sobald AI Geschäftsdaten liest, Workflows auslöst, Anwendungen erzeugt und Tools aufruft, muss das Unternehmen die Runtime kontrollieren, die Objekte, Rechte, Tools, Freigaben und Audit steuert.
Bei AI-Einführung achten Unternehmen oft zuerst auf das Modell: Kontextfenster, Reasoning, Latenz und Generierung.
Sobald AI aber Kunden, Aufträge, Verträge, Tickets, Freigaben und interne Dateien liest, werden andere Fragen wichtiger:
Wo laufen diese Daten? Wer hat Zugriff? Wo landen Logs? Wer kontrolliert Schlüssel? Wer kann stoppen, wenn etwas schiefgeht?
Deshalb sind selbst gehostete AI-Anwendungsplattformen wichtig.
Zuerst selbst gehostet werden muss nicht immer das Modell. Es ist die AI-Anwendungsruntime.
Modelle können extern oder lokal sein. Die Runtime, die Geschäftsobjekte, Berechtigungen, Workflows, Agent-Tools und Audit-Nachweise hält, sollte in Infrastruktur laufen, die das Unternehmen kontrolliert. Das Modell schlussfolgert; die Runtime entscheidet, was gelesen, ausgeführt, freigegeben und protokolliert wird.
Self-hosted ist mehr als Installation
Self-hosting ist nicht nur ein Installer oder eine Private-Deployment-Option. Entscheidend ist die Verantwortungsgrenze.
- Geschäftsdaten bleiben in Ihrer Datenbank.
- Dateien bleiben in Ihrem Storage.
- Identität und Rechte kommen aus SSO, Organisation und Rollen.
- Audit-Logs gehen in Ihre Logging- und Compliance-Systeme.
- Schlüssel, Netzwerke, Backups und Zugriffsregeln bleiben unter Ihrer Kontrolle.
- Externe Modellverbindungen werden bewusst konfiguriert und freigegeben.
Wenn eine Plattform jeden Geschäftskontext zuerst in die Vendor-Cloud hochladen muss, werden Datenresidenz, Audit, Compliance und Exit-Kosten schwer erklärbar.
Der Wert von Self-hosting liegt nicht darin, Cloud oder externe Modelle abzulehnen, sondern die letzte Kontrolle zu behalten.
Runtime, lokales Modell und Private SaaS sind verschieden
Selbst gehostete Runtime: Objekte, Rechte, Workflows, Tools, Freigaben und Audit laufen in Unternehmensinfrastruktur.
Lokales Modell: Modellgewichte oder Inferenzdienste laufen intern, etwa für Isolation, Kosten, Latenz oder Compliance.
Private SaaS: Der Vendor stellt eine dedizierte Umgebung bereit, behält aber Betrieb, Logs, Upgrades und Datenverarbeitung unter Kontrolle.
Diese Optionen lassen sich kombinieren, sind aber nicht dasselbe. Prüfen Sie zuerst die Runtime-Grenze: Gelangen Geschäftsdaten zuerst in Ihre Objektschicht? Erben Agents Ihre Rechte? Landet Audit in Ihrem Log-System?
Wenn die Runtime außerhalb Ihrer Kontrolle liegt, kann selbst ein lokales Modell Geschäftsrechte umgehen. Liegt die Runtime intern, kann auch ein externes Modell mit minimalem freigegebenem Kontext genutzt werden.
AI-Anwendungen brauchen stärkere Grenzen als gewöhnliches SaaS
Gewöhnliches SaaS verarbeitet Daten einer Anwendung. Eine AI-Anwendungsplattform verbindet viele Systeme: CRM, ERP, Tickets, Verträge, Dateien und Identität.
Sobald Agents systemübergreifend lesen und handeln, wird die Plattform zur Betriebsschicht des Geschäfts.
Wenn diese Schicht vollständig extern läuft, steigen Risiken: Datenflüsse sind schwer erklärbar, bestehende Rechte schwer konsistent zu erben, Agent-Verhalten schwer intern zu auditieren, Isolation und regulatorische Anforderungen schwer umzusetzen.
Die Frage ist nicht, ob AI Geschäftssysteme verbinden kann. Die Frage ist, ob die Betriebsgrenze nach der Verbindung unter Unternehmenskontrolle bleibt.
Was die Runtime besitzen sollte
| Fähigkeit | Warum sie in die Runtime gehört |
|---|---|
| Geschäftsobjektschicht | Kunden, Aufträge, Tickets, Verträge und Anlagen als kontrollierte Objekte modellieren. |
| Berechtigungsschicht | Identität, Rollen, Datensatz- und Feldrechte erben. |
| Tool-Schicht | Abfragen, Aktionen und Workflows als kontrollierte Tools bereitstellen. |
| Freigabeschicht | Riskante Aktionen zur menschlichen Freigabe senden. |
| Audit-Schicht | Lesen, Empfehlungen, Tool-Aufrufe, Freigaben und Änderungen protokollieren. |
| Integrationsschicht | Datenbanken, ERP, CRM, Identität und Dateien verbinden, ohne Netzwerk- und Schlüsselhoheit zu verlieren. |
So kann AI echte Geschäftssysteme nutzen, ohne Governance zu umgehen.
Externe Modelldienste bleiben möglich
Self-hosted heißt nicht “nur lokale Modelle”. Unternehmen können externe Modell-APIs, Private-Cloud-Modelle, lokale Modelle oder Mischformen verwenden.
Wichtig ist: Das Modell greift nicht direkt auf Datenbanken zu und besitzt keine Geschäftssystem-Zugangsdaten. Es erhält nur den minimalen, freigegebenen Kontext über eine Runtime wie ObjectOS.
Wenn ein Nutzer fragt, welche offenen Tickets eines Kunden in den letzten 90 Tagen wichtig sind, prüft die Runtime zuerst Zugriffsrechte, filtert nach Objekt- und Feldrechten, verbirgt sensible Felder und sendet nur nötigen Kontext an das Modell. Ausführung läuft zurück durch Berechtigungen, Freigaben und Audit.
Self-hosting bedeutet auch Betriebsverantwortung
Unternehmen übernehmen Deployment, Upgrades, Netzwerkisolation, Backups, Identitätsintegration, Schlüsselmanagement, Verfügbarkeit, Kapazität, Sicherheitsbaselines, Schwachstellenreaktion und interne Audits.
Darum muss eine selbst gehostete Plattform klar sein. Sie darf Komplexität nicht nur abladen, sondern muss Objekt-, Rechte-, Workflow-, Log- und Integrationsgrenzen explizit machen.
Self-hosting kauft nicht Bequemlichkeit, sondern Kontrolle.
Wann Self-hosting notwendig wird
Self-hosting ist oft erforderlich, wenn Daten eine Region, VPC oder lokale Netze nicht verlassen dürfen, Verträge Drittanbieter-Hosting einschränken, interne ERP-, Datenbank- oder Dateidienste angebunden werden, eine vollständige Auditkette nötig ist, interne Identität wiederverwendet werden muss, lokale Modelle oder isolierte Netze gebraucht werden oder AI reale Geschäftsaktionen auslöst.
Je näher AI an den Betrieb kommt, desto klarer muss die Deployment-Grenze sein.
Fragen an Anbieter
- Wo werden Geschäftsdaten standardmäßig gespeichert?
- Erbt der Agent Unternehmensidentität und Rechte?
- Gibt es Objekt-, Datensatz-, Feld- und Aktionsrechte?
- Kann das Modell direkt Datenbanken lesen oder nur kontrollierte Tools nutzen?
- Welcher Kontext geht an externe Modell-APIs und kann er minimiert werden?
- Haben riskante Aktionen Freigabe, Rollback und Stop-Regeln?
- Können Reads, Empfehlungen, Tool Calls und Writes ins interne Audit fließen?
- Laufen Kernanwendungen auch bei Isolation oder Vendor-Ausfall weiter?
Unklare Antworten deuten auf eine Demo-Schicht statt eine Produktionsschicht.
Die ObjectOS-Richtung
ObjectOS beginnt nicht damit, Unternehmensdaten in eine neue Cloud zu verschieben.
Es wirkt als Betriebsschicht in Ihrer Infrastruktur: bestehende Systeme verbinden, als Objekte modellieren und Rechte, Workflows, APIs, Audit und Agent-Tools vereinheitlichen.
Daten, Identität, Dateien und Audit-Nachweise bleiben unter Unternehmenskontrolle. AI kann über kontrollierte Tools lesen und handeln, aber die Runtime-Grenze nicht umgehen.