Sovereign AI Platform

Die Sovereign AI Platform ist ein selbst-gehostetes, Multi-Node-LLM-Inferenz-Cluster, gepaart mit einer Multi-User-Web-Chat-Oberfläche. Dieselbe Produktivitäts- Steigerung wie öffentliche Chat-Assistenten — ohne dass ein einziger Prompt, Anhang oder firmeninternes Wissen jemals eure Infrastruktur verlässt. In aktivem Produktiv-Einsatz.

Der Fall für selbst-gehostete KI handelt nicht davon, jedes Cloud-Feature zu replizieren. Er handelt von der schlichten Tatsache, dass jeder Prompt, den euer Team in einen Anbieter-gehosteten Assistenten tippt, ein Stück Geschäftskontext ist, das an eine Drittpartei übergeben wird — Strategiediskussionen, kundenspezifische Arbeit, Code in Entwicklung, Vertragsentwürfe. Für die meisten Organisationen ist das akzeptabel; für manche ist es das nicht.

  flowchart LR
    A[Nutzer] --> B[Selbst-gehostete Web-UI]
    B --> C(("Load Balancer"))
    C --> D[Inferenz-Knoten A]
    C --> E[Inferenz-Knoten B]
    C --> F[Inferenz-Knoten C]
    B <--> G[(Vektor-DB · RAG)]
    D <--> H[(Geteilter Modell-Speicher)]
    E <--> H
    F <--> H
    B -.->|SSO| I[Identity-Provider]

Worum es geht

Die aktuelle Generation von Cloud-KI-Assistenten — ChatGPT, Claude, Gemini, Copilot — hat verändert, wie Wissensarbeit erledigt wird. Sie sind aber auch designbedingt ein kontinuierlicher Exfiltrations-Kanal für alles, was das Team da hineintippt: Prompts, eingefügte Dokumente, Code-Snippets, Kundendaten, Vertragsentwürfe.

Die Anbieter-Bedingungen variieren. Manche versprechen, nicht auf den Daten zu trainieren; manche bieten Enterprise-Stufen mit stärkeren Zusagen; manche nutzen die Daten trotzdem routinemäßig unter anderem Namen. Selbst wo die Privacy-Zusagen wasserdicht sind, lebt der Inhalt weiterhin auf der Infrastruktur des Anbieters — und ist damit erreichbar durch gerichtliche Anordnung, behördliche Anfrage, Datenleck, Anbieter-Pivot oder einfachen Bedienfehler.

Die Sovereign AI Platform entfernt diesen Kanal. Die Inferenz passiert auf euren Maschinen; die Chat-UI läuft in eurem Netzwerk; der Dokument-Index für Retrieval-Augmented-Chat lebt in eurem Datenspeicher. Die Produktivitäts-Steigerung ist gleich; die Daten-Exposition ist null.

Operative Eigenschaften

• 💬 Multi-User-Chat-Oberfläche. Login, Pro-Nutzer-Konversations-Historie, Prompt-Templates, Modell-Picker, Anhang-Upload, Spracheingabe, Code-Block-Syntax-Highlighting. Dieselbe moderne Experience, die das Team von öffentlichen Chat-Assistenten kennt.
• 🤖 Best-in-Class Open-Weights-Modelle. Ein kuratiertes Set aktueller Open-Weights-Modelle für Instruction-Following, Coding, mehrsprachige Arbeit und Reasoning. Der Betreiber entscheidet, welche Modelle in der UI exponiert werden. Neue Modelle können nach Release ergänzt werden.
• 📚 Retrieval-Augmented-Chat gegen eure Dokumente. Interne Dokumente, Verträge, Wissensdatenbanken, Handbücher hochladen — die Plattform indexiert sie lokal und liefert retrieval-augmentierte Antworten. Dokumente bleiben auf eurem Speicher; das Embedding-Modell ist lokal; die Vektor-Datenbank ist lokal.
• 🔌 OpenAI-kompatible API. Endpoint exponiert dieselbe HTTP-API wie der öffentliche OpenAI-Service. Bestehende Integrationen (IDE-Plugins, eigene Tools, hauseigene Apps) funktionieren durch das Ändern einer URL.
• 🌐 Multi-Node-Inferenz-Cluster. Zwei oder mehr Inferenz-Knoten hinter einem Load Balancer. Jeder Knoten kann die volle Last bedienen; rollende Restarts und Modell-Updates laufen ohne User-sichtbare Downtime.
• 🔐 Authentifizierung und Rollen-Trennung. SSO über LDAP, SAML oder OIDC gegen euren bestehenden Identity-Provider. Rollenbasierter Zugriff — wer welche Modelle sieht, wer Dokumente in den geteilten Korpus hochladen darf, wer administrieren darf.
• 📝 Konversations-Audit-Trail. Pro-Nutzer-Konversations- Historie gemäß eurer Aufbewahrungsrichtlinie. Optionales Admin-seitiges Audit-Log für Compliance-Use-Cases.
• 🚦 Rate-Limits und Quotas. Pro-Nutzer-, pro-Team- oder pro-Modell-Quotas — verhindert, dass ein lauter Nutzer oder eine Integration das Cluster monopolisiert.
• 🔄 Modell-Lebenszyklus-Management. Betreiber können neue Modellversionen ohne Downtime pullen, testen und ausrollen. Sofortiger Rollback, wenn eine neue Version bei internen Benchmarks zurückfällt.
• 📊 Observability. Pro-Modell-Latenz, Durchsatz, Token-Verbrauch, GPU-Auslastung als Metriken. Prometheus-Exporter; Grafana-Dashboards, fertig zum Anschluss an euer bestehendes Monitoring.

Cluster-Form

Das Cluster läuft active/active: mehrere Inferenz-Knoten sind über einen einzigen load-balancten Endpunkt erreichbar; jeder Knoten hält eine Kopie des aktiven Modells im Arbeitsspeicher; neue Anfragen werden an den am wenigsten belasteten Knoten geroutet.

• Kapazitäts-Skalierung. Knoten hinzufügen, um den Durchsatz gleichzeitiger Nutzer / Tokens zu erhöhen. Der Durchsatz skaliert nahezu linear mit der Knotenanzahl, bis Modell-Lade- und Speicher-Bandbreiten-Grenzen greifen.
• HA. Jeder Knoten kann für OS-Patches, GPU-Treiber-Updates oder Hardware-Wartung gedraint werden, ohne Nutzer zu unterbrechen. Der Load Balancer routet drumherum.
• Modell-Speicher. Modelle liegen auf geteiltem Storage (NFS, S3 oder Cluster-Filesystem), sodass alle Knoten denselben Katalog sehen. Ein neues Modell auf dem geteilten Store hinzufügen, macht es cluster-weit verfügbar.
• Vektor-Store für RAG. Eine separate dedizierte Datenbank-Node hält Dokument-Embeddings für Retrieval-Augmented-Chat. Repliziert für HA; nur Lesezugriff von den Inferenz-Knoten.
• Unabhängig von Cloud-APIs. Keine externe Abhängigkeit für Inferenz. Das Cluster läuft weiter durch jeden Internet-Ausfall, Anbieter-Störung oder regulatorisches Ereignis, das Cloud-KI-Anbieter trifft.

Typische Use-Cases

• 🏢 Öffentliche Chat-Assistenten für interne Nutzung ablösen. Dieselbe Produktivitäts-Steigerung für das Team — Entwürfe, Zusammenfassungen, Coding-Hilfe, Übersetzung, Recherche — ohne dass Geschäftskontext den Perimeter verlässt.
• ⚖️ Privilegierte Arbeit. Recht, M&A, Audit, Executive-Entwürfe — Arbeit, die schlicht nicht über die Infrastruktur eines Anbieters laufen darf, aus Vertraulichkeits-, Privilegien- oder regulatorischen Gründen.
• 🩺 Regulierte Sektoren. Gesundheit, Finanzberatung, Versicherung — Sektoren, in denen das Audit-Gespräch über „wohin gehen die Daten?" trivial wird, sobald die Antwort „nirgendwo" lautet.
• 🔐 IP-sensitiver Code. Engineering-Teams, die KI-Unterstützung brauchen, aber ihren proprietären Code nicht an einen Drittanbieter-Assistenten senden dürfen. Selbst-gehostete Inferenz liefert dieselbe „nächste-Zeile-vorschlagen"-Fähigkeit gegen euren eigenen Codebase ohne Exfiltration.
• 📚 Interner Wissens-Assistent. Indexiert das Wiki, das Ticketing-System, die Runbooks und ein Jahrzehnt Board-Protokolle — und stellt eine Chat-Schnittstelle bereit, in der jeder Mitarbeiter Fragen stellen und zitierte Antworten erhalten kann, ohne dass dieser Inhalt das Unternehmen verlässt.
• 🤝 Kundenseitige KI-Features. Einen Kunden-Assistenten oder ein produktinternes KI-Feature bauen, ohne pro Token zu bezahlen, ohne Kundendaten an eine Drittpartei zu senden und ohne dass eure Roadmap an die Preis- oder Policy-Änderungen eines Anbieters gebunden ist.
• 🌍 Geopolitisch eingeschränkte Umgebungen. Wo die Nutzung eines US- oder China-basierten KI-Anbieters rechtlich oder politisch nicht akzeptabel ist, ist Sovereign-Self-hosted die einzige Option.

Warum das ein CEO-Thema ist

• 💰 Kosten-Trajektorie. Cloud-KI-Assistenten rechnen pro Nutzer pro Monat (20–60 €) plus pro-Token-API- Gebühren ab. Bei 200 Mitarbeitern, die KI-Tools täglich nutzen, sind die jährlichen Kosten 60–200 k € und steigen mit zunehmender Adoption. Selbst-gehostet ist eine feste Hardware-Investition (20–80 k € je nach Cluster-Größe) plus Strom — Break-Even typischerweise unter 18 Monaten.
• 🛡️ Prompt-Souveränität. Jeder Prompt, den euer Team in einen Cloud-Assistenten tippt, ist Business-Intelligence, die an diesen Anbieter übergeben wird. Die Anbieter-Bedingungen sind nicht das Problem — die Existenz des Kanals ist das Problem. Den Kanal zu entfernen, entfernt die Klasse der Risiken, die er erzeugt.
• 📋 Regulatorischer Rückenwind. DSGVO, KI-Verordnung, sektorspezifische KI-Governance — alle laufen auf die Frage welche Daten werden an welchen KI-Anbieter gesendet? hinaus. Die Antwort „keine" ist die einzige Antwort, die über Jurisdiktionen hinweg skaliert.
• 🔓 Vendor-Lock-in aufgelöst. Cloud-KI-Anbieter deprezieren routinemäßig Modelle, ändern Preise, beschränken Use-Cases oder pivotieren strategisch. Eure KI-Fähigkeit sollte nicht davon abhängen, dass eine dieser Entscheidungen in eurem Sinne ausfällt. Selbst-gehostet erlaubt es, Modelle auf eurem Zeitplan zu wählen, zu testen und zu wechseln.
• 🤝 Kunden-Vertrauen. Wenn ihr KI-Features in euer Produkt einbaut, ist „eure Daten verlassen unsere Infrastruktur nie" ein materieller kommerzieller Vorteil in regulierten Märkten.
• 🔗 Integration mit dem Rest des Stacks. Derselbe Identity-Provider, dasselbe Monitoring, dieselben Datenresidenz-Garantien wie der Rest des Sovereign-Plattform-Estates — keine separate Anbieter-Beziehung mit separaten Compliance-Pflichten.
• ⏱️ Kontinuität. Ausfälle und Policy-Änderungen bei großen Cloud-KI-Anbietern haben in den letzten 24 Monaten wiederholt Kunden-Workflows lahmgelegt. Ein selbst-gehostetes Cluster entfernt dieses systemische Risiko.

Technologisches Fundament

Aufgebaut auf dem reifen Open-Source-KI-Inferenz-Ökosystem mit operativer Disziplin rund um Clustering, Observability und Modell-Lebenszyklus.

Meld dich, dann skizzieren wir ein Deployment passend zu eurem typischen gleichzeitigen Nutzer-Volumen, den Modell- Größen-Anforderungen und Integrations-Bedürfnissen mit dem Rest des Plattform-Estates.