Datensouveräne KI: Open-Source-LLMs im eigenen KMU-Betrieb

Warum 93 % der Unternehmen deutsche KI-Anbieter bevorzugen. Was Open-Source-LLMs wirklich kosten, wo sie reifen sind und wann der Mittelstand besser cloudbasiert bleibt.

These: Datensouveränität ist keine Option mehr

Im Gespräch mit Geschäftsführern höre ich einen Satz immer wieder. Wir würden KI gerne nutzen, aber nicht, wenn unsere Daten auf fremden Servern landen. Das ist keine übertriebene Vorsicht. Es ist eine strategische Position, die sich aus drei Entwicklungen ergibt.

Erstens wachsen die regulatorischen Anforderungen. Die DSGVO ist nur der Anfang. Branchenspezifische Vorschriften, Kundenverträge mit Datenschutzklauseln und Lieferantenbindungen sorgen dafür, dass ein einfacher API-Aufruf an einen US-Anbieter rechtlich problematisch werden kann. Zweitens erkennen immer mehr mittelständische Unternehmen, dass ihre eigenen Daten der wertvollste Rohstoff sind. Wenn diese Daten in eine Cloud-API fließen, trainiert damit potenziell ein fremdes Modell weiter. Das ist kein theoretisches Risiko. Es ist ein wirtschaftlicher Nachteil. Drittens zeigt der Markt, dass Datensouveränität verkaufbar ist. Kunden fragen gezielt nach, wo Daten verarbeitet werden. Behörden schreiben lokalen Betrieb vor. Wer hier früh handelt, baut Vertrauen auf, das sich in Aufträgen niederschlägt.

Datensouveränität ist deshalb im Mittelstand kein Luxus mehr. Sie ist eine strategische Notwendigkeit, die über Compliance hinausgeht. Wer seine Daten kontrolliert, kontrolliert auch seine Wettbewerbsfähigkeit. Das gilt besonders für Unternehmen mit sensiblen Kundendaten, technischen Spezifikationen oder internen Prozesswissen. Diese Informationen gehören nicht in eine fremde Wissensbasis. Sie gehören in eine eigene, kontrollierte Umgebung.

Beleg: Was die Zahlen wirklich sagen

Der Bitkom hat vor kurzem erhoben, dass 93 % der deutschen Unternehmen bei KI-Lösungen vorrangig auf deutsche Anbieter setzen wollen. Das ist keine sentimentale Vorliebe für Heimat. Das ist ein rationales Abwägen von Risiken. Deutsche Anbieter unterliegen der DSGVO, haben lokale Serverstandorte und lassen sich bei Problemen gerichtlich verfolgen. Das zählt, wenn es um sensible Geschäftsdaten geht.

Das Forschungsprojekt LLM4KMU begleitet seit Monaten, wie kleine und mittlere Unternehmen Large Language Models einsetzen. Eines der zentralen Ergebnisse: Der größte Hemmschuh ist nicht die Technologie. Es ist die Unsicherheit über den Verbleib der Daten. Unternehmen, die diese Hürde nehmen, berichten von deutlich höherer Akzeptanz bei Mitarbeitern und weniger Widerstand aus dem Betriebsrat. Das ist ein wichtiger Punkt, der oft übersehen wird. Technische Lösungen scheitern nicht an der Hardware. Sie scheitern an mangelndem Vertrauen.

Der Kostenvergleich zwischen On-Premise und Cloud fällt anders aus, als viele erwarten. Ein cloudbasierter GPT-4-Zugriff kostet bei intensiver Nutzung schnell mehrere tausend Euro pro Monat. Ein eigener Server mit einer Open-Source-LLM hat zwar Anschaffungskosten, aber keine laufenden API-Gebühren pro Token. Bei zwanzig oder mehr Nutzern im Unternehmen ist der Break-even oft nach zwölf bis achtzehn Monaten erreicht. Dazu kommt die Unabhängigkeit von Preiserhöhungen und API-Änderungen. Wer seine eigene Infrastruktur betreibt, kündigt nicht plötzlich funktionierende Workflows, weil ein Anbieter seine Geschäftsbedingungen ändert.

Allerdings darf man die versteckten Kosten nicht unterschätzen. Strom, Wartung, Backups und die Beschäftigung eines Administrators, der das System im Auge behält. Diese Positionen fehlen in vielen Kalkulationen. Wer On-Premise nur deshalb wählt, weil es auf dem Papier günstiger aussieht, ohne diese Faktoren einzurechnen, erlebt eine unangenehme Überraschung. Die Entscheidung für eigene Infrastruktur muss deshalb bewusst sein und das gesamte Kostenbild betrachten.

Marktanalyse: Welche Modelle sind reif für den Mittelstand?

Der Markt der Open-Source-LLMs hat sich in den letzten achtzehn Monaten dramatisch verdichtet. Drei Modelle dominieren die Diskussion im deutschsprachigen Raum. Meta Llama, Mistral und Falcon. Jedes hat Stärken, aber nicht jedes ist für den Mittelstand gleich geeignet.

Llama 3 in der 70-Milliarden-Parameter-Version liefert Ergebnisse, die in vielen Aufgaben auf dem Niveau früherer GPT-Versionen liegen. Es ist gut dokumentiert, hat eine riesige Community und lässt sich relativ einfach auf Standard-Hardware betreiben. Für Unternehmen, die erste Erfahrungen mit eigenen Sprachmodellen sammeln wollen, ist Llama ein sicherer Einstieg. Die Lizenzierung ist unkompliziert, und es gibt mittlerweile genug deutschsprachige Feintuning-Datensätze, um das Modell für lokale Anforderungen anzupassen.

Mistral aus Frankreich punktet mit Effizienz. Das Mixture-of-Experts-Modell erreicht hohe Qualität bei geringerem Ressourcenverbrauch. Für den Mittelstand bedeutet das: Man braucht weniger leistungsfähige GPUs, um akzeptable Antwortzeiten zu erreichen. Das senkt die Eintrittsbarriere spürbar. Allerdings ist die Dokumentation für deutschsprachige Anwendungsfälle noch lückenhafter als bei Llama. Wer Mistral einsetzt, sollte entweder internes Know-how haben oder mit einem Partner arbeiten, der das Modell bereits in Deutschland betreibt.

Falcon aus den Vereinigten Arabischen Emiraten ist technisch beeindruckend, spielt im deutschen Mittelstand aber bisher kaum eine Rolle. Die Community ist kleiner, deutsche Ressourcen sind rar, und die Integration in bestehende Middleware ist aufwendiger. Für Unternehmen mit arabischen Märkten oder spezifischen regulatorischen Anforderungen in der Region kann Falcon interessant sein. Für den typischen deutschen Maschinenbauer oder Dienstleister ist es derzeit keine pragmatische Wahl.

Die Frage nach den Kosten für einen eigenen Server lässt sich nicht pauschal beantworten. Ein Einsteigersystem mit einer NVIDIA A100 und 80 GB Speicher kostet etwa 12.000 bis 15.000 Euro. Damit lassen sich Modelle bis 70 Milliarden Parameter in akzeptabler Geschwindigkeit betreiben. Wer kleinere Modelle nutzt oder auf quantisierte Versionen zurückgreift, kommt auch mit einer A10G oder gar Consumer-Hardware aus. Das senkt die Kosten auf unter 5.000 Euro. Allerdings leidet dann die Qualität der Antworten spürbar. Die richtige Hardware hängt deshalb davon ab, welche Aufgaben das Modell übernehmen soll. Einfache Textzusammenfassungen funktionieren auf kleineren Systemen. Komplexe Analysen mit langen Kontextfenstern brauchen mehr Leistung.

Implikation: Wann On-Premise, wann Cloud?

Die Entscheidung zwischen eigener Infrastruktur und Cloud ist keine Glaubensfrage. Sie ist eine Kosten-Nutzen-Rechnung unter Berücksichtigung von Risiken und Ressourcen. Es gibt klare Situationen, in denen On-Premise die bessere Wahl ist. Wenn regulatorische Vorschriften den Standort der Daten vorschreiben. Wenn das Unternehmen hochsensible Informationen verarbeitet, deren Weitergabe an Dritte vertraglich ausgeschlossen ist. Oder wenn das Anfragevolumen so hoch ist, dass API-Gebühren schnell die Amortisation eigener Hardware rechtfertigen.

Genauso gibt es Situationen, in denen die Cloud sinnvoller bleibt. Wenn das Unternehmen KI erst einmal testen möchte, ohne fünfstellige Summen zu investieren. Wenn die interne IT-Abteilung ohnehin schon überlastet ist und niemand Zeit hat, einen GPU-Server zu administrieren. Oder wenn die Anforderungen so variabel sind, dass manchmal hundert Anfragen pro Tag laufen und manchmal zehntausend. Die Cloud skaliert diese Schwankungen automatisch. Eigene Hardware nicht.

Der pragmatische Mittelweg ist eine hybride Strategie. Standardaufgaben laufen in der Cloud. Sensitive Prozesse und Daten verarbeitet ein lokales Modell. Das erfordert eine Middleware, die beide Welten verbindet und je nach Anfrage das richtige Backend wählt. Genau diese Architektur setzen wir bei NaveSight ein. Unsere Intelligenz-Schicht kann cloudbasierte Modelle nutzen, Open-Source-LLMs aus dem eigenen Rechenzentrum ansprechen oder beides parallel betreiben. Die Entscheidung fällt nicht mehr beim Kauf der Software. Sie fällt pro Anwendungsfall und lässt sich jederzeit anpassen.

Die NaveSight-Perspektive: Intelligenz-Schicht mit Wahlfreiheit

Bei NaveSight haben wir von Anfang an eine Architektur gewählt, die den Betrieb von Open-Source-LLMs genauso unterstützt wie den Zugriff auf Cloud-APIs. Das ist keine nachträgliche Erweiterung. Sie ist fest in unserer Middleware verankert. Unsere Kunden entscheiden, wo ihre Wissensbasis liegt. Auf einem Server im eigenen Haus, in einem deutschen Rechenzentrum oder in einer zertifizierten Cloudumgebung.

Diese Flexibilität ist entscheidend, weil der Mittelstand heterogen ist. Ein Maschinenbauer mit strengen Kundenverträgen hat andere Anforderungen als ein E-Commerce-Händler mit saisonalen Spitzen. Unsere Muster-Erkennung arbeitet unabhängig davon, welches Sprachmodell im Hintergrund läuft. Die Rules Engine prüft, ob eine Anfrage sensitive Daten enthält, und leitet sie automatisch an das lokale Modell weiter. Standardanfragen können in der Cloud verarbeitet werden, wo mehr Rechenleistung verfügbar ist.

Diese Herangehensweise spiegelt sich auch in unserem Backoffice, IT & Compliance-Modul wider. Hier dokumentieren wir nicht nur, welche Daten wo verarbeitet werden. Wir machen diese Entscheidung konfigurierbar und nachvollziehbar. Für Geschäftsführer, die bei übergreifenden Prozessen den Überblick behalten wollen, und für IT-Verantwortliche, die eine saubere Trennung zwischen sensiblen und Standardprozessen umsetzen müssen.