„Private KI“ wird für alles verwendet – von „Wir haben das Training in unserem SaaS-Konto deaktiviert“ bis „Wir betreiben offene Modelle auf eigenen GPUs in einem abgeschotteten Netzwerk“. Diese Ansätze sind nicht gleichwertig.
Für KMU hängt die richtige Architektur privater KI von Daten, Aufgabe, Qualitätsanforderungen und der Fähigkeit des Teams zum Infrastrukturbetrieb ab. Die privateste Option ist nicht immer die beste. Die leistungsfähigste ist für die Daten nicht immer zulässig. Die günstigste kann teuer werden, wenn sie dauerhaft Entwicklungs- und Betriebsaufwand verlangt.
Dieser Artikel bietet eine praktische Übersicht.
Beginnen Sie mit der Datenklassifizierung, nicht mit einer Modellpräferenz. Ein schwächeres Modell innerhalb der richtigen Datenschutzgrenze ist besser als ein Spitzenmodell, das unzulässige Daten erhält.
Die fünf Bereitstellungsmuster
| Muster | Was es ist | Am besten geeignet für | Hauptbeschränkung |
|---|---|---|---|
| Consumer SaaS | Persönliche ChatGPT/Claude/Gemini-Konten | Öffentliche oder persönliche geringfügige Aufgaben | Schwache Unternehmenskontrollen |
| Enterprise-SaaS | Geschäftstarif mit Administration, SSO, Aufbewahrung und Trainingsausschluss | Die meisten üblichen Unternehmensaufgaben | Daten verlassen weiterhin Ihre Umgebung |
| VPC oder private Cloud | Verwalteter Modellendpunkt innerhalb einer kontrollierten Cloud-Grenze | Vertrauliche Workloads, die stärkere Isolation benötigen | Höhere Kosten und Einrichtungsaufwand |
| Selbst gehostete Inferenz | Sie betreiben offene Modelle auf eigener Infrastruktur | Streng geschützte Daten, angepasste Modelle, Skaleneffekte | Betriebsaufwand |
| Lokale Gerätemodelle | Das Modell läuft auf Laptop, Workstation oder Edge-Gerät | Offline-Aufgaben sowie sensible, eng begrenzte Aufgaben mit geringer Latenz | Kleinere Modelle und Gerätegrenzen |
Die meisten Unternehmen benötigen mehrere Muster. Es geht nicht darum, eines für immer auszuwählen, sondern jeden Anwendungsfall an die richtige Systemgrenze zu leiten.
Datenklassifizierung zuerst
Verwenden Sie vier Kategorien:
| Daten | Beispiele | Standardgrenze für KI |
|---|---|---|
| Öffentlich | Website-Text, veröffentlichte Dokumente, öffentliche Forschung | Jeder genehmigte Tool |
| Intern | Prozessnotizen, anonymisierte Beispiele, nicht sensible Entwürfe | Enterprise SaaS |
| Vertraulich | Kundendaten, Verträge, Quellcode, Finanzen, Strategie | Enterprise SaaS mit Kontrollen, VPC oder selbstgehostet |
| Streng geschützt | Gesundheitsdaten, anwaltlich privilegierte Informationen, Personalermittlungen, regulierte Datensätze, Zugangsdaten | Rechtliche und sicherheitsbezogene Prüfung; häufig lokal, VPC oder keine KI |
Diese Klassifizierung verhindert einen häufigen Fehler: die Verwendung desselben Assistenten für öffentliche Blogentwürfe und vertrauliche Kundendaten, weil es bequem ist.
Muster 1: Enterprise SaaS als Standard
Für viele KMUs ist Enterprise SaaS der richtige Standard. ChatGPT Enterprise/Business, Claude for Work, Microsoft Copilot, Gemini for Workspace und ähnliche Tools bieten in der Regel:
- Vertraglicher Ausschluss vom Training.
- Admin-Kontrollen.
- SSO und Zugangsverwaltung.
- Speicherungskontrollen.
- Audit-Protokolle.
- Sicherheitsdokumentation.
- Unterstützung durch den Anbieter.
Dies ist ausreichend für einen großen Teil der Arbeit: Schreiben, Zusammenfassung, Forschung, Meeting-Notizen, interne Analyse und genehmigter Einsatz von Kundekontext.
Entscheidend ist die Konfiguration. Der Kauf eines Teamtarifs genügt nicht. Konfigurieren Sie Aufbewahrung, Freigaben, Connector-Zugriff, genehmigte Workspaces und Datenregeln.
Muster 2: VPC oder private Cloud
VPC- oder Private-Cloud-Muster eignen sich, wenn Daten Ihre Anwendung verlassen dürfen, aber innerhalb einer kontrollierten Cloud-Grenze bleiben müssen. Beispiele:
- Kundensupport-Assistent über vertrauliche Tickets.
- Interner Wissens-Assistent über sensible Dokumente.
- Dokumentextraktion für Verträge oder Rechnungen.
- Fachspezifischer Assistent, der eine stärkere Datenisolation als SaaS erfordert.
Vorteile:
- Bessere Isolation.
- Mehr Kontrolle über Netzwerke und Protokolle.
- Einfacherer Beschaffungsprozess für sensible Kunden.
- Weniger Betriebsbelastung als vollständige Selbsthostung.
Einschränkungen:
- Teurer als SaaS.
- Mehr Integration.
- Modellwahl kann enger sein.
- Sie bleiben von der Infrastruktur des Anbieters abhängig.
Für viele ernsthafte KMU-Systeme ist dies die praktische Mitte.
Muster 3: Selbstgehostete Inferenz
Selbsthosting bedeutet, dass Sie die Modelllaufzeit betreiben: vLLM, TGI, SGLang, llama.cpp, Ollama oder einen anderen Serving-Stack. Es ist sinnvoll, wenn:
- Daten nicht aus Ihrer Umgebung herausgehen dürfen.
- Sie ein benutzerdefiniertes oder feinabgestimmtes offenes Modell benötigen.
- Die Inferenzmenge hoch genug ist, um Infrastruktur zu rechtfertigen.
- Latenz- oder Verfügbarkeitsanforderungen direkte Kontrolle erfordern.
- Sie Leute haben, die es betreiben können.
Hosten Sie nicht nur deshalb selbst, weil es besonders privat wirkt. Die Betriebskosten sind real: GPU-Kapazität, Monitoring, Aktualisierungen, Sicherheitspatches, Modellevaluation, Skalierung und Reaktion auf Vorfälle.
Selbsthosting ist eine starke Wahl für die richtige Organisation. Für ein kleines Team ohne ML-Infrastruktur-Erfahrung kann es zu einem fragilen Nebenprojekt werden.
Muster 4: Modelle auf lokalen Geräten
Lokale Modelle werden für datenschutzsensible Einzelaufgaben unterschätzt:
- Zusammenfassen lokaler Notizen.
- Entwürfe aus privaten Dokumenten.
- Klassifizierung interner Snippets.
- Offline Feldarbeit.
- Edge-Workflows, bei denen Latenz wichtig ist.
Der Zielkonflikt liegt bei der Qualität. Ein kleines lokales Modell kann für Zusammenfassung, Klassifizierung, Extraktion und erste Entwürfe genügen. Bei anspruchsvollem Reasoning, komplexem Schreiben oder breitem Werkzeugzugriff kann es nicht mit führenden gehosteten Modellen konkurrieren.
Verwenden Sie lokale Modelle, wenn die Aufgabe eng begrenzt und die Datenschutzgrenze wichtiger als Spitzenqualität ist.
Muster 5: Hybrides Routing
Das reife Muster ist hybrid:
- Öffentliche und geringfügige Aufgaben gehen an Enterprise SaaS.
- Vertrauliches Retrieval erfolgt innerhalb eines privaten RAG-Systems.
- Die Extraktion streng geschützter Daten läuft lokal oder in einer VPC.
- Der finale Entwurf kann ein führendes Modell verwenden, nachdem sensible Felder entfernt wurden.
- Protokolle und Bewertungen entscheiden, ob jeder Weg funktioniert.
Hybrides Routing ermöglicht den Einsatz leistungsfähiger Modelle, ohne jeden Datensatz gleich zu behandeln. Es erfordert Disziplin:
- Datenklassifizierung vor Routing.
- Streichung wo möglich.
- Klare Positivliste für Modelle und Werkzeuge.
- Protokolle, die aufzeichnen, welche Grenze verwendet wurde.
- Fallback, wenn das private Modell die Aufgabe nicht ausführen kann.
Entscheidungsrahmen
Stellen Sie sechs Fragen:
- Welche Daten gelangen in das Modell? Öffentlich, intern, vertraulich oder streng geschützt.
- Welche Auswirkungen hat die Ausgabe? Entwurf, Empfehlung, Entscheidung oder kundenwirksame Handlung.
- Welche Qualität wird benötigt? Ausreichend, Expertenniveau oder Spitzen-Reasoning.
- Welche Latenz wird benötigt? Interaktiv, Batch, Echtzeit, Offline.
- Welche Betriebskapazität ist vorhanden? Kein Infrastrukturteam, Anwendungsteam, Plattformteam oder ML Operations.
- Welche Nachweise benötigen Kunden oder Aufsichtsbehörden? Anbieterdokumentation, Protokolle, Datenresidenz, Audit-Spur und Isolation.
Wählen Sie dann das Muster mit der geringsten Komplexität, das die Daten- und Qualitätsanforderungen erfüllt.
Was Sie noch nicht tun sollten
Messen Sie die Workload und Qualitätsanforderung, bevor Sie sich selbst hosten.
Senden Sie streng geschützte Daten nicht an Werkzeuge für Privatkunden.
Gehen Sie nicht davon aus, dass „Open Source“ automatisch „privat“ bedeutet. Privat ist ein System nur, wenn Bereitstellung, Protokolle, Zugriff und Datenflüsse privat gestaltet sind.
Bauen Sie kein zentrales KI-Gateway ohne Datenklassifizierung. Es wird sensible Daten falsch weiterleiten.
Ignorieren Sie keine Bewertungen. Privat, aber falsch, ist immer noch falsch.
Ein praktischer Startpunkt für KMUs
Für die meisten KMUs:
- Genehmigen Sie einen Enterprise SaaS-Assistenten für allgemeine Arbeit.
- Schreiben Sie eine Datenklassifizierungsregel.
- Blockieren Sie streng geschützte Daten, sofern der Anwendungsfall nicht geprüft wurde.
- Bauen Sie einen privaten RAG- oder VPC-Workflow für den wertvollsten vertraulichen Use Case.
- Verwenden Sie lokale Modelle für eng begrenzte sensible Aufgaben, wenn ihre Qualität ausreicht.
- Erwägen Sie Selbsthosting nur, wenn Datenschutz, Anpassung oder Kosten es eindeutig rechtfertigen.
So erhält die Organisation einen Private-by-Design-Pfad, ohne zu behaupten, jeder KI-Anwendungsfall benötige einen GPU-Cluster.
Fazit
Private KI ist eine an den Daten ausgerichtete Architektur. Die richtige Antwort lautet selten „alles SaaS“ oder „alles selbst gehostet“. Gewöhnlich ist es ein Portfolio: Enterprise-SaaS für übliche Arbeit, private oder VPC-Systeme für vertrauliche Workflows, lokale Modelle für eng begrenzte sensible Aufgaben und Selbsthosting, wenn Größenordnung oder Kontrolle es wirklich verlangen.
Wählen Sie anhand von Daten, Auswirkungen, Qualität, Latenz, Betrieb und Nachweispflichten. Das ist die unspektakuläre Variante – und diejenige, die den Produktiveinsatz übersteht.
