Die Ökonomie offener KI-Modelle: Wann sich Self-Hosting für KMU wirtschaftlich rechnet

Die Token-Rechnung, die niemand kommen sah

Ein mittelständischer DACH-Beratungsbetrieb mit rund 30 Mitarbeitenden hatte einen Prototyp im Backend perfektioniert: ein Assistenzfeature, das aus internen Recherche-Notizen fertige Kundenzusammenfassungen entwarf. Auf der geschlossenen API eines großen Modellanbieters lief das Feature drei Monate stabil – bis die Monatsrechnung plötzlich um ein Vielfaches über dem erwarteten Rahmen lag. Ein fehlerhafter Prompt-Loop hatte still im Hintergrund Millionen zusätzlicher Token erzeugt. Der Anbieter bot keine harte Kostenobergrenze, sondern nur ein Dashboard, das niemand regelmäßig beobachtete.

Dieses Szenario ist illustrativ, kein gemessener Kundenfall und kein Benchmark. Es beschreibt aber den Moment, in dem KI für ein KMU von einem Werkzeug zum finanziellen Risiko wird. Das Feature wurde nicht abgeschaltet, weil es inhaltlich scheiterte. Es wurde reduziert, weil sein Preis unberechenbar geworden war. Genau hier beginnt die eigentliche Frage der KI-Ökonomie: Nicht „welches Modell ist am besten?", sondern „wer kontrolliert Kosten, Datenort und Ausstieg?".

Viele KMU sind über 2024 und 2025 genau diesen einfachen Weg gegangen: gemietete APIs mit nutzungsabhängiger Abrechnung und sitzbasierte KI-Bündel in bestehenden Softwareverträgen. Das verschafft schnell Fähigkeit. Es baut aber keine Betriebsgrundlage auf. Wenn die nächste Rechnung steigt oder der nächste Vertrag die Bedingungen ändert, fehlt der Ausstiegspfad. Die KI-Fähigkeit existiert – die Kontrolle über Kosten, Datenlage, Audit-Trail und Exit fehlt.

Was die KI-Ökonomie für ein KMU bedeutet

KI-Ökonomie ist für ein KMU kein Benchmark-Vergleich. Sie ist die Frage, wie AI finanziell und rechtlich im Unternehmen steht: als gemietete Fähigkeit mit nutzungsabhängiger Abrechnung oder als eigene, selbst betriebene Fähigkeit mit planbaren Kosten. Drei Begriffe bestimmen diese Entscheidung.

Nutzungsabhängige Abrechnung bedeutet: Jeder Token, den das Modell verarbeitet, wird anteilig berechnet. Das ist heute der Standardweg, KI zu konsumieren. Er ist flexibel, weil nur gezahlt wird, was verbraucht wird. Er ist aber auch unberechenbar, weil ein fehlerhafter Loop, ein wachsender Use-Case oder ein unachtsamer Prompt die Rechnung treibt, ohne dass ein harter Stop existiert.

Sitzbasierte Bündel bedeuten: KI-Funktionen werden in bestehende Softwarepakete integriert und über die Laufzeit auf alle Nutzenden umgelegt – auch auf die, die die Funktion kaum nutzen. Das senkt die Einstiegshürde, verteuert aber die gesamte Suite und macht es schwer, auf einen kleineren Tarif zurückzufallen.

Selbst betriebene KI bedeutet: Ein offenes Gewichtsmodell wird auf eigener oder souveräner Infrastruktur ausgeführt. Die Kosten verschieben sich von volatiler Token-Abrechnung zu planbarer Infrastruktur – GPU-Kapazität, Kubernetes-Betrieb, Orchestrierung. Dafür erhält das Unternehmen echte Datenhoheit und einen Ausstiegsschlüssel: Modell und Prompts bleiben eigene Artefakte.

Ein nüchterner Punkt bleibt über alle drei Wege hinweg gültig: Die KI-Fähigkeit allein ist kein Geschäftswert. Erst eine Betriebsschicht – wer darf was lesen, wer prüft, wo stehen die Daten, was bleibt im Log, wie wird ausgestiegen – macht aus einer günstigen oder starken API eine kontrollierte, wiederholbare, verantwortbare Fähigkeit. Den meisten KMU fehlt genau diese Schicht.

Die versteckten Kosten gemieteter KI

Die offensichtliche Rechnung ist die Token-Rechnung. Die teureren Kosten sind die, die nicht monatlich auf dem Dashboard stehen. Sie zeigen sich erst, wenn ein Vertrag erneuert oder ein Datenfluss geprüft wird.

Token-Volatilität: Nutzungsabhängige Abrechnung bedeutet, dass Spitzenlasten direkt durchschlagen. Ein beliebtes internes Feature, ein neues Team oder ein fehlerhafter Loop vervielfachen den Verbrauch, ohne Vorwarnung. Das Budget für KI wird so zur Schätzung statt zur Planzahl.

Vertragsänderungen zur Laufzeit: Anbieter ändern Nutzungsbedingungen und Datenverarbeitungswege auch innerhalb einer Laufzeit. Ein DACH-Dienstleister – illustrativ – stellt fest, dass sein KI-Assistent kundennahe Anfragen an einen Endpunkt außerhalb der vereinbarten Datenregion gesendet hat und damit die eigene Datenverarbeitungsvereinbarung verletzt. Ein selbst betriebener Fallback war nie konfiguriert.

Sitzbindung bei Erneuerung: Microsoft hat am 4. Dezember 2025 eine globale Listenpreis- und Paketaktualisierung für kommerzielle Microsoft-365-Suiten angekündigt, die am 1. Juli 2026 in Kraft tritt und zusätzliche KI- und Sicherheitsfunktionen in die Suiten bündelt. Die genaue prozentuale Auswirkung variiert je SKU – unabhängige Quellen nennen eine sehr breite Spanne –, das bestätigte Muster ist jedoch klar: KI-Funktionen werden über höhere Bündelpreise und metered-Abrechnung finanziert. Ein KMU zahlt so für KI-Sitze in der ganzen Firma, die nur wenige tatsächlich nutzen, ohne dass ein sauberer kleinerer Tarif in Reichweite ist.

Datenhoheit als Aufpreis: Datenresidenz ist kein Selbstbedienungs-Feature, sondern eine kostenpflichtige Option. OpenAI erhebt für regionale Verarbeitungs-Endpunkte (Data Residency) bei Modellen ab dem 5. März 2025 einen Aufschlag von zehn Prozent – das ist ein handfestes Beleg dafür, dass Anbieter Datenresidenz als Premium preisen. Selbst betriebene KI auf DACH-Infrastruktur macht genau diesen Aufpreis überflüssig, weil die Inferenz dort läuft, wo die Daten liegen sollen.

Lock-in ohne Ausstieg: Wer KI nur gemietet hat, besitzt nichts, wenn der Anbieter den Preis, die Region oder die Modellverfügbarkeit ändert. Es gibt keine Gewichte zum Re-Hosten, keine Prompts als eigenes Artefakt, keinen Ausstiegspfad. Das klassische Lock-in-Muster trifft die KI-Ebene – nur dass hier zusätzlich sensible Daten im Spiel sind.

Fünf Warnsignale, dass Ihre KI Sie vermietet

Bevor ein KMU teure Architekturentscheidungen trifft, helfen praktische Signale, die sich im eigenen Betrieb wiedererkennen lassen. Fünf Warnsignale zeigen, dass die KI das Unternehmen eher vermietet als befähigt.

• Nutzungsabhängige Abrechnung ohne harte Ober­grenze. Es gibt ein Dashboard, aber keinen Stop-Mechanismus, der bei einer bestimmten Kostenmarke verbindlich anhält.
• Daten verlassen die vereinbarte Region. Weder ist dokumentiert, wo die Inferenz läuft, noch wohin Anfragedaten fließen – und der Vertrag deckt den tatsächlichen Datenweg nicht ab.
• KI-Sitze, die niemand bewusst gewählt hat. Die Suite ist teurer geworden, weil KI-Funktionen hinzugebündelt wurden, nicht weil das Team sie angefordert hat.
• Kein Audit-Trail. Niemand kann später rekonstruieren, welche Modellversion lief, was vorgeschlagen wurde, wer freigegeben oder korrigiert hat und warum.
• Kein Ausstiegspfad. Es existiert kein Plan, wie die Fähigkeit auf anderer Infrastruktur, mit einem anderen Modell oder ohne den aktuellen Anbieter weiterlaufen könnte.

Wer diese Signale ignoriert, erlebt das gleiche Muster wie bei ungeprüfter SaaS-Ausbreitung, nur auf der sensibleren KI-Ebene: Die Fähigkeit wächst, die Beherrschbarkeit schrumpft. Genau dieses unkontrollierte KI ist es, was ein regulierter, selbst betriebener Pfad ersetzen soll.

Was sich im zweiten Quartal 2026 geändert hat

Bis 2025 lautete die ehrliche Antwort auf „reicht ein offenes Modell?" meist: für einfache Aufgaben ja, für anspruchsvolle Enterprise-Workloads eher nicht. Im zweiten Quartal 2026 hat sich das spürbar verschoben – und dieser Wandel ist die Grundlage, warum die Frage „selbst betreiben?" überhaupt wirtschaftlich diskutiert wird.

Betrachtet man die vendor-neutrale AI-Arena-Text-Leaderboard (betrieben von Arena Intelligence, dem Nachfolger der LMSYS Chatbot Arena; Snapshot vom 25. Juni 2026, 661 Modelle), gilt eine nüchterne Lesart: Neun der zehn besten Modelle sind weiterhin geschlossen. Das stärkste offene beziehungsweise offen-orientierte Modell liegt etwa 21 Elo-Punkte beziehungsweise rund 1,4 Prozent hinter dem Spitzenplatz. Auf quantitativen und Coding-Aufgaben rangieren offene Gewichte inzwischen in der Top-Liga. An der absoluten Frontier – und bei kreativen sowie instruktionsnahen Aufgaben – bleibt das Feld jedoch geschlossen geführt.

Das bedeutet konkret: Es ist nicht korrekt zu sagen, offene Modelle seien „jetzt die besten" oder „ganz aufgeschlossen". Korrekt ist: Offene Gewichte haben die Lücke auf einstellige bis niedrige zweistellige Prozentbereiche auf vielen Aufgaben geschlossen und machen Self-Hosting für eine wachsende Zahl realer Workloads glaubwürdig.

Diese Qualitätsverschiebung wird durch eine handfeste Kostenschieflage ergänzt. Nach den offiziellen Preisseiten – DeepSeek für günstige offene Gewichts-Inferenz, OpenAI für die geschlossene Frontier – kostet die Ausgabe eines Million Tokens beim geschlossenen Frontier-Modell ein Vielfaches dessen, was ein offenes Gewichtsmodell verlangt. Die gemessenen Relationen reichen von grob 34-fach bis über 100-fach pro Ausgabe-Token. Und wer Datenresidenz beim geschlossenen Anbieter wünscht, zahlt zusätzlich den erwähnten zehnprozentigen Aufpreis. Offene Gewichte sind nicht kostenlos – sie brauchen Infrastruktur und Betrieb. Aber die Kostenrelation hat sich so deutlich verschoben, dass sich die Frage „selbst betreiben?" für die richtigen Workloads wirtschaftlich lohnt.

Die eigentliche Pointe ist jedoch: Ein günstiger offener API-Endpunkt gewinnt an Kosten, aber nicht an Datenhoheit. Die Daten verlassen weiterhin die DACH-Region. Erst Self-Hosting auf souveräner Infrastruktur verbindet planbare Kosten mit echter Datenhoheit und einem Ausstiegsschlüssel. Genau diese Trennung – Kosten versus Souveränität – muss jedes KMU verstanden haben, bevor es eine Entscheidung trifft.

Mieten, kaufen oder selbst betreiben: Ein Entscheidungsraster für KMU

Drei wirtschaftliche Pfade stehen zur Wahl, und nur einer liefert echte Datenhoheit. Die Entscheidung hängt weniger vom besten Modell ab als von Sensitivität, Volumen und Vorhersehbarkeit des jeweiligen Workloads.

1. Geschlossene Frontier mieten. Höchste Einheitskosten pro Token, Daten verlassen den DACH-Raum (mit Datenresidenz-Aufpreis), kein Ausstiegsschlüssel. Sinnvoll für Workloads, die die absolute Frontier brauchen, geringes Volumen haben oder schnell experimentiert werden müssen.

2. Offene Gewichte als API mieten. Günstig pro Token, aber weiterhin gemietet – die Daten verlassen weiterhin den DACH-Raum. Gut für kostengünstiges Experimentieren und niedrige Volumina, ungeeignet, wenn Datenhoheit Pflicht ist.

3. Offene Gewichte auf DACH-Infrastruktur selbst betreiben. Planbare Infrastrukturkosten plus echte Datenhoheit plus Ausstiegsschlüssel – erfordert aber eine Betriebsschicht: GPU-Kapazität, Kubernetes, Inferenz-Serving, Orchestrierung über n8n, menschliche Freigaben, Logging und Resident-Prüfung. Zahlt sich aus für sensible, hochvolumige, wiederkehrende Workloads.

Kriterium	Geschlossene API	Offene API	Selbst betrieben (DACH)
Kosten pro Token	am höchsten	sehr gering	planbar, fix
Datenhoheit	nein (Aufpreis möglich)	nein	ja
Kosten-Vorher­sagbarkeit	gering (metered)	gering (metered)	hoch (Infrastruktur)
Ausstiegsschlüssel	nein	nein	ja
Betrieblicher Aufwand	minimal	minimal	erheblich (GPU, K8s, Ops)
Beste für	Frontier, geringes Volumen	Experiment, niedriges Volumen	sensibel, hochvolumig, wiederkehrend

Was Self-Hosting tatsächlich verlangt, ist nicht herunterladbares Diffusionswissen, sondern eine Betriebsschicht. Offene Gewichte müssen serviert werden: ein Inference-Layer, GPU-Kapazität dimensioniert auf die Spitzenlast, Kubernetes als portable Laufzeitumgebung, eine Orchestrierung – typischerweise n8n – die Workflow, menschliche Freigaben und Logging verbindet, sowie eine Resident- und Kostenkontrolle. Wichtig sind auch die realistischen Grenzen: Patching, Modell-Updates, GPU-Ökonomie und die Frage, wann Mieten schlauer ist – bei niedrigem oder unvorhersehbarem Volumen oder wenn die absolute Frontier gebraucht wird. Ein KMU muss nicht eine ganze KI-Plattform betreiben; es kann einen einzigen Workload auf die eigene Schicht heben.

Die These lautet daher nicht „offene Gewichte sind umsonst". Sie lautet: Offene Gewichte machen Self-Hosting für die richtigen Workloads wirtschaftlich rational evaluierbar – und erst Self-Hosting wandelt ein günstiges Modell in eine souveräne, geprüfte, eigene Fähigkeit um.

Ein realistischer KMU-Fall: Ein Workload auf die eigene Schicht

Ein illustrativer DACH-Fall zeigt, wie ein einzelner Workload verschoben wird. Eine inhabergeführte DACH-Beratung mit rund 35 Mitarbeitenden, ohne dediziertes KI- oder Plattformteam, betreut wiederkehrende Kundenprojekte. Der relevante Workload: automatisierte Erstellung kundenfertiger Zusammenfassungen aus internen Recherche-Notizen – sensibel, hochvolumig und wiederkehrend, also ein idealer Kandidat für Self-Hosting.

Beteiligte Rollen: Lena, Head of Operations und Entscheidungseigentümerin (Budget und Datenverarbeitungsvereinbarung); Marco, IT-Leitung nebenberuflich ohne ML-Hintergrund; Daniela, Senior-Beraterin und fachliche Qualitätsfreigabe.

Das Datenvolumen ist realistisch dimensioniert: rund 120 Recherche-Notizen pro Woche, etwa 3.000 bis 4.000 Zusammenfassungen pro Monat und sechs bis acht Millionen Token monatlich. Auf einer gemieteten geschlossenen API lag die Ausgabe volatil zwischen etwa 1.800 und 2.400 Euro pro Monat – mit Spitzen an vollen Wochen und ohne feste Grenze.

Die Entscheidungspunkte folgen dem Plan/Unfold/Resonate-Rhythmus. In der Plan-Phase wird der Workload bewertet: hohe Sensitivität (Kundendaten) kombiniert mit hohem Volumen macht ihn zum Top-Kandidaten für die Verlagerung. Niedrigvolumige, ad-hoc Aufgaben bleiben bewusst auf einer günstigen API. In der Unfold-Phase wird ein offenes Gewichtsmodell der DeepSeek-V4-Klasse auf DACH-Kubernetes mit GPU-Kapazität dimensioniert auf die Spitze deployt und über n8n orchestriert. Menschliche Freigaben sind eingebaut: Jede Zusammenfassung läuft über Daniela zur Freigabe, bevor sie einen Kunden erreicht; eine Zweipersonenregel gilt für Modell- und Prompt-Änderungen, jede Änderung wird mit Begründung und Prüfendem geloggt; eine harte monatliche Kostenobergrenze mit Alerting schützt das Band, und ein Resident-Check läuft bei jeder Ausführung.

Der Ausstiegsschlüssel ist kein Marketingwort, sondern ein Artefakt: Modellgewichte und Prompts bleiben Eigentum des Unternehmens. Die Firma kann auf anderer Hardware neu hosten oder das Modell tauschen, ohne Anbieter-Abhängigkeit.

Das Ergebnis ist – ausdrücklich illustrativ, nicht gemessen – eine Verschiebung von einer volatilen Token-Rechnung in ein geplantes, fixes Infrastruktur-Band. Kundendaten bleiben im DACH-Raum. Jede erzeugte Zusammenfassung hat eine Eigentümerin und einen Audit-Trail. Planfold gibt dafür keinen konkreten Euro-Betrag als Ersparnis an – denn der echte Gewinn ist Kostenkontrolle, Datenhoheit und ein belastbarer Exit, keine garantierte Reduktion.

Die Planfold-Perspektive: KI als eigene, geprüfte Fähigkeit

Planfold rahmt KI-Adoption als Infrastruktur plus Governance, nicht als Modellauswahl. Die Argumentationslinie folgt einem klaren Betriebsschema: Plan heißt, KI-Ausgaben, Datenflüsse, Sensitivitätsklassen und Resident-Anforderungen zu auditieren und Workloads nach Volumen und Risiko zu bewerten. Unfold heißt, frontier-klasse offene Gewichte auf souveräner oder selbst betriebener Infrastruktur – Kubernetes, GPU-Kapazität wo der Workload es rechtfertigt – bereitzustellen, orchestriert über n8n mit Mensch-in-der-Schleife-Freigaben und geloggten Entscheidungen. Resonate heißt, mit planbaren Kosten, Datenresident-Nachweisen, einem Audit-Trail und einem Ausstiegsschlüssel zu operieren.

Die Behauptung ist betrieblich und nüchtern, nicht magisch: Offene Gewichte machen Ownership wirtschaftlich rational zu evaluieren – sie garantieren keine Ersparnis und brauchen weiterhin eine Betriebsschicht, die den meisten KMU fehlt. Planfold liefert diese Schicht (souveränes Hosting, Kubernetes-Betrieb, n8n-Orchestrierung, dokumentierte Freigabestandards); Planfold verkauft kein Modell, zertifiziert keine Compliance und gibt keine Rechtsberatung. Regulatorische Themen wie der EU AI Act werden als risikobasierter Rahmen mit Erwartungen an Dokumentation, Logging und menschliche Aufsicht behandelt – als „Architektur für Compliance-Bereitschaft", nicht als Rechts- oder Zertifizierungsversprechen.

Ein begrenzter 90-Tage-Startplan macht das konkret. Woche 1 bis 2: Audit. KI-Ausgaben und Datenflüsse kartieren, Workloads nach Sensitivität und Volumen bewerten, Datenklassen und Review-Rollen benennen. Woche 3 bis 4: Workload wählen. Einen sensiblen, hochvolumigen, wiederkehrenden Workload als ersten Self-Hosting-Kandidaten festlegen – nicht die ganze KI-Strategie auf einmal. Woche 5 bis 8: Pilot. Ein offenes Gewichtsmodell auf DACH-Kubernetes deployen, über n8n orchestrieren, mit harten Kostenobergrenzen, Resident-Check und menschlicher Freigabe. Woche 9 bis 12: Operieren. Kosten-, Resident- und Exit-Nachweise im laufenden Betrieb aufbauen und prüfen, ob der Pfad auf einen zweiten Workload skaliert.

Die Wirtschaftlichkeit offener KI-Modelle hat sich 2026 klar gewendet. Die Frage ist nicht mehr, ob offene Gewichte gut genug sind, sondern ob Ihr Unternehmen eine Betriebsschicht besitzt, die aus einem günstigen Modell eine souveräne, geprüfte Fähigkeit macht. Wenn nicht, ist das der erste Workload, den Planfold gemeinsam mit Ihnen verschiebt.

Planen. Entfalten. Souverän bleiben.