Ich stolpere im Unternehmensalltag immer wieder über dieselbe merkwürdige Situation:
Alle wollen mehr KI nutzen. Nicht nur in Demos, sondern in Projekten, in denen am Ende tatsächlich weniger Handarbeit übrig bleibt.
Der Haken ist fast immer derselbe: Die spannenden Fälle liegen genau dort, wo man die Daten nicht einfach in ein großes Modell werfen darf. Interne Requirements, Architekturentscheidungen, Lieferantenkontext, Projektinformationen, technische Analysen. Material, bei dem ein gutes Modell enorm helfen könnte, das aber nicht ohne Weiteres zu OpenAI, Anthropic oder irgendeiner Cloud-Lösung darf.
Manchmal reicht selbst die übliche Corporate-Cloud-Variante nicht aus. Und dann steht man da: Die Organisation erwartet KI-Nutzung, aber die besten Werkzeuge dürfen an die relevantesten Daten nicht heran.
In der Praxis steht dann genau diese Frage im Raum: Wie nutzt man KI, wenn die besten Werkzeuge die relevanten Daten nicht sehen dürfen?
Lokale Modelle liegen in solchen Situationen nahe. Sie können auf eigener Hardware oder in einer freigegebenen Umgebung laufen, und die Daten bleiben dort, wo sie bleiben sollen. In der Praxis sind sie aber oft schwächer als die großen Cloud-Modelle, vor allem bei komplexen, schlecht geschnittenen Aufgaben.
Ich bin deshalb bei einem Muster gelandet, das keine gute Demo abgibt, im Alltag aber erstaunlich brauchbar ist:
Das starke Modell hilft beim Nachdenken über die Lösung. Die vertraulichen Daten bleiben dort, wo sie bleiben müssen. Das lokale Modell bekommt kleine, klar geschnittene Aufgaben. Und alles, was sich prüfen lässt, wird geprüft.
Daran ist nichts besonders Glamouröses. Vieles kennt man aus Security, Software Engineering und klassischer Systemarchitektur: Datenminimierung, Least Privilege, Validierung, Logging, Review-Prozesse. Interessant wird es, wenn man diese Prinzipien konsequent auf LLM-Nutzung überträgt.
Für mich haben sich dabei drei Dinge bewährt.
1. Erst das Problem sauber beschreiben
Am Anfang hilft eine ziemlich einfache Frage: Was ist hier eigentlich die Struktur des Problems, und was daran ist nur vertraulicher Kontext?
Ein starkes externes Modell braucht oft nur die Struktur des Problems. Projektname, Produkt, Lieferant oder interne Architektur können draußen bleiben.
Die vertraulichen Requirements bleiben außen vor. Im Prompt steht eine generische Beschreibung des Werkzeugs und seiner Regeln:
„Ich brauche ein generisches Tool, das tabellarische Datensätze zeilenweise verarbeitet. Bestimmte Eingabefelder sollen an ein lokales Modell übergeben werden. Die Antwort soll strukturiert zurückkommen, validiert und in Zielspalten geschrieben werden. Fehler sollen protokolliert werden. Nach mehreren Fehlversuchen soll ein Fall zur manuellen Prüfung markiert werden.“
Damit erzählt man dem externen Modell nicht das interne Problem, sondern nur die Form der Aufgabe.
Beim externen Modell landet also eine Art Problemvertrag: Datenformat, Schnittstellen, Grenzen, gewünschtes Verhalten, Fehlerbehandlung.
Die Beispiele können erfunden sein. Für die Struktur reicht oft eine Kaffeemaschine, ein Paketautomat oder ein Smart-Home-Gerät. Sie dürfen fachlich ganz woanders herkommen; entscheidend ist die ähnliche Struktur.
Das starke Modell kann dann beim Tooling helfen: Pipeline, Konfigurationsschema, Tests, Edge Cases, Validierungslogik, Fehlerszenarien.
Der vertrauliche Kontext kommt erst später lokal dazu.
Gute Abstraktion heißt hier: Das Modell versteht die Aufgabe, aber nicht den echten Fall dahinter.
2. Dem Modell nur ein kleines Paket geben
Der zweite Punkt betrifft die Laufzeit.
Lokal heißt nicht: Jetzt darf alles in den Prompt. Auch lokal gibt es Logs, Prompt-Historien, Fehlverhalten und schlechtere Ergebnisse, wenn zu viel irrelevanter Kontext im Spiel ist.
In einem meiner Fälle ging es um eine Batch-Verarbeitung von Requirements in Tabellenform. Die Konfiguration legte pro Zeile fest, welche Zellen sichtbar sind, welche Aufgabe das Modell bekommt, welche Antworten erlaubt sind, wohin das Ergebnis geschrieben wird und wann ein Fall zur manuellen Prüfung markiert wird.
Aus einer großen Datei wird so pro Zeile ein kleines Paket: diese Eingaben, diese Aufgabe, diese erlaubten Antworten, diese Retry-Regeln.
Wenn man dafür einen Namen braucht, könnte man diese Schicht „Context Governor“ nennen. Sie baut den Prompt und begrenzt gleichzeitig, was das Modell sehen, tun und zurückgeben darf.
Weniger Kontext ist hier kein Sparprogramm. Es schützt Daten, vermeidet Missverständnisse und macht Antworten leichter prüfbar. Das hilft bei Compliance und Qualität.
3. Modellantworten nicht sofort glauben
Ein LLM-Ergebnis ist erst einmal ein Vorschlag. Mehr nicht.
Gerade bei lokalen Modellen muss die Antwort geprüft werden: Passt das Format? Liegen die Werte im erlaubten Bereich? Ist das Ergebnis plausibel genug, um übernommen zu werden?
Wenn die Antwort nicht passt, bleibt das Ergebnis leer. Dann gibt es einen gezielten Retry, idealerweise mit Rückmeldung an das Modell. Nach einer begrenzten Anzahl von Versuchen wird der Fall markiert.
Diese markierten Fälle sind wichtig. Sie zeigen, wo eine Eingabe unklar ist, die Aufgabe zu groß geschnitten wurde, eine Taxonomie fehlt oder ein Mensch entscheiden muss.
Nach jedem Durchlauf sollte sichtbar sein, wie viel sauber verarbeitet wurde, wo Retries oder Abbrüche nötig waren und mit welcher Modell- und Konfigurationsversion gearbeitet wurde.
Ohne diese Sichtbarkeit hat man am Ende nur eine Blackbox mit Fortschrittsbalken.
Mit ihr wird daraus ein Verarbeitungsschritt, über den man vernünftig sprechen kann.
Am Ende ist es eher Systemarbeit als Magie
In regulierten Umgebungen entscheidet oft nicht das Modell allein, sondern die Architektur drumherum.
Welche Information darf an welcher Stelle in welchen Modellkontext? Welche Aufgabe ist klein genug für ein lokales Modell? Welche Teile löst man besser deterministisch? Wann ist ein Ergebnis gültig? Wann braucht es einen Menschen? Und wie merkt man, dass das System gerade Unsinn produziert?
Das LLM ist dann nicht die ganze Lösung. Es ist eine Komponente in einer Pipeline.
Alles, was man mit klassischer Logik, Parsern, Regeln, Mappings oder Validierung lösen kann, sollte man auch so lösen. Das Modell übernimmt genau die semantischen Teilaufgaben, für die klassische Logik zu starr ist.
Lokale Modelle werden nützlich, wenn die Architektur die Arbeit so zuschneidet, dass auch kleinere Modelle zuverlässig beitragen können.
Für Unternehmen wird KI dann interessant, wenn Teams beides schaffen: Informationsgrenzen ernst nehmen und trotzdem etwas bauen, das im Alltag Arbeit abnimmt.
Dafür braucht es einen sauberen Problemvertrag für den Entwurf, kontrollierte Kontexte in der Laufzeit und geprüfte Outputs, bevor irgendetwas produktiv wird.
Das ist weniger spektakulär als viele KI-Demos. Aber es ist näher an der Arbeit, die Unternehmen wirklich haben.