Lokales Sprachmodell oder Cloud-KI: Entscheidend ist das Betriebsmodell

„Wir betreiben das Modell lokal, dann sind Datenschutz und Sicherheit gelöst.“ Der Gegenentwurf klingt ähnlich einfach: „Wir nehmen einen Cloud-Dienst, dann müssen wir nichts betreiben.“

Beide Aussagen reduzieren eine Systementscheidung auf den Standort der Rechenleistung. Sie blenden aus, welche Daten tatsächlich fließen, welche Qualität benötigt wird, wer Updates und Störungen verantwortet, wie stark die Last schwankt und was ein späterer Wechsel kostet.

Ein lokal betriebenes Sprachmodell kann den Datenpfad enger kontrollierbar machen. Es bringt dafür Hardware, Kapazitätsplanung, Aktualisierung, Absicherung, Überwachung und Wiederherstellung in die eigene Verantwortung. Ein gehosteter Dienst kann schnell verfügbare Modelle und elastische Leistung bieten. Er schafft zugleich eine externe Abhängigkeit und verlangt eine genaue Prüfung von Vertrag, Datenverarbeitung, Schnittstelle, Änderungsverhalten und Ausstieg.

Die tragfähige Entscheidung lautet deshalb nicht pauschal „lokal oder Cloud“. Sie lautet: Welches Betriebsmodell passt zu diesem abgegrenzten Anwendungsfall und zu den Fähigkeiten der Organisation?

Zuerst müssen die Optionen sauber benannt werden

Zwischen einem Modell auf eigener Hardware und einer öffentlich erreichbaren Standardanwendung liegen mehrere Varianten. Für eine belastbare Diskussion sollten mindestens diese Modelle unterschieden werden:

Betriebsmodell	Vereinfacht beschrieben	Typische Verantwortung
eigener Betrieb	Modell und Laufzeit liegen auf eigener oder exklusiv kontrollierter Infrastruktur	Organisation verantwortet Plattform, Kapazität, Updates, Schutz und Betrieb weitgehend selbst
dediziert gehostet	exklusiv bereitgestellte Umgebung bei einem Dienstleister oder Cloud-Anbieter	Verantwortung wird vertraglich und technisch zwischen Organisation und Anbieter geteilt
verwalteter Modellservice	Zugriff auf Modelle über eine Plattform oder API	Anbieter betreibt Modell und Plattform; Organisation verantwortet Auswahl, Integration, Datenfluss und Anwendung
fertiger KI-Dienst	vollständige Anwendung mit integrierter KI-Funktion	Anbieter kontrolliert einen größeren Teil der Lösung; Organisation steuert Nutzung, Daten, Identitäten und Prozess
hybrider Ansatz	verschiedene Modelle oder Betriebsorte je Daten- und Aufgabenklasse	Organisation muss Routing, Regeln und Übergänge zwischen den Varianten beherrschen

„Cloud“ beschreibt damit weder ein einheitliches Produkt noch eine einheitliche Risikoverteilung. „Lokal“ kann vom Modell auf einem einzelnen Arbeitsplatz bis zu einer hochverfügbaren internen Plattform reichen.

Der Anwendungsfall setzt die Grenze

Vor dem Vergleich muss feststehen, was das System leisten soll. „Wir wollen KI intern nutzen“ ist zu unscharf.

Zu klären sind mindestens:

• Welche konkrete Aufgabe wird unterstützt?
• Welche Eingaben und Wissensquellen werden verwendet?
• Welche Ausgaben entstehen und wer verwendet sie?
• Darf das System nur formulieren oder auch Aktionen auslösen?
• Welche Fehler sind tolerierbar?
• Welche Antwortzeit und Verfügbarkeit werden benötigt?
• Wie viele gleichzeitige Nutzer und welche Lastspitzen sind zu erwarten?
• Welcher manuelle oder technischer Fallback existiert?

Der Beitrag zur Produktionsreife von KI-Piloten behandelt diese Grenze ausführlich. Ohne sie vergleicht die Organisation abstrakte Plattformen statt betrieblicher Optionen.

Sechs Entscheidungsfelder

1. Datenfluss und Kontrollbedarf

Der erste Blick gilt nicht dem Marketingbegriff des Angebots, sondern dem vollständigen Datenfluss:

• Welche Inhalte verlassen welches System?
• Werden Eingaben, Ausgaben oder Metadaten gespeichert?
• Dienen sie einer weiteren Verarbeitung oder Modellverbesserung?
• Welche Unterauftragnehmer oder Regionen können beteiligt sein?
• Wie werden Identitäten, Berechtigungen und Protokolle behandelt?
• Welche Lösch-, Export- und Nachweismöglichkeiten bestehen?

Ein lokales Modell kann verhindern, dass fachliche Eingaben an einen externen Modelldienst gesendet werden. Gleichzeitig können Telemetrie, Updates, externe Wissensquellen oder andere Komponenten weiterhin Verbindungen nach außen besitzen. Umgekehrt kann ein gehosteter Dienst vertraglich und technisch eng begrenzte Datenverarbeitung anbieten. Der Bereitstellungsort ist daher ein wichtiger Faktor, aber kein vollständiges Datenflussmodell.

Das BSI ordnet Risiken generativer KI über den Lebenszyklus ein und nennt unter anderem Abhängigkeiten vom entwickelnden oder betreibenden Unternehmen. Die konkrete Relevanz hängt vom Anwendungsfall, der verwendeten Architektur und den möglichen Folgen ab.

Ein Ausschlusskriterium liegt vor, wenn notwendige Datenflüsse nicht transparent geklärt oder organisatorisch nicht verantwortet werden können.

2. Qualitätsbedarf und Modellzugang

Nicht jedes Modell eignet sich gleich gut für jede Sprache, Domäne, Dokumentlänge oder Aufgabe. Die Organisation benötigt deshalb einen eigenen Testdatensatz und ein fachliches Qualitätsmaß.

Ein gehosteter Dienst kann Zugang zu leistungsfähigen und häufig aktualisierten Modellen vereinfachen. Ein lokales Modell kann stabiler kontrollierbar und gezielt für eine eng begrenzte Aufgabe eingebunden werden. Es kann jedoch mehr Anpassungs-, Integrations- und Evaluationsaufwand verlangen.

Entscheidend ist nicht eine allgemeine Rangliste, sondern:

• Erreicht die Option die benötigte Qualität für die konkrete Aufgabe?
• Bleibt die Qualität über relevante Eingabetypen und Randfälle ausreichend?
• Kann die verwendete Modellversion identifiziert oder kontrolliert werden?
• Wie werden Änderungen des Modells erkannt und erneut geprüft?
• Lässt sich bei unzureichender Sicherheit an einen Menschen oder einen anderen Prozess übergeben?

Ein Ausschlusskriterium liegt vor, wenn die notwendige Qualität nicht reproduzierbar geprüft werden kann oder Fehlerfolgen nicht beherrschbar sind.

3. Betriebsfähigkeit und Verantwortung

Eigener Betrieb bedeutet mehr als das Herunterladen eines Modellgewichts. Benötigt werden je nach Kritikalität:

• abgesicherte Laufzeit und Zugriffssteuerung,
• Hardware- und Kapazitätsplanung,
• Patch- und Modellaktualisierung,
• Überwachung von Verfügbarkeit, Leistung und Qualität,
• Protokollierung mit angemessenem Informationsschutz,
• Sicherung von Konfigurationen und abhängigen Wissensbeständen,
• Störungs-, Wiederherstellungs- und Eskalationswege,
• ausreichende interne Fähigkeiten und Vertretung.

Ein verwalteter Dienst nimmt Teile davon ab. Er entfernt aber nicht die Verantwortung für die eigene Anwendung. Datenklassifikation, Berechtigungen, Qualitätsgrenzen, fachliche Freigabe und Fallback bleiben Aufgaben der nutzenden Organisation.

Der BSI-Kriterienkatalog für KI-Modelle und KI-Systeme betrachtet Risiken und Maßnahmen anwendungsbezogen und über verschiedene Rollen im Lebenszyklus. Diese Rollentrennung ist für die Make-or-Buy-Frage wichtiger als die Behauptung, eine Variante sei grundsätzlich sicherer.

Ein Ausschlusskriterium liegt vor, wenn für eine Option kein realistischer Owner, Supportweg oder Wiederanlauf geschaffen werden kann.

4. Lastprofil, Antwortzeit und Verfügbarkeit

Lokale Kapazität muss für erwartete Nutzer, Eingabelängen, Antwortzeiten und Spitzen ausgelegt werden. Überdimensionierung bindet Kapital und Betrieb. Unterdimensionierung führt zu Warteschlangen oder verhindert die geplante Nutzung.

Gehostete Dienste können schwankende Last häufig flexibler aufnehmen. Dafür hängen Antwortzeit und Verfügbarkeit zusätzlich von Netzwerk, Anbieter und vereinbartem Leistungsumfang ab. Mengenbegrenzungen und variable Kosten können bei wachsender Nutzung relevant werden.

Für den Vergleich sollten deshalb keine abstrakten „Tokens pro Sekunde“ genügen. Benötigt werden betriebliche Szenarien:

• normaler Arbeitstag,
• erwartete Lastspitze,
• Ausfall einer Komponente oder Verbindung,
• umfangreiche Dokumente,
• gleichzeitige Nutzung durch mehrere Rollen,
• zulässige Wartezeit und manueller Fallback.

Ein Ausschlusskriterium liegt vor, wenn die Option eine notwendige Verfügbarkeit oder Antwortzeit nicht im relevanten Szenario erreicht.

5. Gesamtkosten statt Einzelpreis

Der Preis pro Anfrage und der Kaufpreis einer GPU sind nicht direkt vergleichbar. Beide bilden nur einen Ausschnitt ab.

Beim eigenen Betrieb gehören mindestens in die Betrachtung:

• Hardware, Ersatz und Abschreibung,
• Energie, Kühlung und Stellfläche,
• Plattform- und gegebenenfalls Lizenzkosten,
• Aufbau, Integration und Tests,
• Administration, Überwachung und Bereitschaft,
• Updates, Sicherheitsmaßnahmen und Wiederherstellung,
• Reservekapazität und Ausfallvorsorge.

Bei einem gehosteten Dienst gehören dazu:

• nutzungsabhängige und feste Entgelte,
• Datenübertragung und Zusatzdienste,
• Integration, Identitäts- und Berechtigungskonzept,
• Qualitätsprüfung bei Modelländerungen,
• Vertrags-, Sicherheits- und Lieferantensteuerung,
• Kostenobergrenzen und Missbrauchsschutz,
• Export, Wechsel und möglicher Parallelbetrieb.

Der Beitrag „IT-Kosten im Mittelstand“ beschreibt, warum interne Arbeitskosten und betriebliche Leistung in dieselbe Betrachtung gehören. Für KI gilt das besonders: Eine vermeintlich kostenlose lokale Software kann erheblichen internen Betrieb erzeugen; ein schnell startbarer Dienst kann bei hoher oder schlecht begrenzter Nutzung teuer werden.

Ein Ausschlusskriterium liegt vor, wenn die Kosten unter realistischen Lastannahmen nicht begrenzt oder verantwortet werden können.

6. Abhängigkeit, Wechsel und Rückfall

Jede Option erzeugt Abhängigkeiten. Beim gehosteten Dienst können Schnittstellen, Modellverfügbarkeit, Vertragsbedingungen und Anbieteränderungen relevant sein. Beim eigenen Betrieb entstehen Abhängigkeiten von Hardware, Spezialwissen, Modellformaten und internen Schlüsselpersonen.

Vor der Entscheidung sollten daher geklärt sein:

• Welche Anwendungslogik ist vom Modellanbieter getrennt?
• Können Prompts, Testfälle, Wissensbestände und Konfigurationen exportiert werden?
• Lässt sich ein anderes Modell mit vertretbarem Aufwand testen?
• Was geschieht bei Preis-, Qualitäts- oder Verfügbarkeitsänderungen?
• Kann der Prozess vorübergehend ohne KI weiterlaufen?
• Wie wird eine Option geordnet beendet?

Der NIST AI RMF behandelt KI-Risikomanagement als fortlaufende Aufgabe über den Lebenszyklus. NIST weist zum Abrufzeitpunkt darauf hin, dass Version 1.0 überarbeitet wird. Das unterstreicht einen praktischen Punkt: Bewertungsrahmen und technische Möglichkeiten verändern sich. Eine Architektur braucht deshalb nicht nur eine Einstiegs-, sondern auch eine Überprüfungs- und Ausstiegsentscheidung.

Vergleichsmatrix ohne Scheingenauigkeit

Eine Entscheidungsmatrix kann die Diskussion strukturieren. Eine universelle Punktzahl würde jedoch unterschiedliche Ausschlusskriterien verdecken.

Kriterium	Eigener Betrieb	Verwalteter Dienst	Zu klärende Evidenz
Datenfluss	enger selbst gestaltbar, aber vollständig selbst abzusichern	vertraglich und technisch vom Angebot abhängig	dokumentierter Ende-zu-Ende-Datenfluss
Modellqualität	Auswahl durch verfügbare Hardware und betreibbare Modelle begrenzt	häufig breiter oder schneller aktualisiert	Test auf eigenem, freigegebenem Datensatz
Betrieb	hohe eigene Verantwortung	geteilte Verantwortung	Rollen, Support, Monitoring und Wiederanlauf
Skalierung	Kapazität wird vorgehalten und geplant	oft elastischer, aber abhängig von Limits und Kosten	Lasttest und Kostenmodell
Änderbarkeit	Modellwechsel technisch möglich, Integration bleibt Aufwand	API kann Wechsel erleichtern oder Anbieterbindung verstärken	Austauschtest und Exportmöglichkeiten
Kosten	höherer fixer und interner Anteil	stärker nutzungs- und vertragsabhängig	TCO-Szenarien für Normal-, Spitzen- und Wachstumsfall

Die Matrix wird pro Anwendungsfall ausgefüllt. Ein Chat-Assistent für öffentliches Produktwissen kann zu einer anderen Entscheidung führen als die Analyse vertraulicher Entwicklungsdokumente oder eine zeitkritische Produktionsunterstützung.

Konstruiertes Beispiel: lokal gelöst, Betrieb offengelassen

Das folgende Beispiel ist konstruiert.

Ein Unternehmen entscheidet sich für ein lokales Sprachmodell, damit vertrauliche Dokumente das eigene Netz nicht verlassen. Der Pilot funktioniert auf einer leistungsfähigen Arbeitsstation. Für den späteren Betrieb bleiben jedoch Fragen offen: Das Gerät besitzt keine definierte Vertretung, Modell- und Sicherheitsupdates werden nicht geplant, die Wissensdatenbank wird nicht gesichert und niemand misst, ob neue Dokumenttypen die Antwortqualität verschlechtern.

Der engere Datenpfad ist ein echter Vorteil. Er löst aber nicht automatisch Verfügbarkeit, Zugriffsschutz, Qualität und Wiederherstellung. Die Entscheidung war deshalb nicht falsch, sondern unvollständig.

Umgekehrt wäre auch ein gehosteter Dienst nicht allein deshalb betriebsreif, weil der Anbieter die Infrastruktur betreibt. Das Unternehmen müsste Datenfluss, Qualitätsgrenzen, Kostenlimit, Berechtigungen und Fallback weiterhin selbst verantworten.

Hybride Modelle sind möglich, aber nicht kostenlos

Ein hybrider Ansatz kann Aufgaben trennen:

• sensible Inhalte werden lokal verarbeitet,
• allgemeine oder besonders anspruchsvolle Aufgaben nutzen einen gehosteten Dienst,
• ein vorgeschalteter Prozess klassifiziert Daten und wählt die zulässige Route,
• ein gemeinsamer Test- und Protokollierungsrahmen bewertet beide Varianten.

Das kann Nutzen und Kontrolle verbinden. Es fügt jedoch Routinglogik, mehrere Betriebswege, zusätzliche Tests und ein komplexeres Berechtigungskonzept hinzu. Hybrid ist deshalb keine automatische Kompromisslösung, sondern eine eigene Architekturentscheidung.

Sie lohnt sich, wenn die Aufgabenklassen stabil unterschieden werden können und der zusätzliche Betrieb durch einen erkennbaren Nutzen gerechtfertigt ist.

Eine belastbare Entscheidungsreihenfolge

Für einen mittelständischen Anwendungsfall ist folgende Reihenfolge praktikabel:

1. Prozessgrenze, Nutzer und zulässige Aktionen festlegen.
2. Datenflüsse und Schutzbedarf vollständig beschreiben.
3. Qualitätsmaß und repräsentativen Testdatensatz definieren.
4. notwendige Verfügbarkeit, Antwortzeit und Lastszenarien bestimmen.
5. Ausschlusskriterien je Betriebsmodell prüfen.
6. verbleibende Optionen mit realistischen TCO-Szenarien vergleichen.
7. Owner, Support, Monitoring, Wiederherstellung und Fallback festlegen.
8. Wechselmöglichkeit praktisch testen, nicht nur vertraglich behaupten.
9. Pilot und Produktivbetrieb ausdrücklich trennen.
10. Entscheidung nach veränderter Nutzung, Technik oder Quellenlage erneut prüfen.

Das Generative-AI-Profil NIST AI 600-1 ergänzt den allgemeinen AI RMF um spezifische Risiken generativer KI und Maßnahmen für Beschaffung, Betrieb und Drittanbieter. Es liefert keine pauschale Antwort auf „lokal oder Cloud“. Genau das ist seine Stärke: Risiko und Maßnahme werden an Kontext und mögliche Wirkung gebunden.

Der erste sinnvolle Schritt ist deshalb kein Infrastrukturangebot. Er ist ein einseitiges Betriebsbriefing für genau einen Anwendungsfall. Wenn Datenfluss, Qualitätsgrenze, Owner, Last, Fallback und Ausstieg darauf nicht verständlich beschrieben werden können, ist auch der Vergleich der Bereitstellungsmodelle noch nicht entscheidungsreif.