Die Veröffentlichung von LFM3 durch Liquid AI gibt Plattformteams eine weitere Möglichkeit, spezialisierte Agenten auf eigener Hardware zu betreiben. Für die Governance hat das eine praktische Folge: Jede ausgerollte Variante braucht eine verantwortliche Person, eine Lizenzentscheidung und eine Dokumentation der Tools, die sie verwenden darf. Dass die Inferenz auf ein Gerät verlagert wird, legt für sich genommen noch nicht fest, wozu der daraus entstehende Agent autorisiert ist.
Liquid AI kündigte LFM3 am 27. Oktober 2026 an und beschrieb sechs kompakte Modelle für Text, Bild, Audio, kombinierte Modalitäten und strukturierte Entscheidungen. Nach Angaben des Unternehmens lassen sich die Modelle per lokalem Fine-Tuning spezialisieren. Dabei handelt es sich um Herstellerangaben; sie belegen nicht, dass die Modelle für eine bestimmte Unternehmensaufgabe geeignet sind.
Ein Release mit einsatzspezifischen Grenzen
Die Model Card zu LFM3-1.7B beschreibt ein Textmodell für lokale Agenten, Tool-Aufrufe und strukturierte Ausgaben mit einem Kontextfenster von 256K Tokens. Für wissensintensive Aufgaben empfiehlt sie Retrieval oder Suche und rät von agentischem Programmieren sowie komplexen mehrstufigen Schlussfolgerungen ab. Diese Grenzen sollten auch dann Teil eines Evaluierungsplans bleiben, wenn ein ausgewählter Benchmark vielversprechend aussieht.
Offen veröffentlichte Gewichte kommen ebenfalls mit Bedingungen. Die veröffentlichte LFM Open License v1.0 definiert einen Schwellenwert anhand eines Jahresumsatzes von 10 Millionen US-Dollar oder mehr. Abschnitt 5 knüpft die Bedingungen für die kommerzielle Nutzung durch Sie oder Ihre Rechtseinheit an diesen Schwellenwert. Teams sollten die konkreten Bedingungen für ihren geplanten Einsatz prüfen lassen, statt das Release pauschal als uneingeschränkt zu kennzeichnen oder von einer Apache-2.0-Freigabe auszugehen. Eine Freigabe für ein Pilotprojekt sollte die berücksichtigte Lizenzversion dokumentieren.
Lokale Bereitstellung verändert die Anforderungen an das Inventar
Nach Einschätzung von Maetra machen spezialisierte lokale Modelle die Identität einer Bereitstellung detaillierter. Der Name einer Modellfamilie ist zu grob, um zu erklären, welches Artefakt eine Aktion ausgelöst hat. Ein Text-Checkpoint, eine quantisierte Kopie und ein per Fine-Tuning angepasstes Derivat können zwar derselben Linie entstammen, sich bei derselben Anfrage aber unterschiedlich verhalten.
Für einen hypothetischen Assistenten zur Rechnungsweiterleitung sollte ein brauchbarer Datensatz den ursprünglichen Checkpoint, das lokale Artefakt, die verantwortliche Stelle für den Fine-Tuning-Datensatz, den Runtime-Build und das Evaluierungsergebnis festhalten. Er sollte außerdem die Buchhaltungstools benennen, die dem Assistenten zur Verfügung stehen, sowie die Daten, auf die diese Tools zugreifen können. Das sind vorgeschlagene Inventarfelder, keine Aussagen über eine Kundenbereitstellung.
Verknüpfen Sie den Agenteneintrag mit dem Artefakt, das in den Tests verwendet wurde. Wenn ein Entwickler eine neue Quantisierung oder eine andere Laufzeitumgebung einsetzt, sollte die vorherige Konfiguration erhalten bleiben, und es ist festzulegen, welche Tests wiederholt werden müssen. So entsteht eine prüffähige Änderungshistorie, ohne dass jedes Experiment zu einem Produktiv-Release werden muss.
Prüfen Sie die Laufzeitumgebung, die tatsächlich ausgeliefert wird
Die Kompatibilität zum Start verdient eine eigene Prüfung, getrennt von der Modellankündigung. Webdigas öffentliche Tests lokaler Laufzeitumgebungen vom 27. Oktober beschreiben Unterstützung, die je nach Betriebssystem, Runtime-Build und Modalität variierte. Das sind unabhängige Hinweise zur Integration, aber keine unabhängige Bestätigung der von Liquid AI genannten Modell-Benchmarks.
Eine Bereitstellungsprüfung sollte deshalb die exakte Softwareversion und das Zielgerät festhalten. Testen Sie die Eingabetypen, den Parser für Tool-Aufrufe und das Ausgabeformat, die der Workflow benötigt. Wenn die Unterstützung von einem Release Candidate oder einem nicht getaggten Build abhängt, sollte diese Abhängigkeit ausdrücklich dokumentiert und entschieden werden, wie Updates kontrolliert werden.
Übertragen Sie eine erfolgreiche Desktop-Demonstration nicht vorschnell auf eine allgemeine Bereitstellungsaussage. Ein Test sollte sich in der vorgesehenen verwalteten Umgebung reproduzieren lassen, mit derselben Laufzeitumgebung, denselben Berechtigungen und denselben Netzwerkbedingungen. Wenn der Agent einen externen Suchdienst oder eine Business-API benötigt, sollte diese Abhängigkeit bei der Dokumentation mitgeführt werden, wohin Daten gelangen können.
Modellausgabe und Ausführungsbefugnis trennen
Ein Modell kann einen Tool-Aufruf vorschlagen, während die Anwendung entscheidet, ob und wie er ausgeführt wird. An dieser Anwendungsgrenze sollte ein Team die freigegebene Aufgabe, die zulässigen Tools und jede erforderliche menschliche Prüfung durchsetzen. Weder die Modellgröße noch der physische Ausführungsort ersetzen diese Kontrollen.
Im Rechnungsbeispiel kann die Klassifizierung lokal laufen, während die Ausführung von Zahlungen auf einen separaten autorisierten Workflow beschränkt bleibt. Die Dokumentation sollte erklären, welche Komponente welche Entscheidung trifft und welche Nachweise die beabsichtigte Wirkung bestätigen. Das ist eine Architektur-Empfehlung, keine Aussage darüber, dass LFM3 Zahlungskontrollen bereitstellt.
Bevor ein spezialisiertes Modell an Geschäftstools angebunden wird, sollten uneindeutige Eingaben, fehlende Felder und Anfragen außerhalb der zugewiesenen Aufgabe getestet werden. Legen Sie fest, wann die Anwendung stoppen, um Klärung bitten oder den Fall an eine Person weiterleiten soll. Nutzen Sie die Einschränkungen der Model Card, um realistische Einsatzaufgaben auszuwählen, statt sie hinter einem allgemeinen Agentenlabel zu verdecken.
Einen klar abgegrenzten Evaluierungsnachweis aufbauen
Ein brauchbares Pilotprojekt kann mit einer wiederkehrenden Einzelaufgabe und einer klaren Abnahmebedingung beginnen:
- Benennen Sie die Aufgabe, die verantwortliche Person und die zulässigen externen Auswirkungen.
- Dokumentieren Sie das exakte Modellartefakt, die Lizenz und die Konfiguration der Laufzeitumgebung.
- Evaluieren Sie repräsentative Fälle, einschließlich Fehlschlägen und unsicheren Ausgaben.
- Testen Sie die Anwendungskontrollen rund um Tool-Ausführung und Datenzugriff.
- Bewahren Sie das Ergebnis auf und legen Sie fest, welche Änderungen es ungültig machen.
Die Klassifizierung von Agenten nach Autonomie, Datenzugriff und Risiko bietet einen verwandten Ansatz, um den Workflow zu beschreiben. Maetra Discover unterstützt Inventarisierung und Fähigkeitsmapping; Task Guard unterstützt Aufgabenabgleich und Prüfungen externer Wirkungen. Beides belegt nicht, dass eine bestimmte LFM3-Bereitstellung zuverlässig oder regelkonform ist.
Beginnen Sie mit einer eng gefassten Evaluierung, deren Ergebnis ein anderer Ingenieur reproduzieren kann. Die Dokumentation von Maetra kann dabei helfen, das Agenteninventar mit Aufgaben- und Laufzeitkontrollen zu verbinden, wenn der Workflow in den operativen Betrieb übergeht.
Quellen
- Liquid AI: Introducing LFM3, 27. Oktober 2026. Primäre Release-Ankündigung und Herstellerangaben.
- Liquid AI: LFM3-1.7B model card. Primäre Hinweise zum vorgesehenen Einsatz und zu Einschränkungen.
- LFM Open License v1.0. Primärer Lizenztext.
- Webdiga: How to run LFM3 locally, 27. Oktober 2026. Unabhängige Prüfungen der Laufzeitumgebung zum Starttag, keine Reproduktion der Modell-Benchmarks.