Small Language Models auf EU-Boden: Die On-Prem-Agentenarchitektur, auf die der Mittelstand gewartet hat

Jedes Mal, wenn Ihr KI-Agent eine Rechnungsnummer extrahiert, eine Support-Mail klassifiziert oder eine Vorlage ausfüllt, bezahlen Sie ein Frontier-Modell für Arbeit, die ein viel kleineres Modell schneller, günstiger und ohne dass die Daten Deutschland je verlassen erledigen könnte. Die meisten Agentenarchitekturen schicken alles - triviale wie schwierige Schritte gleichermassen - an ein großes, in den USA gehostetes Modell, weil das 2023 das Einzige war, was zuverlässig funktionierte.

Diese Voreinstellung ist heute teuer und für viele Mittelständler schlicht unnötig. Gartner prognostiziert, dass Unternehmen bis 2027 kleine, aufgabenspezifische KI-Modelle dreimal häufiger einsetzen als universelle große Sprachmodelle¹. NVIDIA-Forscher argumentieren, dass kleine Modelle nicht nur eine Sparoption sind, sondern die richtige Architektur für Agenten². Der Grund ist einfach: Das meiste, was ein Agent den ganzen Tag tut, ist Routine, und Routinearbeit braucht kein Frontier-Gehirn.

Dieser Leitfaden richtet sich an CTOs, Operations-Verantwortliche oder Geschäftsführer, die agentische KI wollen, die kostenkontrolliert, DSGVO-sauber und souverän ist - ohne bei den schwierigen Problemen an Fähigkeit einzubüssen. Er erklärt das SLM-Router-Muster, bei dem kleine Modelle auf EU-Boden 80 bis 90 Prozent der Agentenschritte übernehmen und ein Cloud-Modell nur dann gerufen wird, wenn es wirklich gebraucht wird.

Die Frontier-Modell-Voreinstellung ist eine Steuer auf den Mittelstand

Die erste Welle der Unternehmens-KI hatte eine Architektur: jeden Prompt an das größte verfügbare Modell in einer US-Cloud schicken. Das funktionierte, und es war richtig, solange kleinere Modelle nicht leistungsfähig genug waren. Doch auf einen Produktionsagenten angewandt, der Tausende Schritte pro Tag ausführt, erhebt diese Voreinstellung heute drei getrennte Steuern.

• Eine Kostensteuer - Sie zahlen Frontier-Preise für triviale Arbeit. Der Betrieb eines Modells mit 3 bis 9 Milliarden Parametern ist 10- bis 30-mal günstiger pro Token als eines mit 70 bis 405 Milliarden, und die meisten Agentenschritte sind trivial⁴.
• Eine Latenzsteuer - Große Modelle sind langsamer und oft hinter schwerer Parallelisierung eingereiht. Für einen Agenten mit einem Dutzend interner Schritte pro Aufgabe summiert sich diese Latenz und macht Echtzeit-Workflows träge⁴.
• Eine Souveränitätssteuer - Jeder Aufruf schickt Unternehmensdaten an einen US-kontrollierten Anbieter. Nach dem CLOUD Act können US-Behörden diesen Anbieter zur Herausgabe zwingen, selbst wenn die Daten in einem EU-Rechenzentrum liegen¹⁴.
• Eine Lock-in-Steuer - Preise, Rate-Limits und Modellverhalten legt ein Anbieter fest, den Sie nicht kontrollieren. Eine Modellabkündigung oder Preisänderung kann Ihre Wirtschaftlichkeit über Nacht kippen.
• Eine Abhängigkeitssteuer - Fällt die Frontier-API aus, stehen Ihre Agenten still. Ein lokaler Standard hält den Normalpfad am Laufen, auch wenn die Cloud nicht erreichbar ist.

Nichts davon bedeutet, dass Frontier-Modelle schlecht sind. Es bedeutet, eines für alles zu nutzen ist, als würde man jeden Brief per Kurier verschicken, weil manche Briefe eilig sind. Die Lösung ist kein schlechteres Modell - es ist das richtige Modell für jeden Schritt. Das macht den Umstieg auf kleine Modelle zu einer Mittelstandsgeschichte und nicht zu einer Fußnote der Kostensenkung.

Was ein Small Language Model wirklich ist

„Klein“ ist relativ, und der Begriff wird lose verwendet. Für Agentenarbeit ist die brauchbare Definition praktisch statt akademisch: Ein Small Language Model ist eines, das wirtschaftlich innerhalb Ihres eigenen Perimeters läuft und schnell genug für einen einzelnen Agenten in Echtzeit antwortet.

• Grob unter 10 Milliarden Parametern - NVIDIA-Forscher ziehen die Grenze bei rund 10B, dem Punkt, unter dem ein Modell auf einen gängigen Beschleuniger passt und schnell genug für interaktiven Agenteneinsatz antwortet².
• Der Sweet Spot von 3 bis 9 Milliarden - Groß genug für zuverlässige Tool-Aufrufe und Reasoning über kurzen Kontext, klein genug, um günstig zu laufen und in Stunden nachtrainiert zu werden¹⁰.
• Aufgabenspezifisch, nicht dialogorientiert - Ein SLM ist ein Facharbeiter für einen definierten Job, kein allgemeiner Chat-Begleiter. Gartner beschreibt den Wandel als eine Verschiebung hin zu Modellen, die auf spezifische Funktionen oder Domänendaten feinjustiert sind¹.
• Betreibbar zu Ihren Bedingungen - Auf einer einzelnen GPU, auf einem Server, am Edge oder in einer EU-Private-Cloud. Der Punkt ist, dass Sie wählen, wo es läuft.
• Günstig zu spezialisieren - Das Fine-Tuning eines kleinen Modells auf Ihre eigenen Beispiele dauert wenige GPU-Stunden statt Tage oder Wochen⁴.

Die Modelle, die das real gemacht haben

Das ist nicht theoretisch. Eine Welle leistungsfähiger kleiner Modelle erschien 2024 und 2025, und unabhängige Benchmarks bestätigen, dass sie genau bei den Aufgaben bestehen, die Agenten brauchen.

Warum kleine Modelle, und warum jetzt

Der Grund für kleine Modelle ist nicht, dass sie im Trend liegen. Es ist, dass drei unabhängige Kräfte gleichzeitig zusammenkamen, und jede weist für den Mittelstand in dieselbe Richtung.

1. Die Fähigkeit hat die Schwelle überschritten - Kleine Modelle bewältigen 2025 die häufigen Agentenschritte, die 2023 an kleinen Modellen scheiterten: Intent-Erkennung, Entitätsextraktion, striktes Tool-Calling und vorlagenbasierte Generierung⁵. Die Lücke, die alle zu Frontier-Modellen zwang, hat sich für Routinearbeit geschlossen.
2. Die Ökonomie hat sich umgekehrt - Der Betrieb eines kleinen Modells ist 10- bis 30-mal günstiger pro Token, und das Fine-Tuning kostet GPU-Stunden statt Wochen⁴. Für hochfrequente Agentenschritte macht das aus KI von einem gefürchteten variablen Kostenblock einen planbaren.
3. Die Analysten haben es benannt - Gartner erwartet, dass kleine aufgabenspezifische Modelle die Nutzung universeller LLMs bis 2027 im Verhältnis 3 zu 1 übertreffen¹, und rechnet separat damit, dass die Frontier-Inferenzkosten bis 2030 um über 90 Prozent fallen, was den gesamten Markt Richtung Effizienz drückt⁶.
4. Souveränität wurde strategisch - Die EU baut mit dem Cloud and AI Development Act verbindliche Souveränitätsrahmen auf¹⁵, und deutsche Firmen reduzieren aktiv ihre Abhängigkeit von US-kontrollierten Clouds²⁰. On-Prem-Kleinmodelle passen nativ in diese Richtung.
5. Das Tooling ist gereift - Agenten-Frameworks liefern heute einen lokalen Modell-Router und eine Cloud-Eskalationsspur als erstklassiges Muster mit, sodass die Architektur nicht mehr von Grund auf erfunden werden muss⁸.

Für den Mittelstand ist das Timing besonders wichtig. Viele mittelständische Firmen hielten sich bei der ersten KI-Welle zurück, gerade weil das Senden von Prozessdaten in eine US-Cloud sich falsch anfühlte und weil die laufenden Kosten unvorhersehbar waren. Der Umstieg auf kleine Modelle beseitigt beide Einwände auf einmal. Unser Beitrag zum souveränen Company Brain behandelt den breiteren Fall, die Wissensschicht unter EU-Jurisdiktion zu halten.

Das SLM-Router-Muster, erklärt

Die Architektur, die das möglich macht, ist nicht „ersetze dein großes Modell durch ein kleines“. Es ist ein Router, der Modelle als Flotte behandelt und jeden Schritt an das günstigste Modell schickt, das ihn gut erledigen kann. Denken Sie an Triage für Agentenarbeit.

Wie eine einzelne Aufgabe hindurchfliesst

1. Die Aufgabe trifft ein - Eine Kunden-E-Mail kommt herein, eine Rechnung landet, eine Serviceanfrage wird erfasst. Der Agent zerlegt sie in Schritte.
2. Der Router prüft jeden Schritt - Ein leichtgewichtiger Klassifikator entscheidet, ob dieser Schritt Routine ist (ein Feld extrahieren, eine Kategorie klassifizieren, ein Tool aufrufen) oder schwierig (offenes Reasoning, mehrdeutiges Urteil, langes unbekanntes Dokument).
3. Routineschritte bleiben lokal - Das kleine Modell innerhalb Ihres Perimeters erledigt sie in Millisekunden, für den Bruchteil eines Cents, ohne dass Daten das Gebäude verlassen.
4. Schwierige Schritte eskalieren - Der Router schickt den wirklich schwierigen Schritt über eine konfigurierbare Spur an ein größeres Modell, das je nach Ihren Datenregeln auf ein EU-gehostetes großes Modell oder ein globales Frontier-Modell zeigen kann.
5. Alles wird protokolliert - Welches Modell welchen Schritt bearbeitet hat, warum eskaliert wurde und wie sicher es war. Dieses Protokoll ist zugleich Ihr Audit-Trail und Ihr Fine-Tuning-Datensatz.

Warum das eine Ein-Modell-Architektur schlägt

• Kosten folgen der Schwierigkeit - Sie zahlen Frontier-Preise nur für Frontier-schwere Schritte, nicht für das Extrahieren eines Datums aus einem PDF.
• Latenz sinkt im Normalfall - Die 80 bis 90 Prozent der Schritte, die lokal bleiben, kommen in Millisekunden zurück, statt auf ein großes entferntes Modell zu warten.
• Datenminimierung ist eingebaut - Die meisten Schritte senden nie Daten aus Ihrem Perimeter, sodass die Eskalationsspur der einzige Ort ist, an dem Sie Übermittlungen prüfen.
• Die Eskalationsspur ist eine Richtlinie, kein Umbau - Sie ändern per Konfiguration, welches Modell schwierige Schritte bearbeitet, oder verbieten die Eskalation für bestimmte Datenklassen.
• Sie degradiert würdevoll - Fällt die Frontier-API aus, läuft die Routinearbeit auf dem lokalen Modell weiter, und nur die schwierigen Ausnahmen stauen sich.

Das ist das agentische Geschwister eines Musters, das wir in der Multi-Agenten-Orchestrierung behandeln: statt eines großen Generalisten ein koordiniertes Set richtig dimensionierter Arbeiter mit klaren Übergaben. Der Router ist der Übergabemechanismus, und das kleine Modell ist der Standard-Arbeiter.

Wo kleine Modelle gewinnen, und wo Sie weiterhin ein Frontier-Modell brauchen

Ehrlich über die Grenze zu sein macht diese Architektur vertrauenswürdig. Kleine Modelle sind kein universeller Ersatz, und das Gegenteil zu behaupten ist der Weg, auf dem Projekte scheitern. Hier ist die Aufteilung, basierend auf den Aufgabenkategorien, die NVIDIA-Forscher identifizieren⁵.

Aufgaben, die ein kleines Modell gut erledigt

• Intent-Erkennung - Entscheiden, worum es in einer Kunden-E-Mail oder Anfrage tatsächlich geht, damit sie korrekt geleitet wird.
• Entitäts- und Feldextraktion - Rechnungsnummern, Datumsangaben, Teilenummern und Beträge aus Dokumenten und Nachrichten herausziehen.
• Klassifikation - Tickets, Dokumente oder Transaktionen in bekannte Kategorien einsortieren.
• Striktes Tool-Calling - Wohlgeformte Aufrufe an Ihr ERP, CRM oder Ihre internen APIs mit den richtigen Argumenten erzeugen.
• Vorlagenbasierte Generierung - Eine Standardantwort, ein Status-Update oder eine strukturierte Zusammenfassung nach bekanntem Muster entwerfen.
• Reasoning über kurzen Kontext - Kleine logische Schritte über eine begrenzte Informationsmenge.
• Boilerplate-Code - Routineskripte und Transformationen, die vertrauten Mustern folgen.

Aufgaben, die weiterhin auf ein Frontier-Modell gehören

• Lange, unstrukturierte, unbekannte Probleme - Offene Situationen, die sich nicht vorab in klare Schritte zerlegen lassen⁵.
• Sehr lange Dokumente - Reasoning, das einen großen, komplexen Kontext auf einmal zusammenhalten muss.
• Neuartige Urteilsentscheidungen - Mehrdeutige Entscheidungen mit echten Konsequenzen, bei denen die Breite des Weltwissens zählt.
• Freie Kundenkonversation - Wo allgemeine dialogische Gewandtheit das Produkt ist und nicht Mittel zum Zweck.
• Komplexe fachübergreifende Synthese - Viele unverbundene Felder zu einer kohärenten Antwort zusammenführen.

Der Kernpunkt ist, dass dies eine Entscheidung pro Schritt ist, nicht pro Projekt. Derselbe Agent nutzt ein kleines Modell für die Feldextraktion und ein Frontier-Modell für den einen Absatz echten Reasonings - in derselben Aufgabe. Sie wählen kein Modell, Sie wählen eine Richtlinie.

Die Souveränitäts-Dividende: Warum On-Prem das DSGVO-Gespräch verändert

Das stärkste Argument für kleine Modelle im Mittelstand sind nicht die Kosten. Es ist, dass der Betrieb des Standardmodells innerhalb Ihres Perimeters die schwierigste Compliance-Frage - die internationale Datenübermittlung - für den Großteil Ihrer Arbeitslast zu einer Nicht-Frage macht.

Was der CLOUD Act tatsächlich bedeutet

• Standort ist nicht Jurisdiktion - Der US CLOUD Act verpflichtet US-ansässige Anbieter zur Herausgabe von Daten in ihrem Besitz oder unter ihrer Kontrolle, selbst wenn diese in einem EU-Rechenzentrum liegen¹⁴.
• Verträge lösen es nicht vollständig - Eine leitende Microsoft-Führungskraft sagte dem französischen Senat 2025, keine vertragliche Regelung könne garantieren, dass französische Daten des öffentlichen Sektors niemals US-Behörden erreichen¹⁷.
• DSGVO-Übermittlungsregeln sind streng - Personenbezogene Daten an einen US-kontrollierten Verarbeiter zu senden erfordert eine Übermittlungsgrundlage und eine Einzelfall-Risikoprüfung, die viele Datenschutzbeauftragte lieber vermeiden¹⁸.
• Die EU legislaturiert Richtung Souveränität - Der Cloud and AI Development Act legt verbindliche Souveränitäts-Sicherungsstufen fest, einschließlich Kriterien zu EU-Eigentum und -Kontrolle für die höchste Stufe¹⁵.
• Deutschland handelt danach - Deutsche und französische Regierungsspitzen beriefen im November 2025 einen europäischen Digitalsouveränitäts-Gipfel ein, ein Signal, dass dies nun Politik ist, nicht Präferenz²⁰.

Drei Betriebstopologien

Souveränität ist ein Spektrum, kein Schalter. Die meisten Mittelständler landen je nach Datensensibilität und Bereitschaft, Hardware zu besitzen, bei einer von drei Topologien.

In allen drei Fällen ist die Eskalationsspur der Ort, an dem Sie Ihre Governance bündeln. Sie entscheiden pro Datenklasse, ob ein schwieriger Schritt den Perimeter überhaupt verlassen darf, und wenn ja, zu welchem Modell und mit welcher Schwärzung. Das ist eine Richtlinie, die Sie einem Datenschutzbeauftragten und einem Betriebsrat mit Überzeugung vorlegen können.

Das Kostenmodell: Warum sich die Ersparnis kumuliert

Die Ersparnis von 10 bis 30 pro Token ist nur die halbe Geschichte. Die andere Hälfte ist, dass die Schritte, die Sie auf das kleine Modell verlagern, die hochfrequenten sind - die Ersparnis landet also dort, wo das Volumen ist.

• Kosten pro Token - Ein Modell mit 3 bis 9 Milliarden Parametern ist 10- bis 30-mal günstiger pro Token als eines mit 70 bis 405 Milliarden⁴.
• Volumengewichtung - Routineschritte sind zugleich die häufigen Schritte. 80 bis 90 Prozent der Aufrufe auf das günstige Modell zu verlagern bedeutet, dass die Ersparnis auf den Großteil Ihrer Nutzung wirkt, nicht auf einen Ausschnitt².
• Fine-Tuning-Kosten - Ein kleines Modell zu spezialisieren sind GPU-Stunden, nicht Wochen, sodass die Verbesserung der Genauigkeit günstig und kontinuierlich ist⁴.
• Planbarkeit - Auf eigener oder reservierter Hardware sind die Kosten weitgehend feste Kapazität statt eines nutzungsabhängigen Zählers, der mit dem Verbrauch nach oben schnellt.
• Eskalation als steuerbare Größe - Ihre einzigen Frontier-Kosten fallen auf der Eskalationsspur an, die Sie messen und deckeln können.

Der 90-Tage-Fahrplan zur Einführung

Sie müssen nicht das ganze Meer auskochen. Eine fokussierte Einführung bringt einen hochvolumigen Workflow in etwa 90 Tagen von reiner Cloud auf eine SLM-Router-Architektur.

Phase 1: Kartieren und klassifizieren (Wochen 1-4)

1. Woche 1: Workflow wählen - Wählen Sie einen hochfrequenten, gut abgegrenzten Prozess: Rechnungseingang, Ticket-Triage, Auftragsbearbeitung. Volumen macht die Ersparnis real.
2. Woche 2: In Schritte zerlegen - Zerlegen Sie den Workflow in seine atomaren Schritte und markieren Sie jeden als Routine oder schwierig. Das ist der wichtigste Schritt überhaupt; er definiert, was lokal bleibt.
3. Woche 3: Datenregeln festlegen - Entscheiden Sie mit Ihrem Datenschutzbeauftragten, welche Datenklassen eskalieren dürfen, zu welchem Modell und mit welcher Schwärzung. Das wird die Eskalationsrichtlinie.
4. Woche 4: Topologie wählen - On-Prem, EU-Private-Cloud oder Hybrid, je nach Sensibilität und Volumen. Wählen Sie Kandidaten-Kleinmodelle für die Routineschritte.

Phase 2: Den Router bauen (Wochen 5-8)

5. Woche 5-6: Lokales Modell aufsetzen - Setzen Sie das gewählte SLM in Ihrer Topologie auf, verbunden mit den Tools, die es aufrufen muss. Verdrahten Sie den Router und die Eskalationsspur.
6. Woche 7: Auf Ihre Beispiele feinjustieren - Füttern Sie das kleine Modell mit echten Beispielen aus dem Workflow. Hier wird aus einem generischen Kleinmodell ein Spezialist, der ein generisches großes Modell schlägt.
7. Woche 8: Konfidenzschwellen setzen - Justieren Sie, wann der Router eskaliert. Starten Sie konservativ (mehr eskalieren) und ziehen Sie an, sobald sich das lokale Modell bewährt.

Phase 3: Betreiben und nachziehen (Wochen 9-12)

9. Woche 9: Schattenbetrieb - Lassen Sie den Router parallel zum bestehenden Prozess laufen. Vergleichen Sie Ausgaben, messen Sie die lokale Bearbeitungsrate und die Eskalationsrate.
10. Woche 10-11: Live auf einem Ausschnitt - Verlagern Sie echtes Volumen für ein Team oder einen Dokumenttyp auf den Router. Beobachten Sie Kosten, Latenz und das Eskalationsprotokoll.
11. Woche 12: Messen und ausweiten - Berichten Sie den lokalen Bearbeitungsanteil, die Kosten pro Schritt und die Latenz gegen die reine Cloud-Basislinie. Nutzen Sie das Eskalationsprotokoll, um das nächste Fine-Tuning zu planen.

Wie Superkind passt

Superkind baut maßgeschneiderte KI-Agenten für KMU und Unternehmen, und das SLM-Router-Muster ist, wie wir diese Agenten günstig, schnell und souverän halten. Der Ansatz ist prozess-zuerst: Wir starten von Ihrem Workflow und Ihren Datenregeln und wählen dann den Modellmix, der passt - nicht andersherum.

• Modell-Routing auf Schrittebene - Wir zerlegen Ihren Workflow und leiten jeden Schritt an das kleinste Modell, das ihn gut erledigt, mit einer konfigurierbaren Eskalationsspur für die schwierigen Ausnahmen.
• Läuft dort, wo Ihre Daten bleiben müssen - On-Premise, in einer EU-Private-Cloud oder hybrid. Sie wählen die Topologie; das Standardmodell bleibt innerhalb Ihres Perimeters.
• Feinjustiert auf Ihre Arbeit - Wir spezialisieren das kleine Modell auf Ihre Rechnungen, Tickets oder Dokumente, sodass es ein generisches großes Modell bei Ihren spezifischen Aufgaben schlägt.
• Sitzt auf Ihrem Stack - Agenten verbinden sich über APIs mit Ihrem bestehenden ERP, CRM, MES und DMS. Kein Rip-and-Replace, nichts Neues für Ihr Team zu lernen.
• Eskalation als gesteuerte Richtlinie - Welche Daten den Perimeter verlassen dürfen, zu welchem Modell, mit welcher Schwärzung, ist Konfiguration, die Ihr Datenschutzbeauftragter prüfen kann - kein in einem Anbieterprodukt vergrabener Code.
• Vollständige Protokollierung und Audit-Trail - Jeder Schritt erfasst, welches Modell ihn bearbeitet hat, die Konfidenz und den Grund jeder Eskalation. Das ist Ihr Compliance-Nachweis und Ihr Fine-Tuning-Datensatz.
• Ergebnisse, keine Lizenzen - Die Preisgestaltung ist pro Anwendungsfall gegen messbare Ergebnisse (lokale Bearbeitungsrate, Kosten pro Schritt, Latenz), nicht pro Platz.
• Kontinuierliche Verbesserung - Wir nutzen das Eskalationsprotokoll, um das kleine Modell laufend nachzutrainieren, sodass die lokale Bearbeitungsrate steigt und die Kosten mit der Zeit fallen.

Wenn Sie SAP oder ein Legacy-ERP betreiben, verbindet sich der Router genauso wie ein Agent heute - siehe unseren Leitfaden dazu, wo die Grenze zwischen einem ERP und einem KI-Agenten verläuft, für die Frage, wie die Reasoning-Schicht über dem System of Record sitzt.

Entscheidungsrahmen: Ist der SLM-Router das Richtige für Sie?

Das Muster ist mächtig, aber nicht universell. So erkennen Sie, ob es jetzt zu Ihrer Situation passt oder ob Sie warten sollten.

Häufig gestellte Fragen

Henri Jung

Mitgründer von Superkind, wo er KMU und Unternehmen dabei hilft, maßgeschneiderte KI-Agenten einzusetzen, die wirklich zur Arbeitsweise ihrer Teams passen. Henri brennt dafür, die Lücke zwischen dem, was KI kann, und dem Wert, den sie in echten Unternehmen schafft, zu schließen. Er ist überzeugt, dass der Mittelstand alles hat, um bei KI führend zu sein - er braucht nur den richtigen Ansatz.