Lokale KI wird für Unternehmen zu einer strategischen Architekturfrage. Besonders spannend wird das dort, wo chinesische Open-Weight-Modelle wie DeepSeek, Qwen oder Kimi On-Premise betrieben werden können. Viele Organisationen sind mit Cloud-KI gestartet: API anbinden, Prototyp bauen, erste Ergebnisse testen. Für den Einstieg war das sinnvoll. Doch sobald KI produktiv genutzt wird, ändern sich die Anforderungen.
Plötzlich geht es nicht mehr nur um Modellqualität, sondern um:
- laufende Tokenkosten
- sensible Unternehmensdaten
- regulatorische Anforderungen
- Abhängigkeiten von Cloud-Anbietern
- Betriebssicherheit
- Governance
- und die Frage, welche KI-Aufgaben wirklich ein teures Frontier-Modell benötigen
Genau deshalb prüfen immer mehr Unternehmen lokale KI-Modelle, Open-Weight-Modelle und hybride KI-Architekturen. Modelle wie DeepSeek, Qwen, Kimi oder GLM sind dabei nicht interessant, weil sie aus China stammen. Interessant werden sie, weil sie Kosten, Kontrolle und Datenhoheit neu verhandelbar machen.
Das Wichtigste in Kürze
Chinesische Open-Weight-Modelle sind für Unternehmen vor allem aus drei Gründen relevant: Kostenkontrolle, Datenhoheit und lokaler Betrieb.
Cloud-Modelle bleiben stark, wenn maximale Qualität, Reife des Ökosystems oder komplexes Reasoning gefragt sind. On-Premise-Modelle punkten dagegen bei sensiblen Daten, hohem Nutzungsvolumen und klaren Governance-Anforderungen.
Die beste Lösung ist häufig kein Entweder-oder, sondern eine hybride Modellstrategie: lokale Modelle für sensible und volumenstarke Standardaufgaben, Frontier-Modelle für komplexe Spezialfälle.
Warum das Thema gerade relevant ist
Die erste Welle generativer KI war geprägt von Geschwindigkeit. Unternehmen wollten ausprobieren, was möglich ist: interne Chatbots, Dokumentenzusammenfassungen, Wissensassistenten, Code-Unterstützung, erste Automatisierungen.
In dieser Phase waren Cloud-APIs ideal. Sie waren schnell verfügbar, technisch bequem und qualitativ überzeugend.
Inzwischen verschiebt sich der Fokus.
Aus Experimenten werden produktive Anwendungen. Aus einzelnen Prompts werden dauerhafte Workflows. Aus überschaubaren Kosten werden wiederkehrende Budgets. Und aus anonymen Testdaten werden echte Unternehmensinformationen.
Damit entstehen neue Leitfragen:
| Frage | Warum sie jetzt wichtiger wird |
|---|---|
| Was kostet KI bei täglicher Nutzung? | Tokenvolumen wächst stark, sobald KI produktiv läuft. |
| Welche Daten verlassen das Unternehmen? | Verträge, Quellcode, Kundendaten oder interne Dokumente sind sensibel. |
| Wer kontrolliert Modellzugriffe und Logs? | KI muss in bestehende Security- und Governance-Prozesse passen. |
| Welche Modelle sind wirklich nötig? | Nicht jeder Use Case braucht ein Top-Tier-Frontier-Modell. |
| Wie bleibt das Unternehmen flexibel? | Anbieterpreise, Modellqualität und Regulierung ändern sich schnell. |
Praxispunkt: Die KI-Diskussion verschiebt sich von „Welches Modell ist am besten?“ zu „Welche Architektur ist für unsere Daten, Kosten und Prozesse tragfähig?“
Lokale KI statt reiner Cloud-API: Warum sich die Anforderungen ändern
Viele Unternehmen starten mit einem einfachen Setup: Eine Anwendung sendet Prompts an ein Cloud-Modell, das Modell liefert Antworten zurück. Für Prototypen ist das effizient.
Doch im produktiven Betrieb entsteht schnell mehr Komplexität.
Ein internes RAG-System durchsucht Dokumente, bereitet Kontext auf, sendet längere Prompts, bewertet Antworten und speichert Ergebnisse. Ein KI-Agent ruft Tools auf, verarbeitet Zwischenschritte und erzeugt mehrere Modellanfragen pro Aufgabe. Ein Code-Assistent analysiert große Mengen internen Quellcode.
Damit wird KI Teil der Unternehmensinfrastruktur.
Typische Entwicklung in Unternehmen
| Phase | Fokus | Typische Frage |
|---|---|---|
| Experiment | Geschwindigkeit | Was kann KI für uns leisten? |
| Pilot | Nutzen | Welcher Use Case lohnt sich? |
| Produktivbetrieb | Skalierung | Was kostet das dauerhaft? |
| Governance | Kontrolle | Welche Daten, Modelle und Risiken müssen wir steuern? |
| Zielarchitektur | Nachhaltigkeit | Welche Modellstrategie passt langfristig? |
Der entscheidende Punkt: KI wird nicht mehr nur als Tool betrachtet, sondern als Betriebsmodell. Genau hier entstehen On-Premise-Szenarien.
Was mit chinesischen KI-Modellen gemeint ist
Der Begriff „chinesische KI-Modelle“ ist unscharf. Für Unternehmen ist deshalb eine klare Unterscheidung wichtig.
Es gibt einen großen Unterschied zwischen:
- der Nutzung einer externen chinesischen API,
- dem lokalen Betrieb eines Open-Weight-Modells,
- einer hybriden Architektur mit mehreren Modellklassen.
Für europäische Unternehmen ist besonders die zweite Variante interessant: Modelle, deren Gewichte lokal betrieben werden können. Dabei bleiben Daten, Zugriffskontrolle und Infrastruktur stärker im eigenen Einflussbereich.
Relevante Modellfamilien
| Modellfamilie | Anbieter | Warum sie relevant ist |
|---|---|---|
| DeepSeek | DeepSeek AI | Stark diskutiert bei Kosten, Coding und Reasoning; Open-Weight-Varianten verfügbar. |
| Qwen | Alibaba | Breite Modellfamilie, multilingual, Coding- und Enterprise-relevante Varianten. |
| Kimi | Moonshot AI | Relevant für lange Kontexte und agentische Workflows. |
| GLM | Zhipu AI | Weitere chinesische Open-Weight-Alternative. |
Wichtig ist: Die Herkunft eines Modells ist nicht allein entscheidend. Unternehmen sollten nüchtern prüfen:
- Welche Lizenz gilt?
- Sind die Modellgewichte verfügbar?
- Wie gut ist das Modell im eigenen Use Case?
- Wie lässt es sich betreiben?
- Welche Sicherheitsrisiken bestehen?
- Wie transparent sind Updates und Modellverhalten?
- Welche Daten dürfen verarbeitet werden?
Kurz gesagt: Für Unternehmen zählt nicht, ob ein Modell „chinesisch“ oder „amerikanisch“ ist. Entscheidend ist, ob es wirtschaftlich, sicher, rechtlich und technisch zum jeweiligen Einsatz passt.
Warum Tokenkosten strategisch relevant werden
Bei ersten KI-Prototypen fallen Tokenkosten oft kaum ins Gewicht. Einige Tests, ein kleiner Pilot, ein paar interne Anwender: Das bleibt meist überschaubar.
Im produktiven Betrieb sieht das anders aus.
Tokenvolumen entsteht nicht nur durch direkte Nutzereingaben. Es entsteht auch durch Kontextdokumente, Systemprompts, Zwischenschritte, Tool-Aufrufe, Antwortvalidierungen und wiederholte Modellanfragen.
Wo Tokenvolumen schnell wächst
- Dokumentenanalyse mit vielen Dateien
- RAG-Systeme mit langen Kontexten
- interne Wissensassistenten
- Codeanalyse
- automatisierte Klassifikation
- Kundenservice-Workflows
- KI-Agenten mit mehreren Verarbeitungsschritten
- Massendatenverarbeitung
Ein einzelner Prompt ist selten das Problem. Die Summe produktiver Workflows ist es.
Die eigentliche Kostenfrage
Nicht der Preis pro Token allein entscheidet, sondern der Preis pro erledigtem Prozess.
Ein günstiges Modell kann teuer werden, wenn es häufig falsche Ergebnisse liefert oder Nacharbeit verursacht. Ein teures Modell kann wirtschaftlich sein, wenn es komplexe Aufgaben zuverlässig löst.
Deshalb sollten Unternehmen Kosten immer mit Qualität, Risiko und Automatisierungsgrad verbinden.
| Bewertungsfrage | Bedeutung |
|---|---|
| Wie viele Token verbraucht der Prozess? | Grundlage für laufende Kosten. |
| Wie zuverlässig ist das Ergebnis? | Schlechte Qualität erzeugt Nacharbeit. |
| Wie kritisch ist der Prozess? | Fehler haben je nach Use Case unterschiedliche Folgen. |
| Wie oft wird die Aufgabe ausgeführt? | Hohe Wiederholung begünstigt lokale Modelle. |
| Welche Daten werden verarbeitet? | Sensible Daten können On-Premise attraktiver machen. |
Praxispunkt: Unternehmen sollten nicht „Modellpreise“ vergleichen, sondern Use-Case-Kosten. Entscheidend ist, was ein vollständiger Prozess kostet – inklusive Qualitätssicherung, Betrieb und Nacharbeit.
Wann lokale KI für Unternehmen sinnvoll wird
On-Premise-KI klingt zunächst einfach: Modell herunterladen, GPU bereitstellen, lokal betreiben. In der Praxis ist es anspruchsvoller.
Lokaler Betrieb kann wirtschaftlich und strategisch sinnvoll sein, wenn mehrere Bedingungen zusammenkommen:
- hohe oder planbare Nutzung,
- sensible Daten,
- klare Anforderungen an Datenhoheit,
- internes oder externes Betriebs-Know-how,
- wiederkehrende Standardaufgaben,
- Bedarf an Governance und Auditierbarkeit.
Vorteile von On-Premise-KI
| Vorteil | Bedeutung für Unternehmen |
|---|---|
| Datenkontrolle | Sensible Inhalte müssen nicht zwingend an externe APIs übertragen werden. |
| Kostenplanung | Infrastrukturkosten können bei hoher Auslastung planbarer sein als Tokenabrechnung. |
| Governance | Zugriff, Logging und Rollenmodelle lassen sich intern steuern. |
| Integration | Lokale Modelle können enger in bestehende Systeme eingebunden werden. |
| Unabhängigkeit | Weniger direkte Abhängigkeit von einzelnen Cloud-API-Preisen. |
Grenzen von On-Premise-KI
| Herausforderung | Warum sie wichtig ist |
|---|---|
| Hardwarekosten | GPU-Server oder Appliances sind teuer. |
| Auslastung | Unausgelastete Hardware verschlechtert die Wirtschaftlichkeit. |
| Betrieb | Monitoring, Patching, Updates und Security müssen organisiert werden. |
| Know-how | LLMOps, Inferenz-Stacks und Modellbewertung erfordern Erfahrung. |
| Modellqualität | Nicht jedes lokale Modell erreicht Frontier-Niveau. |
Der häufigste Fehler ist eine zu einfache Rechnung: „Eigene GPU ist günstiger als API.“ Das stimmt nur, wenn die Auslastung hoch genug ist und der Betrieb professionell organisiert wird.
Kurz gesagt: On-Premise lohnt sich nicht wegen der Hardware. Es lohnt sich, wenn Use Case, Datenlage, Governance und Auslastung zusammenpassen.
EU AI Act, DSGVO und digitale Souveränität
Regulierung ist ein wichtiger Treiber der Debatte – aber sie wird oft zu pauschal dargestellt.
Der EU AI Act ist kein reines Datenschutzgesetz. Er regelt unter anderem Risikoklassen, Transparenzpflichten, Governance und Anforderungen an bestimmte KI-Systeme und General-Purpose-AI-Modelle.
Parallel bleiben weitere Themen relevant:
- DSGVO
- Auftragsverarbeitung
- Datenklassifizierung
- Cloud-Verträge
- Informationssicherheit
- branchenspezifische Vorgaben
- Kundenanforderungen
- NIS2 oder DORA, je nach Branche
Für Unternehmen entsteht daraus eine praktische Frage: Welche Daten dürfen in welchem technischen und rechtlichen Setup verarbeitet werden?
Warum On-Premise regulatorisch attraktiv sein kann
On-Premise bedeutet nicht automatisch Compliance. Aber lokaler Betrieb kann helfen, bestimmte Risiken besser zu steuern.
Beispiele:
- Kundendaten bleiben im eigenen Rechenzentrum
- vertrauliche Dokumente werden nicht an externe APIs übertragen
- Zugriffe können über bestehende Rollenmodelle gesteuert werden
- Logs bleiben intern verfügbar
- Modellversionen lassen sich dokumentieren
- Audit- und Freigabeprozesse können in bestehende IT-Governance eingebunden werden
Trotzdem braucht auch lokale KI klare Regeln. Wer ein Modell intern betreibt, muss dokumentieren, welche Version eingesetzt wird, welche Daten verarbeitet werden, wer Zugriff hat, wie Outputs geprüft werden und wie Sicherheitsupdates erfolgen.
Praxispunkt: Datenhoheit ist kein einzelnes Feature. Sie entsteht durch Architektur, Prozesse, Berechtigungen, Monitoring und Governance.
Können chinesische Modelle qualitativ mithalten?
Die Frage „Kann Modell X mit GPT oder Claude mithalten?“ ist für Unternehmen meist zu grob.
Besser ist die Frage: Reicht dieses Modell für unseren konkreten Prozess aus?
Viele Unternehmensaufgaben benötigen nicht zwingend das stärkste Modell am Markt. Für Zusammenfassungen, Klassifikation, Extraktion, einfache Recherche, Dokumentenvorbereitung oder bestimmte Coding-Aufgaben können lokale Open-Weight-Modelle sehr gute Ergebnisse liefern.
Bei anderen Aufgaben bleiben Frontier-Modelle im Vorteil.
Use-Case-Vergleich
| Use Case | Lokales Open-Weight-Modell | Frontier-Modell |
|---|---|---|
| Dokumentenzusammenfassung | oft ausreichend bis gut | sehr gut |
| Klassifikation | oft sehr gut | sehr gut |
| Informationsextraktion | oft gut | sehr gut |
| Coding-Unterstützung | je nach Modell stark | häufig führend |
| komplexes Reasoning | prüfen | häufig stärker |
| multimodale Anwendungen | oft begrenzt | meist stärker |
| sensible interne Dokumente | On-Premise-Vorteil | abhängig von Setup |
| Massennutzung | oft wirtschaftlich attraktiv | häufig teurer |
Warum eigene Benchmarks wichtiger sind als Leaderboards
Öffentliche Benchmarks geben Orientierung. Sie ersetzen aber keine Use-Case-Prüfung.
Ein Unternehmen sollte mit eigenen Beispieldaten testen:
- Wie korrekt sind die Antworten?
- Wie stabil ist das Modell bei ähnlichen Aufgaben?
- Wie gut funktioniert es mit deutschen Fachtexten?
- Wie verhält es sich bei langen Dokumenten?
- Wie häufig halluziniert es?
- Wie gut lässt es sich in Workflows integrieren?
- Wie hoch sind Latenz und Betriebskosten?
Kurz gesagt: Es geht nicht darum, ob ein lokales Modell „das beste Modell“ ist. Es geht darum, ob es für den konkreten Prozess gut genug, sicher genug und wirtschaftlich genug ist.
Risiken chinesischer KI-Modelle
Ein glaubwürdiger Blick auf chinesische KI-Modelle muss Risiken klar benennen. Open-Weight heißt nicht automatisch risikofrei. Lokal heißt nicht automatisch sicher. Günstig heißt nicht automatisch wirtschaftlich.
Zentrale Risikofelder
| Risiko | Worauf Unternehmen achten sollten |
|---|---|
| Lizenz | Ist kommerzielle Nutzung erlaubt? Gibt es Einschränkungen? |
| Herkunft | Woher stammen Modellgewichte und Updates? |
| Transparenz | Was ist über Training, Alignment und Sicherheitsmechanismen bekannt? |
| Modellverhalten | Gibt es Bias, Zensur oder unerwartete Antwortmuster? |
| Security | Wie wird das Modell abgesichert und aktualisiert? |
| Betrieb | Gibt es Monitoring, Logging und Verantwortlichkeiten? |
| Support | Wie reif sind Tooling, Community und Enterprise-Unterstützung? |
Besonders wichtig ist die Trennung zwischen Modellrisiko und Betriebsrisiko.
Ein Modell kann technisch gut sein, aber schlecht betrieben werden. Umgekehrt kann ein solides Betriebskonzept viele Risiken reduzieren, ersetzt aber keine Modellprüfung.
Typische Missverständnisse
| Missverständnis | Realistische Einordnung |
|---|---|
| „Open Weight bedeutet volle Transparenz.“ | Meist sind Gewichte offen, aber Trainingsdaten und Alignment nicht vollständig nachvollziehbar. |
| „On-Premise ist automatisch sicher.“ | Sicherheit entsteht erst durch Betrieb, Zugriffskontrolle und Monitoring. |
| „Günstige Modelle sind immer günstiger.“ | Nur wenn Qualität, Nacharbeit und Betriebskosten passen. |
| „Ein Modell reicht für alles.“ | Unternehmen brauchen meist mehrere Modellklassen. |
Praxispunkt: Chinesische Modelle sollten nicht euphorisch übernommen, sondern systematisch bewertet werden – wie jede andere kritische Technologie auch.
Die realistische Lösung: Hybrid statt Entweder-oder
Die Zukunft liegt wahrscheinlich nicht in „Cloud oder On-Premise“. Realistischer ist eine hybride KI-Architektur.
Dabei entscheidet nicht der Anbieter, sondern der Use Case.
Beispiel für Modell-Routing
| Aufgabe | Sinnvolle Modellstrategie |
|---|---|
| sensible interne Dokumente | lokales Modell |
| einfache Klassifikation | günstiges lokales Modell |
| große Dokumentenverarbeitung | lokales Modell wegen Kostenkontrolle |
| Standard-Chatbot | lokales oder günstiges API-Modell |
| komplexes Reasoning | Frontier-Modell |
| multimodale Spezialfälle | Frontier-Modell |
| Code-Review mit Schutzbedarf | lokales Coding-Modell plus Fallback |
| besonders kritische Entscheidungen | Modell plus menschliche Prüfung |
Ein solches Routing kann nach mehreren Kriterien erfolgen:
- Datenklasse
- Sensibilität
- gewünschte Qualität
- Kostenrahmen
- Latenz
- Risiko
- regulatorische Anforderungen
- Verfügbarkeit interner Systeme
Das Ziel ist nicht, möglichst viele Modelle zu nutzen. Das Ziel ist eine Architektur, die Aufgaben intelligent verteilt.
Starker Merksatz: Unternehmen brauchen künftig keinen Lieblingsanbieter, sondern eine Modellstrategie.
Entscheidungsmatrix: Wann lohnt sich On-Premise?
Bevor Unternehmen in lokale KI-Infrastruktur investieren, sollten sie strukturiert prüfen, ob On-Premise wirklich sinnvoll ist.
10 Fragen für die Bewertung
- Welche Daten werden verarbeitet?
- Sind personenbezogene, vertrauliche oder regulierte Daten enthalten?
- Wie hoch ist das monatliche Tokenvolumen?
- Wie stark schwankt die Nutzung?
- Welche Qualitätsanforderung hat der Use Case?
- Ist Latenz kritisch?
- Gibt es internes Know-how für GPU-Betrieb oder LLMOps?
- Muss das Modell auditierbar sein?
- Welche Vorgaben ergeben sich aus DSGVO, EU AI Act, NIS2, DORA oder Kundenverträgen?
- Ist ein hybrides Routing möglich?
Einfache Orientierung
| Situation | Empfehlung |
|---|---|
| frühes Experiment, geringe Nutzung | Cloud-Modell nutzen |
| sensible Daten, hohe Wiederholung | On-Premise prüfen |
| komplexe Aufgaben mit hoher Qualitätsanforderung | Frontier-Modell einsetzen |
| hohe Kosten bei Standardaufgaben | lokales Modell benchmarken |
| gemischte Anforderungen | hybride Architektur aufbauen |
Diese Matrix ersetzt keine technische Analyse, verhindert aber vorschnelle Entscheidungen.
Best Practices für den Einstieg
Der beste Einstieg beginnt nicht mit Hardware. Er beginnt mit Use Cases.
Schritt 1: Use Cases priorisieren
Nicht jeder Prozess eignet sich gleich gut. Gute Kandidaten sind Aufgaben mit klarer Struktur, hoher Wiederholung und messbarem Ergebnis.
Beispiele:
- Dokumente zusammenfassen
- Informationen extrahieren
- Texte klassifizieren
- interne Wissensabfragen beantworten
- Code analysieren
- Supportfälle vorsortieren
Schritt 2: Daten klassifizieren
Bevor ein Modell ausgewählt wird, muss klar sein, welche Daten verarbeitet werden.
- öffentlich
- intern
- vertraulich
- personenbezogen
- reguliert
- geschäftskritisch
Diese Klassifizierung entscheidet stark darüber, ob Cloud, On-Premise oder Hybrid sinnvoll ist.
Schritt 3: Modelle benchmarken
Unternehmen sollten mehrere Modelle mit echten Testfällen vergleichen. Wichtig sind nicht nur Antwortqualität, sondern auch Latenz, Stabilität, Halluzinationsrate, Integrationsaufwand und Kosten.
Schritt 4: Betriebskonzept definieren
Lokale KI braucht klare technische Verantwortung.
Dazu gehören:
- Modellversionierung
- Monitoring
- Zugriffskontrolle
- Logging
- Sicherheitsupdates
- Evaluierungsprozesse
- Prompt-Schutz
- Notfall- und Fallback-Konzepte
Schritt 5: Hybrid starten
Für viele Unternehmen ist ein hybrider Pilot sinnvoll: lokale Modelle für sensible Standardaufgaben, Cloud-Fallback für komplexe Fälle. So entsteht Praxiserfahrung, ohne sich zu früh auf eine starre Zielarchitektur festzulegen.
Fazit: On-Premise-KI ist eine Architekturentscheidung
Chinesische KI-Modelle On-Premise zu betreiben ist kein pauschaler Wechsel von einem Anbieter zum anderen. Es ist eine Architekturentscheidung.
Unternehmen prüfen diese Option, weil produktive KI neue Anforderungen stellt: Kostenkontrolle, Datenhoheit, Governance, Skalierbarkeit und sicherer Betrieb.
Open-Weight-Modelle wie DeepSeek, Qwen, Kimi oder GLM erweitern den Handlungsspielraum. Sie können besonders dort sinnvoll sein, wo sensible Daten verarbeitet werden oder hohe Tokenvolumen entstehen. Gleichzeitig müssen Lizenz, Herkunft, Modellverhalten, Security, Support und Betrieb kritisch geprüft werden.
Die beste Strategie ist häufig hybrid. Lokale Modelle übernehmen sensible und volumenstarke Standardprozesse. Frontier-Modelle bleiben für komplexe Aufgaben verfügbar. Dazwischen braucht es klare Regeln, Modell-Routing und technische Governance.
Für Unternehmen bedeutet das: Nicht das einzelne Modell entscheidet über den Erfolg, sondern die Qualität der Architektur.
GECKO unterstützt Unternehmen dabei, diese Fragen strukturiert zu klären – von AI Readiness und Use-Case-Priorisierung über Daten- und Prozessanalyse bis zur passenden Zielarchitektur für produktive KI. Denn erfolgreiche KI-Projekte scheitern selten am Modell allein. Sie stehen und fallen mit Daten, Prozessen, Integration, Governance und Betrieb.
