KI on-premise: unter eigener Kontrolle
statt in fremder Cloud
Sie wollen KI nutzen. Aber Ihre Daten dürfen das Haus nicht verlassen – aus Compliance-Gründen, aus Wettbewerbsgründen, oder schlicht, weil es Ihre Daten sind. SaaS-KI ist bequem. Der Preis ist, dass Ihre Inhalte durch fremde Clouds laufen. Diese Abwägung müssen Sie nicht eingehen.
Komfort gegen Kontrolle
Cloud-KI ist schnell startklar – genau das macht sie attraktiv. Für regulierte oder datensensible Kontexte kippt die Rechnung, sobald sensible Daten an einen externen Dienst gehen. Dann stellen sich Fragen, die kein Feature beantwortet:
Verarbeitungsort
Wo werden Ihre Daten tatsächlich verarbeitet – und wessen Recht gilt dort?
Zugriff
Wer beim Anbieter hat Zugriff auf Ihre Prompts, Dokumente und Ergebnisse?
Verbleib
Was passiert mit den Daten nach der Anfrage – werden sie gespeichert, weiterverwendet, trainiert?
Nachweisbarkeit
Lässt sich das alles belegen, wenn Revision oder Aufsichtsbehörde fragen?
Oft endet das in einem Patt: Die Fachseite will die KI, die Compliance kann sie nicht freigeben. Das KI-Projekt steht still – nicht an der Technik, sondern an der Datenfrage.
Ihre Daten bleiben bei Ihnen – die KI kommt zu ihnen
mAIstack läuft dort, wo Ihre Daten ohnehin liegen: bei Ihnen. Entscheidend ist, dass Datenschutz, Identität und Governance in der Architektur verankert sind – nicht nachträglich als Aufsatz. Das ist keine Worthülse, sondern die Bauweise: von Tag eins Fundament statt Nachrüstung.
Dex bündelt Ihre Identitäten (LDAP, Entra, OIDC) hinter einem Standard; das obot-Gateway erzwingt rollenbasierte Rechte über 6 Rollen und schreibt jeden Tool-Aufruf lückenlos ins Audit-Log.
Presidio erkennt über 50 PII-Typen – Namen, IBAN, Kontaktdaten – und maskiert sensible Inhalte, bevor sie den LiteLLM-Proxy überhaupt erreichen. Schutz vor dem ersten Byte, das nach außen geht.
Betrieb lokal über Ollama oder wahlweise über mehr als 100 Provider via LiteLLM – Sie entscheiden, was wo läuft. Jede Agenten-Aktion läuft isoliert in einer gVisor-Sandbox statt ungebremst auf Ihren Systemen.
Sicherheit im Vergleich
Der Unterschied zwischen „KI ausprobieren” und „KI verantworten” zeigt sich nicht im Demo, sondern in der Architektur dahinter:
| Kriterium | Offene Frameworks | SaaS-Anbieter | mAIstack |
|---|---|---|---|
| Code-Ausführung | Auf dem Host, keine Isolation | In der Cloud des Anbieters | gVisor-Sandbox, Kernel-Isolation |
| Netzwerk | Unbeschränkt | Vom Anbieter kontrolliert | Default-Deny NetworkPolicy pro Tenant |
| Credentials | Geteilt oder exponiert | Geteilte API-Keys | Isoliert, bcrypt-gehasht, verschlüsselt |
| Zugriffskontrolle | Keine oder rudimentär | Keine oder rudimentär | RBAC mit 6 Rollen + granulare ACLs |
| Audit | Kein Trail | Nur beim Anbieter | Lückenlose Protokollierung + Export |
| Datenhoheit | Keine Kontrolle | Cloud-Anbieter | Self-hosted, air-gapped-fähig |
| Modellwahl | Vom Anbieter vorgegeben | Vom Anbieter vorgegeben | Multi-Provider via LiteLLM + Ollama |
Wann On-Premise die richtige Wahl ist – und wann nicht
✓ Wenn es passt
On-Premise spielt seine Stärke aus, wenn Datenhoheit, Compliance oder Auditierbarkeit echte Anforderungen sind – nicht als Prinzip, sondern weil Ihr Markt es verlangt. Dann ist der Aufwand kein Nachteil, sondern der bewusste Tausch von „fremd und bequem” gegen „eigen und kontrolliert”.
— Wenn nicht
On-Premise verlangt Kubernetes-Betriebsfähigkeit – Cluster, Helm, GitOps – und ein Team, das damit umgehen kann. Auch dann ist es kein Zero-Config-Zustand: Single-Sign-On über Obot ist im Standard deaktiviert und wird projektspezifisch eingerichtet, die PII-Pseudonymisierung ist opt-in und wird je Use Case validiert. Fehlt die echte Datenhoheits-Anforderung, kann ein Cloud- oder Hybrid-Weg leichter sein.
Kurz beantwortet
Geht auch Cloud oder hybrid – oder nur On-Prem?
Beides ist vorgesehen: Der Modellzugriff läuft über LiteLLM zu mehr als 100 Cloud-Providern oder alternativ vollständig lokal über Ollama. Sie entscheiden projektspezifisch, welche Workloads on-premise bleiben und welche über die Cloud laufen – bis hin zum air-gapped-fähigen Betrieb ganz ohne Außenverbindung.
Welche Modelle laufen lokal?
Für den lokalen Betrieb kommt Ollama zum Einsatz. Welches konkrete Open-Source-Modell infrage kommt, hängt von Use Case und vorhandener Hardware ab – das klären wir im Erstgespräch.
Wie funktionieren Betrieb, Updates und Audit?
Betrieb und Updates laufen in Ihrer eigenen Infrastruktur. Für Nachvollziehbarkeit sorgt das obot-Gateway: Es protokolliert jeden Tool-Aufruf lückenlos, während sensible Daten für alle Rollen außer der dedizierten Auditor-Rolle maskiert bleiben.
Holen Sie sich KI ins Haus – im Wortsinn.
Gespräch vereinbaren. Kein Commitment. Kostenlos und unverbindlich – wir melden uns innerhalb von 24 Stunden.
Dieses Formular wird über HubSpot eingebunden und benötigt Marketing-Cookies, die du gerade nicht akzeptiert hast.
Lieber direkt: kontakt@mayflower.de
