Lokale KI soll im Unternehmen nicht nur überzeugend antworten. Sie soll Informationen richtig zuordnen, bestehende Systeme einbeziehen und Arbeit nachvollziehbar vorbereiten. Genau darauf richten wir bei HDN – High-Definition Development & Networks GmbH aus Tirol die Weiterentwicklung von PaulinAI aus.
Mit HDN-Multiplexing und LLM-Extensions beschreiben wir einen Entwicklungsansatz: lokale Sprachmodelle und spezialisierte Erweiterungen gezielt zusammenarbeiten lassen, statt jede Aufgabe durch denselben umfangreichen Modellaufruf zu schicken.
Entwicklungsstand: Dieser Beitrag beschreibt unser Konzept und die vorgesehenen Prüfschritte. Er ist keine Ankündigung einer bereits allgemein verfügbaren Multiplexing-Funktion und kein Nachweis einer Überlegenheit gegenüber anderen KI-Systemen.
PaulinAI ist das Produkt – HDN entwickelt die Verbindung zur Praxis
Der Paulina Hub verbindet Unternehmenswissen, spezialisierte Agenten-Apps und kontrollierte Abläufe. P-Chat dient dem Gespräch und Wissenszugriff, P-Docs der Dokumentenverarbeitung und P-Workflow der Verbindung einzelner Arbeitsschritte. Welche Fähigkeiten im jeweiligen Betrieb eingesetzt werden, hängt von Installation, Anbindungen und Freigaben ab.
Unser nächster Entwicklungsschritt setzt an einer praktischen Frage an: Welche zusätzliche Verarbeitung braucht eine Aufgabe wirklich, damit ein brauchbares und überprüfbares Ergebnis entsteht?
Was wir unter HDN-Multiplexing verstehen
Die geplante HDN-Schicht soll Aufgaben verteilen, Teilergebnisse zusammenführen und entscheiden, welche offenen Punkte noch bearbeitet werden müssen. Dazu gehören die Auswahl geeigneter Modelle und Erweiterungen, die Berücksichtigung verfügbarer Ressourcen sowie Prüfungen gegen freigegebene Datenquellen.
Ein bereits richtig ausgelesener Dokumentteil sollte nicht bei jeder Korrektur vollständig neu verarbeitet werden müssen. Zugleich darf ein Zwischenergebnis nur wiederverwendet werden, wenn Quellenstand und Berechtigungen weiterhin passen. Diese Bedingungen sind Teil des Entwicklungsansatzes, keine optionale Abkürzung.
Das Ziel ist nicht, möglichst viele Modelle gleichzeitig rechnen zu lassen. Es ist, die passende Verarbeitung für den nächsten erforderlichen Schritt einzusetzen. Ob das im konkreten Prozess Zeit oder Rechenleistung spart, muss gemessen werden.
LLM-Extensions: gezielt trainierte Fähigkeiten statt eines neuen Grundmodells
Als LLM-Extensions bezeichnen wir gezielt trainierte, anwendungsspezifische Erweiterungen für Sprachmodelle. Kundenspezifische Extensions sind ausschließlich dem jeweiligen Kunden zugeordnet und bleiben unter seiner Kontrolle im lokalen Kunden-Hub.
Die eigene Entwicklungsarbeit liegt in der fachlichen Spezialisierung, den geeigneten Beispielen, der Prüfung und der sicheren Einbindung in PaulinAI. Dabei können bewährte technische Grundlagen genutzt werden; die konkrete Umsetzung ist noch auszuwählen.
Eine Extension ist außerdem kein universelles Zubehör für jedes Modell. Grundmodell, Version und Laufzeit müssen zusammenpassen.
Kundenspezifische Extensions bleiben im Kunden-Hub
Für die geplante HDN-Multiplexing-Schicht ist die Trennung der Kunden eine verbindliche Entwicklungsanforderung von Anfang an. Kundenspezifische Trainingsdaten und LLM-Extensions dürfen den jeweiligen lokalen Kunden-Hub nicht verlassen. Sie werden nicht für andere Kunden verwendet, geteilt oder zu einer gemeinsamen kundenübergreifenden Erweiterung zusammengeführt.
Eine kundenspezifische LLM-Extension darf nur geladen werden, wenn sie eindeutig dem richtigen Mandanten zugeordnet und mit einer gültigen Signatur seines Kunden-Hubs versehen ist. Vor dem Laden muss die Multiplexing-Schicht Mandantenbindung, Signatur und Freigabestatus prüfen. Fehlt die Zuordnung, gehört sie zu einem anderen Kunden, ist die Signatur ungültig oder die Freigabe widerrufen, muss das Laden abgelehnt werden. Es darf keinen Rückgriff auf die Extension eines anderen Kunden geben.
Ihr Wissen. Ihre kundenspezifischen Erweiterungen. Ihr lokaler Hub. Diese Trennung muss ebenso für Zwischenergebnisse und deren Wiederverwendung gelten. Signaturen ergänzen die Zugriffskontrolle, ersetzen sie aber nicht. Die Durchsetzung dieser Anforderungen ist vor einer Produktfreigabe technisch zu prüfen; eine bereits abgenommene Umsetzung wird hier nicht behauptet.
Wie wir solche Erweiterungen trainieren und prüfen wollen
Ausgangspunkt ist ein eng umrissener betrieblicher Vorgang. Dafür werden im jeweiligen Kunden-Hub geeignete, zur Nutzung freigegebene Beispiele mit fachlich bestätigten Soll-Ergebnissen zusammengestellt. Training und anschließende Nutzung der kundenspezifischen Erweiterung sollen lokal in diesem Hub erfolgen, ohne Trainingsdaten oder Extensions an andere Kunden weiterzugeben. Fehlende oder unklare Angaben gehören ausdrücklich dazu: Die KI soll eine Lücke erkennen, statt einen plausiblen Wert zu erfinden.
Vor einem Training prüfen wir, ob der Fehler tatsächlich beim Modell liegt. Eine fehlerhafte Texterkennung, falsche Datenquelle oder unpassende Werkzeugschnittstelle muss an dieser Stelle korrigiert werden. Training ist dafür kein Ersatz.
Erst anschließend wird eine Spezialisierung trainiert und mit dem unveränderten Ausgangsmodell verglichen. Ein zurückgehaltener Testsatz dient der Abschlussprüfung. Dokumente und nahezu identische Varianten dürfen nicht zugleich im Training und im Abschlusstest landen.
Neue Erweiterungen sollen versioniert und erst nach Prüfung freigegeben werden. Ungeprüftes Selbsttraining aus laufenden Kundengesprächen ist nicht das Ziel.
GPU für Modelle, CPU für geeignete Steuerungsaufgaben
Lokale Sprachmodelle benötigen weiterhin entsprechende Hardware. Eine Multiplexing-Schicht macht diesen Bedarf nicht überflüssig.
Auftragsverwaltung, Berechtigungsprüfungen, Zahlenabgleiche und viele Steuerungsregeln lassen sich auf der CPU ausführen. Modellgestützte Analyse oder Bewertung benötigt dagegen weiterhin Modellrechenleistung. Der geplante Vorteil liegt darin, unnötige Modellaufrufe zu vermeiden – nicht darin, große Sprachmodelle ohne Geschwindigkeitsverlust auf den Hauptprozessor zu verschieben.
Lokale Daten und menschliche Verantwortung bleiben zentral
Der Ansatz ist auf den lokalen Betrieb ausgerichtet. Vertrauliche Inhalte sollen nicht zur Verbesserung der Verarbeitung an externe Sprachmodelle geschickt werden müssen. Quellenrechte und Schutzrichtlinien müssen bei jedem Verarbeitungsschritt und jeder Wiederverwendung berücksichtigt werden.
Der Mensch legt fest, welche Systeme angebunden sind, welche Aufgaben automatisiert werden dürfen und wann eine Freigabe erforderlich ist. Ein Modellvorschlag ist keine Berechtigung zum Handeln.
Woran wir den Nutzen messen
Die wichtigste Frage lautet: Wie viele Vorgänge werden richtig bearbeitet, und welche Fehler bleiben unbemerkt? Erst danach betrachten wir Bearbeitungszeit, GPU-Aufwand und Wartezeiten bei mehreren Nutzern.
Verglichen werden sollen das Ausgangsmodell, ein fester Ablauf mit Spezialisierung und die geplante HDN-Steuerung – jeweils mit denselben Daten und Prüfmaßstäben. Bis solche Ergebnisse vorliegen, sind Leistungssteigerungen ein Entwicklungsziel, keine zugesicherte Produkteigenschaft.
Einen passenden Prozess gemeinsam auswählen
Für Unternehmen beginnt sinnvolle KI nicht mit dem größten Modell, sondern mit einem klaren Vorgang und überprüfbaren Ergebnissen. HDN verbindet dafür Softwareentwicklung, Systemanbindung und den lokalen KI-Ansatz von PaulinAI.
Mehr zu unserem Angebot unter KI & Prozessautomatisierung, zum Produkt auf paulinai.dev oder im persönlichen Gespräch mit HDN.
