Lokale Sprachmodelle in der Produktion: was die Maschine darf
Ein Sprachmodell im Browser darf sich irren. Der Nutzer liest die Antwort, runzelt die Stirn, fragt nach. In der Produktion gibt es dieses Korrektiv nicht: Dort wird aus einer falschen Antwort ein falsch codiertes Etikett, ein falsch parametrierter Reader, ein Batch Ausschuss. Wer Sprachmodelle an Produktionsprozesse lässt, beantwortet deshalb besser zuerst eine Architekturfrage, und zwar nicht die, die meist gestellt wird.
Die falsche Frage: Wie gut ist das Modell?
Benchmarks sind die Währung der KI-Branche, und sie sind für den Werksboden fast irrelevant. Ein Modell mit 99 Prozent Genauigkeit klingt beeindruckend, produziert bei 10.000 Etiketten aber rechnerisch 100 fehlerhafte, wenn seine Ausgabe ungeprüft auf dem Chip landet. Kein seriöser Betrieb würde eine Maschine so abnehmen. Die Frage ist nicht, wie oft das Modell recht hat. Die Frage ist, was passiert, wenn es unrecht hat.
Damit wird aus der Güte-Frage eine Rechte-Frage: Was darf das Modell überhaupt?
Zwei Bahnen: verstehen und ausführen
Die Antwort, die wir für tragfähig halten, ist eine strikte Trennung in zwei Bahnen.
Die Datenbahn ist klassische, deterministische Software: geprüfte Rezepte, ein Builder für die Datenstrukturen, Schreiben mit vollständigem Rücklesen, Audit-Log. Hier existiert kein Sprachmodell. Jeder Schritt ist reproduzierbar und testbar wie jede andere Industriesoftware.
Das Sprachmodell sitzt davor und tut genau zwei Dinge: Es erkennt, welches Auftragsmuster vorliegt, und es zieht Werte aus dem Auftragstext. Entscheidend ist die Form der Ausgabe: kein Freitext, sondern strukturierte Felder, und jeder übernommene Wert trägt das wörtliche Zitat aus der Quelle als Beleg. Was nicht belegt ist, wird als Vorschlag markiert oder bleibt leer. Zusammengebaut wird der Auftrag von der Datenbahn, nie vom Modell.
Dazwischen steht der Mensch, mit einer Anzeige, die den Unterschied sichtbar macht: belegt, Vorschlag, fehlt. Und als letztes Gate eine Erststückprüfung, bei der das erste physische Teil zurückgelesen und im Klartext bestätigt wird, bevor die Serie läuft.
In einem Satz: Die KI darf nie schreiben. Wenn sich das Modell irrt, stirbt der Auftrag an der Validierung oder an der Erststückprüfung. Das Werkstück erreicht der Irrtum nicht.
Das Vokabular gibt es schon, nur woanders
Das Vokabular für dieses Prinzip stammt nicht aus dem Maschinenbau, sondern aus der IT-Sicherheit. Die OWASP Top 10 für LLM-Anwendungen führen „Improper Output Handling“ (Modellausgaben nie ungeprüft an nachgelagerte Systeme) und „Excessive Agency“ (Modelle ohne Not mit Ausführungsrechten ausstatten) als eigene Risikoklassen. NVIDIA führt dafür in seinen NeMo Guardrails eine eigene Rail-Klasse, „execution rails“, die Werkzeug- und Aktionsaufrufe kontrolliert. Und constrained decoding, das Erzwingen eines Schemas schon bei der Token-Auswahl, härtet die Extraktion zusätzlich.
Der nächste Verwandte in der Forschung ist das Fraunhofer-IOSB Projekt LLM4OPC, das Industriemaschinen per natürlicher Sprache ansprechbar macht. Dort führt ein Tool-Agent nach menschlicher Freigabe aus. Das Prinzip der zwei Bahnen ist die strengere Variante: Das Modell führt nicht nach Freigabe aus, es führt nie aus.
Warum lokal statt Cloud
Für den Betrieb auf dem Gerät statt in der Cloud sprechen zwei Argumente, ein technisches und ein praktisches.
Das technische: Constrained decoding braucht Zugriff auf die Token-Wahrscheinlichkeiten des Modells. Wer das Modell selbst betreibt, mit offenen Gewichten und lokal, kontrolliert diese Ebene selbst und kann die Kontrolle prüfen. Bei einer Cloud-API bleibt sie eine Zusicherung des Anbieters.
Das praktische: Datenhoheit ist in Deutschland kein Nischenthema. In der Bitkom-Erhebung vom März 2026 nennen 77 Prozent der Unternehmen Datenschutzanforderungen als Digitalisierungshemmnis, öfter als jedes andere; in einer separaten Bitkom-Befragung von 2025 gaben 70 Prozent an, Innovationspläne schon mindestens einmal wegen Datenschutzvorgaben gestoppt zu haben. Und seit NIS2 in Deutschland in Kraft ist, reichen betroffene Unternehmen ihre Sicherheitsanforderungen per Lieferantenfragebogen an Zulieferer weiter. Ein Gerät, dessen Sprachmodell lokal läuft und das ohne Cloud-Verbindung arbeitet, beantwortet die meisten dieser Fragen von selbst: Die Auftragsdaten verlassen das Haus nicht.
Dazu kommt eine europäische Dimension, die sich gerade dreht. Mit Projekten wie Soofi, den Sovereign Open Source Foundation Models, entstehen große offene Modelle, die vollständig in Deutschland entwickelt und trainiert werden: gefördert vom Bundesministerium für Wirtschaft und Energie, koordiniert vom KI Bundesverband; die erste Modellgeneration Soofi S steht vor dem offenen Release, angekündigt für dieses Jahr. Für Betreiber heißt das zweierlei. Es gibt absehbar eine reale europäische Alternative zu außereuropäischen Modellen. Und nur eine Architektur mit offenen Gewichten kann sie aufnehmen: Wer heute lokal mit austauschbaren Modellen baut, hält sich den Weg zu europäischen Modellen offen, ohne die Anwendung neu zu bauen. Ein Vertrag mit einer Cloud-API außerhalb Europas tut das Gegenteil. Souveränität entscheidet sich eben nicht nur beim Training, sondern jeden Tag dort, wo das Modell läuft und wohin die Auftragsdaten fließen.
Was der AI Act dazu sagt
Die europäische KI-Verordnung ist für dieses Architekturprinzip kein Hindernis, sondern ein Rückenwind. Nach dem Digital Omnibus vom Juli 2026 gelten die Hochrisikopflichten des Anhangs III erst ab Ende 2027, und Werksassistenz gehört ohnehin nicht zu den dort gelisteten Bereichen. Was heute schon gilt, ist die Transparenzpflicht aus Artikel 50: Der Bediener muss erkennen können, dass er mit einem KI-System interagiert. Das ist ein Hinweis in der Oberfläche, keine Hürde.
Ein Detail aus den Leitlinien der EU-Kommission hilft zusätzlich: Systeme, die ausschließlich auf von Menschen definierten Regeln beruhen, sind keine KI-Systeme im Sinne der Verordnung. Eine sauber getrennte deterministische Datenbahn bleibt damit das, was sie ist, nämlich klassische Industriesoftware. Reguliert wird genau die Komponente, die ohnehin nichts schreiben darf. Auch deshalb lohnt die Trennung.
Was das für Auto-ID bedeutet
In unserer Branche ist der Engpass selten die Hardware, sondern das Fachwissen im Bedienablauf. Wer eine RFID- oder NFC-Codierung aufsetzt, muss Speicherbänke und Lock-Modi kennen, ein EPC-Schema mit Partition und Filter wählen, Access- und Kill-Passwörter verwalten und bei NFC den NDEF Recordaufbau beherrschen. Die etablierte Etikettensoftware bildet genau dieses Wissen ab, in Dialogen für Fachleute.
Ein Sprachmodell ändert daran nichts, und das ist der Punkt: Das Codieren selbst ist deterministisch und bleibt es. Was sich ändern lässt, ist der Zugang. Wenn ein Produktionsmitarbeiter den Auftrag so beschreiben kann, wie er auf dem Auftragszettel steht, und ein System daraus belegte, prüfbare Vorschläge macht, die deterministischer Code ausführt, dann wird ein Fachprozess bedienbar, ohne dass Fachwissen im Kopf des Bedieners stecken muss. Es steckt dann in geprüften Rezepten, einer Chip-Datenbank und einem Prüfablauf.
Wir bauen nach diesem Muster derzeit ein Gerät für einen konkreten Codierprozess bei Etikettenherstellern. Mehr dazu an dieser Stelle, sobald es seinen Namen trägt. Wer das Thema vorher vertiefen will: Wir beraten herstellerunabhängig zu RFID- und NFC-Projekten, von der Chipauswahl bis zur Codierung — sprechen Sie uns an.
Quellen: OWASP Top 10 for LLM Applications 2025; NVIDIA NeMo Guardrails Dokumentation; Fraunhofer IOSB, Projekt LLM4OPC; Verordnung (EU) 2026/1744 (Digital Omnibus on AI); Bitkom-Presseinformationen vom 11.03.2026 und 23.05.2025; NIS2UmsuCG (BGBl. 2025 I Nr. 301); Projektinformationen Soofi, soofi.info (Stand 08/2026).
